The most performant way to expose this BizTalk pipeline functionality as a two-way WCF service, is by routing the transformed request message automatically back to the send pipeline of the two-way receive port. This pure messaging scenario only involves one pub/sub mechanism to the MsgBox. We have tested this on a single box development machine, arriving at only 60ms roundtrips for our flat file test schema.
In some cases, other applications want to make use of the flat file parsing functionality of BizTalk. These applications need for example a conversion between their .NET object and a flat file, or vice versa. The functional context can be EDI, HL7, Copybook or custom flat file parsing.
The most performant way to expose this BizTalk pipeline functionality as a two-way WCF service, is by routing the transformed request message automatically back to the send pipeline of the two-way receive port. This pure messaging scenario only involves one pub/sub mechanism to the MsgBox. We have tested this on a single box development machine, arriving at only 60ms roundtrips for our flat file test schema.
This can be achieved by adding a custom pipeline component at the end of the receive pipeline. This pipeline component promotes the necessary properties to route back the request directly to the subscribing send pipeline. The Execute method of this component is where the magic happens:
string ns = http://schemas.microsoft.com/BizTalk/2003/system-properties;
inmsg.Context.Promote(“RouteDirectToTP”, ns, inmsg.Context.Read(“IsRequestResponse”, ns));
inmsg.Context.Promote(“EpmRRCorrelationToken”, ns, inmsg.Context.Read(“EpmRRCorrelationToken”, ns));
return inmsg;
This logic can also be used in custom disassembler pipeline components, which need to generate a response message that needs to be routed back to the original caller.
Toon Vanhoutte
Subscribe to our RSS feed