Configuring BizTalk for AS2 communications can be challenging and time-consuming at times. The most complex aspect of it is dealing with certificates. In the last post I discussed about Secure messaging and Configuring certificates for AS2. In this post I will discuss about the Agreement and Party settings to handle EDI data over AS2.
EDI relies heavily on the concept of Party. Party really is a representation of a particular group within organization or partner you do business with.
EDI/AS2 settings are defined in party profiles and agreements define relationship between two parties.
Trading partner agreements is an understanding between two business profiles to use a specific message encoding protocol or a specific transport protocol while exchanging EDI messages with each other.
Trading partners are the entities involved in B2B (Business-to-Business) communications. When two partners establish a relationship, this is referred to as an Agreement. The agreement defined is based on the communication the two partners wish to achieve and is protocol or transport specific
In the above illustration, there’s an agreement between the “Shipping” and “Invoice” profiles of Fabrikam and Contoso respectively to use the X12 encoding for business messages (encoding agreement) and AS2 transport for exchanging messages (transport agreement). There can be many such agreements between various business profiles. For example, there can be an agreement between the “Payments” and “Invoice” profiles to use the EDIFACT message encoding standard. All such agreements for all the profiles for a pair of trading partners constitute a Partnership between the two trading partners.
In order to specify how to handle the EDI data is being sent via AS2, you will need to set up a BizTalk party and two agreements. One agreement is for the AS2 messaging (transport agreement), and one agreement is for dealing with the actual EDI data (encoding agreement).
The basic steps for setup are as follows for receiving AS2 data from a trading partner (sending data to a trading partner is very similar):
– Create a new BizTalk party with the name of the trading partner from which you will be receiving data.
– If you will be sending a 997 to the trading partner, specify the send port that the 997 will be sent out on.
– Create a new agreement on this party that will handle AS2 messaging. Let’s give it a name as Agreement_AS2
- On the General tab, set the Protocol property to AS2, the First Party to your home organization, and the Second Party to the trading partner. Once you’ve set the General tab this way, two additional tabs will appear: one for inbound data from the trading partner, and one for outbound data to the trading partner. If you are just receiving data from the trading partner and returning an MDN, you only need to configure the inbound trading partner tab.
– On the inbound trading partner tab, on the Identifiers tab, set the AS2-From and AS2-To properties to the appropriate values as defined in your trading partner agreement.
– On the Validation tab for the AS2 agreement, you can set the appropriate values for validation of the data. For example, if you are receiving a signed and encrypted inbound post from a trading partner, then you would set the properties.
– On the Acknowledgement tab of the AS2 agreement, you can set the properties that pertain to the MDN response back to the trading partner
The MDN is the acknowledgement for AS2 posts. There are two possible methods for postback of an MDN: synchronous and asynchronous.
The synchronous response is posted back via the same open HTTP connection that the original document came in on, and does not require any additional BizTalk Components. Simply set the Request MDN checkbox in the BizTalk agreement, and it will automatically post back.
For asynchronous MDNs, a send port must be created.There are some additional properties that will likely need to be set or adjusted on the other tabs; a few of the most common are noted here.
- On the Receiver MDN Settings tab, enable the Sign Requested MDN setting if you want to always send an MDN, regardless of what is noted on the inbound AS2 request from the trading partner.
- In the HTTP Settings for Messages, enable everything except for the Ignore SSL Certificate Name Mismatch property.
- In the HTTP Settings for MDN, enable everything except for the Unfold HTTP Headers property.
- On the Signature Certificate tab, set the certificate that you want to use for signing the outbound MDN. If nothing is selected here, the default certificate for the BizTalk group will be used.
Create a new agreement for the EDI data that will be consumed. Setting this up will depend on the specifics of the EDI document type(s) that are being received over AS2. What is important to know here is that you must have this additional agreement in place so that BizTalk knows how to process the EDI data once the AS2 agreement has successfully completed the data transfer.
Testing your AS2 Configuration
As mentioned by Mark Beckner in his EDI book, that one of the most challenging (and frustrating) aspects of AS2 configuration is the actual trading partner testing. The best advice is to plan to set up your AS2 configuration in stages. Try to exchange plain text data (unencrypted and unsigned) first before dealing with the various settings requiring certificates. If you can get the plain, unencoded data to flow (and the MDN to return) successfully, then you can move into testing encryption and signing.
There are many things that can go wrong during testing, and the error messages are often very generic and cryptic. The errors could be on your side, or they could be on the trading partner’s side. The more you can do to limit what is being tested at any given stage, the quicker you will be able to get to resolution and completion.
Resources:
Related Links:
https://msdn.microsoft.com/en-us/library/bb245935.aspx
https://msdn.microsoft.com/en-us/library/ee920490.aspx
