Party resolution in BizTalk Server EDI
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:
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:
If this Property was set before the EDIAssembler, the assembler would use the EDI setup of the Party specified.
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:
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:
- http://schemas.microsoft.com/Edi/PropertySchema#AgreementNameForSend (The Agreementname (AgreementWithPartner in my example above)
- http://schemas.microsoft.com/Edi/PropertySchema#SenderPartyNameForSend (MySelf)
- http://schemas.microsoft.com/Edi/PropertySchema#ReceiverPartyNameForSend (MyPartner)
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
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’
This gives me the following output:
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:
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!