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

Setting up a build server with the BizTalk Deployment Framework

Image
This chapter describes the steps to a TFS Build Server to set up BizTalk deployment with the following functionality: • Build solution • Perform unit testing Using BizUnit • Create Deployment Packages Using BDTF • Deploy to Server Using R packages created in previous step • Create documentation BizTalkDocumenter For this the following steps are required: • Installation Components (30 min) • Configuring a build account (30 min) • Setting up the build service (30 min) • Scrum template installation (30 min) • Share for the build output directory (10 min) • Adjustments Build Template for use BTDF (30 min) • Design of build definitions (60 min) • Setting BTDF (60 min) • Use BTDF • Build execution / scheduling UPDATE (21-06-2013) - When using sharedassemblies, the following URL is a big help http://mohamedradwan.wordpress.com/2013/01/31/set-custom-assemblies-path-for-host-build-service-on-the-cloud/ - For viewing the basic instructions a video is available on the following blog http:
Read more