Geeks With Blogs

News This is the *old* blog. The new one is at blog.sixeyed.com
Elton Stoneman
This is the *old* blog. The new one is at blog.sixeyed.com

Itineraries are at the core of the ESB Guidance offering. They enable the client to define what services its message needs, rather than fixing them at the provider. So in a typical BizTalk service an orchestration will define the steps - e.g. receive, transform, enrich, send. With ESB the client specifies those steps in an itinerary.

This has three major benefits. Firstly you can decouple all your service components. Instead of exposing a composite service tailored for each client, the clients do their own tailoring by defining the itinerary steps they require. Secondly, leveraging ESB's resolution capabilities, the service used to process each step can be dynamically resolved. The fulfillment of the service is then decoupled so new service providers can be swapped in without the clients changing or even knowing. Thirdly, itinerary steps can specify services which exist outside of BizTalk configuration, so you can design an app with fewer BizTalk artifacts to develop and maintain.

Take an example where ProjectX and ProjectY both submit payments to PeopleSoft. In a BizTalk app this could be structured as an orchestration with a dynamic receive subscribing to SubmitPayment message types. The orchestration has steps to validate the message and pass on to PeopleSoft, along with various levels of error handling. Consumers ProjectX and ProjectY have different message content, so each has its own receive location with a dedicated map, transforming to the SubmitPayment schema for the orchestration. So far we have two maps, two receive locations, a receive port, orchestration, and various send ports for PeopleSoft and the exception handlers.

Say the PeopleSoft team are finding issues with some payments originating from ProjectX and want to extend the validation. The new validation is only relevant to ProjectX payments and should not be applied to any other requests. In the BizTalk implementation we need to change our orchestration. It may be that we can identify ProjectX payments from the message properties and perform the extra validation in the orchestration. Or it could be that we need a complete new orchestration dedicated to ProjectX, which does the validation then calls into the existing orchestration. The existing orchestration can no longer subscribe to all SubmitPayment messages so we'd need new dedicated receive ports for each client. There are various approaches, but all of them effectively mean the service knows about different clients and offers a tailored solution to each.

In ESB Guidance the solution would look very different. We still have the maps and the orchestration, but now it only has the validation steps and the send to PeopleSoft. ESB Guidance has a rich layer of error handling so we can dispense with the custom exception handling. There are no specific receive ports or locations for the service – we'll use the generic itinerary on-ramp.

The client builds an itinerary that says: map the enclosed message then call this service. Map and service details are specified statically or as dynamic lookups. The client then sends the itinerary and the message to the ESB Guidance on-ramp. The on-ramp is a receive port with a pipeline component which promotes the itinerary details (received in the message header) to context properties. Then a generic orchestration picks up the message and, for each step in the itinerary, resolves the service and submits to it a copy of the message.

Our requirement to change the validation is now straightforward – just expose the additional validation as a separate service, and include that service as a step in the ProjectX itinerary (other consumers' itineraries don't need to change).

The next couple of posts will look at what happens when the itinerary is processed by the on-ramp, and provide a walkthrough for constructing and submitting a simple itinerary.

Posted on Thursday, April 10, 2008 12:22 PM ESB Guidance , BizTalk 2006 R2 | Back to top


Comments on this post: Itinerary Processing: Overview

# How do you transform one xml message to multiple xml messages with different schemas using the Itinerary
Requesting Gravatar...
Hi Elton,
I have two services that require two different xml schemas. Service1 requires messageB(Surname, Forename, AccessRights) and Service2 requires MessageC(Surname, Forename, Gender). The On-Ramp Itinerary will be invoked with MessageA(Surname, Forename, Gender, AccessRights) within the itinerary message. The Itinerary message needs to be setup so that it transforms messageA to messageB to Route to Service1 and then Transforms from messageA (again) to messageC to send to Service2.
I cannot see how to setup Step 3 in the following itinerary:
- Step1 : Transforms from messageA to messageB,
- Step2 : Routes to server1 with messageB,
- Step3 : Transforms from MessageA to messageC
- Step4 : Routes to server2 with messageC
At the end of Step 2 the itinerary message contains MessageB. How do we get messageA (from Step1) in the itinerary message so that the MessageA can be transformed in MessageC in Step3?

