PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict Handler (ECH) part 2
In the first part of my article about FEH and ECH PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict Handler (ECH)I’ve described how to prepare a custom proxy call to make it use ECH framework for exception handling instead of using standard fault messages. In this part I will concentrate on simple examples of other available methods:
– retry
– fail
– complete
Once you open a message in the PostProcessing Office you can see that there are a few possible ways to handle en error. You can either repeat (in case the error should not happen anymore), confirm (complete the message in case of an authorization issue the message was processed manually) or discard (fail message in case the processing should not be repeated at all).
Retry Method
Within this method you can call the proxy’s method one more time with the same data. The best idea is to copy the standard method into a new one (let’s say DO_APP_PROCESS as in my example) add the same importing parameter and exception but also add bapiret exporting parameters which will indicate if the retry was successful or not this time. If the call was not successful again you just need to invoke the exception and call collect method as show in the first article. Below you can find a very simplified version of an retry method:
| DATA: lr_feh_registration TYPE REF TO cl_feh_registration, ls_api_data TYPE YYMT_TEST. *— Create FEH instance for Retry —————————–* CALL METHOD lr_feh_registration->retrieve_data me->DO_APP_PROCESS( exporting input = ls_api_data ). *in your own method (do_app_process) you can have output parameters (bapiret) *——- Update FEH to resolve ticklist ——————————-* lr_feh_registration->resolve_retry( ). |
Now once you use the repeat button you will see that the repeat call was correct.
Confirm method
Within this method you can do multiple things like sending an e-mail message to a correct use that he needs to reprocess the transaction manually, etc. and as the end thing you need to call the finish method as shown in the code below.
| CALL METHOD cl_feh_registration=>s_finish EXPORTING i_data = i_data IMPORTING e_execution_failed = e_execution_failed e_return_message = e_return_message |
When you confirm the message in the PostProcessing Office the status should get updated accordingly.
Fail Method
The last method should be used when you cannot do anything with the message and just want to delete it’s status so it will not longer be reprocessed by anyone. You can also send e-mails and other alerts from it prior to calling the s_fail method as shown below.
| *— Update status in FEH ——————————————–*
CALL METHOD cl_feh_registration=>s_fail |
Again using this method should update the status of the message in ECH.
Using any of the buttons/methods described should udpate the global message status.
Hello Michal,
I was trying to set up the email alert for one standard interface ERPEmployeeTimerequest_in.
The software component is CA-SOA-ESM-ERP-HR and business process is EETME_RQ.
The steps were
1. Define business process in post processing.
2. Define priority to Business process.
3. Define worklist
4.Assign worklist to business process
5.Process notification for orders in worklist -- according to worklist.
6. Print workbench setting - mail.
Assigned users in the transaction\SAPPPO\WL_CHANGE.
When the error is thrown the email is nt trigerred. Can any one let meknow what could be missing.
Regards,
Prerna
How does this look like in the light of SAP Application Interface Framework (AIF)? Afaik AIF boasts about FEH. But as per this blog, this was already available before and without AIF!?