ESB Toolkit Series – Part IV ‘Resubmit’

 

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;

 

clip_image002

 

I am now talking about the last option – Restart the Itinerary at step X;

 

 

image

Note: The ESB Portal allows you to resubmit a message, however, always starting from step 1.

 

clip_image004

 

The Itinerary is a fancy DSL diagram, and can be exported to Xml as which it is used inside the ESB Toolkit;

 

clip_image005

 

You can export to Xml and directly into the Database (depending on what you prefer for your release management);

 

clip_image006

 

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

 

clip_image008

 

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)

 

clip_image009

 

Attempt #2 – Change the position of the Itinerary metadata (assumption: Itinerary is processed based on the position of the Itinerary metadata)

 

clip_image010

 

Attempt #3 – Change the Name of the itinerary metadata (Assumption: name of the Itinerary metadata is used to start the correct itinerary service

 

clip_image011

 

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

 

clip_image012

 

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;

clip_image013

clip_image014

 

Crucial part of code

 

// serialize the updated itinerary and update this in the resolver dictionary (ESB context)

using (StringWriter sw = new StringWriter())

{

ser.Serialize(sw, it);

sw.Flush(); // ensure all data is written

itineraryData = sw.ToString();

}

 

msg.SetPropertyValue(typeof(Microsoft.Practices.ESB.Itinerary.Schemas.ItineraryHeader), itineraryData);

 

 


 

Testing…..start at the last step! Attempt #4 – result

 

clip_image015

 

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.

 

clip_image017

 

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;

 

image

 

  Fault: Metadata related to the fault

- application

- description

- errotype

- failurecatagory

- faultcode

- faultdescription

- faultseverity

- scope

- faultgenerator

 

  Message : Metadata related to the message

- FaultID

- MessageName

- InsertedData

 

  MessageData : The payload of the message

- MessageID

- MessageData

 

  ContextProperty : contextproperties related to the message in MessageData

- MessageID

- Name (e.g.. : Itinerary)

- Value

- Type

- InsertedDate

 

Retrieving the Itinerary is possible using the contextproperty ‘ItineraryHeader’ ;

 

clip_image019

 

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.

 

clip_image021

 

 

Features

·         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

 

 

 

 

Kind regards,

Sander Nefs

 

Tags van Technorati: ,,

Comments

Popular posts from this blog

Azure implementation guidelines

UK Connected Systems User Group – BizTalk Services questions

Setting up a build server with the BizTalk Deployment Framework