Integrating to the max...BizTalk Style

  An Itinerary determines the business flow, when the business flow is interrupted we would like to be able to restart a process. When can do this with the ESB Portal, but this portal is not always the way to go (I will post more on that in the do’s and don’ts).   If we look at the options we have to resubmit a message in the ESB Toolkit context, we can;     I am now talking about the last option – Restart the Itinerary at step X;     Note: The ESB Portal allows you to resubmit a message, however, always starting from step 1.     The Itinerary is a fancy DSL diagram, and can be exported to Xml as which it is used inside the ESB Toolkit;     You can export to Xml and directly into the Database (depending on what you prefer for your release management);     So based on the component described in the orchestration on-ramp I thought that it should be possible to not only resubmit a message from any process, ...

  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;   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 ...

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 c onsider 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 B izTalk  ‘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 data...

As there are a lot of resources available on the following pages, there is no need to dive into the ‘what is an ESB’, ‘what is the toolkit’, ‘how to install’. Understanding the ESB Toolkit Glossary Survival guide However, the ESB Toolkit is quite complex;   …and I know that not everything it yet clear, described, and I hope to fill in this gap all combined in the ESB Toolkit Series In this post we will look at the ‘Itinerary’, Itinerary - An itinerary is a set of steps, where each step performs an action e.g. message transformation, routing, orchestration execution. The next three components i.e. Pipelines, Pipeline Components, and Adapter & Resolver Framework together provide dynamic resolution of End Points, Transformation maps and Itinerary based on message context. Great! But what is this?   First question - how does it look? Second question - What do we see? If we open an Itinerary, we see a designer, which defines all th...