Jotting this one down really quick...
If you send a plain text email by assigning the SMTP.EmailBodyText context property on a message (keep it short... the property limit is 255 chars!), you MUST set EmailBodyTextCharset on that message, or you will receive a very unhelpful "unknown error" from the SMTP server. Charset is a valid IANA charset string, like "utf-8." A list of charsets are here http://www.iana.org/assignments/character-sets (note that I have no idea which of these character sets may or may not work within the context of a BizTalk orchestration/send.
Monday, March 24, 2008
Friday, March 7, 2008
Base64Binary, XLANG, arrays, and you
The XML type xs:base64Binary maps to a byte array in the .NET framework. This is simple enough to manage in most any .NET application you can think of, but in BizTalk orchestrations, it can be a little more complicated.
The short story is this: BizTalk orchestrations are based on XLANG technology, which cannot comprehend arrays. This is why you can't create an orchestration variable of an array type. If you promote an xs:base64Binary field and try to use it anywhere in an orchestration, the framework will try to deal with it as a byte array and the orchestration will fail, even if you simply use an expression shape to hand it to a .NET method that is expecting a byte array as a parameter.
The solution is to access the field with an xpath that's wrapped in the "string()" xpath function, and manipulate it as a string variable. Maybe this means that you'll hand it to a .NET method and turn it back into a byte array. You can do whatever you want with it, except treat it as a byte array within an orchestration.
The short story is this: BizTalk orchestrations are based on XLANG technology, which cannot comprehend arrays. This is why you can't create an orchestration variable of an array type. If you promote an xs:base64Binary field and try to use it anywhere in an orchestration, the framework will try to deal with it as a byte array and the orchestration will fail, even if you simply use an expression shape to hand it to a .NET method that is expecting a byte array as a parameter.
The solution is to access the field with an xpath that's wrapped in the "string()" xpath function, and manipulate it as a string variable. Maybe this means that you'll hand it to a .NET method and turn it back into a byte array. You can do whatever you want with it, except treat it as a byte array within an orchestration.
Don't use XMLTransmit on SOAP Ports
This one's short and simple: Don't use the XMLTransmit pipeline (or any other pipeline with an XML assembler) on the send side of a SOAP port.
The SOAP adapter receives the message to send in pieces, and knows how to assemble it. The XML assembler (which really only serves a few purposes, none of which are very important, and all of which are easy to achieve via other methods or workarounds) can get confused by these pieces and will fail.
Using the XMLReceive pipeline (or any pipeline with an XML disassembler) on the receive side of a SOAP port is fine, because the adapter has already delivered the full XML message.
The SOAP adapter receives the message to send in pieces, and knows how to assemble it. The XML assembler (which really only serves a few purposes, none of which are very important, and all of which are easy to achieve via other methods or workarounds) can get confused by these pieces and will fail.
Using the XMLReceive pipeline (or any pipeline with an XML disassembler) on the receive side of a SOAP port is fine, because the adapter has already delivered the full XML message.
Subscribe to:
Posts (Atom)