Communications involving Asynchronous Inbound Proxy interface typically encounter issues during data conversion or business logic processing. When administrators or business users detect that the system tries to handle the errors on the provider side,they can investigate the error messages to solve the issue. The resolution process depends on the type of error. An error may be resolved automatically,resolved manually, or rejected and delegated back to the consumer.
Forward Error Handling (FEH) functionality provided by the ABAP runtime can be used to process errors detected on the provider side when performing asynchronous service communication.This way, if the system detects an error while executing a service call
- It does not reject immediately to perform the requested service.
- It does not send back immediately a “rejection message” containing error
information to the service consumer.
Instead, the system uses the FEH framework and tries to resolve the issue on the provider side.In the event of failures on the target system, companies or
business would expect the following:
- Trigger an email notification to the business user so that timely action can be taken.
- Ability to re-process with no permission to change the payload content.
Both the FEH set up and Email alert set up has been explained in very details informative blogs by Michal Krawczy and Vijay Hariharan respectively,this blog post mainly deals with general Authorization and implementing content based authorization controls.
Ø Standard Authorization objects
Standard SAP provides Authorization object /SAPPO/ORD to restrict usage on transaction /SAPPO/PP02 and /SAPPO/PPO3 by specifying the Software component, Business Process and Activity as parameters.
As an Example the below sample would allow display or change access to the user.
| /SAPPO/ORD |
|---|
| Component CA-SOA-ESM-ERP-PUR |
| Business Process PURORD006 |
| Activity 02 or 03 |
Ø Content Based Authorization check
Additional user specific content based authorization controls can be applied using the BADI in the component Error and Conflict Handler (CA-FS-ECH). This BAdI uses interface IF_FEH_PE_CNT_AUT.
For our example we have enabled change/edit access for payload editor in the Post Processing office.For simplicity/ usage sake we have put in the source code to restrict payload access based on the current logged on user.
Source code snippet of the BADI implementation..
Additional logic can be incorporated depending upon the additional checks required.
Test Payload restrict access
Navigate to Message Data tab and click on the change link to try accessing the payload editor in change mode.
Observe the status message below based on the check incorporated.
Continue Re-processing ..
Click ‘Repeat’ and try to reprocess the message.Message will be reprocessed successfully capturing all same error messages in the log. The Latest Processing log is always highlighted in “yellow”.
Before Re-process (Observe the log section highlighted in Yellow )
After Re-process (Log changed to reflect the latest processing details).
Navigate back to the Post processing office desktop display screen to confirm that processors comments during reprocessing were captured successfully.
In addition to the content based Authorization check provided in this document (using a BADI implementation) there are additional BADI’s that be implemented to perform Customer-Specific checks before saving in the payload editor.
There is also a provision to encrypt the payload of postprocessing orders on database level for better data security. You can assign an encryption key to the business processes of the error and conflict handler. You use this key to encrypt the payloads of newly created postprocessing orders.This means that all appropriately configured postprocessing order payloads are encrypted when stored in the database. Users that start a database query, for example, with SQL, cannot read the contents of the payload.
