SAP CRM Data Exchange with R/3 Back End

SAP CRM Data Exchange with R/3 back end has external techniques is carried out through adapters.The adapters map and convert knowledge between numerous formats.The CRM System helps the handling of CRM business objects, like clients and prospects,activities and alternatives, products and product catalogs in a variety of CRM elements like Web Sales, Web Service, Interaction Center, Telesales, Marketing campaign Administration and various others. The CRM Server Functions exchange information with the CRM middle ware by manner of the CRM Adapter.The SAP Internet Software Server is the successor to the SAP Basis System. The kernel launch used with CRM 4.0 is 6.20.

Message Flow

1. Inbound processing: Incoming information of different formats, that's, BAPI buildings from a SAP R/3 Backend, synchronization BDoc messages, XML/SOAP or IDocs, are converted into messaging BDoc messages.
2. Validation: the integrity of incoming information is validated by the respective application. In case of a successful validation, the information unit is handed on to outbound processing. In case the incoming data is not legitimate, the BDoc message will stay in the message flow with an error status.
3. Outbound processing: the receiving systems, for instance, SAP R/3 Backend, external methods or Mobile Purchasers, are determined. Then the BDoc message is passed to the corresponding outbound adapter, which converts the message into the data codecs of the receivers.

The data change through the CRM middle ware requires that an R/3 Plug-In is installed on SAP R/3.Supported R/3 releases are 3.1I, 4.0B, 4.5B, 4.6B/C and above.The SAP R/3 Backend (one or several SAP R/3 Backends) serves as ?? Supplier for customizing and enterprise information (master information, transaction knowledge).Receiver of business information for additional execution (at the moment primarily with mySAP Financials and mySAP SCM for accounting and logistics execution).The CRM release 4.zero can be used as a stand-alone system, that implies that R/3 Backend is now not required for the execution of CRM-associated tasks.In CRM, the R/3 Adapter communicates with the R/3 System through distant enabled features of the R/3 Plug-In.

Connection with R/3

On the R/3 side, it's a must to create an RFC Vacation spot to the CRM system. Then activate CRM as client in table CRMCONSUM and preserve the table CRMRFCPAR. By this desk, the determination of the RFC locations for the information switch is connected with the consumer, consumer, object identify and transfer type. For instance, you'll be able to ship data to a shopper in an initial download solely, and never in a delta download.In the CRM system, it's necessary to create an RFC Vacation spot to the R/3 backend and a R/3 Website with the tool Administration Console. The R/3 Web site references the RFC-Destination. Activate R/3 OLTP as client in table CRMSONSUM.

Starting Administration Console

The Administration Console may be accessed by manner of the menu-middle ware- Administration-Administration Console (or by manner of the transaction SMOEAC).
Object sorts are used for the replication modeling:

1. Websites
2. Replication objects
3. Publications
4. Subscriptions
5. Organization
6. Employees (Cell users)
7. Inter linkages (Mobile-particular)

Creating Site

Four steps are required to create a brand new site.

1. Select the Create button.
2.Provide the location particulars, such as

• A site identify and a web site description,
• Choose the location type, such as Cell Client, R/3 Backend, Exterior Interface for XML/IDocs.
• Specify the location attributes depending on the location type, for instance, an RFC vacation spot for R/3 Back ends.

3.Assign the location to one or more subscriptions .
4.End the creation process by selecting the Save button.

There are two SAP roles that specify the authorization to create or keep objects inside the Administration Console:

position SAP_CRM_MWAC_ADMINISTRATOR for workers, websites, organizational items and subscriptions and

function SAP_CRM_MWAC_CUSTOMIZER for replication objects and publications


R/3 Websites are determined by an RFC destination, a logical system, and the discharge of the R/3 Back end.

Customizing Synchronization

There are predefined mappings of customizing tables between SAP R/3 and SAP CRM, including
costs and conditions. This kind of customizing can be downloaded by manner of CRM middle ware or by the Customizing Distribution with the SAP Answer .The answer supervisor contains mapping rules between the R/3 and CRM customizing tables, known as Synchronization objects. Choose transaction SCDT_SHOW_MAPPING in the solution manager and CRMBBP launch 40 as goal component.Detailed monitoring of customizing differences between SAP CRM and SAP R/3 is feasible through the SAP Answer Supervisor (Customizing Scout).Preliminary load of customizing from SAP R/3 to SAP CRM and vice versa is possible via CRM middle ware. Be aware: not all required customizing settings are downloaded. Some customizing settings (like ISO codes, currencies, and so on) should be both transported by approach of the transport administration system, or manually adjusted or distributed by means of the SAP Answer Manager.

