Acknowledgement Handling in IDoc to SOAP Scenario in PI 7.3

[subhro_de]

This blog outlines the situation where idoc acknowledgement status needs to be updated when the receiver is a webservice and is called using the SOAP adapter.

IDoc AAE communication channel was used on the sender

Asynchronous Scenario

In case if only system acknowledgement is required from an asynchronous scenario of posting to a webservice  then the following parameters need to be checked and updated :

1) Ensure that the persistence flag of the Java IDoc adapter is enabled in NWA.

2) The following parameter needs to be set in SOAP receiver communication channel.

1. XMBWS.GenerateSysAck – true

Synchronous Scenario

In some cases we have a requirement of updating the

This scenario basically shows the usage of RequestResponseBean where the response can be used to trigger a separate scenario. This was to enable tracking of the application acknowledgement message returned from the web service from idoc status tracking in ECC.The application message returned from the receiver sent back the original idoc number which was used to create an ALEAUD idoc to post into ECC.

For this purpose two scenarios were created – Scenario 1 triggering Scenario 2.

Scenario 1 : IDoc to SOAP Webservice request call

Scenario 2 : SOAP Webservice response mapped to ALEAUD

Scenario 1:

1) Create the first scenario in the standard asynchronous way with mapping and ID objects.

2) The only difference would be the receiver communication channel with RequestResponseBean adapter module as shown in the screenshot below.

3) This configuration will post the response to the Scenario 2 . The scenario 2 should be configured as follows :

Sender Communication Component – Receiver Business System of Scenario 1

Sender Service and namespace– by default this would be receiver interface of Scenario 1.

This is over ridden here by the parameter replaceInterface in the receiver communication channel of  Scenario 1 as shown in the screenshot above to match the sender interface and namespace of Scenario 2.

Scenario 2:

1. As mentioned above, the scenario 2 is configured using the same sender interface name and namespace as in receiver communication channel of  Scenario 1.
2. The important part is that the scenario should have the receiver system as virtual receiver as well – refer to the screenshot below (Thanks to the SAP consultant for showing us the way - without this guidance it would have been tough to get the resolution!).
   
3. This scenario has the receiver channel configured as IDoc Receiver for posting the ALEAUD idoc with the necessary mapping to map to the relevant idoc status.
   
4. Note that the sender communication channel can be dummy (so for example a dummy file channel can be used as well)  for this scenario as the response is placed in the pipeline directly by the Request Response Bean in the first scenario.

In case if the webservice returns standard fault messages and the requirement is to capture the same approach can be applied

using the following parameters in receiver communication channel of Scenario 1.

• interfaceOnFault - interface name for forwarding an application error message.
• interfaceNamespaceOnFault - interface namespace of the interface above.

Handling of a similar scenario in a different approach was  found in the link below – adding here for reference

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/03/25/requestresponse-bean-for-idocaae-...