Share via

BizTalk: Error Message Routing Pattern

  • Article

This topic deals with Error Message Routing Pattern Demo.

Where can you use this? One of the examples may be when your send port end point is erroring out or the subscriber to a RP is unavailable for some reason(For example may be a a send port working in a time window) then you will bump into a scenario where in a message comes in on a receive port and doesn’t finds a subscriber which it would have had it come between the defined time window ***or  ***where you may see the Zombie message scenario (Let me accept it is not a very ideal solution to handle the Zombies but may fit your need, one never knows).   It is going to leave you unconsumed messages suspended messages in BizTalk, if you choose to terminate them it can lead to data loss scenario . Even if you resume these messages they going to suspend back because there instance subscription is no longer valid(In case the response was to consumed by orchestration). You may want to handle them and this is one of the way on How can you do it.

I am trying to demo how can handle this.

Lets Create The Non Subscribed Orphaned Message Scenario

1>Create a receive port with the “Enable Routing Failure For Failed Message” ticked in.

https://psrathoud.files.wordpress.com/2014/06/rcvport.png?w=300&h=241

2>when you drop a message which has the subscriber defined it will be consumed by the respective BizTalk artifact. Now if you drop a message which has no subscriber defined: You will have a suspended message with no subscriber found error. So you have your orphaned message created at this point in time. The need is to handle it and route it to appropriate destination. This is how you are going to handle this.

3>Create an directly bound to message box orchestration with the following  subscription

(ErrorReport.ReceivePortName == “Your receive Port Name Where You Are Expecting The Orphaned Or Zombie Scenario To Occur”)

In case your orchestration has to subscribe to the failed messages at a send port then above property will be changed to ErrorReport.SendPortName.

Define the business logic you may need in this orchestration.

4>Once you start this orchestration you will no longer see the suspended messages, all of them would have been consumed by them. However you will still see a suspended non resumable routing failure class report which is a kind on notify only event from BizTalk. You will have to clean them once in a while.

On the send side if you need error routing here is the property needed to be selected:

https://psrathoud.files.wordpress.com/2014/06/untitled.png?w=630

*** Note: In case you need to create  Zombie message scenario then design a sequential convoy orchestration and once it exits the collect loop add a delay of 1 minute in logic. So if during the delay of 1 minute you drop a message for this orchestration it will behave as Zombie.***

This Is How It Works

  1. BizTalk Receives messages  on  Receive Port : Your receive Port Name Where You Are Expecting The Orphaned Or Zombie Scenario To Occur
  2.   If any of the message coming into the BizTalk server doesn’t finds a subscriber message will get suspended and create non resumable “Routing Failure Report”
  3.   Now post suspension the Receive port is configured to handle a failure by creating a promoted failed error property for the message : **ErrorReport.ReceivePortName **.
  4. The orchestration handling the orphaned message  is listening on any message  error property(ErrorReport.ReceivePortName) on the same receive port which suspended the message, which is now created(Note: The property only gets promoted  after the message is suspended)
  5. The orchestration handling the orphaned message subscribes to the failed message and does its business logic to route to destination system.