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, but also from any step! This can be useful to ‘manually fix’ a step in the process where you are not able to fix the request or know that a certain step fails. This also opens up the door to add an ‘Itinerary Submitter’ which can replace all the default ‘On-Ramps’ which are using various techniques (asmx allows for Resubmit using the Itinerary…., WCF uses the Itinerary from the database, thus has no state).
We want to specify which ESB Toolkit Itinerary step to start to perform a resubmit
Attempt #1 – Change the state of the Itinerary services (assumption: Itinerary is processed based on the service state of any of the services)
Attempt #2 – Change the position of the Itinerary metadata (assumption: Itinerary is processed based on the position of the Itinerary metadata)
Attempt #3 – Change the Name of the itinerary metadata (Assumption: name of the Itinerary metadata is used to start the correct itinerary service
Errors for #1-3: There was a failure executing the receive pipeline:.....Reason: The service instance does not have the same properties as the first pending service.
Attempt #4 – Change the position, State of previous Services before the position, Name of the Itinerary metadata
How did I do this? We need to change the Xml, this is attached in the context by the ESB Pipeline components, which can be manipulated using the component Tomasso has written. He originally posted on having an Orchestration as on-ramp to start an Itinerary. I figured that changing the state should be possible with that component as well.
I made a few changes;
Crucial part of code
// serialize the updated itinerary and update this in the resolver dictionary (ESB context)
using (StringWriter sw = new StringWriter())
sw.Flush(); // ensure all data is written
itineraryData = sw.ToString();
Testing…..start at the last step! Attempt #4 – result
What I did, was create an custom Orchestration with a published WCF On-Ramp, I am now able to start an Itinerary, but also start the Itinerary from any step. This allows me to create a very flexible Error building blocks which can easily be integrated in existing portals.
If we then look at the ESB ExceptionDatabase, we can use the information from the various tables, to display the Faults / Message and retrieve the Itinerary;
Fault: Metadata related to the fault
Message : Metadata related to the message
MessageData : The payload of the message
ContextProperty : contextproperties related to the message in MessageData
- Name (e.g.. : Itinerary)
Retrieving the Itinerary is possible using the contextproperty ‘ItineraryHeader’ ;
As I cannot share anymore code than this, I’m sorry the full solution is not provided, however, this should get you going! An example of a tool I created to prove the functionality works, before we integrate this in a custom portal looks like this.
· Retrieve all the Faults and related Messages with an Itinerary attached
o Linq datamodel to query the ESBException db easily
· Display the Itinerary and Services (Deserialize the Itinerary) and select the Itinerary Step to start
o Reference to the Itinerary OM Model (Assembly)
· Send a new request which starts at step #
o Combination of all the information in this post
This now allows you to:
· Use the ESB Toolkit to define your processes (I mean business processes) in a more abstract way by using the Itinerary instead of tightly coupling this in your Orchestration
· Use the ESB Toolkit Exception handling without having the need to use the ESB Portal
· Implement functionality in your own preferred portal, using your preferred method