Bidirectional delta customizing distribution of associated customizing from SAP R/3 to SAP CRM and vice versa is possible via the SAP Answer Manager (Customizing Scout).Middle ware load might be diminished by optimizing customizing obtain for new installations as a substitute of using CRM middle ware.

For several Customizing Objects, there is a predefined information switch from R/3 to CRM accessible, even when the structure of the Customizing tables are different in R/3 and CRM. The information of a quantity of database tables are grouped in Customizing Adapter Objects. The data of a Customizing Adapter Object can be transferred from R/3 to CRM system with an initial load.

Customizing Adopter

Use Transaction R3AC3 to show Customizing Adapter Objects in CRM.All Customizing Adapter Objects are assigned to Object Class CUSTOMIZING. Within the Initial Circulation Contexts tab, you discover the supported CRM middle ware Circulation with supply and target Sites.In the Tables/Buildings tab, you find the names of the database tables to be chosen in supply system. To create filter criteria, choose the Filter Icon. The next graphic explains the finest method to create filter criteria.


Specify the R/3 Site. The positioning has to be created beforehand in the Administration Console (SMOEAC),because the corresponding RFC destination will in all probability be used for synchronization.Specify the desk fields for the the place clause inside the data extractor in R/3. Specify the Filter Options (Choices: Filter in supply and target database, filter only in target database,filter only in source database).Save the Filter criteria. The Filter standards will possible be automaticaly synchronized with R/3.

The Customizing data is transported to the CRM System by manner of qRFC in generic construction BAPIMTCS.The Mapping Function Module maps this information to the structure of the CRM desk and updates the CRM Table.There isn't any such thing as a MBDoc created and no Message Flow started.

Inbound and Outbound Ques

Once you begin an initial load with transaction R3AS for a specific customizing adapter object, the data request is distributed from the CRM system to the R/3 Backend through qRFC. The naming convention for the qRFC queues utilized in initial load is R3AI_ (R3A: R/3 Adapter; I: initial Load).The generic extractor for Customizing information selects the database tables assigned to the Customizing Adapter Object and triggers the info switch per qRFC.

You find the identify of the generic Extractor in table CRMSUBTAB:

1. Start transaction SM30 in R/3.
2. Choose table CRMSUBTAB.
3. Seek for Object Class CUSTOMIZING and Download.
4. The Function module CRS_CUSTOMIZING_EXTRACT is assigned in column Operate Name.
5. CRM will retailer the title of the customizing tables assigned to the customizing adapter object to the generic extractor. The generic extractor checks the filter standards and selects the data from the customizing tables. The information will probably be transformed to switch construction BAPIMTCS. This data package will be transferred per qRFC to the R/3 Adapter of CRM.

The R/3 Adapter calls the Mapping Perform Module for the precise Customizing Adapter Object and passes the info container to the perform module. The Mapping Perform Module converts the
BAPIMTCS data into the construction of the CRM customizing tables and updates the tables. The mapping guidelines are applied within the Mapping Operate Module.The outbound scheduler is often not continually working. Due to this fact, its standing is often shown as INACTIVE.It only begins working if new entries are stored in the outbound queue.To find out if it is running, verify row Last update. To replace the display, choose the Refresh button. If the outbound scheduler is processing a amount of qRFC-LUWs, its standing shows as WAITING.Be aware: Solely registered queues will be processed. You can cease outbound processing by deregistering the RFC destination (for maintenance solely).

Outbound Que Monitoring

Though the LUWs belonging to a queue are stored within the tRFC tables ARFCSSTATE and ARFCSDATA, you cannot keep or show these LUWs using tRFC monitoring (Transaction SM58). You must use the outbound queue administration transaction SMQ1.The outbound queue knowledge (queue attributes and pointers to the relevant LUWs in the tRFC tables) is stored in table TRFCQOUT, which you'll display and maintain utilizing Transaction SMQ1.The next capabilities are available:

1. Record queues
2. Show queues, including a listing of associated LUWs and function modules (with input data)
3. Begin/stop transmitting the queues
4. Delete queues or queue entries (Warning: deleting queues may cause inconsistencies)
5. If an error occurs in an LUW on the distant receiver system, the function modules of the queue entries are rolled back there. The related LUW and all the different LUWs within the queue remain in the queue and within the tRFC tables on the sender system. After correcting the error, you ought to use Transaction SMQ1 to transmit the LUW of the queue once more (via Edit ?? Execute LUW).

The inbound scheduler is configured primarily based on queue names (which is completely different from the outbound scheduler SMQS which handles destinations). Which means that if new queues are used, they have to be configured otherwise these entries is not going to be processed.The LUWs belonging to a queue are saved in the tRFC tables TRFCQIN, TRFCQSTATE and TRFCQDATA. However, you can't maintain or show these LUWs using tRFC monitoring (Transaction SM58). You want to use the inbound queue administration transaction SMQ2.The inbound queue data (queue attributes + tips to the relevant LUWs within the tRFC tables) are stored in desk TRFCQIN. The status you can find in table TRFCQSTATE, the data in desk TRFCQDATA.

You may display and maintain the inbound qRFC utilizing Transaction SMQ2.The following features can be found:

1. Record queue
2. Display queues with a list of accompanying LUWs and performance modules
3. Start/cease transmitting the queues
4. Delete queues or queue entries (Warning: deleting queues may trigger inconsistencies)
5. If an error happens in a LUW, the perform modules of the queue entries are rolled again there. The relevant LUW and all dependent other LUWs in the queue stay in the queue and within the inbound qRFC tables. After correcting the error, you ought to utilize Transaction SMQ2 to transmit the LUW of the queue again.

Middle ware Trace

The middle ware Hint Monitor is a tool to track program flows, report occasions from this, and supply info for evaluation.The middle ware Trace could be accessed both from transaction Show BDoc Messages (SMW01),by menu path middle ware-Monitoring-message Circulate-Display middle ware Hint or straight with Transaction SMWT.

Data Consistency

In certain circumstances, you want tools to appropriate knowledge inconsistency, for instance, after it's necessary to reset one system (incomplete recovery). SAP offers tools to detect inconsistencies and repair inconsistencies.The Customizing Scout within the SAP Resolution Manager can evaluate customizing settings (defined in synchronization teams) between totally different systems and if mandatory, can synchronize customizing deltas between the in contrast systems.The Data Integrity Manager is a tool inside CRM (transaction SDIMA) and can be used to repair inconsistent customizing settings between CRM and the R/3 Backends.The Request masses chosen data from SAP R/3 System to the CRM database or from an CRM database to an R/3 system. Both are triggered on the CRM system with Transaction R3AR4. The request overwrites entries for customizing objects and business data. Subsequently, it behaves like an preliminary load.

The request filters complement the adapter object filters, by further narrowing the information load and therefore permitting more refined filtering. Requests are used to synchronize information with no delta load capability like customizing.With the Data Integrity Supervisor (DIMa), you'll have the ability to detect and restore inconsistencies between objects across components inside the SAP CRM system landscape.An SAP CRM system panorama usually consists of a couple of database. Every SAP CRM system has a CRM database. Usually, knowledge alternate with one or more SAP R/3 again-finish methods is necessary. A consolidated database is the premise for data exchange with cellular clients. It is very essential to keep the objects in the completely different databases or datasets synchronized.The Data Integrity Manager compares knowledge in different elements and shows inconsistencies. The data comparisons are at all times carried out for the CRM database and an R/3 back-end database, and the CRM database and the consolidated database.

For loads of objects, it's also potential to synchronize the information via the Data Integrity Manager.There are two compare types accessible within the Information Integrity Manager: header examine and detail compare.

1. A header compare checks if an object instance exists in each databases.
2. A detail examine compares all information of an object occasion present in each databases.
3. Some objects could not permit a header compare. The element compare is then carried out.

Data Exchange Between R/3 and CRM

With the Information Integrity Manager (DIMa), you can detect and repair inconsistencies between objects across components throughout the SAP CRM system landscape.An SAP CRM system landscape often consists of a couple of database. Each SAP CRM system has a CRM database. In most cases, data alternate with a number of SAP R/3 back-finish systems is necessary. A consolidated database is the idea for information exchange with cell clients. It is vitally necessary to keep the objects within the totally different databases or datasets synchronized.The Data Integrity Supervisor compares data in several elements and displays inconsistencies. The knowledge comparisons are at all times carried out for the CRM database and an R/3 back-end database, and the CRM database and the consolidated database.

