BizTalk Best Practice – Use Well-Known Identifiers for EDI Global Properties

When working on a BizTalk EDI project recently, I received some errors that seemed to be doing things that I had not configured BizTalk to do. The error messages were mentioning that a problem was occuring when sending an EDI message from Party A to Party B with a message namespace which was for an 850 response message but I had only configured Party B to send to Party A with an 855. It took me a long time to get my mind around what was happening until I looked at the EDI global properties. This new portion of BizTalk Server 2006 R2 provides a default catch-all party for messages that cannot be resolved for a party based on the ISA/GS headers. Essentially what happens when the BizTalk runtime is unable to resolve the ISA/GS headers on a message to a trading partner party, it will change the context properties and ISA/GS headers and then if these do not resolve to party or other errors are encountered, these will be logged. So if you are looking in the logs for an error message, what you see may not always be true to what you would expect. Here is a link to some more information on the EDI global properties – http://msdn.microsoft.com/en-us/library/bb245981.aspx, and the role of the party in EDI processing – http://msdn.microsoft.com/en-us/library/bb226560.aspx.

 

For this reason, I have started using well-known identifiers in my EDI global properties so that if the BizTalk runtime cannot resolve the ISA/GS headers, at least I will know this after reading the Event Viewer log messages. So for the ISA 06/GS02 value I specify GLOBALSENDER and for ISA08/GS03 I specify GLOBALRECEIVER. Although I appreciate that BizTalk provides a fallback party resolver, this seems misleading or worse. Think for example if you specified a value for one trading partner as the fallback and then when you added another partner, it would be easy to wind up sending unsolicited messages to a different partner. Also, I think that if the party cannot be successfully resolved based on the ISA/GS headers, you need to know this rather than have the runtime substitute a value for you. The default values such as BTSSender are ok but do not convey the sense that they are coming from the global properties. BTW, the BTSGuestParty is another one of the built-in parties that operates on behalf of the BizTalk runtime, so watch out for this party as well. As far as I know, though, the ISA/GS headers for this party cannot be configured.