I had a requirement for controlling integration where I had to configure the middleware to enable the flow of service transactions from CRM to ECC. I will be trying to post a blog on the details of Controlling Integration soon; however this short blog is for those who are looking for options to debug service order related transactions from CRM to ECC.
(Apologies if any of these are repetitive from any previous posts or forums, I had to struggle a bit to get through to this as I did not find any existing post on this!)
1. First step – very simple and familiar to anyone having experience debugging middleware – deregister the queues.
If the middleware setup has been done correctly bdocs will be generated for every service order/confirmation that is generated. Hence through transaction SMW01, check the bdocs that are getting generated. Under the queue name, you will find the name of the queues to be deregistered. Depending on the requirement, you can block either the entire CSA_ORDER_* queues or any particular queue corresponding to a single transaction. (Please be careful not to stop the subsequent flow or confirmations that need to flow for an order).
Goto transaction code SMQR to deregister the queue.
Once this is done, the bdoc for transaction 8000000144 will be in wait status when it is generated as the queue is blocked. (Make sure some change is applied to the transaction so that the change triggers the bdoc creation).
2. Goto transaction SMQ2 (Inbound queues) and you will find the queue readily waiting for you to flag it off!
3. Click on the right entry and select debugging icon
4. Hurray! You are within the ABAP debugger – a developer’s paradise where everything is within your control 😎
5. Now is the tricky part. Where do I put the right breakpoints so that I can find out what is being done in ECC?
Depending on the bdocs generated, SAP uses certain standard function modules to transfer data to ECC. For example, in this situation, I got confused because the control goes to the function module CRM_R3_SALESDOCUMENT_UPLOAD also, but within in it doesn’t transfer to ECC as this transaction type is not a sales related one. Hence it passes through this FM without doing anything.
The right FM to be checked in the service scenario is CRM_R3_SERVICECONF_UPLOAD. (Place a breakpoint in this FM so that the control reaches here).
6. My requirement was to only check what was happening within ECC and hence I only needed to jump to the point where the call to ECC was being made. Hence I went directly to line number 343 in the FM CRM_R3_SERVICECONF_UPLOAD.
Just like in any other middleware debugging scenario, change the value of the parameter GV_SYNCHRONOUS_CALL to ‘X’. This will call the BAPI ‘BAPI_SERVICECONF_PROXY_UPLOAD’ in foreground and you will be able to get into ECC to debug.
There you go! You have the world in your hands to troubleshoot any issues arising out of service order replication to ECC! Happy Debugging!
Some other potential issues that can spoil your day after doing all the above:
– RFC destination is not set-up right with the required authorizations
– Your userid might not have the authorizations to execute this activity of debugging in the external system