DEBUG IN CRM Middleware debugging - Que blocking

SAP wouldn't be SAP if they didn't provide us with some powerfull controlling and monitoring tools for their system. The CRM middleware is an excellent example of this: over the different system (2.0c - 3.0 - 3.1 - 4.0) our enthousiasm has only grown! Que-monitoring and controlling is one of these tools. When clearly understood, allmost all errordebugging can be started from it. They are actually not middleware specific, but can be seen as transactional RFC que loggers. When the system encounters an error that cannot be assigned to data contained in a message, the error will be logged in one of the ques. Two ques are identified an can be monitored in the CRM-system:

Inbound que (SMQ1): all inbound messages (whether they come from R/3, a MSAapplication or an external application) pass through this que. Outbound que (SMQ2): all CRM outbound messages pass through this que.

The R/3-system contains the same ques:

Inbound que (SMQ1): a CRM transactional message fi is first passed to the CRM ountbound que, then to the R/3 inbound que and from there processed in R/3. Outbound que (SMQ2): the errors in this que are mostly passed to the CRM inbound que

These ques can be registered and deregistered (SMQS and SMQR). A deregistered que will be stopped and show a "ready" status. This means that the message is logged in the CRM DB and awaits further processing. This can be triggered by actually chosing to process or -and this is the important part - to debug it. Example 1: stopping and debugging a business partner (CRM) - customer update (R/3). This example has -of course...- the prerequisite that CRM business partners are integrated to R/3 customers, and that the RFC-users for communication are defined as dialog users! Create a business partner in CRM, and monitor the integration of it towards R/3 (transaction SMW01). Copy the que name and deregister it (using transaction SMQR). Make a change to the business partner and save. The Bdoc can now be seen in transaction SMW01 and will have an intermediate state (yellow). The message is logged in the outbound que, where it shows a "ready" status. The message can now be debugged: this will jump directly into the R/3 system (using the defined RFC user). Example 2: debugging a Bdoc error An outbound Bdoc has triggered an error and has an error state. A discrepancy of mandatoriness between CRM and R/3 can trigger this. The Bdoc will show the illusive error "mandatory field missing" which doesn't really help us to identify the error - or we should have to check in customizing which fields are mandatory.

If we stop the que and debug the process in R/3, indentifying the error becomes a lot easier. Stopping the que can be done as described above, or by turning the debugger on (/h) in transaction SMW01, reprocessing and flagging the "in background task do not process"-flag in the debugsettings and allow it to process (F8). The message is then logged in the outbound que, from where it can be debugged. When doing this for an error in the business partner(CRM)-customer(R/3) integration, you will notice that the Bdocflow actually uses "call transaction"-technology to update the customer! This is a bit disconcerning, because the customer is THE master data object of SD so one would expect it to be updated by BAPI-technology (as stated in all beautiful slide-presentations of the middleware), but on the other hand it's very usefull! Simply put a breakpoint on all "call transaction"-statements and you'll be able to follow the customer update to the byte! Example 3: debug a MSA inbound message The MSA application communicates with the CRM server using sBdocs (synchronisation Bdocs). These can actually be completely understood as SQL-statement that are executed on the SQL-DB of the client. When send to the CRM server, the sBdoc is first converted to a validation mBdoc. This Bdoc is validated (to see whether its contents corresponds with the processing rules of CRM online) and in its turn converted into a notification Bdoc. It is this Bdoc that will take care of all updates in the CRM DB and that will trigger the updates in all depedent systems A difficulty that can be encountered is that the original sBdoc (that was sent from MSA) is never logged on the CRM server. So if an error occurs, the contents of the original message cannot be found in the system! The trick consists of stopping the inbound que of the MSA application and process the sBdoc-mBdoc flow yourself. The contents of the sBdoc can thus be viewed in the inbound que. Stopping the inbound que can be done by deregistering it as described above.

Middleware debugging - Eternal loops

