Siebel Workflow Error Handling

Most Siebel implementations have created custom solutions for capturing errors. A custom extension table, to store the error, and a custom business service (or workflow), to populate this table. This custom error handling can be called from all sorts of objects.

Workflows can be equipped with error handling as well. The most common way is to connect each step in the workflow with an error handling step. You can use the Error Exception lines for this specific connections. The workflow will automatically continue with this error exception when an error occurs within a step. This solution works perfectly well in most cases. The biggest disadvantage of this solution is the large amount of red error exception lines in workflows containing many individual steps. Each step needs to be connected to your error handling step. This will make the workflow very hard to read and understand.

Alternative

A more elegant way of applying error handling to a workflow is to use the “Error Process Name” property of the workflow. Here you can specify a workflow which will handle the error from the parent workflow. If an error occurs in the parent workflow, the error process is called. The error process receives all workflow process properties with matching property names. By default these are:

– Error Code;
– Error Message;
– Process Instance Id;
– Siebel Operation Object Id;
– Object Id.

You can also add your own properties. For example, if you want to provide the workflow process name to the error process, then you will have to create a workflow process property with the same name in both workflows. For example, create a property named: “WFName”. Default this property in the main workflow with the name of the workflow. When an error occurs in this main workflow, the default value is passed on to the error process.

When not to use

When your workflow should raise a custom error to the GUI via a workflow Stop step, you should not populate the workflows “Error Process Name” property. The error process will simply suppress the error from the stop step and log it into your error table. The error will not be shown to the user in the GUI.