1/29/2016 7:24:16 AM
1. How does the debugging of a document from CRM to R/3 work?
a) Switching on the debugger:
Before saving the document, you should switch on the debugger by entering the command /h. => Save the document.
b) Stopping the process in the CRM queue SMQ1 or SMQ2:
A breakpoint should be set on function module CRM_UPLOAD_BTMBDOC_START_FLOW. When a CRM document is transferred normally, you can set field LV_IN_UPDATETASK to SPACE before method PROCESS_OUTBOUND is called. In addition, you have to select indicator "In background task: Do not process" in the debugger settings. Then continue with F8.
Usually, this should cause that the BDoc stops in the Middleware queue and can be found again using Transaction SMQ1 or SMQ2.
c) Process does not stop in CRM queue SMQ1 or SMQ2:
If this method does not work, you should open a parallel mode and go to Transaction SMQR while you stop in the debugger in function CRM_UPLOAD_BTMBDOC_START_FLOW. Now deregister the queue with the queue name. Go back to the debugger and continue with F8.
Remark: After starting the process from the queue, you must register the queue name again - this is necessary, on the one hand, to keep the number of entries in Transaction SMQR low, and, on the other hand, to avoid inadvertently holding up other documents.
d) Determination of the queue name:
In order to find again the process in SMQ1 or SMQ2 and in particular to deregister the queue, you have to know the name of the queue. For this purpose, you can use the following '80% method':
Using F6, debug over the position READ TABLE lt_orderadm_h INTO ls_orderadm_h INDEX 1. Now display field ls_orderadm_h-object_id = <obj.id>. The queue name is then CSA_ORDER_<obj.id>.
If the '80% method' is not successful, you can find out the name of the queue if you debug into method call PROCESS_OUTBOUND. Here you have to debug into method PROCESS_NOTIFICATION for the "Single Case" (see comment '* Single Case' in the source code). Field LV_HEADER-QNAME is determined there. This field contains the queue name.
e) Starting the process from queue SMQ1 or SMQ2:
The document should have stopped now in the queue, that is, call Transaction SMQ1 and search for the name of the queue. If you cannot find the queue, check in Transaction SMQ2. If you do not find the name here either, you might have to vary the above-mentioned method.
If the queue was found, it can be debugged. Double-click twice the name of the queue, then select the line and choose 'Debug LUW'. Breakpoint on function module CRM_R3_SALESDOCUMENT_UPLOAD. Continue with F8.
In this module, the filtering and mapping and the call to the R/3 system (BAPI_SALESDOCU_PROXY_UPLOAD) occurs.
If the document still contains errors, module CRM_SALESDOCUMENT_FILTER returns a SY-SUBRC not equal to zero and the document is not transferred to the R/3 system. Thus, if you do not reach the R/3 system, you can check what the filter returns here.
In addition, errors in the CRM documen, which would usually prevent the transfer can be avoided by setting SY-SUBRC to zero after the call of module CRM_SALESDOCUMENT_FILTER.
If certain fields are not transferred from the CRM server to the R/3 system, you should take a closer look at the mapping of the BDoc structures in the BAPI structures. This is done in function module CRM_SALESDOC_MAP_MBDOC2BAPI.
h) Call to the R/3 system:
The call to the R/3 system is performed via module BAPI_SALESDOCU_PROXY_UPLOAD. You can call this module in two different modes: Asynchronous (that is, in the background, which is disadvantageous for debugging), or synchronous (that is, directly). The second method is appropriate for debugging directly to the R/3 system (without a queue). For this purpose, parameter GV_SYNCHRONOUS_CALL must be set to 'X' (preferably immediately before the call of BAPI_SALESDOCU_PROXY_UPLOAD).
If you use the synchronous method, you can select setting 'In background task: Do not process' in the debugger. In this case, the document should stop in the queue.
i) Debugger does not stop in the R/3 system:
If it is not possible to debug into the R/3 system, the reason for this is often that the RFC user that is used in the R/3 system is not a dialog user. To check this, SAP recommends that you search for the user in Transaction SM59 in the corresponding R/3 connection (see below) ('Logon/Security' tab, User). You can check the settings for this user in the R/3 system in Transaction SU01. On the 'Logon data' tab, 'Dialog' should be set as the user type.
j) Determination of the connected R/3 system:
To determine the user (for example, in Transaction SM59), you have to know the connected R/3 system. For this purpose, you can display the contents of table SMOF_ERPSH in Transaction SE16. It should contain an entry with SITETYPEID = SMOF_ERPSITE. Field RFC_DEST contains the ID of the connected R/3 system.
2. How does the debugging MSA -> CRM -> R/3 work?
First of all, you should ask the customer to create a document on the client and place it in the inbound queue of the CRM server. This document should have BDOC type SALESDOCGEN_O_W. As of Release 3.0, an MSA sales document is also created in CRM. That is, module CRM_ORDER_MAINTAIN is always called and then module CRM_ORDER_SAVE. Thus, module CRM_UPLOAD_BTMBDOC_START_FLOW is also called in the further course of processing. The f urther process is the same as described under Question 1.
3. How does the reply from R/3 to CRM work?
a) Determining the data that is to be retransferred to CRM:
In the R/3 system, FORM routine MV45AF0B_BAPIDATEN_ERMITTELN is called in MV45AF0B_BELEG_SICHERN. If a CRM server is connected, this FORM routine determines the data that is supposed to be returned to the CRM Server. This is done by means of module SD_SALES_DOCUMENT_PREFETCH and depends on the scenario set in Customizing (see Note 541113). In the standard scenario, for example, no order data is returned to CRM; The data determined for the reply is transferred in global tables (for example, GT_VBAK in function module CRS_SALES_COLLECT_DATA).
b) Flow logic within the R/3 system:
You should stop in function module CRS_SALES_COLLECT_DATA by means of a breakpoint. Here, variables GV_SEND_TOGETHER and GV_KEYS_AVAILABLE must be set to 'X'.
The subsequent flow logic starts with module CRS_SALES_SEND_TO_SERVER which calls module CRS_SEND_TO_SERVER. Afterwards, module CRS_SALES_COLLECT_KEYS is called.
c) Determining the queue name for the reply:
To deregister the queue in the CRM server (see below), you require the queue name. This queue name is determined in module CRS_SEND_TO_SERVER for the reply. The actual task is performed by module CRM_FIRST_CALL_OPERATIONS which is called there. Table GT_RFCDEST is filled afterwards. Field RFC_QUEUE contains the queue name.
d) Filtering the data to be returned:
The filtering of the data to be returned is also performed in module CRS_SEND_TO_SERVER, with the aid of module CRM_FILTER_DOWNLOAD_DATA. The data to be filtered is contained in table T_BAPISTRUCTURES which contains fewer entries if data has been filtered out.
e) Deregistering the queue in the CRM server and restarting the document:
At this point you should deregister the reply queue in the CRM server in Transaction SMQR. Afterwards, you can exit the debugging mode in the R/3 system using F8. Back in the CRM server you can find the stopped BDoc in the inbound queue (Transaction SMQ2) under the queue name that was deregistered before. You can start this queue by choosing 'Debug LUW'. Do not forget to reregister the queue name in Transaction SMQR!
f) Flow logic within the CRM server:
The function module that starts the inbound processing in CRM is BAPI_CRM_SAVE.
The process sequence is roughly as follows:
First, the data is mapped from the BAPI to the CRM structures. This is done by module CRM_SALESDOC_MAP_BAPI2MBDOC. Afterwards, the validation occurs by means of module CRM_DOWNLOAD_BTMBDOC_VAL. This module calls module CRM_DOWNLOAD_BTMBDOC which in turn calls module CRM_DOWNLOAD_BTMBDOC_FILTER which resets status 'To Be Distributed' and sets status 'Distributed' instead.
g) Document processing in CRM:
Document processing is also called in CRM from module CRM_DOWNLOAD_BTMBDOC if data was returned to the CRM server and not only the status was reset. Document processing is carried out via module CRM_ORDER_MAINTAIN. Finally, the call to save the document is called from module CRM_DOWNLOAD_BTMBDOC. The document is saved by means of module CRM_ORDER_SAVE.
4. How does the initial download work?
a) Maintaining the filter settings:
First of all, the customer has to maintain the filters for object 'Salesdocument' in Transaction R3AC1. You can reach the filter settings by choosing the filter symbol. Then go to the 'Tables/Structures Within Object' tab. In addition, you must select the corresponding source site (that is, the R/3 system). Now the filter conditions should be displayed. The filter can be set according to different criteria, for example according to a document number interval. In this case, only the documents contained in this interval are sent to the CRM server. It is important that you fill up the document number to 10 characters with leading zeros.
If you encounter problems with the filter settings, Note 497327 might be of further assistance.
b) Starting the initial download with Transaction R3AS:
If the filter settings are correct, the initial download is started with Transaction R3AS for the corresponding object.
IMPORTANT! The initial download should only be carried out once for each document because problems can occur if you start the initial download for documents that already exist in the CRM Server. In this context, also refer to Note 617598. After the initial download has been carried out once successfully, another initial download is no longer required because changes to the documents are automatically sent by delta download from the R/3 system to the CRM server.
c) Starting the debugging of the initial download:
The sequence of the initial download is as follows:
Call Transaction R3AS, select the object by means of the input help and go to the debugger by using /h.
First, module SMOF_START_DOWNLOAD_OR_REQUEST is called. This module calls module SMOF0_INIT_DNL_START. In this module the call to the R/3 system is started. The corresponding module in R/3 is CRS_FIRST_DOWNLOAD_TRIGGER.
d) Synchronous or asynchronous call of the R/3 system:
Like with the upload, you also have the option here of calling directly to the R/3 system (synchronous call) or via a queue (asynchronous call). During the asynchronous call, the queue must be deregistered again in Transaction SMQR. You can determine the queue name if you set a breakpoint on the line 'IF lv_do_not_use_standard IS INITIAL.' which is located just above the call of function module TRFC_SET_QUEUE_NAME in module SMOF0_INIT_DNL_START. At this time, the local variable LV_QNAME should contain the queue name. If, on the other hand, you want to debugger synchronously (that is, directly) into the R/3 system, you have to set variable DA_SMOFPARSFA-PARVAL1 to 'X' at the above-mentioned breakpoint.
e) Selecting the R/3 documents that are to be sent to CRM:
In the R/3 system, the documents that are supposed to be sent to the CRM server are selected with the help of the filter settings from table VBAK. This is done in module ORDER_SELECT_NEXT_ID. This module returns table T_OUT_ID_LIST which contains all documents that were found using the filter settings. If a customer experiences problems that some documents are not loaded into the CRM server, you can check here whether the documents are actually selected with the valid filter settings.
f) Sending the R/3 documents and processing in CRM:
Module SD_SALES_DOCUMENT_PREFETCH which provides the document data is called with T_OUT_ID_LIST. Afterwards, module CRS_SALES_SEND_TO_SERVER is called as in the reply (see Point 3). The further process is the same. The data is filtered, the queue is determined. However, during the download in CRM, document processing is always carried out with modules CRM_ORDER_MAINTAIN and CRM_ORDER_SAVE. It should be noted here that the initial download can be a BDoc with more than one sales document.
5. How does the request download work?
a) Difference to initial download:
Basically, the way the request download works is similar to the initial download. However, it is possible at any time and can also be started for individual documents that already exist in the CRM server. However, to avoid errors it is always better to delete the document before using program CRM_ORDER_DELETE.
b) Creating the request in Transaction R3AR2:
A new request is created in Transaction R3AR2. You can choose any request name you like. SAP recommends that you select the object name via the input help because the remaining data is then also filled. The sales document object is the 'SALESDOCUMENT'.
Next, you have to create the request details (by double-clicking the 'Request detail' folder to the left of the tree and choosing 'New entries'). As in the initial download, you can enter selection criteria. The most simple thing to do is to work with the document number. For document number 21922, that would look as follows:
Table Name = VBAK
Field Name = VBELN
Incl/Excl = I Inclusive defined set/array
Option = EQ Equality (= Low)
Low = 0000021922
c) Starting the request download:
You start the request download using Transaction R3AR4. Again, SAP recommends that you select the request name using the input help. The further steps are the same as with the initial download.
6. How does the delta download work?
a) Delta download characteristics:
The delta download is started from the R/3 system. It is started whenever a document that is relevant for the download according to the filter condition (see initial download) is created or changed.
b) Flow logic within the R/3 system:
As in replies, the data to be sent is determined in FORM routine MV45AF0B_BAPIDATEN_ERMITTELN by means of module SD_SALES_DOCUMENT_PREFETCH. Afterwards, module CRS_SALES_COLLECT_DATA is called. Unlike in replies, the data is then transferred directly to module CRS_SALES_SEND_TO_SERVER.
c) Problems when debugging module CRS_SALES_SEND_TO_SERVER:
Module CRS_SALES_SEND_TO_SERVER is usually called 'In Update Task'. However, because the 'Update Task' cannot be debugged, you have the option here of setting a breakpoint on the line 'IF gv_send_together IS INITIAL.' just above the call of CRS_SALES_SEND_TO_SERVER in module CRS_SALES_COLLECT_DATA and setting local variable LV_IN_UPDATE_TASK to 'SPACE'. You can now debug to module CRS_SALES_SEND_TO_SERVER directly. This module calls module CRS_SEND_TO_SERVER.
d) Further process of delta download:
The further process is exactly as described for the reply (under Question 3).
7. How does the reply to CRM work with a delivery / rush order / billing document?
Before saving the delivery, switch on the debugger by entering /h.
Then set a breakpoint in subroutine SAPMV50A / SD_MOB_CLIENT_UPDATE. Set variable V50AGL-SYNCHRON to 'X'. (FORM routine SD_MOB_CLIENT_UPDATE is contained in Include FV50XF0B_BELEG_SICHERN.) Then debug module SD_CRM_ORDERDATA_FROM_DLV_INV. The statuses are determined here. The remaining process is as described for the delta download (Question 4).
b) Rush order:
The rush order is a special case in which module SD_CRM_RUSHORDER_DATA_READ is called in routine MV45AF0B_BAPIDATEN_ERMITTELN directly from the sales order. The remaining process is also as described for the delta download (Question 4).
c) Billing document:
Before saving the billing document, switch on the debugger by entering /h. Then set a breakpoint in subroutine SAPLV60A / CRM_UPDATE. Set variable LV_SYNCHRON to 'X' here. (FORM routine CRM_UPDATE" is contained in Include LV60AD26.) Afterwards, also debug module SD_CRM_ORDERDATA_FROM_DLV_INV. For the remaining process, see the delta download (Question 4).
d) Cumulative quantities and document flow:
In CRM, structure CUMULATED_I is interesting both for the delivery and for the billing document because the quantities are updated here, in addition the document flow is updated in table DOC_FLOW.
If you like this blog, please share (Facebook/LinkedIn/Google+) to click below links so it will reach to others.