Quantcast
Channel: Process Integration (PI) & SOA Middleware
Viewing all articles
Browse latest Browse all 741

SAP PO Technical and Business Errors

$
0
0

Introduction: In SAP PO Implementation, the segregation criteria for Business and Technical error

 

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.

 

Error.png

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

 

Business and technical error in PI.png

 

                    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.


Viewing all articles
Browse latest Browse all 741

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>