For many objects, additionally it is doable to synchronize the data by method of the Information Integrity Manager.There are two examine sorts out there within the Knowledge Integrity Manager: header compare and detail compare.A header compare checks if an object instance exists in each databases.A detail examine compares all information of an object instance found in both databases.Some objects could not enable a header compare. The detail examine is then carried out.

Initial Download

The info move for initial download consists of the next steps:

1. With the CRM transaction R3AS, an initial obtain trigger is raised.
2. The RFCs are queued and processed in a sequence (dependent or impartial objects).
3. In the back-end system, a function module name (object particular extractor module call) is used to extract the requested data.
4. A BAPIMTCS data container is created with the selected information to be sent to the CRM middle ware server.
5. The info is transferred to the CRM System using qRFC.
6. In the R/3 Adapter, the data is mapped to a mBDoc after which passed to the Inbound Message Flow.
7. The inbound message stream triggers the validation service. The data is handed via the CRM.
8. Adapter to the CRM Application. The CRM Software validates the info and updates the relevant CRM database tables. After profitable validation, the outbound message move is triggered.

You presumably can show and maintain Business Adapter Objects with transaction R3AC1. In Preliminary Circulate Contexts tab, you find the supported source and target website types and the corresponding Move Context.Business Adapter Objects

Filter options are set in the CRM system and allow the filtering of business objects within the supply system only, within the target system only or in both the supply and the target system. Nonetheless, business knowledge is usually filtered in the supply system to lower back the quantity of data transmitted from R/3. In this case, the filter standards is applied before the information is sent to the CRM Server.

1. Cut back the information volume between the R/3 Backend and the CRM Server
2. Maintain the R/3 specific data within the R/3 Backend
3. Filter settings are part of customizing the system.
4. The transaction to specify the filter standards may be discovered underneath: middle ware-Data Trade-Object Management- Enterprise Object (transaction R3AC1). Select a business object and Filter Settings tab. You ought to utilize all predefined fields (stored in desk SMOFFILFLD) .
5. Saving a filter entry triggers the automated switch to the Plug-In in R/3. The CRM system makes use of the RFC vacation spot of the corresponding Site. Subsequently a site to R/3 needs to be maintained first (transaction SMOEAC). Filter settings are saved in table SMOFFILTAB and seek advice from desk fields.
6. The filters are additionally accessible for Delta Loads (R/3 Backend to the CRM Server). Word: not all business objects help this feature yet.

The data transport is predicated on qRFC technology.

1. The naming conference for the qRFC queues utilized in preliminary load is R3AI_
2. (R3A: R/3 Adapter; I: initial Load)
3. The specific extractor for business information selects the database tables assigned to the Enterprise Adapter Object and triggers the info transfer per qRFC.

Message Bdoc Types

A messaging BDoc consists of as much as two elements:

1. Half 1: classical part
2. This part is mandatory.
3. The classical half consists of a BDoc header and segments, which can be organized in a hierarchical fashion. The segments of the classical part are not mapped to database tables.
4. This half is to be modeled with the (CRM Server based) BDoc Modeler.
5. Solely the classical half is used to discover out the receivers of mBDoc messages.
6. Since there isn't any mapping to database tables (that's, no CDB), this part always needs to be stuffed completely by the application at runtime.
7. Half 2: Extension part
8. This part is optional.
9. The complicated knowledge type is modeled with the Knowledge Repository Instruments (SE11).
10. The extension does solely exist for messaging BDocs.
11. The extension part is used to hold delta or extract data meant to pass into the CRM Server application (inbound case) or to ship to distant methods (outbound case).
12. The extension part can't be used for receiver determination.
13. When replicating data (for example, from CRM to R/3), a messaging BDoc kind is like an envelope,with knowledge contained in the envelope (Extension part) which CRM middle ware can't entry, and data on the envelope (classical part), which the CRM middle ware can access. Every application uses different tackle info, in order that, for instance, gross sales orders will be routed in accordance with the sales group to totally different back-end systems.

