Skip to Content

About me:

Hi Readers, My name is Sai Krishna and presently working as Functional consultant in SAP CRM. I am new to this technology and faced lot of problems while working. I am writing this post to help people who are new to this field with Introductory concepts.

Business Scenario:

Whenever there are issues with flow of data between SAP & non – SAP systems, errors may occur which needs to be solved with an understanding of minimum concepts like Bdocs, how to load data manually,etc.

About CRM Middleware

CRM middleware integrates various data producers both SAP and Non-SAP systems with SAP CRM landscape

This area enables the replication, synchronization and distribution of data, for example between a networked branch office and its mobile field sales representatives. CRM Middleware links together the various types of data producers (mobile clients, R/3 back-end systems, Business Information Warehouse, etc.) within a CRM landscape, and provides all components with the necessary information.

In the context of an SAP CRM landscape, Middleware refers to the R3 adapter, which is used to transfer data from the CRM to external systems such as R3, mobile client, Groupware and vice versa. The data are sent via qRFC (queued remote function calls). The Middleware is also used to transfer data internally from CRM Online to the CDB.

CRM Online: As the name suggests, this database contains data relevant for online processing on the CRM system

CDB (Consolidation Database): This database contains data relevant for the mobile client. If the mobile scenario is not used, then this database need not be updated.

Types of Data Transfer/Loads using Middleware:

(i)               Initial load (can be from R3 to CRM or CRM to R3).

(ii)              Delta load (only from R3 to CRM)

(iii)             Upload (only from CRM to R3)

(iv)            Request (uses the same framework as the initial load)

Important Transactions for Analysing MW Issues:

 

R3AS: Start Initial load

R3AC1: Adapter Object Overview (Application Objects)

R3AC3: Adapter Object Overview (Customizing Objects)

R3AC5: Adapter Object Overview (Condition Objects)

qRFC

 

The R3 Adapter uses queued Remote Function Calls (qRFC’s) to transfer data to and from the CRM system. The advantage of using qRFC’s is that the data  are sent in sequence and if the one entry is stopped for any reason, then subsequent entries will not be processed until this entry has either been deleted or successfully processed. Thus, data consistency will be maintained, as long as a stopped entry is not manually deleted.

Important qRFC Transactions:

SMQ1 – Monitor Outbound Queue

SMQ2 – Monitor Inbound Queue

SMQR – Inbound Queue Scheduler

SMQS – Outbound Queue Scheduler

 

Note that queues in SMQ2 (i.e, inbound queues) must be registered in SMQR to be processed automatically. If the queue type has not been registered, then such queues will remain in status “Ready” until they are manually activated within SMQ2. It is possible to use a wildcard entry “*” for the queue name specified in SMQR.

The Outbound Queue Scheduler (SMQS) uses destination names rather than queue names. For outbound queues, automatic processing requires that the corresponding destination be registered in SMQS. (Exception: CRM_SITE_* queues do not have to be registered.)

BDoc Analysis

BDoc (Business Document) messages are used in SAP CRM systems as containers for the data that constitute a business process (application message, transaction). BDoc messages are exchanged internally within the CRM Server between the CRM Application and the CRM Middleware, and between the CRM Server and CRM Mobile Clients (Field Applications). SAP ERP does not know the concept of BDocs, so there is no exchange of BDoc messages between an SAP ERP system and SAP CRM. Instead, the business data is packed into containers during BAPI calls. So during a data exchange to and from SAP ERP, there are in fact outbound and inbound BDoc messages on the CRM Server, but only to communicate with the inbound and outbound ERP (R/3) adapters. Externally the content of the BDoc message is mapped to the mentioned BAPI container structure.

To display BDocs in your system you can use transaction SMW01 or SMW02.

Tr SMW01 can be used to check the status of all BDoc’s.  The search can be filtered according to status, BDoc GUID, BDoc type and queue name.

SMW02 is just a summary – which groups the bdocs by type and status

BDoc’s in Error Status:

Errors can be seen by clicking on the red “Show BDoc msg/errors/receivers” button.  Validation errors are always raised by the application; in most cases technical errors are also the responsibility of the application

In order to find the responsible component, click on the long text and look for the component responsible for the validation module mentioned (ie “service that caused the error”) and/or the error code given.

Sales BDoc’s Look Successful in SMW01 But Data are Missing

It is possible in some cases that a BDoc with a green light may have still have an error or errors. This can occur if a partial confirmation has been sent.  In such cases, you can see any errors by clicking on the “Show BDoc msg errors/receivers” button, or else by checking the application log, transaction SLG1.

 

Header Data Empty

If a BDOc is created with no classic (header) data, then the problem should be investigated from the application side. Once the Middleware has created a BDoc, the application is responsible for filling the header data

BDoc Status Codes

BDoc Status Description Severity Reprocessing
D01 To be processed (Debug) Intermediate X
E01 Technical error (incomplete) Error X
E02 Partially send, receivers have errors Error X
E03 BDoc cannot be read from DB Error
E04 BDoc validation error Error X
E05 Inbound processing failed Error X
E06 Outbound processing failed Error X
E07 Conversion error Error X
E08 Mapping error Error
E09 Update failure Error X
F01 Rejected (fully processed) Final
F02 Confirmed (fully processed) Final
F03 Set to processed (fully processed) Final
F04 Confirmed (fully processed by all receivers) Final
F05 Information (no processing) Final
I01 Received (intermediate state) Intermediate X
I02 Written to qRFC Queue (intermediate state) Intermediate X
I03 After qRFC step (intermediate state) Intermediate X
I04 BDoc stored before update task (intermediate state) Intermediate
O01 Sent to receivers (not all have confirmed) Intermediate X
R01 Retry after temporary error Error X
T01 Temporary lack of resources in application layer Error X

 

This completes my discussion on CRM Middleware. 

 Happy Reading 🙂 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply