BizTalk ESB Toolkit: Two-way Request Response Itinerary process | Web Service call from ESB | Part 1

In this article, I would demonstrate how to develop a 2 way itinerary process invoking a web service. This can be achieved in 2 ways, either service request transformation at On-Ramp or at Off-Ramp. If we have to use transformation at on ramp or off ramp ESB Dispatcher component should be used in the pipeline.

Itineraries:-
Service request transformation at On-Ramp
{OnRamp[Static Resolver,Two-Way Receive Port] -->Messaging Extender[Static Map Resolver, Canonical Xform]-->Messaging Extender[Static Map Resolver, Service Request Xform]}-->Off-Ramp Extender[Static Routing Resolver] -->OffRamp[Two-Way Dynamic Send Port]

Service request transformation at Off-Ramp
{OnRamp[Static Resolver,Two-Way Receive Port] -->Messaging Extender[Static Map Resolver, Canonical Xform]}-->Off-Ramp Extender[Static Routing Resolver] -->{Messaging Extender[Static Map Resolver, Service Request Xform]-->OffRamp[Two-Way Dynamic Send Port]}

Receive Port Configurations:
Two-way receive port with WCF-Custom webHttpbinding, shown below

Dynamic Send Port Configurations: 
Here is a screen shot of send ports, 

Deploy the itinerary and start the application, then test the solution by placing a request through fiddler and wait the response of the process. Refer test results below, 

Conclusion
In this article, I illustrated how to develop an itinerary process to invoke web service and respond back to caller.

BizTalk ESB Toolkit | ESB Routing Slip Itinerary Process

In this article, I would demonstrate to develop simple itinerary. 

An itinerary is a piece of metadata that describes the path through the bus that a message should use; it can also include a set of services that should be applied to a message as it flows through the bus. It is used to determine the flow of messages through the BizTalk ESB Toolkit run time. 

Here are the three artifacts in this itinerary: 

• An OnRamp 
• An Itinerary Service 
• An OffRamp 

ESB Flow:
OnRamp[Static Resolver, Receive Port] -->Off-Ramp Extender[Static Routing Resolver] -->OffRamp[Dynamic Send Port]

Here we use the ItinerarySelectReceive, which by its name indicates it will select the correct itinerary, and then simply pass the message to the MessageBox. 

The ItinerarySelectReceive pipeline is configured on the receive side and this pipeline has a component named the ESB Itinerary Selector in the first (decode) stage of pipeline processing. The main role of the ESB Itinerary Selector is to configure an Itinerary Resolver. Resolvers in the BizTalk ESB Toolkit are registered through global configuration through monikers; the configured Resolver has a moniker of “ITINERARY:\\name=ESB.RoutingSlip;version=1.0;” which means that the Resolver will look up the value of the 
ESB.RoutingSlip from the registered Itinerary store.

So far we have built an OnRamp to the BizTalk ESB Toolkit that has a single physical address where every message that arrives will be associated with the ESB.RoutingSlip itinerary by the ESB-provided pipeline and pipeline component (due to configuration of them on this ReceiveLocation). After being processed by the ReceivePort, the message will go to the MessageBox. Therefore, the next piece we need is a dynamic SendPort that can subscribe to the messages that will be published by this ReceivePort. 

Now, we need an OffRamp associated with the OnRamp. Associating the OffRamp in the Itinerary Designer with the OnRamp accomplishes this. Like the OnRamp, each OffRamp has to be associated with a physical SendPort. The SendPort will need a filter, as show below 

The Itinerary Service serving as the resolver of the URI for the endpoint and route the message to destination system. Here we use a static resolver, as show below. 

• In OnRamp, choose the application and then select the Receive-Port. 
• Use the itinerary service as an off Ramp extender with a static resolver. 
• In Off Ramp, choose the application and then select the dynamic port. As shown, connect all the components. 

Deploy the itinerary and start the application, then test the solution by copying an XML document with structure defined by the schema inside the input folder and wait the response of the process in the output folders. 

Conclusion 
In this article, I covered principles of the itinerary as well as I illustrated how to develop an itinerary process with a simple static resolver.