SAP PO – Asynchronous SAP PROXY Lookups!! Yes It Is Possible!
I came across a requirement where we had to post a message to a SOAP Proxy “Asynchronously” and at the same time send the request to either System A or System B depending on a value map.
SENDER System X——–>SAP PO—>(Always to SAP PROXY Asynch) and System A or System B.
Calls to System A and B are Synchronous and we will get exactly one response depending on which system is called.
Now we managed to do this without BPM by following this fantastic blog.
Now for the SOAP Proxy part there were two options we either do it via BPM or via a SOAP PROXY Lookup!!
You can check how to perform a SOAP Proxy lookup via this wonderful blog.
The first thing that comes to mind is that the “SystemAccessor” by it’s default nature works on Synchronous calls and no matter whatever method you may try(limited number of methods) we cannot change the Quality of Service!!.
So when you try to call an Asynchronous Proxy via SOAP Proxy lookup you get an error in SXMB_MONI of ECC that the QOS is invalid!! As it is by default BE(Best Effort) but ECC expects it to be EO(Exactly Once).
- while writing the SOAP Proxy lookup always use these two extra methods.SystemAccessor accessor = LookupService.getSystemAccessor(channel);accessor.setOperationName(“InboundServiceInterfaceName”);
- Now as next step dont get the result of the accessor call into the Payload variablePayload SOAPOutPayload = null;//The response will be a Payload. Parse this to get the response field out.
SOAPOutPayload = accessor.call(payload);// DON’T USE THIS
- Now Set the Quality of Service AS EO!!! How?
This can be achieved by Module Beans placed in the Receiver SOAP Proxy adapter.
- Run the SOAP Proxy lookup in Test mode and check SXMB_MONI and you see a successful message now.
Asynchronous SAOP Proxy Lookups are possible in SAP PO but then these are not lookups but essentially Data is being posted to ECC.
System Accessor does not support transactional behaviour and should not be used to update the same object as different threads can be trying to update the same Object in ECC (which was not the case in our scenario)