This blog tells a story about the wrong EDIFACT content type on an AS2 payload. Additionally it presents a solution to the problem.
EDIFACT Content Type – Messaging Only Solution
Consider a messaging only solution where firstly a receive location receives an order. Furthermore the receive location promotes EDI properties on the incoming message. See a previous post that describes EDI party resolution. Secondly a send port subscribes to this message. The send port transforms the message to a EDIFACT XML order. In addition a custom pipeline creates a AS2 message with a EDIFACT payload.
The AS2 agreement sets the default content type of the EDIFACT payload . The AS2 encoder pipeline component on the send pipeline uses this default to set the content type on the EDIFACT payload.
The AS2PayloadContentType is application/edifact. You can find this in the group hub.
EDIFACT Content Type – Orchestration Solution Problem
Following on, let’s see what happens if we add an orchestration into the messaging only solution.
If we look at same AS2 message I was surprized to see that content type is now text/xml.
Explanation and Consequences
The AS2 encoder only sets EDIFACT content type if the content type on the message does not exist. Hence the messages coming out of the orchestration must have the content type of “text/xml”. This MDSN forum article talks about this same strange behaviour. Firstly setting the HTTP.ContentType in the orchestration nor setting the content type on the send port has any affect.
Finally Brett’s workaround adds a custom pipeline component in between the EDI Assembler stage and the AS2 Encoder stage in a custom Pipeline. This custom component only does one thing, clears the IBaseMessage.BodyPart.ContentType property of the current message stream. By “clearing” the default value, the AS2 stage to uses the appropriate value for the content type.
In most cases your trading partner does care about the content type of the payload but if they do you will have to implement some type of workaround if you are using an orchestration.
Using the BRE Pipeline Component Framework
Can we use the BRE pipeline component instead of Brett’s workaround? Our pipeline shown above already contains this component and the solution was ridiculously simple. Simple adding a business rule to set the content type to an empty string does the trick.
What I liked about this solution is that requires no re-deployment. This is just another illustration of the power of the BRE Pipeline Component Framework.
Finally looking at the same AS2 message after flowing through an orchestration we see a content type of application/EDIFACT.
Conclusion
Sending messages from an orchestration can cause problems and you have to do some extra work to insure that the EDIFACT payload has the correct content type. Good grief BizTalk server solution can be very complicated sometimes. Here’s hoping AS2/EDIFACT solutions are easier in Azure.
Learn from yesterday, live for today, look to tomorrow, rest this afternoon.
