• 2 replies
  • Latest Post - ‏2011-03-07T15:02:39Z by SystemAdmin
100 Posts

Pinned topic Best Practices for Error Handling?

‏2008-09-16T03:06:46Z |

What are the Best Practices for Error Handling within Orchestrations?

Updated on 2011-03-07T15:02:39Z at 2011-03-07T15:02:39Z by SystemAdmin
  • SystemAdmin
    100 Posts

    All projects must contain


    All projects must contain basic error
    handling to ensure that there is no possibility that a customer will
    lose data without any notification. The Catch All branch and the
    Try/Catch All activities handle fatal errors in an orchestration such
    as failures to parse a flat file, primary key violations, connectivity
    problems, and mapping exceptions.
    Catch AllThe Catch All branch is an all-encompassing branch that
    will catch all fatal errors that occur in an orchestration. It provides
    the opportunity to log the error, giving the customer the opportunity
    to react to the situation. The recommended practice is to add the Catch
    All, make a call to a generic error handling routine, and then
    terminate the orchestration. The Terminate activity will ensure there
    is variable logging in the WMC when logging is set to ‘Error
    Values.’ The Catch All activity emits three variables: the fault name,
    the fault data, and the fault information. Pass this information to the
    error handler or emit the crucial information through a Create Job Keys

    Try/Catch AllThe Try/Catch All activity allows the orchestration to
    catch exceptions from an individual activity. The Catch All component
    of the activity allows the user to gracefully handle the error and
    decide whether to continue or terminate the job. You must be aware of
    the type of error that the activity will throw. For example, will only throw an exception if there is a SOAP fault
    due to an invalid login or a problem with the external id in an Upsert
    activity. Handle all other errors through validation of the response
    message. For a database update, failure to update any data is not an
    error, whereas violation of a primary key constraint is an error.
    Some more Tips & Tricks:

    • - When doing transactions in bulk, store the chunk in case of a
      failure and send it as an email (Recommended, as we can’t drill down to
      the specific record thats causing the exception).

    • - When doing transactions with SF/ WS activities, do a specific try/catch for those.

    • - You can talk about the standard exception handler (and its
      shortcoming, that is we can’t invoke it for bulk records, it has to be
      done one-by-one).

    • - Use Job Log keys in the orchestrations as often as you can.

    • - Recommendation: Do transactions in bulk using stylesheets as opposed to one-by-one.

    • - Look at this for SF exceptions:

  • SystemAdmin
    100 Posts

    Add a catch branch?

    Can someone tell me how to add a specific catch branch?  I am able to add the branch, but cannot enter the specific exception to catch.  The Fault Name drop-down is empty.
    I have the Try/Catch around a single Update Rows activity.  I want to catch database connection exceptions separate from row level exceptions like field too long.