The use of eternal loops can (and should actually) be understood as the creation of programming errors to debug the system. The created loop simply doesn't contain an exit condition, which means that the code within the loop-statement is processed over and over again. As a system, SAP executes coding in a process (in our case a dialog or a background process), which is assigned to the logical unit of work responsible for the processing of our code. These processes are limited, can be viewed and debugged. So... what we do is allow one of these processes to get stuck in an eternal loop that we can monitor and debug! The danger of doing this is evident... When not closely monitored, multiple processes might get stuck in meaningless tasks (which limits the processing capacity of the system). But in online integrated evironments (SAP CRM, SAP R/3, SAP EBP, ...) that use asynchronous processes to control their data flows, the solution is justified - sometimes it's the only possibility of debugging that we have. And if you're doing it, you might as well centralise all debugging-access points to all your user-exit, BaDI-coding or... in one customizing table! To implement: 1. Create a customizing table containing the debugging access points 2. Create a function for the looping

3. Call the function accordingly. 4. debug the loop using transaction SM50 1. Customizing table Create a table containing the following fields:

Loop_id (char4): identifies the loop Active (char1-flag field): activate/deactivate the debugging access point User (uname): indentify the user (to limit looping based on user-name: not always succesfull, because SAP-communicatie uses lots of generic RFC users). Debug_code (char1): determines means of debugging (eternal loop or breakpoint). Description (char50): a description of the access point

2. Looping function. FUNCTION z_debug. *"---------------------------------------------------------------------*"*"Local interface: *" IMPORTING *" VALUE(IV_ENTRY) TYPE ZZENTRY *" VALUE(IV_UNAME) TYPE XUBNAME *"---------------------------------------------------------------------DATA : lt_zzdebug TYPE TABLE OF zzdebug, ls_zzdebug TYPE zzdebug, lv_chkuname TYPE c, lv_exit TYPE c. CHECK NOT iv_entry IS INITIAL. SELECT * FROM zzdebug INTO TABLE lt_zzdebug WHERE zzentry EQ iv_entry AND zzactiv EQ gc_x. CHECK sy-subrc = 0. READ TABLE lt_zzdebug WITH KEY zzuser = iv_uname INTO ls_zzdebug. IF sy-subrc = 0. MOVE gc_x TO lv_chkuname. ELSE. READ TABLE lt_zzdebug WITH KEY zzuser = ' ' INTO ls_zzdebug. IF sy-subrc = 0. MOVE gc_x TO lv_chkuname. ENDIF. ENDIF. CHECK lv_chkuname = gc_x. CASE ls_zzdebug-zzdebug. WHEN gc_debug-break. BREAK-POINT. WHEN gc_debug-loop. DO. CHECK NOT lv_exit IS INITIAL.

EXIT. ENDDO. ENDCASE. ENDFUNCTION. 3. Calling the function Call the code from within whatever user-exit or enhancement like this: CALL FUNCTION 'Z_DEBUG' EXPORTING iv_entry = '(1)' "--> indentify debugging entry point here iv_uname = sy-uname. "(2) "--> identify the username here (or in case of a generic user, don't 4. SM50 Use transaction SM50 to view all system processes. You can indentify your process by it's function group and by the fact that it's processing time is steadily increasing without changing much to the process contents :-)

Middleware debugging
To debug the Bdoc flows, one needs to understand the middleware and how Bdoc are processed on the server. Each Bdoc is linked to several flow contexts , which identify the Bdoc type, direction and load type. Fi. an inbound capgen (customer) Bdoc coming from MSA is linked to the SI1 flow context. 'S' for the Bdoc type, 'I' for inbound and '1' identifying a normal notification Bdoc. A Bdoc that sends 100 customers from CRM to R/3, will be liked to the MO2 context: 'M' for messaging Bdoc, 'O' for outbound and '2' for multiple notification. These flow contexts consist of several services that will do the actual Bdoc processing. A service is a simple ABAP function, which means that on processing, the Bdoc will be passed on sequentially to a list of functions. These flow contexts can be viewed using standard transaction 'SMO8FD'. Using the list of services, debugging of a bdoc becomes as easy as reading linux manuals ... all the information is there, you just need patience finding the error. Having an error, I mostly take the following steps

Does the Bdoc error make any sence? If so, the problem is probably a master data error, a customizing issue or a transactional data error that doesn't need debugging. Does the Bdoc error contain a function module? If so, reprocess the Bdoc in debugging mode and stop the process at the function. Without function, interpret the error and try to deduct a function from the flow-context which is called before the error and stop the process there.

Always keep in mind that inbound sBdocs are immediately mapped to mBdocs for validation. The sBdocs that you see in your system do not necessarily contain the data as sent from MSA. Inboud sBdocs therefore have no real flow context, because they are mapped to inbound mBdocs.