Introduction
We can send the proxy message to either integration engine or adapter engine using IS_URL parameter in SXMB_ADM integration engine configuration as described in this document How to Set Up the Communication between ABAP Backend and SOAP Adapter using XI Protocol, even though we maintain all the configurations in ECC to route the proxy message to adapter engine, still the message reach to ABAP stack as mentioned in this thread No receiver could be determined for ICO PI 7.3, we just need to make sure all the configurations in place and guess what went wrong.
In this blog i want to show you how to debug the outbound proxy message to troubleshoot wrong configuration or some other problems in ECC, then we can identify the exact problem without guessing.
Configuration in PI
I have created below ICO in PI, The scenario is PROXY to FILE. I have created all the channels and activated ICO in the integration directory.
Configuration in ECC
The global configuration of integration engine in ECC system is pointing to ABAP stack of PI system using HTTP destination.
The below is the HTTP destination which we used above to send the proxy message to integration server of PI ABAP stack.
But this particular interface configured as ICO and ICO only runs on adapter engine, we need to send the proxy message to adapter engine of PI system. I have created sender ID in transaction SXMSIF. I mentioned exactly same sender component, sender interface and sender namespace which is maintained in the ICO.
The below is the interface specific IS_URL configuration in SXMB_ADM->Integration Engine Configuration which is pointing to G type destination.
The below is the G type destination which we used above. It is pointing to adapter engine of PI system.
Deregistration of Queue
To be able to debug the outbound proxy message we need to deregister the outbound proxy queue which is XBTS*, go to SMQR select the XBTS* queue and click deregistration button in the application toolbar.
After we done the deregistration we can observe registration column updated with 'U'.
Trigger the Message
Trigger the outbound proxy using outbound proxy program or test message from SPROXY.
After we trigger the outbound proxy the message will be handed over to qRFC and we can see the entry in the SMQ2 and outbound proxy queue XBTS*. As we deregister the queue, the LUW will not processed automatically it will be sitting in READY status like below.
Get Class and Method
Before debug the message we need to identify what is the class and method from the trace of the previous messages in SXI_MONITOR, below is the example messages and in the trace you can see the class and method where the interface specific URL will determined.
Class Name: CL_XMS_PLSRV_IE_ADAPTER
Method Name: ENTER_PLSRV
Debug Proxy Message
Now we can debug the LUW which is sitting in the queue, select the LUW and click on Debug LUW in the application toolbar.
The debug session will be started in separate window. We can set the breakpoint at specific method which we identified above. Click Breakpoints->Breakpoint at -> Breakpoint for Method like below.
Next screen enter the class name and the method name like below then click on continue.
After that run F8 or continue in the application toolbar as mentioned below.
The system will take you to above class and method, with in the method line 57 getting the URL of integration server.
Right click on the line and select Create Session Breakpoint then it will create a session breakpoint on that line. Press F8 again the control will stop at line 57 and then click on F5 to go into that method.
With in this method line 56 getting the list of sender ID's which matches the current message header attributes, create the session breakpoint and press F8 then the control will stop at line 56 and press F5 to go into that method.
With in this method get all the configured sender ID values from SXMSIF transaction and reading one by one and comparing the current message attributes like party, service, interface and namespace. If match found adding it to sender ID internal table.
After finish above method if any entries found for senderID table then system is reading the interface specific IS_URL for that sender ID using function module SXMB_GET_CONFIG. If the entry found then writing the entry to trace of the message which we observed initially in SXI_MONITOR. After this system will send the proxy message to adapter engine using identified IS_URL.
You can find below result of the function module, it identifies the adapter engine URL which we configured in SXMB_ADM.
If there is no sender ID found for this interface based on message header then system will take the IS_URL from the global configuration.
Conclusion
Using above described debug steps we can identify the problem if we have done any wrong configuration in the system for interface specific IS_URL without blind guesses. This is one of the example i showed in this blog, we can debug some other issues related to outbound proxy in future using above steps. I hope this helps whoever face above similar problem in future.
- SAP Managed Tags:
