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.)

In this post, You got to know about different Tcodes and bdoc related things.
In my next post, you can see more in detail like how to solve Bdoc related issues and what are the challenges faced?
To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply