BizTalk ESB Toolkit Video Tutorial

BizTalk ESB Toolkit: ESB Service Composition | Service Chaining

In this article, I would brief about service composition or chaining.

Lets say we have set of services running that allows us to booking a taxi/cab and flight and client wants invoke all the service in a sequential manner. Lets say's based on the cab booking status, invoke the the second flight service booking. This can be achieved using service composition logic. 

Itinerary service is defined as shown below, note this is a 2 way itinerary service.

This can be achieved by enabling a simple transformation at the Off-Ramp receive handler and setting routing information for 2nd service call. The dynamic 2-way send port should use ItinerarySendPassThrough send and ItineraryForwarderSendReceive receive pipelines.

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

This is in continuation for my previous article on Request Response itinerary process to invoking a web service and echo back service response to the client. Here we would go one step further and build our itinerary process to respond back to the client in their expected response format.

Lets say we have set of services running that allows us to booking a taxi/cab and flight based on the request made the customers, say client have their own Booking Request and Response schema and they want us book service request by them and respond back the status in their expected response format.

This can be achieved by enabling a simple transformation at the Off-Ramp receive handler and dynamic 2-way send port should used ItinerarySendPassThrough send and ItinerarySendReceive receive pipelines
Itinerary:-

Here is the itinerary flow,

{OnRamp[Static Resolver,Two-Way Receive Port] -->Messaging Extender[Static Map Resolver,ClientRequestToService Request Xform at the Receive Handler]} -->Off-Ramp Extender[Static Routing Resolver] -->{OffRamp[Two-Way Dynamic Send Port]-->Messaging Extender[Static Map Resolver, Service ResponseToClientResponse at the receive handler]}

Receive Port Configurations:

Two-way receive port with WCF-Custom webHttpbinding, shown below,

Dynamic Send Port Configurations: 

Here is a screen shot of dynamic send port,

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 client in their response format.

BizTalk ESB Toolkit: Dynamic Resolvers in ESB Itinerary Process

In this article, I would demonstrate the features of dynamic resolvers by using BREs. In previous post, we had used a static itinerary resolver, now the itinerary will be resolved dynamically by the OnRamp. And itinerary will be able to do a dynamic transformation of the message received at OnRamp then based on the transformed message we would route the message to destination system. 

ESB Flow:
{OnRamp[BRI Resolver, Receive Port] -->Messaging Extender[BRE Map Resolver]}-->Off-Ramp Extender[BRE Routing Resolver] -->OffRamp[Dynamic Send Port]

The main role of the ESB Itinerary Selector is to configure an Itinerary Resolver, and here we would use BRI resolver as shown below. 

Itinerary Resolver:

• Rule 1: If Message from RequstorA or RequestB then Set Itinerary Name as ESB.DynamicRoutingSlip; halt and exit the BRE execution. 
• Rule 2: if any other messages received Set Itinerary Name ESB.StaticRoutingSlip; halt and exit the BRE execution. 

BRE Map Resolver: 
Let’s say we receive an inbound message and we would evaluate message and select the map as show below,

• Rule 1: If Message from RequstorA then Set Transform Type as RequestAToCanoical; halt and exit the BRE execution. 
• Rule 2: If Message from RequstorB then Set Transform Type as RequestBToCanoical; halt and exit the BRE execution. 

Routing Resolver: 

This BRE would use transformed message,

• Rule 1: If Transformed Message from RequstorA then Set End Point Outbound Transport Location and Set End Point Outbound Transport Type accordingly; halt and exit the BRE execution. 
• Rule 2: If Transformed Message from RequstorB then Set End Point Outbound Transport Location and Set End Point Outbound Transport Type accordingly; halt and exit the BRE execution. 

Itinerary Configuration:

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

Conclusion 

In this article, I covered principles of the itinerary as well as I illustrated how to develop an itinerary process with a dynamic resolver using BREs. 

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.