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.