Orchestration Error handling: Fix-and-Log


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


Comments (9)
  1. DJ says:

    Great post! You might want to rename the assignment action in the Create Valid Response construction action. 🙂

  2. dhtoran says:

    ups! I’ve added two assign shapes, just to improve readability…

  3. jorrytdevries@hotmail.com says:

    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?

  4. Art Owens says:

    I was trying something similar.

    Can you send your source for this example.

  5. ... says:

    Ich erklare meinen Freunden uber diese Seite. Interessieren!

  6. ... says:

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

  7. ... says:

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

Comments are closed.

Skip to main content