Mar 282013

Microsoft has asked Stott Creations to create a few ESB samples for the release of BizTalk 2013. We are finalizing those samples right now.

One thing I hate about the current samples that come out of the box with the ESB Toolkit, pharm is that they rely on other samples being created. If I want to learn how to do something, dosage there are steps on how to get the sample I care about working. The problem is that each first step states that another sample needs to be completed before you can start working on this one. I go to the that sample, and that example states that it relies on another sample being created first. All told, I have to create 4 different samples to get to the one that really want to work on. With each sample I incur a compound set of exponential opportunities to make a mistake. It generally means that I never get to the actual sample I want to work on.

That rant drove these samples to be completely self contained, so if you want to learn each of these, they rely on nothing else being done. 

Dynamic Endpoint


We will be showing how to use a purchase order to send to various end points. Our sample will be a messaging based solution where we will use a static itinerary resolver. The itinerary that it walks through will use the BRE to resolve both the map and the backend system it is going to. We will be showing that it can be sent to the following endpoints:

  • SQL: New PO processing Interface
  • File: Old PO Processing Interface
  • SMTP: Email to operations that this purchase order does not belong to this department
Defining Business Processes


We will be showing the following flow within the Itinerary Flow Designer:

  1. Receive Purchase Order
  2. Create Advanced Shipment Notification
  3. Warehouse Notification
  4. Email confirmation

We will show, using the BRE, how this same flow can orders, and how the end points, even though they are for the same flow, based on the data, will go to two different warehouses. The two different areas are defined in this map:

Once we show that is working, we are going to add another warehouse to the mix based on some new criteria, which means we add a new rule to the policy and it is now able to handle this new warehouse:


We will show a member verification process as part of an order process. This process will have the following steps:


  1. State Verification
  2. Item Verification

When, we will show that there is a new service that is brought online, and we will change the itinerary to add this new step, and watch the new flow without breaking any logic. We will deploy a new map, and add the additional step into the flow, deploy the new itinerary. The new flow will be:


  1. State Verification
  2. Member Id Verification
  3. Item Verification
Exception Handling


We are going to step outside of ‘ESB World’ and show a standard orchestration that fails, and that orchestration has been setup to send data to the exception handling mechanism. This means that the management console remains ‘empty’ and that the Exception Portal being configured for notifications that an email will be sent out notifying of the failure. The failure will be a mis-configured send port that is bound to the orchestration. We will show that you can resubmit the message back for the orchestration to reprocess it after the send port was corrected.

Repair and resubmit will also be shown, where you can modify the message (as the order will have 0 orders bought, which throws a separate error).

After resubmission, you see the process complete. Again, the best part of this that instead of suspended messages in the message box (I am sure you have never seen this in a production environment before), the messages go to the ExceptionDb and can be handled separately without clogging up the message box.

Mar 012013

So if you are creating itineraries, order and you need to stick an orchestration in your itinerary, there are two orchestrations that come out of the box.




However, if you are like me, you have found the documentation a little lacking, especially regarding these two orchestrations.

Looking at our previous blog entry about how to look at the shapes in an orchestration, I will describe what is going on with these two orchestrations.

Receive Msg

Gets the message from the message box called InboundMessage

Get Current Itinerary

Retrieves the current Itinerary, Itinerary Step, logs ServiceName and ServiceType to the Trace.

Retrieve Resolvers

Retrieves the resolvers associated to the itinerary at this step, and logs to the trace the number of resolvers at this step

Resolvers Returned?

Checks to ensure that there are resolvers present (resolvers.Count > 0)

Loop through Resolvers



Extract out of the resolvers, the current resolver, write to the trace, fill the resolverDictionary the items contained in the current resolver, log all of the items that are specified in the static resolver, set the transportLocation and transportType (internal strings)

Transport Info Returned

Ensured that the two strings have a length greater than 1

Construct Delivery Message/Set Delivery Message

Creates a new message from the InboundMessage called DeliveryMessage, sets the endpoint of the DeliveryMessage, sets the DeliveryPort’s address to the transportLocation and the deliveryPort’s transport type to transportType

Send Delivery

Sends the message off to the address

Catch Delivery Exception

Creates a fault message, sets the fault code to 2444, logs that An error occurred attempting to deliver message., sets the severity to critical and sends the message on

Catch Exception

Same thing except sets the fault code to 2555

and continues the looping through the rest of the resolvers

Advance Itinerary/Construct Outbound Message/Set Advance Itinerary

Creates a new message called OutboundMessage from the InboundMessage, advances the OutboundMessage itinerary, writes it, logs the ServiceName, SeriviceState, and ServiceType.

Catch Exception

If it throws an exception it logs it as 2555 and logs that there was an Exception while attempting to Advance Itinerary

More Itinerary Steps

Checks to see if the state is complete ( itineraryStep.ItineraryStep.State != Microsoft.Practices.ESB.Itinerary.State.Complete )

Send Message

Sends the OutboundMessage back to the bus

Construct Post Itinerary Fault Message

Logs 2777 with the following error message ‘Unable to persist routed message, are there subscribers for it?’

Catch Routing Resolution Exceptions

for some catastrophic error. a fault message is created with error 2111 with the error Exception while attempting to work with Itinerary Step

Use case

If you need to take your message off of the bus and send it out (Scatter pattern), this is the orchestration to do it.



Receive Message

Receives InboundMessage from the bus

Get Current Itinerary

Retrieves the current Itinerary, Itinerary Step, logs ServiceName and ServiceType to the Trace.

Retrieve Resolvers

Retrieves the resolvers associated to the itinerary at this step, and logs to the trace the number of resolvers at this step

Resolvers Returned?

Checks to ensure that there are resolvers present (resolvers.Count > 0)


Gets the current resolver, takes the items from the static resolver and adds it to the dictionary, logs it to the trace, and sets the transformType

Map Name Returned?

transformType.Lenth > 0

Construct Map Resolution Fault Message

Sets fault code to 1111 and logs Exception while attempting to determine map type, creates fault message and send it off

Construct Outbound Message/Construct Outbound Message

Executes the transform and advances the itinerary and drops the OutboundMessage off to the bus

Set Mp Exception Fault Message (sic)

Sets fault code to 1444 and logs Unable to retrieve the the Type for map type: the map

Set Map Execution Fault Message

Sets fault code to 1222 and logs Exception while attempting to apply map: the map

Use Case

You want to execute a map on the bus, you can add this service, specify the map in the resolver, and the map will be transformed and placed back on the bus.

(A close friend asked me if there was a way that multiple maps can be executed in a row in the ESB. This is a perfect service to do just that. Just remember, that only the first resolver will be invoked (any others will be ignored), so if you need multiple maps executed, you need to add multiple services chained together each with one resolver and you can incrementally map the data.)