Guus Dorenbos
Read all my blogsAs a functional consultant you will often have to monitor the middleware when sending Business Partner information from SAP CRM to SAP ERP. Often the error message of the BDoc will give you a clue as to where to find the cause of the error, but as often you are left in the dark as where to find the exact cause, for example when it tells you to fill in all required entry fields (but which ones are not clear!).
This week’s blog explains how to find the cause of a BDoc error when replicating Business Partner data from SAP CRM to SAP ERP.
First of all check the middleware errors in transaction SMW01. Select the BDoc that shows a status ‘red’ and thus went into an error. First you will need to click on the ‘Show BDoc Message Errors/ Receivers’ icon 
and then the grid icon 
to find the description of the error.
and then the grid icon to find the description of the error.If this does not give you enough information, start the debug session by typing /h in the area where you would normally enter the transaction code. Left below, you will now see that the debug session has been switched on.
Next, select the BDoc that you want to debug and choose to re-process this BDoc by clicking
on
Reprocess BDoc message). You will now enter in the debug session. Here, choose the following from the menu: Settings -> Display/ Change Debugger Settings and check the option ‘TRFC (In Background Task): Block Sending’.
on
Reprocess BDoc message). You will now enter in the debug session. Here, choose the following from the menu: Settings -> Display/ Change Debugger Settings and check the option ‘TRFC (In Background Task): Block Sending’. 
This setting makes sure the BDoc will be stopped in the outbound queue where you can intervene by running the BDoc through the debug session. However, the BDoc will be in the queue only for a short instance, so you have to work fast.
Before moving ahead, make sure you open the outbound queue by starting transaction SMQ1. In the next step you will need to move quickly from the debug session to the outbound queue to make sure the BDoc does not get processed before you get a chance to debug it.
Back in the debug session, after checking ‘TRFC (In Background Task): Block Sending’ hit F8. A pop-up will now come up asking you if you would like to proceed reprocessing the BDoc message or not.
Click YES and then quickly jump to the outbound queue to pick up the BDoc from this queue.
When you find the BDoc in the queue, double click twice on the entry to drill down into the object to get to the function module.
In the next screen that appears click on the icon ‘Debug Logical Unit of Work’
to again go to the debug session.
to again go to the debug session.Now you will need to set a breakpoint so that the program stops at a particular point where you can change the mode of the transaction call. In the menu of the debug session select the following: Breakpoints -> Breakpoint at -> Breakpoint at Statement. You will now need to create a breakpoint, by choosing ABAP Commands ‘call transaction’.
Next ENTER and hit F8. The system will now go through the ABAP code until it reaches the breakpoint, which you have just defined.
In the ABAP code you will see that the breakpoint has been reached at Mode Call_Transaction_Mode.
Double click on Call_Transaction_Mode and change the contents of the variable from N (do not show dynpros) to A (show all dynpros) by double clicking on the pencil icon. ENTER and SAVE.
Save the change, and hit F8 again. Since you have changed the variable to A, you will now be able to go through the screens in the GUI as if you were creating the customer yourself in ERP with transaction XD01.
You can go through these screens one by one by hitting the Enter key. This will move you through the steps of creating the customer in ERP. This will now allow you to see which mandatory fields cannot be filled with the information in the BDoc by showing a flagged check box for the mandatory fields. You can now directly enter the missing information in this field in ERP or correct the data in CRM.
Sometimes it happens that when going through the steps in ERP you get back into the debug session where again you have to double click on the pencil and change N to A and hit F8 again. Again you will be redirected to the creation screens in ERP. When finished you will be re-directed to the outbound queue where you will now see that the BDoc has disappeared from the queue.
Back in SMW01 you will see that the BDoc has finished successfully.
As you can see from the above, you do not need to be a developer to do some debugging!
Contributed by Bianca Koene | Acorel BV
Receive our weekly blog by email?
Subscribe here:
3 responses to “What’s wrong with those BDocs?”
Make sure the user that is used for debugging is defined as a ‘dialog’ user in the target system. In case the RFC connection uses a fixed RFC user of type ‘system’ it maybe required to temporarily set the user to type ‘dialog’ for debugging purpose.
For additional tips on debugging BDOC's take a look at 656823 and 573857
Hey Bianca – Great post about middleware debugging..haven't done this so far 🙂
I also created quite some posts about middleware monitoring on my site:
http://www.sapuniversity.eu
cheers
Davy
I have reached till the point where the Queue appears in smq1.but am unable to debug the LUW.
When i drill down the Queue , and click to debug the LUW,it disappears.
I have even stopped the Queue in Smqr,r3aubupa*