Thursday, October 16, 2008
Friday, October 10, 2008
Failed to serialize message part ....
Well, I've come across this error message quite often:
Failed to serialize the message part "" into the type "" using namespace " http://namespace". Please ensure that the message part stream is created properly.
The first time you will probably end up searching what is causing the error. Generally this error occurs when the message is holding an improper value, think of a character string in an integer field, or a complex type field is empty (and not nullable). It could also be that a mandatory field is missing in the message being sent to the adapter (this won't occur when you are using validation).
Also keep into account that this error may also occur because of a weird (or wrong) WSDL / proxy class generation in BizTalk and fields become optional, allthough they are mandatory. When adding the proxy class, the schemas that are being generated aren't correct at all. E.g. all strings are generated as optional, though they may not be optional in the service contract. I will put this problem in a seperate entry next week, because it's really hard to find anything on this problem on the internet.
Failed to serialize the message part "
The first time you will probably end up searching what is causing the error. Generally this error occurs when the message is holding an improper value, think of a character string in an integer field, or a complex type field is empty (and not nullable). It could also be that a mandatory field is missing in the message being sent to the adapter (this won't occur when you are using validation).
Also keep into account that this error may also occur because of a weird (or wrong) WSDL / proxy class generation in BizTalk and fields become optional, allthough they are mandatory. When adding the proxy class, the schemas that are being generated aren't correct at all. E.g. all strings are generated as optional, though they may not be optional in the service contract. I will put this problem in a seperate entry next week, because it's really hard to find anything on this problem on the internet.
Labels: biztalk, message, part, proxy class, serialize, WSDL, XML
BizTalk Macros
Sometimes it may happen that you can't remember what the macros are to display variables in your filenames in your sendports. Here's a list of the macros (source: Jan Tielens' bloggings):
- %datetime%
Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508). - %datetime_bts2000%
UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds). - %datetime.tz%
Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800). - %DestinationParty%
Name of the destination party. The value comes from message the context property BTS.DestinationParty. - %DestinationPartyID%
Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID. - %DestinationPartyQualifier%
Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier. - %MessageID%
Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID. - %SourceFileName%
Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%). - %SourceParty%
Name of the source party from which the File adapter received the message. - %SourcePartyID%
Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID. - %SourcePartyQualifier%
Qualifier of the source party from which the File adapter received the message. - %time%
UTC time in the format hhmmss. - %time.tz%
Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).
Monday, October 6, 2008
Errors in .NET proxy class generation and its WSDL in BizTalk
When a proxy class is generated with BizTalk 2004 and 2006 (not R2 as it seems) it will hold a few errors. It's important to take these irregularities into account (Microsoft calls it "by design").
Mandatory strings (minoccurs="1") are converted to optional (minoccurs="0"). Nullable types (xsi:nil="true"), e.g. xs:int or xs:datetime, are ignored when passing it through the proxy class.
I could try and explain the problem, though the entire "problem" can be found on the URL below. This is a Microsoft source.
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101972
Mandatory strings (minoccurs="1") are converted to optional (minoccurs="0"). Nullable types (xsi:nil="true"), e.g. xs:int or xs:datetime, are ignored when passing it through the proxy class.
I could try and explain the problem, though the entire "problem" can be found on the URL below. This is a Microsoft source.
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101972
Labels: asmx, biztalk, generation, issue, microsoft, minoccurs="0", minoccurs="1", nillable, nullable, proxy class, types, WSDL, xs:int, xs:string, xsi:nil
Error: Unknown error
I started this blog just 5 minutes ago. And why? Hmz, that's a good one. Not that I am that proud of myself, but I think people using BizTalk may find some help useful, especially with the library of weird error descriptions and how to solve them. Ofcourse I will try and post some patterns as well.
I have been active with BizTalk 2002, 2004 and 2006 for 2 years now and I have come across many (weird) errors or behaviours. I have been active with mainly the messaging and orchestrating part of BizTalk. You can always send an e-mail if you have any questions regarding messaging. I can't answer questions about the rules engine (yet). Maybe in about 6 months ;-)
I have been active with BizTalk 2002, 2004 and 2006 for 2 years now and I have come across many (weird) errors or behaviours. I have been active with mainly the messaging and orchestrating part of BizTalk. You can always send an e-mail if you have any questions regarding messaging. I can't answer questions about the rules engine (yet). Maybe in about 6 months ;-)

