This article tells you how to use the “BRE Pipeline Component Framework” to configure EDI party resolution. In the first place, a receive port promotes EDI properties on an incoming message. This enables an EDI send pipeline to determine the agreement for that message. Finally, the send port uses these to generate and validate the outgoing message. Morton La Cour describes the EDI properties here.
A classical approach to EDI Party Resolution
A word of caution this is someone else’s solution and is not one I recommend. Later on I describe an improved version that uses the BRE Pipeline component framework.
This approach sets the value of “http://schemas.microsoft.com/Edi/PropertySchema#AgreementPartIDForSend”. Thereupon, BizTalk Server resolves the agreement by matching the AgreementPartIDForSend context property with the ID of the agreement.
This starts with receiving an order message on a FTP adapter. Subsequently the message travels through a custom pipeline like this.
The EDICustomPartyMapper pipeline component assigns the value of SupplierCode from the incoming message. The pipeline component sets the value of SourceToMatch to SupplierCode.
Secondly, a query looks up the value of AgreementPartIDForSend in a custom table using the SupplierCode. Morton ‘s article shows how to configure the custom table.
Thirdly, promoting this value to the http://schemas.microsoft.com/Edi/PropertySchema#AgreementPartIDForSend context sets the message up for agreement resolution.
Finally, after routing the message to the send port, EDI party resolution of the agreement happens. Subsequent generation of the outgoing EDIFACT message occurs next. Another key point is that the send port assigns the AS2 agreement by binding to the send port configured on that agreement. It is important to remember that while many EDI agreements use the same send port , we only use one As2 agreement.
To sum up, the above implements EDI party resolution by promoting one context property on the outgoing message i.e. “http://schemas.microsoft.com/Edi/PropertySchema#AgreementPartIDForSend”. I think this solution has two failings. Firstly it requires the creation of a custom SQL table. Furthermore this relies on knowing the value of AgreementPartIDForSend in the [BizTalkMgmtDb].[tpm].[Agreement] table. Secondly, you cannot restore the custom SQL table to another environment because on deploying the party bindings the AgreementPartIDForSend changes every time. We found this to be a major issue for deployments with the BizTalk Deployment Framework.
Using the BRE Pipeline Component Framework
The goal of this second solution was to firstly remove the dependency on a custom SQL table. Secondly we want do with away with having to know the value of AgreementPartIDForSend in the BizTalk database. An alternative way of setting up EDI Resolution is to promote three properties namely;
- AgreementNameForSend,
- SenderPartyNameForSend
- ReceiverPartyNameForSend.
I like this approach because all these values are known at runtime and configuration does not require any database lookups.
How do we promote these properties on the receive port? One option was to create a new pipeline component that allows us to configure these properties on the receive port. Instead I choose the BRE Pipeline Component for this task because it already exists on our BizTalk Server. I highly recommend using this pipeline component because it is so extensible.
Let’s begin by selecting a pipeline to replace the one above. I was able to reuse one of our standard pipelines because we also did away with the audit component, shifting that from a pipeline component to send port with a subscription to the receive port.
The magic happens when we configure the pipeline and business rules at run time. Configuring the pipeline with a Excecution Policy and Instruction loader policy we are set to configure the business rules.
First, we need configure a new vocabulary to get the value of SupplierCode from the incoming message. Just for clarity, the vocabulary below uses the TradingPartnerID because this is the name of the Supplier Code on the incoming flatfile.
Secondly, we configure an instruction loader policy to instantiate an instance of the flat file schema when the BRE Pipeline componemt processes the incoming message. Without this it is not possible to get the TradingPartnerID from the message.
Finally configuring the execution policy we can promote the three context properties.
Conclusion
In summary I have shown how to use the BRE pipeline component to set up EDI Party resolution. Copying this to another environment only involves copying the business rules because there is no longer any dependency on a custom database. Additionally we can now use the BTDF to do our deployments. I acknowledge Alastair who did all the hard work of setting this up in our environments.
Now I have got this of my chest I can move on and gut this sucker and move it into Azure Logic apps.