Replication traits are per the transient nature of the mBDoc, that's, solely the entire BDoc could be either distributed to all possible recipients (bulk replication) or to some of them (simple intelligent replication). It's not doable to choose out sure components of the mBDoc for replication and exclude others as is the case for sBDocs that are designed for the mobile world. Within the cellular world, there is a massive number of databases so that extra refined information distribution strategies - comparable to realignment are useful. This is not valid for the data exchange for messaging BDocs; due to the easy replication, no distribution data are saved in tables and due to this fact, a realignment for messaging BDocs is not possible.

The BDoc Modeler (SBDM) is a device used for displaying, creating, and enhancing BDoc types. The present BDoc types are listed in the BDoc overview (navigation tree) of the BDoc Modeler. Here you may choose and develop a BDoc type to show its structure. The structure shows the hierarchy of the data segments.Observe that the definition and enhancement of BDoc types require knowledge of the application. The CRM middle ware does not have the enterprise logic to create or enhance BDocs. From this level of view, it's just a knowledge container to move and process BDoc messages.

BDoc modeling features as of CRM 3.0:

1. Modeling of messaging BDoc varieties
2. Project of a number of synchronization BDocs sort to a messaging BDoc type (n:1 relationship)
3. Project of web site sorts (see Knowledge Exchange unit) to synchronization and messaging BDoc varieties

Flow Context

For the inbound message stream, there is solely one service obtainable: the validation service. We are going to explain the concept of circulation context in detail with the outbound message flow.You find the name of the validation operate module per mBDoc Kind in transaction SMW3FDIF. For instance: For mBDoc BUPA_MAIN the validation service is implemented with operate module CRM_BUPA_MAIN_VAL.After successful validation, the middle ware starts the corresponding outbound message movement with circulate context MO1 or MO2 in case of mass processing.Download R/3 CRM Request

To create a new request, begin transaction R3AR2.

1. Swap to vary mode and select New Entries.
2. Enter a request identify and the corresponding adapter object. Choose Enter to actualize the object class and the opposite attributes.
3. You probably can navigate to the maintenance of the selection criteria by double-clicking Request Detail. Select New Entries and enter the table title and field name of the source table in sender system. Select the value or the interval for the database selection.

Explicit Request

Requests may be began utilizing the menu or Begin Requests (R3AR4).The Request loads chosen knowledge from SAP R/3 to the CRM database or from an CRM database to R/3.Both are triggered on the CRM system with Transaction R3AR4. The request overwrites entries for customizing objects and enterprise data. Therefore, it behaves like an initial load. The request filters complement the adapter object filters, by additional narrowing the information load and permitting subsequently extra refined filtering.The request filters are merged with the general Adapter Object filters.Common Adapter Object filters for the desk fields are ignored throughout a Request, if the filters of that request are defined for the same desk fields. The reason for that is that the extractors, that is, the modules that extract the data from the database, mix filters for a similar desk fields with an or statement. If the filter of a request is also mixed with an or statement, the outcome would be all the information quantity of the preliminary load. Please preserve this in thoughts, for those who define filters for Requests.

Requests can additionally be scheduled utilizing background jobs (report SMOF_REQUESTN). With a devoted request, the chance exists to restore a BDoc error. Mark the defective BDoc as deleted in Transaction SMW01 and begin the request for the item (for instance, BUPA_MAIN) with the particular filter settings.


Delta Download Data flow

The delta hundreds enable a continuous synchronization of predefined adapter objects (except customizing information) between R/3 backends and the CRM server, that signifies that knowledge updates are despatched to the CRM Server immediately. Received knowledge is processed automatically. qRFC is used for the serialization.


The object class controls the activation and deactivation of delta masses for teams of Business Adapter Objects. The Business Adapter Objects can be assigned to an object class. Moreover, names of Enterprise Transaction Event (BTE) are assigned to the thing class.You probably can maintain object courses in transaction R3AC4.The implementation of the Business Transaction Events is part of the R/3 Plug-In. If a BTE is activated in R/3, the program to maintain Business Information will set off the BTE when updating a database table. The BTE converts the information into BAPIMTCS structure.You possibly can see which BTEs are activated in desk TBE31 in R/3.

Activation of Delta Download

The delta load is routinely activated after a successful initial load. You may test the activated BTEs in R/3 with transaction SM30 in the database desk TBE31.Manual (de)activation of BTEs is possible with the transaction.

Related Posts

SAP CRM Organizational Model
SAP CRM Technology Overview


PERFORMANCE DURING TABLE ACCESS IN ABAP DAY 13
DATA CONSISTENCY IN ABAP DAY 14