ESB Toolkit Series – Part II ‘On-Ramp’

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;
image 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. image 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
No portal? The portal is a sample application that needs to be compiled and manually installed (discussed in the post ‘Scenarios’) If we look at the Pielines, we see that they are all related to ‘Itinerary’ which implies, that before we can have all these magic features, we need an On-Ramp to start with an Itinerary; image Note: There are a lot of Pipelines, some comparable to the Default BizTalk pipelines (Xml/PassThrough) with the same functionality (choice of Xml validation, promotion of properties etc) but in the ESB context, these determine if you would like to work with the typed message, or the abstract Microsoft.Practices.ResolverMessage), there is the FaultProcessor which is responsible for routing messages to the Exception database (Upgrade ESB SendPort from using SQL to supported WCF-SQL).   Let’s look at the details of the pipeline components; image
We see 2 components;

  • ESB Dispatcher
    • Which is responsible for preparing the Itinerary with all the steps needed to execute the Itinerary (see the trace output below)
  The screenshot above is from DebugView and can capture the ESB tracing, for this we need to enable this in the configuration. As the ESB Toolkit 2.2 is in the program files directory now specified without the version number. What’s next? image  In the next post, we will look at the 3 dynamic features of the ESB Toolkit which use the Business Rules Engine to determine 1.which Itinerary is selected, 2. which transformation is used and 3. dynamic routing.    General Series Overview
·         Itinerary
o   What is an Itinerary and how to view this from a BizTalk perspective
·         On-Ramp
o   How is an Itinerary executed, where does this happen
o   The ESB Toolkit adds functionality, but how exactly (dynamically)
·         Resubmit
o   The ESB Toolkit adds resubmit functionality, how can we extend this without using the ESB Portal
·         ESB Toolkit considerations
 Kind regards, Sander Tags van Technorati: ESB Series,BizTalk ESB


Popular posts from this blog

Azure implementation guidelines

Setting up a build server with the BizTalk Deployment Framework

BizTalk 2013, replace HTTP adapter by WCF-WebHttp REST