After explaning the Itinerary in the previous post ESB Series – Part I and some of the components, it is now time to look at where the Itinerary is started.This post is about the On-Ramp, in this I mean the technical implementation using the ESB Toolkit.
If we consider the following ESB architecture overview, focused on ESB message processing;
We can see that the start of an On-Ramp is usually a port, using ESB Pipeline components, defined in an ESB Pipeline. So to get the whole picture, we need to understand the Pipeline. The ESB Toolkit provides a bunch, which are deployed in the BizTalk ‘Microsoft.Practices.ESB’ application. One of the changes of BizTalk 2013, is that this application can be installed (available after installing BizTalk 2013, or importing/installing these manually in earlier versions, and running the ESB configuration setup). And additionally, we need to configure the ESB Toolkit; What have you installed after these 2 steps?
- ESB Itinerary database
- Which contains the defined Itineraries (used to retrieve an Itinerar based on a resolver, at runtime, this will flow a long with the ESB context properties
- ESB Exception database
- Which contains all ESB Fault messages and context information, which is a fairly complete model and thus is a good choice over designing your own Exception handling model
- ESB Webservices
- These provides functionality such as a SOA TransformService, SOA RoutingService etc
- Microsoft.Practices.ESB application with ports (pre defined On-Ramps for custom usage or usage by a portal) of pipelines
We see 2 components;
- Itinerary Selector
- which determine the Itinerary, with the ‘BRI’ resolver which calls the Business Rule Engine to determine the Itinerary
- Or use a custom component to have an Orchestration as On-Ramp to start an Itinerary
- ESB Dispatcher
- Which is responsible for preparing the Itinerary with all the steps needed to execute the Itinerary (see the trace output below)