Beruflich Dokumente
Kultur Dokumente
IndustriesIndustries
SupportSupport
TrainingTraining
CommunityCommunity
DeveloperDeveloper
PartnerPartner
AboutAbout
Search
Log On
o
o
o
o
Home / Community /Blogs
Actions
POV: FEH or AIF or Custom Error Handling
May 3, 2013 | 802 Views |
Former Member
SAP Cloud Platform Integration for process services
SAP Process Integration sap netweaver process integrationSAP Netweaver Process
Orchestration
share 0
share
tweet
share
Follow RSS
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.
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 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.h
tm
http://scn.sap.com/community/pi-and-soa-middleware/blog/2011/02/24/pixi-forward-error-handling-feh-for-
asynchronous-proxy-calls-with-the-use-of-error-and-conflict-handler-ech
http://scn.sap.com/community/pi-and-soa-middleware/blog/2011/02/27/pixi-forward-error-handling-feh-for-
asynchronous-proxy-calls-with-the-use-of-error-and-conflict-handler-ech-part-2
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
http://help.sap.com/aif
http://scn.sap.com/community/pi-and-soa-middleware/blog/2012/10/20/michals-pi-tips-
application-interface-framework-aif–idoc-processing-with-aif-actions
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 Minor custom development
cost cost
Interface Pattern- No No No
Synchronous
Interface Pattern- Yes Yes Yes
Asynchronous
Support for ABAP Proxies Yes Yes Yes
Support for IDOCs No Yes Yes
Error Monitoring Yes – Via Post Yes – via /AIF/ERR Yes – via standard Idoc tools
Processing office
Framework Development None None Yes – to build reusable
Effort classes for generating IDOCs
from proxies
Usability/Navigation Mostly Technical Mostly Technical Uses standard IDOC
Perspective – XML Perspective transactions like
payload like WE02/WE05/BD87, business
representation, difficult for users habituated with this
business users to
comprehend
Start-up Configuration minor Major – including setup minor ( Includes defining
and installation ( partner profiles)
Configurations similar to
FEH)
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:
Alert Moderator
4 Comments
You must be Logged on to comment or reply to a post.
1. if you share links please include the AIF and FEH blogs from SDN (many on PI space)
http://scn.sap.com/community/pi-and-soa-middleware/blog/2011/02/24/pixi-forward-error-
handling-feh-for-asynchronous-proxy-calls-with-the-use-of-error-and-conflict-handler-ech
http://scn.sap.com/community/pi-and-soa-middleware/blog/2011/02/27/pixi-forward-error-
handling-feh-for-asynchronous-proxy-calls-with-the-use-of-error-and-conflict-handler-ech-part-2
AIF:
http://scn.sap.com/community/pi-and-soa-middleware/blog/2012/10/20/michals-pi-tips-
application-interface-framework-aif–idoc-processing-with-aif-actions
2. on the compare table – there are also some changes to be done:
a) with AIF – there’s no automated error processing – so please remove it from the table
unless you know a report for autoamted reprocessing of AIF errors
b) start up configuration – same effort for both (the only diffrence is installation in terms of AIF)
c) usability navigation – AIF – this is only for business users not at all for technical people – the
whole idea of AIF is that it’s used by business people
d) development effort – with AIF in case of IDOCs or custom proxies you need to do the coding
yourself, same thing with FEH in case you want to go for custom proxy – so there’s certainly a
coding effort involved
On the usability front, though AIF gives a lot of flexibility to business users, to define
rules/mappings etc along with robust Error monitoring transactions, I have been on clients where
business users require a more simplified view of the errors, with special drill-up and drill-up
capabilities.
for e.g., I have been on a Utility Client, and they want to use EMMA cases to report errors. The
advantage being, the ability to roll-up errors to SAP business objects, and easy launch of base
ECC transactions.
In some cases ( typically in case of upgrades/re-implementations) users are comfortable with
IDOCs and their structures, to understand and resolve errors.
like (0)
Michal Krawczyk
like (0)
Additional the blog says: „Prerequisites: Standard FSCM Credit Worthiness Scenario has been
enabled in ECC/PI. “ What needs to be done before the implementation of BADI_SD_CM? Do
you mean the following points need to be implemented?
WS-RM Based Integration.
Step 1: Navigate to SOAMANGER
Step 2: Selection of the Server Proxy Name
Arjan
like (0)
Share & Follow
Privacy
Terms of Use
Legal Disclosure
Copyright
Trademark
Sitemap
Newsletter