This blog shows how to send an EDIFACT order via AS2. Specifically, I will continue to record my experiences migrating a BizTalk interchange. In the same way as my last post this is a beginners guide to AS2 messaging in Azure. Additionally I describe two gotchas on configuring the HTTP action that sends the AS2/EDIFACT request.
Set up Sending an EDIFACT Order via AS2
Firstly a service bus trigger picks up a canonical order and secondly transforms this to EDIFACT XML order.
Thirdly an EDIFACT encode shape uses the EDIFACT agreement to convert the XML to an EDIFACT flat file. See this link on how to create the EDIFACT agreement.
Formerly in the previous post we resolve the agreement name using an action on the service bus topic subscription. The right hand branch sends a NACK if the agreement name is not in the integration account. The left hand branch creates a functional ACK to keep the symmetry of the flow.
First gotcha with the HTTP Action
To begin with, I describe a solution that fails because there are some learnings that I want to highlight.
The fourth action encodes the EDIFACT flat file with an AS2 wrapper. The Azure documentation says that the Encode AS2 connector performs these tasks:
Applies AS2/HTTP headers
Signs outgoing messages (if configured)
Encrypts outgoing messages (if configured)
Compresses the message (if configured)
Transmit file name in MIME header (if configured)
See this link on how to configure a As2 agreement in your integration account.
The next step is posting this AS2 payload in an HTTP action to suppliers endpoint. If you just add the content from the previous step with out any headers you get 500 errors. If you look on the AS2 receiver ( I was using BizTalk Server) you see errors like;
“An AS2 message was received that did not contain the AS2-From header.”
For this reason you have to add AS2 information to the headers of the request. Adding all the headers has shown does yield a positive MDN response from the supplier. Instead we see this MDN disposition message
“processed/error: insufficient-message-security”
On the positive side this tests the NACK flow but is not so good for the left hand side. Thus decoding the response from the HTTP post ( a MDN) and then testing the MDN disposition type is always false.
For this reason we consulted Microsoft and they said look at this example. Sure enough this example assigns outbound headers differently. Thus, on the HTTP action, click on the little T icon to change it from name value pair to just a JSON value, and then choose the “OutboundHeaders” from the previous AS2 encode as the value for the headers.
Second Gotcha with HTTP Action
Submission of the same request gives a different MDN disposition namely
“processed/decryption-failed: error”
The reason for this error is hard to find but it is under Troubleshoot B2B errors in the Microsoft Documentation. Adding the expression to the body as @base64ToBinary(body(‘Encode_to_AS2_message’)?[‘AS2Message’]?[‘Content’]) yields the desired result. Finally, on receiving a positive MDN the left hand side of the flow is lit up.
Conclusion
Migrating the sending of a AS2/EDIFACT message from BizTalk Server to Azure requires little effort once you get over some initial hurdles. In particular you must;
- Add outbound headers from the As2 encode step as json
- Convert the AS2 Content using @base64Tobinary
Both these steps are hidden deep in the Microsoft documentation and I think they should be explicitly called out.
