Party resolution in BizTalk Server EDI

When working with BizTalk Server EDI, configuring the correlation between the Send Ports and the Party/Agreements might sometimes require more flexibility than the Agreement set up provides us…

While the Party/Agreement set up in BizTalk Server provides us with the ability to link each Agreement (Party before BizTalk Server 2010) to a Send Port, so that the EDIAssembler Pipeline Component knows what Agreement to use when transforming EDI XML to EDI, this might not be the most flexible approx:

01_AgreementSendPortSetupNotice that an Agreement holds two Agreement Parts (MyPartner->MySelf and MySelf->MyPartner), it will typically only be one of these parts where a Send Port association will need to be made.

The disadvantage of creating a hard reference between each Agreement and a Send Port is:

  • The same Send Port cannot be used for more than one Party
  • Dynamic resolution from message data is not an option.
  • Problems with binding files, as the Party set up vs. the Port set up becomes sort of a “hen and the egg” problem.

So what can we do instead?

How it used to be:

Well until BizTalk Server 2009, there was an option of writing the Party name to the Context Property:

http://schemas.microsoft.com/Edi/PropertySchema#DestinationPartyName.

Example:

context.Write(“DestinationPartyName”,”http://schemas.microsoft.com/Edi/PropertySchema”,PartyName);

If this Property was set before the EDIAssembler, the assembler would use the EDI setup of the Party specified.

The change:

As of 2010, Agreements were introduced to BizTalk Server, and since the same Party could now have multiple Profiles and/or Agreements, and each Agreement contains parts, the DestinationPartyName was not sufficient anymore.

It was, however, kept in 2010 but marked deprecated. To use it in 2010, one needs to set it in the Agreement part as follows:

02_DesitationSetuponAgreements

So if the old Party names from 2009 and below was inserted in the DestinationPartyName property of the Agreement part, one could use existing Pipeline Components or Orchestrations already made, and have the solution work in BizTalk Server 2010.

BUT: The Property has vanished in 2013 (don’t say they didn’t warn you, it was deprecated, it’s just very seldom that they actually remove deprecated stuff in BizTalk Server, so I was still surprised!).

Note: The ability to set DestinationPartyName on the Agreement part is still present i 2013, it is just useless! 🙂

The new Solution:

This has forced me to look into how one is supposed to do Party resolution in BizTalk Server 2010 and beyond.

To do this we need to write to three (3!) Properties:

It is because an Agreement consists of two parts that all three Properties must be set.

The undocumented one Property

If three Properties are too much for you it is possible to just set the

http://schemas.microsoft.com/Edi/PropertySchema#AgreementPartIDForSend

Property, but this requires us, manually to find the Agreement part id.

In the BizTalk Server Management Database (BizTalkMgmtDb) you can do the following query:

select a.Name as ‘Agreement’,
a.SenderOnewayAgreementId as ‘AgreementOwnerAsSender’,
a.ReceiverOnewayAgreementId as ‘AgreementOwnerAsReceiver’
from
tpm.Agreement a

This gives me the following output:

03_SQLOutputNow look that the Agreement:

04_AgreementOwnerpng

Now the Agreement “owner” (not a 100% accurate description, but play along with me!) will always be the First Party. So in my case, if I want the Agreement part: MyPartner->MySelf, MyPartner (owner) would be Sender, and therefore I would write 1002 to the Property:

http://schemas.microsoft.com/Edi/PropertySchema#AgreementPartIDForSend

and ofcourse 1003 if I was to use the other Agreement part.

One final note: the AgreementPartIDForSend Property is of type Int, and it will NOT work if you write a string containing “1002” or “1003” to the Property!

BizTalk Tracking made easy..

Contact me (2)

Kategorier: Biztalk, Integration

Tagged as:

3 Comments »

  1. If your message has a PartyName, SenderID, ReceiverID they can be used to map to AgreementNameForSend, SenderPartyNameForSend and ReceiverPartyNameForSend. Might not be a 1 to 1 mapping, syntax conversion etc. could be required. But the option is definitely there

  2. If you cannot use property values to set these props, you can still hardcode them on the send pipeline before the edi transmit pipeline component and use regular filter conditions like customer account or something

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s