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

Post a Comment

Popular posts from this blog

Azure implementation guidelines

In My post ‘ Service Bus Management ’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments. Follow this link to the ‘Azure Implementation Guidelines’ HTH, Sander
Read more

Focus and innovation - recap of the last 2 years

It's been a long time since my last post. Hereby a partial explanation for that, with the note that this blog will remain active for the purpose of being a resource for historical references. My IT career started with programming, and adventures within holland, as well as overseas. When I realised programming is something you can specify, I figured that providing added value is crucial for a long term career and decided to focus on process centric roles. I started with webservice integration and eventually from that to process integration using BizTalk. The great feeling when discussing high level processes and implementing solutions within days, even highly scalable and interfacing with LOB systems is great. After several years of implementing solutions like these, I started questioning if all of this work was justified by the business case, if the solution was actually contributing, if the choices had been valid. In other words, I needed to understand the choices made. When...
Read more

BizTalk Pub/sub vs Topics based routing–discussion

My colleagues and I had a brief discussion about the subject ‘Topics’ and what it brings… Do you all agree/disagree with the following statement: topic-based pub-sub messaging doesn’t really exist in BizTalk “In my opinion; I disagree, as BizTalk offers the following 'out-of-the-box' • Message Routing (f.e build in context properties like message type, trading partner, operation etc) • Content Routing (f.e. promoted properties, message inspection in orchestrations/pipelines icw orchestration logic)” My colleague Rene Brauwers Here my 2 cents…. I agree that it exists...however the current offerings in BizTalk are tightly coupled, making the usage far from perfect. When doing content based routing on custom fields (promoted properties), you will be making the solution message-coupled; Your custom message property schema is deployed, and the message filter on these fields have a direct relationship with this property schema. Making any change to this schema will g...
Read more