ESB Toolkit Series – Part III ‘Itinerary, Transformation, Endpoint Resolution and Routing’

 

If we look at the ESB toolkit, it allows for flexibility by several features, of them, I would like to explain three which I think need some clarification;

Abstraction of your business process

by defining these as building blocks, using them inside an Itinerary, which allows you to re-use these blocks

Runtime Transformation

instead of configuring this using In-Outbound maps / maps being called in Orchestrations

Dynamic Endpoint resolution

instead of setting this using a pipeline / orchestration in dynamic maps, or static send ports

 

If we look at the ESB Toolkit dynamic features, it builds on the Business Rule Engine, by providing Vocabularies;

image

 

Abstraction of your business process

In this scenario, we can use the Business Rules Engine to determine which process to start. In classic BizTalk we do this in general, based on the MessageType. The ESB Toolkit, allows you to do this in a different way. You can basically, dynamically start your process based on information in your message, and as an Itinerary is set of abstracted building blocks, we can design our system to be even more loosely coupled.

The On-Ramp will determine which Itinerary to start, this by using ‘The Resolver and Adapter Provider Framework’. In the On-Ramp when can select the Itinerary (with the ItinerarySelector pipeline component), which can select the Itinerary to use (using a ‘static’ itinerary, determine it by using ‘Xpath’ or call the rule engine using a so called BRI resolver).

Let’s consider the scenario, where a message depending on a value in the message, should start a specific process;

image

 

  • We Create a Rule which looks into the message

image

 

  • Inside the Rule we set the Itinerary name

image

  • We call the Rule from the On-Ramp using the BRI resolver and the ItinerarySelect pipeline component will add the Itinerary services to the Itinerary and start off the Itinerary

image

 

Once the Itinerary is started, we can call so called ‘ItineraryServices’. Which are available in Messaging Services and Orchestration Services (custom).

Runtime Transformation

Runtime transformation, allows to determine the map to use by calling a business rule (for instance, based on a message). This is something we can do in our Itinerary, by leveraging the TransformService (which is an Itinerary Service of the type ‘Messaging’);

image

Note: This uses a BRE Resolver, it is also possible to use other resolver like a static / Xpath / BTDF SSO etc.

With the BRE Resolver, we can set the map to apply;

image


Dynamic Endpoint resolution

Dynamic endpoint resolution allows to determine the endpoint to use at runtime, so we can use a rule to determine (for instance

The last service we can call (besides orchestrations) is to determine the endpoint;

image

This allows us to dynamically define the Endpoint, based on a rule, which can be done inside an orchestration, but since we prefer to work message based, this is now something, which provides for more scenarios. This also works using a resolver; static, or dynamically by calling a BRE resolver;

image

 

We can test all these features with the ESB Rules Test tool! And after using it, I added a small dialog which allows you to pick the Rule from the BizTalk Rule Store..

 

Changes v1.1

“Sander Nefs, a fellow integration specialist has added the PolicyPicker feature to pick the name of the Policy from the Microsoft.RuleEngine” Glimlach

What's New For This Release
- PolicyPicker

 

How to test Specifying an itinerary

Open the XML file in the TestTool and specify the following properties:

  • Select the “ESB.Itinerary” Fact.
  • Enter the name of the Policy in containing the Business Rules.
  • Enter the Document Type of the message.

How to test Dynamic transformation

Open the XML file in the TestTool and specify the following properties:

  • Select the “ESB.TransformInfo” Fact.
  • Enter the name of the Policy in containing the Business Rules.
  • Enter the Document Type of the message.

How to test Dynamic Routing

Open the XML file in the TestTool and specify the following properties:

  • Select the “ESB.EndPointInfo” Fact.
  • Enter the name of the Policy in containing the Business Rules.
  • Enter the Document Type of the message.

 

So, hopefully this has shown more about the capabilities of the ESB Toolkit, the usage and even ways to test this (even with some modifications by automated Unit testing).

 

 

Regards,

Sander

Comments

Post a Comment

Popular posts from this blog

Azure implementation guidelines

In My post ‘ Service Bus Management ’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments. Follow this link to the ‘Azure Implementation Guidelines’ HTH, Sander
Read more

Focus and innovation - recap of the last 2 years

It's been a long time since my last post. Hereby a partial explanation for that, with the note that this blog will remain active for the purpose of being a resource for historical references. My IT career started with programming, and adventures within holland, as well as overseas. When I realised programming is something you can specify, I figured that providing added value is crucial for a long term career and decided to focus on process centric roles. I started with webservice integration and eventually from that to process integration using BizTalk. The great feeling when discussing high level processes and implementing solutions within days, even highly scalable and interfacing with LOB systems is great. After several years of implementing solutions like these, I started questioning if all of this work was justified by the business case, if the solution was actually contributing, if the choices had been valid. In other words, I needed to understand the choices made. When...
Read more

BizTalk Pub/sub vs Topics based routing–discussion

My colleagues and I had a brief discussion about the subject ‘Topics’ and what it brings… Do you all agree/disagree with the following statement: topic-based pub-sub messaging doesn’t really exist in BizTalk “In my opinion; I disagree, as BizTalk offers the following 'out-of-the-box' • Message Routing (f.e build in context properties like message type, trading partner, operation etc) • Content Routing (f.e. promoted properties, message inspection in orchestrations/pipelines icw orchestration logic)” My colleague Rene Brauwers Here my 2 cents…. I agree that it exists...however the current offerings in BizTalk are tightly coupled, making the usage far from perfect. When doing content based routing on custom fields (promoted properties), you will be making the solution message-coupled; Your custom message property schema is deployed, and the message filter on these fields have a direct relationship with this property schema. Making any change to this schema will g...
Read more