Error Handling Framework XI(Out-of the box)-Episod...

STALANKI · ‎11-23-2006

As rightly pointed out my SDN pal Naveen this blog is not for those eagerly awaiting for a solution to address the pain points of existing error handling framework but for those who are combating with bits and pieces of zigzag puzzle for getting a complete picture of error handling supported by SAP. I get lots of requests to give a single shot info for error handling mechanisms and various tactics to handle errors. Hence the blog is here! I will also come up with a solution approach for addressing the pain points of existing framework in the coming few days. Read through Error Handling Framework XI(Out-of the box)-Episode 1.

III.Restart Capabilities

This framework provides with mechanisms to resubmit failed transactions at the correct point in the message flow cycle. This is often a critical requirement in case of transactional data wherein it is undesirable or in some cases even impossible to regenerate data at source for either technical or business reasons. Another important benefit of being able to resubmit transactions at the correct point is that data duplication is avoided.

Messages in XI can fail due to many reasons. Most of the common failures are due to connection failure to end systems, wrong or missing configuration settings, exceptions that weren't handled or lack of disk space for processing messages. These errors can be categorized as those generated in:
1. Integration Engine.
2. Adapter Engine.
3. Business Process Engine.

We should be able to restart the failed messages through numerous ways in XI through the ABAP and JAVA stack depending at the point of the error. Some times for adhoc errors we might need to reconcile them through a ccBPM or develop a custom report for re-starting the messages at the correct point of failure if the standard re-start mechanism cannot be used. Further Details are enclosed in the appendix which provides a detailed guide for re-starting the failed messages.

IV. Monitoring

Error handling does not end with logging the errors and tracing .The production support team won't be looking at the logs every now and then to check if an error got logged. Agreed that most of the time your users would be the ones raising the issue, but having a "monitoring" tool that looks at your log and notifies you has immense benefits. So, it is an essential part of the error handling approach.

The central monitoring of SAP Exchange Infrastructure (XI) offers you the option of executing various monitoring activities. Primarily, you use the Runtime Workbench, the central tool for accessing XI monitoring. The Runtime Workbench gives you the option of navigating to the monitoring functions of the Integration Engine, as well as integration with the Computing Center Management System (CCMS), and the Process Monitoring Infrastructure (PMI) of SAP. The CCMS and PMI needs to be configured by the SAP administration team if we have to use this as a mode of monitoring the ABAP and JAVA Stack of SAP XI

The monitoring of Messages in the Integration Engine can be done using transaction SXMB_MONI and SXMB_MONI_BPE.
SAP XI monitoring offers you the following options:
1. Component monitoring
2. Message monitoring
3. End-to-end monitoring
4. Performance monitoring
5. Index administration
6. Alert configuration
7. Cache monitoring

By using the monitoring tool we can establish the stats of what errors are happening most frequently and ask your developers to fix them. For Ex: The monitor sees that in the last few minutes 50 errors have been logged and realises that business is about to raise a high severity issue and might send a threshold error to the production support team. This feature can be configured as per the criticality requirements of the business.

Appendix