Support for Multiple Home Organization Identifiers
Well it's been a while since the last post. The team has been very busy servicing our TAP customers and making sure that we hit our milestones for the upcoming Beta 2 release. That said, we will increase the frequency of posts as we describe many of the new features that will be shipping in the Beta 2 release, many of which are also present in the recently released Customer Technology Preview. Read on for more about that ...
About a week ago Microsoft released to the Connect Site our BizTalk Server 2006 R2 Customer Technology Preview (CTP) release for February. This is an advance view of our upcoming Beta 2 release. The February CTP is only available to our Technology Adoption Program (TAP) customers and partners while the Beta 2 release will be a public beta. This release contains about a dozen customer-driven enhancements since the Beta 1 release in addition to numerous bug fixes. In this post we will discuss one of the most important enhancements in this release - support for multiple home organization EDI identifiers.
The Previous Approach
Prior to this release, if a customer employed multiple home organization EDI identifiers (ISA-level identifiers in X12, UNB-level identifiers in EDIFACT) you had to employ a somewhat onerous work around in order to get all of your transactions to process correctly. First, you would have to create party records for each trading partner / home identifier combination in order for outbound transactions, including acknowledgments, to have properly formatted envelopes. While it is not unusual to have to create 'agreements' between two parties in the EDI world, prior to this release this meant that you could no longer use the Alias to store the identifier of the trading partner because you could have two parties with the same Alias which BizTalk doesn't allow. By no longer using the Alias you are disabling the primary party resolution mechanism for inbound transactions and being forced to employ other techniques for outbound party resolution.
Inbound Transactions
Losing Party resolution for inbound transactions means that the EDI receive pipeline will fall back on Global EDI Properties regarding acknowledgment generation and reporting and these might be counter to the behavior desired for a particular party. In addition, acknowledgments generated by the EDI receive pipeline would not automatically get the correct DestinationPartyName property which ensures proper formatting of the envelope for outbound transactions.
Outbound Transactions
Without the DestinationPartyName property the only other way to ensure proper outbound party resolution was to use Send Port party resolution by creating a Send Port for each 'agreement' (i.e. Party) and associate it to the Party record for the intended trading partner. This created a Send Port proliferation problem in that you had to create a specific send port for each party that had to communicate with more than one home organization identifier. In addition, this also created a Send Port filter maintenance problem because you had to employ multi-part filters to suscribe to the acknowledgments for each of these parties. Lastly, for non-acknowledgment outbound EDI you had to either set the DestinationPartyName, which would require some external cross-reference, or employ additional send ports and/or filters to subscribe to these transactions. For a small number of trading partners this would be manageable. However, companies that have multiple EDI identifiers tend to be multi-national, have grown via acquisition, or some combination of the two and typically have a significant number of trading partners making this situation undesirable.
The New Approach
Inbound Transactions
With the February CTP we have addressed these issues by changing the way that Party (agreement) resolution takes place for EDI (AS/2 party resolution will remain the same). For inbound transactions, the Alias will no longer be used to look up the sender party. Instead, we have added four new fields each to both the X12 Interchange Processing Properties and EDIFACT Interchange Processing Properties for Party as Interchange Sender. The four new fields will store the sender qualifier and identifier and the receiver qualifier and identifier and together will uniquely identify the partner agreement. (See screen shot)
Using these new fields the EDI engine will lookup a Party for an inbound transaction by using the sender AND receiver qualifiers and identifiers (ISA05, ISA06, ISA07, ISA08 in X12 and UNB2.1, UNB2.2, UNB3.1, UNB3.2 in EDIFACT) and comparing them with the values in the four new fields. If no match is found then it will revert back to using just the sender qualifier and identifier (as it does today), but by comparing them with the new sender fields in the EDI properties and NOT the Alias for that Party. If no match is found there then the engine will revert to Global EDI Properties as it did previously.
Outbound Transactions
For outbound transactions, four new context properties have been added: EDI.DestinationPartyReceiverIdentifier, EDI.DestinationPartyReceiverQualifier, EDI.DestinationPartySenderIdentifier, and EDI.DestinationPartySenderQualifier. By setting these properties on an outbound document the EDI engine will use them to lookup a Party based on the values stored in the sender and receiver qualifier and identifier fields that already exist in the ISA Segment Definition and UNB Segment Definition property pages for Party as Interchange Receiver. The outbound party resolution algorithm under this new approach is as follows. The engine will look for the DestinationPartyName property as it did previously and attempt to lookup the Party using that if it is present. If it cannot find a match and all of the four aforementioned properties are present it will attempt to lookup the Party using them as described above. If it cannot find a match it will suspend the message. The rationale here is that if one takes the time to populate these properties, it was done for a reason, and if no Party match is made that is a problem. If none of these properties are present, then the engine resorts to Send Port party resolution as it did previously.
Easier to Maintain
With this new functionality, send port proliferation and the need for extra filters on those ports is signficantly minimized. In addition, outbound party resolution is made easier because you no longer need to worry about setting the DestinationPartyName property. You can just use the sender and receiver identifiers and qualifiers and let the engine do all the work!
Cheers,
Tony
