Introduction to CRM Middleware

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

This completes my discussion on CRM Middleware. 

 Happy Reading 🙂