Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
agasthuri_doss
Active Contributor

Introduction: In SAP PI Implementation, the segregation criteria for Business and Technical errors.

Technical errors: which are triggered by the system, these might be errors during file transfer due to a failed server, Connection failure, Communication errors, Infrastructure errors, Components down, Scheduling errors, Mapping error, etc

Business errors: which are triggered or handled by the application alone. An example would be a request for data about a material that is unknown in the receiver system, logical error, corrupted file, format errors, data conversion errors, process flow error etc

Error handling is essentially of interest in the synchronous case. In this case, an application can report application errors to the caller application. In the asynchronous case, we can capture an error that has occurred during transfer and forward an error to monitoring.

                                   Let us consider a flow from SAP ECC to Non-SAP thru SAP PO – Middleware

                    T1/T2/T3 are technical errors and will be handled by the technical team to resolve it

                    B1/B2/B3 are business errors and the process/business/functional team will work on that to fix it

Depending on the business requirement we can either receive the error message as alert by e-mail, fax, or to other error monitoring tool and in each case we will also find the alert in SAP PI alert inbox. This is the inbuilt mechanism provided by SAP PI and it has to define certain steps like alert categories, alert rules etc for the service to get activated. Alerts can be triggered from various points in the message processing like mapping, Adapter issue and connection point of sender/receiver system and in the sphere of integration engine. The point where the alerts are triggered depends upon the interface and business requirements.

Business errors are handled 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.

The goal of the blog is to help users to make aware of the Technical and Business errors, recommendations are based on my personal experience in SAP Implementation as an SAP employee and technical architect.The user can follow the suggestions provided by the blog and it should supplement with additional information,the suggestion provided by the blog might vary as per the project requirement.

SAP Help, at http://help.sap.com, provides official documentation from SAP. It is structured help that is indexed and includes diagrams to illustrate key points. This site is open to the public; no login information is required.

10 Comments