Any typical SAP implementation landscape, has a multitude of 3rd Party or Legacy Systems. Business Operations mandate interface between the 3rd party systems and SAP. In such a situation, errors on interfaces are inevitable due to multiple point of failures. The diagram below depicts such failure points
The following is a brief description of the various POF.
Term | Definition |
Functional Errors | Errors that occur as a result of incorrect business data |
Technical Errors | Errors that occur as a result of technical capability not operating as anticipated |
Trigger | An event that will kick-off a Business process in SAP |
Extract | Moving data from the source system to PI |
Load | Moving data from the PI to the target system |
Process | Logic used within the SAP system to process the data |
Transformation | Mapping data from source to destination |
POF | Point of Failure |
The errors on the Point of Failures ( Trigger/Extract/Load/Transformation) can be handled via multiple robust techniques, such as CCMS/Alert Monitoring in PI etc.
This blog focuses on the Point of Failure “PROCESS”. This is a step during interface processing when data is processed locally in the SAP system. There are error situations e.g. Locking Business Objects like Business Partners, Purchase Orders etc. or Missing Configuration etc. which could lead to failures in the transactions being processed.
In most cases these errors need to be resolved locally on the target system, without a restart from the source.
What I have seen as Typical Requirements for such situations are :
- A generic/plug-able framework required. This should be reusable across all interfaces
- Ability to display errors in a consistent manner. This should easily be understood by business users
- Ability to re-process errors, in some cases automatically as well
- Ability to support multiple inbound communication protocols like IDOCs and Proxies.
Given these, the next question is to determine a technology which can meet the above requirement. There are multiple technologies available from SAP to support this some examples are FEH ( Forward Error Handler), AIF ( Application Interface Framework), along with custom solutions which can be built.
Let us start with a brief description of such technologies.
Forward Error Handler:
Forward Error handler is a technology available in the ABAP Runtime, based on SAP's ECH ( Error and Conflict Handler Framework). This leverages the SAP Post processing office. It has support only for Asynchronous messages with an integration pattern involving inbound ABAP Proxies.
Error monitoring and display is done within the post processing office ( transactions /SAPPO/PPO2 and /SAPPO/PPO).
More Details can be found here
http://help.sap.com/saphelp_nw73/helpdata/en/cd/798aa3c7754c61b2f2d50ea7b66aac/content.htm
Application Interface Framework:
SAP AIF or Application Interface Framework is a robust tool from SAP, which supports Interface development and error handling. It has support for both IDOC and Proxy based integration pattern. It has support mainly for Async messages. Error monitoring can is handled via the transaction /AIF/ERR etc.
More Details can be found at
Custom Error Handling Framework:
In many cases, custom error handling frameworks are build using the robust SAP IDoc Monitoring technology. In case of proxy based integration pattern, custom error idocs are generated, with a structure similar to the inbound proxy from within the inbound proxy code. These Idocs can capture locking error as well as transient configuration errors. The error monitor is the default transactions like WE02/WE05 etc. and reprocessing can happen via transactions like BD87.
In my opinion the frameworks above can be compared as below, based on the given parameters.
arameters | FEH | AIF | Custom Framework |
Licensing Cost | No additional Cost | Has additional Licensing cost | Minor custom development cost |
Interface Pattern-Synchronous | No | No | No |
Interface Pattern- Asynchronous | Yes | Yes | Yes |
Support for ABAP Proxies | Yes | Yes | Yes |
Support for IDOCs | No | Yes | Yes |
Error Monitoring | Yes – Via Post Processing office | Yes – via /AIF/ERR | Yes – via standard Idoc tools |
Framework Development Effort | None | None | Yes – to build reusable classes for generating IDOCs from proxies |
Usability/Navigation | Mostly Technical Perspective - XML payload like representation, difficult for business users to comprehend | Mostly Technical Perspective | Uses standard IDOC transactions like WE02/WE05/BD87, business users habituated with this |
Start-up Configuration | minor | Major – including setup and installation ( Configurations similar to FEH) | minor ( Includes defining partner profiles) |
Payload Manipulation | Yes – via PPO | Yes | Yes – via IDOC transactions |
Error Reprocessing | Yes – Manual and Auto | Yes – Manual | Yes – Manual and Auto |
In my opinion, the choice of the framework should be tied to one of the above parameters. Just as an example of a few business case examples:
Custom frameworks can be used when:
- Cases in which cost, business user usability is important.
- Majority interface patterns are IDOC Based and do not require additional transformations at the target.
- Configuration/Installation time needs to be reduced.
FEH can be used when:
- In case of Integration patterns heavily using SAP Enterprise services
AIF can be used when:
- When cost and configuration is not a factor
- Target side mapping( post PI mapping ) is required.
- Patterns need to support both IDOCs and Proxies.
- SAP Managed Tags:
4 Comments
