Skip to Content

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.
Error Handling

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.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Anonymous
    Hello Sravaya,

    In the last 2years there have been many blogs/articles addressing the issue of errors. Though these were not addressed under the same umbrella like your attempt. I hope you plan to bring out something new in this series.

    Topics like
    1. Different types of errors,
    2. ways to restart failed messages,
    3. monitoring error messages ,
    4. different places to monitor,
    5. different alerts,
    6. logs for viewing errors
    are all common knowledge at this point of evolution of XI.As per the title I hope you are trying to throw more light on the out of the box provided functionalities available in XI.

    SAP is putting a lot of time and energy addressing the above mentioned issues making them very user intutive. Many focus groups have been gathering information from customers regarding things and processes that could potentially make a difference in how we conduct trouble shooting.

    As a result in the coming Sps of Pi7.0 SP7-10 monitoring/ error handling / and payload modification / NWA for monitoring is going to be bolstered with more functionality.

    I hope your series is going to address the new features than dwelling over the known facts of XI.

    Again thanks for writing very interesting blogs.


    1. Sravya Talanki Post author

      Firstly I am trying to formulate a generic error handling framework and then coming up with a solution approaches for better error handling.

      Yes.I do agree there are lots of bits and pieces of
      information but we do require a consolidated one which can give a birds view and then delve into the solution approaches.

      The reason I have structured that way because SAP XI being a new product, I get lot of mails daily where to start for getting onto XI?Most of them are not from EAI background and typically not even know the terminologies of EAI.

      I always like to give a complete picture and then delve into very technical details later to suit all kinds of readers:)…

      Probably you can just read the the solution approach blog that is scheduled in few days.

      1. Anonymous
        Hello Sravya,

        >>Firstly I am trying to formulate a generic >>error handling framework and then coming up >>with a solution approaches for better error >>handling.
        Is this something you are planning on building over what is available in XI???

        >>I always like to give a complete picture and >>then delve into very technical details later to >>suit all kinds of readers:)…
        You are a seasoned writter , with some very good articles. Your approach towards a topic is really commendable. I was kind of lost looking at the title. I wasn’t sure if you are building a custom framework for error handlying or using the existing approachs.

        >>Probably you can just read the the solution >>approach blog that is scheduled in few days.
        A technical document from you would be very good.


        1. Yallabandi Rajesh
          Nice blog sravya….
          Itz really adequate info…

          In the handling mechanism part:
          juzz highlight the SAP recommendations / Solutions as links (blogs/threads/notes/How to…).

          ‘n good work done by U, keep it up…

          Best regards,
          Rajesh Y.

        2. Sravya Talanki Post author
          Hello Naveen,

          Point Taken.I will change the title.
          Iam going to come up with both to suit all kinds of readers and requests.

          I will come up with pain points of XI error handling and the approach for overcoming the problems in coming few days.

  2. Anil Kumar Veepuri
    Hi Sravya,

    >>>>We have to use the features provided by SAP XI latest versions to configure them centrally and dynamically.
    What exactly do u mean by the above statement? i dont know how to do that as i haven’t seen such feature in XI so far if i’m not wrong.Can v maintain even the user authentication details in the File adapter some where centrally. i’m interested in this as every other day, the user details are changed for some silly reason in my project.


Leave a Reply