Rob
Left by RobP on Sep 10, 2008 2:11 PM

# re: Itinerary Processing: Overview
Requesting Gravatar...
Hi Rob,

I don't think you can do this with a single itinerary, as effectively the steps are processed synchronously, with the output of one forming the input to the next.

If the requests aren't related (i.e. MessageA can be transformed to MessageC and routed to server2 without having been to server1) can you use separate itinerary requests?

Failing that, you could look at the scatter-gather pattern - a sample implementation comes with the Guidance package, which might be a starting point.
Left by Elton on Sep 11, 2008 9:36 AM

# How do you transform one xml message to multiple xml messages with different schemas using the Itinerary
Requesting Gravatar...
Hi Elton,
Thanks for pointing me in the right direction. The scatter-gather does the job using two orchestrations; a Broker and ServiceDispatcher.
The Itinerary can be setup with the scatter-gather with two steps:
Step 1 Uses two resolvers 1:Transform MessageA to MessageB and 2:Route for service1
Step 2 Uses two resolvers 1:Transform MessageA to MessageC and 2:Route for service2

The Broker calls the ServiceDispatcher with messageA once for each Step so that ServiceDispatcher can transform messageA to messageB and route to a service1 and then transform messageA to messageC to route to service2.

RobP
Left by RobP on Sep 12, 2008 5:36 PM

# re: Itinerary Processing: Overview
Requesting Gravatar...
I am trying to use an Orchestration in an Itinerary to transform using custom XSLT provided at runtime. I ran into problem and not able to resolve it. Can you point out where am I going wrong?

Once the orchestration gets the message, I need to perform two transformations before sending out the request to the WebService. And, When I get the response from the WebService, I need to perform another two transformations before sending it out to the caller. Note, that the transformations should be done using a .NET code and not using BizTalk Mapper. This is because the transformation logic is only available in the XSLT Style Sheet which would be available only at runtime. You can't user the mapper for the XSLT, because the path would be provided at runtime. I have written a Custom .NET code to do the transformations and I am able to pull call that code from the Orchestration and perform the transformation.


Initially, I thought of doing all this in an ESB Itinerary. The way I would do this is, one of the Itinerary Service would call the Orchestration to do the custom mapping using the XSLT style sheet provided at the runtime. Once the orchestration returns the transformed XML, another Itinerary Service would send it to the WebService for processing. When I get the response from WebService, another Itinerary Service would pick it up from there and call the Orchestration again to do the transformations before sending it back to the client. This is the perfect logic...

But where I am stuck is, one I get the transformed message back from Orchestration, I am not able to send it to WebService. The Itinerary Service that is supposed to pick this message and send it to Webservice isn't picking up. When I look at the event log, it says, The published message could not be routed because no subscribers were found. with status.

What could be wrong?? Do let me know. I would really appreciate your help!!! Is there any better way to do this?

Thanks a lot!!!
Left by Michelle Hartney on Jul 31, 2009 11:02 AM

# re: Itinerary Processing: Overview
Requesting Gravatar...
"Hi Rob,

I don't think you can do this with a single itinerary, as effectively the steps are processed synchronously, with the output of one forming the input to the next.

If the requests aren't related (i.e. MessageA can be transformed to MessageC and routed to server2 without having been to server1) can you use separate itinerary requests?

Failing that, you could look at the scatter-gather pattern - a sample implementation comes with the Guidance package, which might be a starting point. "

You took the words out of my mouth... agree completely.
Left by Jack Oliven on Jan 10, 2011 1:18 PM

# re: Itinerary Processing: Overview
Requesting Gravatar...
Check Online PEC 5th, 8th Class Result 2017 By Roll No, Name, School on 31st March 2017 after 10Am on pec 8th class result 2017 and pec 5th class result 2017 online on bond result.com
Left by Result PEC on Mar 26, 2017 7:39 AM

Your comment:
 (will show your gravatar)


Copyright © Elton Stoneman | Powered by: GeeksWithBlogs.net