One of the tenacious key areas that have to be focused while plumping for an EAI product is to gauge its robust error handling mechanism. This is the most recurrent trepidation raised by the customers while evaluating the SAP XI. Here I propose a very generic error handling mechanism that is supported by SAP XI for handling various types of errors that can occur in various phases of SDLC.
There is a first-rated white paper on Error Handling Framework in EAI by Dheeraj Saxena that can be used for brushing up the concepts. We pigeonhole the error handling into the following categories:
I. Error Handling at the Complete Landscape.
II. Error Handling at the Interface Level.
III. Re-Start Capabilities of SAP XI.
IV. Potential of Message Monitoring in SAP XI.
I. Error handling at the complete landscape :
Technical errors (Ex: Adapter Failures, Cache Failures etc) are informed during message processing through errors. Depending on the business we can either receive the alert by e-mail, fax, or SMS and in each case you will also find the alert in your alert inbox. This is the inbuilt mechanism provided by XI and it has to define certain steps like alert categories, alert rules etc for the service to get activated. However we do not deal with the errors that occur outside the SAP XI .Alerts can be triggered from various points in the message processing like mapping, ccBPM and in the sphere of integration engine. The point where the alerts are triggered depends upon the interface and business requirements. Configuring alerts is detailed in the appendix section and one can use the guide for configuring the alerts in XI.Business and miscellaneous errors are dealt separately and vary based on business requirements per interface. Those errors can either be alerted/rejected/e-mailed on the record level or at the interface level based on the business requirements. The point of trigger also depends on the type and functionality of the interface. Errors can be reported at the adapter level, mapping or while routing. We have to design the appropriate mechanisms for each interface. We can also trace/log the errors for reporting them at the later stage by trading off between the performance and business requirements of the interface.
II.Error Handling at the Interface Level :
The Errors Handling can be categorised into following categories:1. Business Error
2. Technical Error
3. Miscellaneous Error
1.Business Errors :
A. Error Type : Logic Errors.
Examples : Invalid combination of data ,Invalid trigger data, Business constraints violated.
Handling Mechanisms :
A.1Validation mechanisms that are feasible can be built to generate the logic errors in an interface through Adapter module/mapping programs/ ccBPM (if Exists) via an email or configuring alerts in adapter monitoring of runtime work bench.
A.2. Depending on the criticality and type of the error, an appropriate error message with the error code can be mailed/alerted to the application support help desk.
B.Error Type : Format Errors.
Examples : Blanks not explicitly padded with spaces for character data ,Date format errors, File/Data Structure Format errors.
Handling Mechanisms :
B.1. Messages might be validated for uniform format errors that are business critical and some errors might be handled but if there is a huge disparity then the message is eroded out and notified to the application support helpdesk.
C.Error Type : Data Conversion Errors.
Examples : Lookups not available with specified keys, Error in mapping between disparate data types.
Handling Mechanisms :
C.1. For adhering to the performance standards we do not really lookup for dynamic values.
C.2. Mapping errors can be raised if required by business and an alert is triggered to the middleware support desk for correcting it who can request the source to re-send the message in case of data errors. We will define both source and target field data types as a string in case of disparity between the data types that will avoid errors of these kind.
2. Technical Errors :
A.Error Type : Communication Errors.
Examples : Database connections lost, Unable to execute transactional calls due to target system unavailable
Handling Mechanisms :
A.1. If the target system is unavailable and the data has to be pushed onto XI adapter (Ex: Sender File Adapter) then the target system has to re-send the data when available.
A.2. If the data has to be pushed from XI then messages are re-sent depending on the QoS of the configured adapter.
A.3. Transaction integrity is guaranteed by XI adapters as duplicate messages are not triggered from adapter queue.
A.4. The receiver system availability cannot be checked prior to sending the data from Integration engine to adapter engine but the data can be resent using manual or automated mechanism. The Interface has to be asynchronous for the data to be resent.
B.Error Type : Infrastructure Errors.
Examples : High disk usage stopping event persistence, High CPU usage bringing components down, Network related errors, Errors related to client libraries for remote calls in client server computing.
Handling Mechanisms :
B.1. Infrastructure errors can definitely happen when huge messages arrive at XI. Integration and adapter queues might get stuck due to which all the incoming messages from the other interfaces can be blocked. To avoid clogging we might design a distinct queue to handle it.
B.2. Queues can also be clogged if more messages arrive at XI and get stopped. Integration Queues can be re-started manually through smq1, smq2, smq3 transactions. Adapter queues can be re-started manually through adapter monitoring of the runtime work bench.
B.3. We can track the remote errors through the adapter monitoring provided by the runtime workbench.
3. Miscellaneous Error :
A.Error Type : Components down.
Examples : Executable components are down due to technical /infrastructure errors.
Handling Mechanisms :
A.1. Integration Engine or Adapter Engine or cache failures are reported to the support desk through the alerts.
A.2. Required How-To-Guides are provided in the upcoming series if the systems are not configured appropriately. This is SAP administration activity.
B.Error Type : Username / passwords changed and so on.
Examples : Login Information changed without changing configuration in connection utilities.
Handling Mechanisms :
B.1.This is the usual case in the File/RFC adapters etc. and the adapters might not work as the new username/passwords are not configured. We have to use the features provided by SAP XI latest versions to configure them centrally and dynamically.
C. Error Type : Scheduling errors.
Examples : Externally controlled batch job fails to execute .For Example; there could be a multi-step job.
Handling Mechanisms :
C.1. Jobs can be scheduled through event driven monitoring and job failures can be reported either via custom report or e-mail or alerts to the support desk.
C.2. However a job schedule error in the application system is not handled by XI team.
D. Error Type : Time constraint errors.
Examples : Certain actions are coded to time-out after specific intervals.
Handling Mechanisms :
D.1. Timeout exceptions can be triggered if we have to collect and bundle messages through the deadline monitoring branch of ccBPM.
E. Error Type : Threshold Errors
Examples : In certain scenarios , it might be required to throw an exception in case the total number of errors exceeds a certain threshold value. Handling Mechanisms :
E.1. The threshold value varies from project to project and can be set and alerted via an email using the alert mechanism of SAP XI.
With this we complete the two kinds of error handling mechanisms and wait for the next series to get a birds view of the complete error handling frame work.
9 Comments
