BizTalk ESB Toolkit: ESB Itinerary Broker Service and Broker Outport | Decide Shape

In this article, I would explain how to use ESB Itinerary Broker Service. Broker Service is kind of a decide shape in workflow.The itinerary look at a certain value (in the context), and decides on the path. Say, we receive MsgA, MsgB and both needs to be routed to different flows.

Lets define itinerary, drag an On-Ramp model and then itinerary Broker Service. Configure broker service with context resolver and then add filters as shown. Using broker outport map the corresponding filters as shown below(1,2 and 3)

Bring in orchestration extender and add static resolver and using off-ramp extender and offramp, route the message to destination system as shown below. Repeat the same steps for the other flow.

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 Itinerary with Custom Orchestration Extenders

In this article, I brief you about creating a custom orchestration extenders and configure it in itinerary flows. 

Eventually, we would develop 2 Itinerary flows having custom orchestration extender and chain it.

Overall, we have a simple itinerary having two orchestration extenders, in first  orchestration extender would receive the message from the on-ramp and which would archive the message to archive path; where as second extender would act as en-richer component by enrich incoming message and route to enriched archive path.

Another itinerary would receive the message then transform and route it to target system using a custom orchestration extender.

Lets, create Receive Process Orchestration with direct bindings on receive and send; this would acts a custom orchestration extender which would archive the msg to endpoint path as specified in the resolvers.

High-level steps to be followed for create a extender, refer below screen for the associated steps.

Step 1    >> Retrieve the current itinerary step.

Step 2    >> Retrieve the Resolvers associated with the itinerary.

                Step 2.1 >> Retrieve the Resolver properties, implement routing or transaction or any web service as per requirement.

Step 3    >> If the Itinerary has further steps, advance the current or enriched message to Itinerary step by initialising correlation of ESB properties (ServiceName,ServiceState,ServiceType)

Here is custom orchestration extender,

Similarly, I have developed Enrich Orchestration extender, which would enrich the msg and route to intermediate destination.

Here is the target orchestration extender, which would receive the msg, transform and route to the destination. Lets create a simple receive location with a static itinerary resolve as shown below.

Register these custom odx extender in esb config as shown,now lets develop, itinerary flows using these extenders.

Make sure, have set the appropriate filter condition in each custom extender orchestration; ESB ServiceType and  ESB ServiceState would be Orchestration and Pending respectively; finally ESB ServiceName would Name used in the esb config.

Here is the common itinerary process, which would receive msg and archive it.

As shown, let’s add another step to the itinerary, this would enrich the msg and route to intermediate folder.

Here is the other itinerary; which would pick a message and transform it then route to the destination folder.

Lets say, we want to chain these two itinerary, this can achieved by using a helper component as shown below,this would retrieve the itinerary details and attach it to the msg and publish to other itinerary.

Let’s use this helper method in en-richer orchestration and publish the message to target itinerary from the current itinerary itself,as shown below.

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: 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.