If we want to send message through a SMTP Port with attachments and we want to set the attachment's filename, we have to set MIME.FileName property.
When we are designing the orchestration, Intellisense don't show us this property:
We have to write "Message_1(MIME." and Intellisense will show us this property:
This is because MIME.FileName is a PartContextPropertyBase and Intellisense by default only show us the MessageContextPropertyBase properties.
Sunday, April 27, 2008
SMTP Adapter - "Unknown Error Description"
If inside an orchestration, we set SMTP.EmailBodyText property in a message and we don't set SMTP.EmailBodyTextCharset, we receive "Unknown Error Description" when we send this message through a Dynamic Port.
To avoid this error, we have to set SMTP.EmailBodyTextCharset property.
More information in http://msdn2.microsoft.com/en-us/library/aa578225.aspx.
To avoid this error, we have to set SMTP.EmailBodyTextCharset property.
More information in http://msdn2.microsoft.com/en-us/library/aa578225.aspx.
Thursday, April 24, 2008
BizTalk Server 2006 R3
Yesterday, in BizTalk Server Team Blog and in Steven Martin's blog, announced their plans to deliver BizTalk Server 2006 R3.
At high level, new features will be:
- New web service registry capabilities with support for UDDI (Universal Description Discovery and Integration) version 3.0
- Enhanced service enablement of applications (through new and enhanced adapters for LOB applications, databases, and legacy/host systems)
- Enhanced service enablement of “edge” devices through BizTalk RFID Mobile
- Enhanced interoperability and connectivity support for B2B protocols (like SWIFT, EDI, etc)
- SOA patterns and best practices guidance to assist customer’s implementations
They expect to deliver a CTP of BizTalk Server 2006 R3, later this year and an RTM in H1 CY09.
They have also launched the BizTalk Server 2006 R3 TAP program.
At high level, new features will be:
- New web service registry capabilities with support for UDDI (Universal Description Discovery and Integration) version 3.0
- Enhanced service enablement of applications (through new and enhanced adapters for LOB applications, databases, and legacy/host systems)
- Enhanced service enablement of “edge” devices through BizTalk RFID Mobile
- Enhanced interoperability and connectivity support for B2B protocols (like SWIFT, EDI, etc)
- SOA patterns and best practices guidance to assist customer’s implementations
They expect to deliver a CTP of BizTalk Server 2006 R3, later this year and an RTM in H1 CY09.
They have also launched the BizTalk Server 2006 R3 TAP program.
Wednesday, April 02, 2008
XmlAsmException (HRESULT = 0xc0c01829) And XmlDasmException (HRESULT = 0xc0c01470)
XmlAsmException (HRESULT = 0xc0c01829) And XmlDasmException (HRESULT = 0xc0c01470) are exceptions without an error message.
Using Tomas Restrepo's error lookup utility (see my previous post), we can get a more detailed message:
0xc0c01829 = "BtsErrorAssemblerDoctypeDoesntMatchSchemas"
0xc0c01470 = "BtsErrorDisassemblerDoctypeDoesntMatchSchemas"
This error message means, that the provided schemas don't match with:
<message root element name> or <message namespace>#<message root element name>
This is the obvious error, but also we can get both error messages if our message has the DocumentSpecName context property setted.
The problem is that the standard biztalk's assemblers and disassemblers, override the DocumentSpecNames property of the XML Assembler/Disassembler pipeline components and the Document Schema property of the Flat File Assembler/Disassembler pipeline component if we set the message's DocumentSpecName context property.
Using Tomas Restrepo's error lookup utility (see my previous post), we can get a more detailed message:
0xc0c01829 = "BtsErrorAssemblerDoctypeDoesntMatchSchemas"
0xc0c01470 = "BtsErrorDisassemblerDoctypeDoesntMatchSchemas"
This error message means, that the provided schemas don't match with:
<message root element name> or <message namespace>#<message root element name>
This is the obvious error, but also we can get both error messages if our message has the DocumentSpecName context property setted.
The problem is that the standard biztalk's assemblers and disassemblers, override the DocumentSpecNames property of the XML Assembler/Disassembler pipeline components and the Document Schema property of the Flat File Assembler/Disassembler pipeline component if we set the message's DocumentSpecName context property.
Subscribe to:
Posts (Atom)