In SAP CRM, Middleware is an important part through all the CRM scenarios (E-commerce, IC, Marketing, Mobile, etc). The basic item in CRM Middleware is the BDoc, which is always transfered through qRFC to process data. These days, I am learning about this, and here are some basic knowledge about it and if possible I would provide some trouble shooting cases.
Basically, we have mBDoc and sBDoc, which indicates ‘Messaging flow’ and ‘Synchronization flow’ accordingly. mBDoc is used for most of the scenarios to update the data when some change occurs. It can be possibly triggered when either inbound or outbound processing happens. sBDoc is less used than mBDoc, because it only can be used for CDB based message processing in CRM Mobile environment. It is only used in Mobile Scenario. Only in one scenario that sBDoc is assigned to one mBDoc, the assigned mBDoc is not stored but only exists till the outbound mBDoc message is created after the validation. In other cases, sBDoc can only be seen in Mobile Scenarios.
The flow configuration
We could configure the message flow through the entries in these tables, SMW3BDOCIF, SMW3FDSTD, SMW3FDBDOC, SMW3FDCUST. At the customer side, only the SMW3FDCUST (‘FD’ stands for ‘Flow Definition’ in my opinion) is required to be maintained. The evaluation logic for outbound processing is "from bottom to top" of these tables. First, customer enhancements in SMW3FDCUST are checked, then whether there are BDoc type specific entries in SMW3FDBDOC. If not, the standard services from SMW3FDSTD are taken.
The flow definition of each BDoc type can be checked out within t-code SMO8FD.
Components of BDoc messages
· Exactly one message header,
· A list of message receivers (outbound processing),
· An error segment, e.g. a list of validation errors,
· A message body (classical part, s-BDocs and m-BDocs)
· A message extension (m-BDocs only) - This extension is supposed to hold the transaction data, whereas the classic part (message body) shall only contain fields used in the receiver determination by the replication component
· Root ID (only for BDoc message with single instance),
· A list of receiver specific error information.
When we do BDoc trouble shooting, we can check the BDoc in table SMW3_BDOC and check the specified BDocs via the BDoc link fields (the field indicating the link between BDocs) and the QName (which will tell you the queue where the BDoc is supposed to be in. Table SMW3_BDOCQ can be checked for details). Here SAP Note 765236 can be referred.
BDoc Monitoring
SMW01 and SMW02. We can use them to do following jobs.
Analyze the status of BDoc processing, Display the BDoc related information (processing trace, data content, receipient list, object link, etc) and Corrective actions (reprocess or delete failed BDocs)
Error Handling
For BDoc with multiple receivers, each receiver might have a different processign state. In such a case, please note that each receiver has its own error segment and can be reprocessed individually.
We need to distinguish between errors in the inbound process and those in outbound processing.
Inbound processing always brings validation errors.
Outbound processing always brings error types E01 and E02. Receiver specific errors can only be written for outbound messages.
Tcode SMW02 and SMW02A is more speific for summary and analyzing. we can use SMW02 to get an overview on all the BDocs.
For inbound mBDoc validation error, check the validation function module mapping in SMW3BDOCIF and debug the validation FM if possible.
For outbound mBDoc error, select the BDocs and display the receivers and then we can find the specific error message and solve it.
Intemediate, Final, Particular not-final BDocs Handling
Can be checked out in the refrence material. :)
Ways to handle the ‘unprocessed’ messages.
Mark message as deleted/processed: Deletes a message, SMW01
Retry to process message: Processes message further, SMW01
Define, start and monitor single requests for load: R3AR2, R3AR4, R3AR3
Synchronize objects: R3AS4, R3AM1 (for customizing objects only)
Process aborted BDoc Messages: SMW20
Unlock data in source or target system and repeat: CRM Application
Tools/Funtionalities available for analyzing the problem
Receivers SMW01: Displays a list of the receivers of a message
Errors SMW01: Displays error segments
Middleware Trace SMW01: Displays records for individual steps
Classic Data SMW01: Data segments of a message
Extension Data SMW01: Extension of a message (only for m-BDoc messages)
Outbound queues SMQ1 (see also outbound queue scheduler SMQS)
Inbound Queues SMQ2 (see also inbound queue scheduler SMQR)
Mobile clients In- and outbound Queues SMQ1, SMQ2
Short Dumps ST22 (+- 15 minutes), select update User
Links SMW01: Links between messages and object types
DIMA SDIMA: Compare and adjust data between two data sources
Update requests Transaction SM13 to check if there are any hanging update requests
System log SM21: Check for “User xxx is deleting inbound/outbound queue xxx” to see if queues were manually deleted.
Case Study
Situation: BDoc Type: BUPA_MAIN Status: E02, Context: MO1
Solution:
Select BDoc message, then press button ‘Links’, all the corresponding s-BDocs are displayed.
Select BDoc message, then button ‘receivers’, if the receiver’s state is “sent” that means that the CRM
Server is waiting for a confirmation from this consumer (receiver). Start SMQ1 and select destination
name, a queue R3AUBUPA<id> is there and could be in error status CPICERR:
1. Restart the queue after the reason of problem is solved (adjust RFC connection and RFC user and
password!)
2. If no queue does exist, that means that it was deleted manually. Define and start a request to get the
current status from CRM Server to R/3 or retry the message processing if you are sure that this is the
last change or for test purposes.
Select BDoc message, then press button ‘Receivers’, if the receiver has the state: “Error outbound in
processing”, select button ‘errors’ to get detailed information and implement the solution to the problem.
After solving the problem, retry to process the BDoc message or extract the data from the CRM Server
and send it to the receiver. In this case do not forget to delete the BDoc message.
(The End)