Orchestration Error handling: Fix-and-Log

Published 10 May 05 02:21 AM | dhtoran 

Abstract: An exception has been thrown, what should I do? --> At least two actions: Fix the situation and Log it

Orchestrations tend to fail. Sure. This is because the nature of integration: Orchestrations deal with external applications, and expect behaviors that are not always as expected.
Exception handlers should be everywhere where errors can happen. The rule of thumb is that “Suspended/Non Resumable state should never occur”.
Each exception handler should perform at least two actions: fix the situation and log it.

Fix the situation
Fixing means not allowing the orchestration fail into a suspended state, and notify all the caller process. This is usually done by creating an error response message, or valid response that contains no data, but some detail on the error, so the flow can continue in some way.
Note that using the same response message or a different and specialized fault message usually depends on the message schemas and other requirements.

Log
A common practice when handling with errors is to log full message or context data (or both!) using the Windows Event Log or any other log framework. Typically, developers log data about the exception, the state of the orchestration, the message that raised the error, etc.
With this practice is very easy to duplicate a lot of data, because BizTalk already stores all this data for you. This information can be found in the tracking database, using HAT. The problem with HAT is that is difficult to find useful info if you are not sure what you are looking for.
So what kind of information should you log in case of error? -> Enough info to:

1. know what kind of error happen.
2. know where it has happen
3. be able to find the details using HAT

Nothing more. This is the tip: don't log data that is logged by BizTalk. If there is an exception, BizTalk has the details. If message tracking is enabled, do not log message contents. Learn to use HAT efficiently, and you’ll save time and logging code.
Here is an easy sample of parallel Fix-and-Log:

 

sample picture of a Fix-and-Log exception handler

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# DJ said on May 10, 2005 8:50 AM:
Great post! You might want to rename the assignment action in the Create Valid Response construction action. :)
# dhtoran said on May 10, 2005 10:47 AM:
ups! I've added two assign shapes, just to improve readability...
# jorrytdevries@hotmail.com said on May 19, 2005 6:42 AM:
Hi, I've tried this, it all seens to work fine. The message i've got in return has the created error info. But also the message is suspended in the messagebox. How do I prevend this from happening?
# Art Owens said on June 13, 2006 5:58 PM:
I was trying something similar.
Can you send your source for this example.
# ... said on April 11, 2007 9:27 AM:

Ich erklare meinen Freunden uber diese Seite. Interessieren!

# ... said on April 13, 2007 11:47 AM:

Stupore! Amo questo luogo!:)))))))

# ... said on April 16, 2007 6:16 AM:

E grande io ha trovato il vostro luogo! Le info importanti ottenute! ))

# Biztalk 2004 Error Handling Best Practices | keyongtech said on January 21, 2009 9:18 PM:

PingBack from http://www.keyongtech.com/330385-biztalk-2004-error-handling-best

# David Hurtado s Integration Traces Orchestration Error handling Fix | Outdoor Ceiling Fans said on May 31, 2009 7:58 AM:

PingBack from http://outdoorceilingfansite.info/story.php?id=5103

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

Search

This Blog

Syndication

Page view tracker