Siebel Error Handling Approach

Introduction

Error Handling or Exception Handling, is an essential part of any Siebel project, but where does it come from?. Unlike other commercial development environments, Siebel dosnt provide a standard error handling framework out of the box, or even as a third party add on. Surprising as it sounds, It is left up to each project to implement their own specific error handling capability.

Importance of Error Handling

"Jason, can you help me, my Tools is corrupt, the WF designer discards every one of the error branches that I try to create!"

"I see the problem, you are not providing the Error branch with a name"


The above is a real life scenario of a senior consultant not knowing how to handle errors in Workflow. While Error Handling is important, it seems not everyone knows how to implement it. Its an issue that plagues many developers, because the first step in development is to ensure our build is working first, before we can really understand the circumstances around how it could fail. It requires experience and forethought, to build to components with robust guards in place.

Not everyone gets it right the first time, but that's okay, because robustness is improved over time, but more alarmingly, not every developer designs with Error Handling in mind, nor goes back and puts error handling in place after the build is unit tested.

Error Handling Standards and Features

Error Handling is more than just using TheApplication().Trace at key points in your program, and it is not limited to scripting. Error Handling frameworks vary from project to project, but the fundamentals should remain the same.

Here is a list of ideas, which I've separated into 5 categories, that you could incorporate into your Error Handling Approach.

Scripting
★ Ensure call functions are wrapped in try/catch/finally
★ Put return statement after the finally block
★ Errors should be bubbled up, and handled at the place of invocation
★ Capture stack trace
★ Capture state of variables

WF
★ All major steps should have unhandled exception branches and error checks
★ Unhandled Exceptions should capture as much context around the error as possible
★ Sub processes should return an error property to the parent WF where the error is handled
★ Parent WFs should utilise the Error Process Property or route Errors to a standard project Error Handling Sub Process

Integration
★ All Outbound/Inbound messages should be logged
★ Capability to recognise and handle SOAP Fault and SOAP Warnings accordingly
★ Capability to handle non committed Enterprise transactions
★ Retry capability

BRP
★ Validation errors shouldnt be put into the system error property
★ Errors should be bubbled up, and handled at the place of invocation

General
★ Logging framework to allow debugging
★ Message Lookups
★ Settle on a standard Error Property
★ Provide generic friendly message

Some of the above ideas are standards that need to be enforced through training and technical reviews, while others are capability and tools that needs to be built to support the error handling needs of the project. Some projects take the idea a little further, and provide help desk features such as error assignment, capturing resolution and KPIs.

Show me the details

When an error occurs we want to log as much information as possible, at the point where the error occurred, and depending on the severity, we can make an informed decision on whether to fix the issue straight away or defer it to another release.

Some of the most important error details to log are


★ User Name
★ Error Time
★ Host Name
★ Primary Id
★ Internal Error Code
★ External Error Type
★ External Error Code
★ Error Message
★ Error Category
★ Transaction Time
★ Calling Function/WF
★ Stack Trace
★ XML Logs

Until next time

Imagine that you have an application in production, your users are getting generic error messages that is of no absolute value, and you have to spend hours trying to recreate the issue to get to the bottom of the problem. At this point, you are probably wishing that you had better Error Handling capability, but it is too late, because you know you would have to live with this until the next release, so don't let poor error handling slip by unnoticed.

Having full details of the error, provides you with the confidence to resolve issues, or ignore problems and move on, and defer fixing it in the next iteration of your development. Any reputable System Integrator would have an Error Handling Framework ready, that they would have carried over from past projects, or even if you've got an in-house project, there's nothing stopping you from drawing on the experience of your consultants, or use the above list as fuel, to build your own Error Framework.

Handling errors when working with EAI, requires more specialised capability, and in the follow up to this article, we go through the design process of how to implement the XML logging feature listed above, and in the tradition of Impossible Siebel, bypass a Siebel limitation a long the way.

Part 2 continues here


2 comments:

  1. Just out of curiosity, what's the right way to handle workflow errors then? Your "real life scenario" happened recently to me, *exactly* as you described it. And I solved it just by providing names to the error branches. Should I have done something more/else?

    ReplyDelete
  2. Hi

    Providing names for the error branches is a must.

    As to how to handle errors in Siebel, please consult with your local dev team for specific standards, which may be applicable to your own project.

    ReplyDelete

Comments are open to all, please make it constructive.