• This document will guide you through the SAP CRM MiddlewareTransactions and Settings to be done for data exchange between ECC and CRM. Overview • This article provides a basic overview of the key features of the CRM Middleware along with steps to help analyze and/or resolve some of the most common middleware problems. • 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). • 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 integrates various data producers both SAP and Non-SAP systems with SAP CRM landscape. • Middleware is a tool which is inbuilt within SAP CRM that enables the SAP CRM system to interact with various other SAP (R/3, BW, APO etc.) and non SAP systems (3rd party web channel etc.) • Using middleware we can control what data should flow in and out of the CRM system and also monitor the same. • The data exchange between the CRM Middleware and external systems is performed via adapters. The adapters map and convert data between various formats. SAP CRM Architecture • SAP CRM system can be act as a logical box and connected to different systems like interaction center, web channel, mobile clients, handholds, SAP SCM, BI/BW, ERP and with other various systems. CRM Server Architecture: • CRM architecture can be divided into 3 parts. 1. SAP CRM Middleware 2. Business Objects 3. CRM Server applications 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 (loads with user specified ranges) 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) • R3AM1: You can see if there are any loads in WAITING, RUNNING, ABORT (or) DONE status. • R3AR3: You can see if there are any request loads (which are nothing but loads with user specified ranges) in WAITING, RUNNING, ABORT (or) DONE status. Types of Download Object Used in CRM: • There are 3 types of download objects: • Application Objects (Defined in transaction R3AC1) - These objects are used to transfer data used in normal, every day application processing, such as material data, business partners, sales documents etc. • Customizing Objects (Transaction R3AC3) –The IMG is also used for CRM customizing, but much of the customizing that governs how application data are configured must be synchronized between the CRM and R3 using customizing Adapter Objects. • Condition Objects (Tr R3AC5) - Pricing and other condition objects. • The objects are stored in the table SMOFOBJECT. Some Background Information on qRFC’s • 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 - Queues in SMQ2 must be registered in SMQR to be processed automatically. • SMQS – Outbound Queue Scheduler - Uses destination names rather than queue names. For outbound queues, automatic processing requires that the corresponding destination be registered in SMQS. BDoc Analysis • BDOCs are containers for transporting the business data. • Tr SMW01 can be used to check the status of all BDoc’s. • The different relevant BDOC types: -BUPA_MAIN: contains the master data of a business partner (and is triggered on creation and change of a business partner) - BUPA_REL: used when you create a relationship between two business partners - PRODUCT_MAT: is used for data exchange of products/materials - BUS_TRANS_MSG: for data exchange of transactional data • BDoc’s in Error Status: Errors can be seen by clicking on the red “Show BDoc msg/errors/receivers” button. Setting up CRM middleware • Step 1 - Define Logical systems (CRM) In the SAP CRM IMG menu, go to Customer Relationship Management -> CRM Middleware and Related Components -> Communication Setup -> Set Up Logical Systems -> Define logical system and New Entries(F5). • Step 2 – Assign logical system to a client (CRM) Go to tcode SCC4. • Step 3 – Define Logical system (ECC) In the ERPIMG menu, go to SAP Netweaver -> Application server -> ALE -> Basic settings -> Logical systems - > Define logical systems -> Choose new entries. • Step 4 – Assign logical system to a client (ECC) Go to tcode SCC4. • Step 5 - Creating RFC users (CRM & ECC) An RFC user needs to be created in both the systems, which will be used by the middleware to connect to the target systems. • Step 6 - Creating RFC destinations (CRM & ECC) RFC destinations is like giving a name to your system which can be used to by other systems to connect to it. To create an RFC destination go to tcode SM59. • Step 7 - Creating Sites, Publications and Subscriptions. • Any system involved in the data transfer is referred to as a site. • A Publication is a logical group or set of data eg Bus. Partners, relationships, campaigns etc. Each publication has replication object (which is generated from and represents a particular BDoc type) assigned to it which determines the data which shall be exchanged. • Subscription is the assignment of a Publication to a particular site. • These can be done in tcode SMOEAC(Admin Console). • Step 8 - Define Middleware Parameters. These are the parameters which determine how the data exchange between various systems will happens. We can maintain these parameters using transaction R3AC6. • Step 9 - Registration of RFC destination. • Check that all the RFC Destinations have been registered. • This can be done in transaction SMQS • Step 10 - Registering the queues. • In tcode SMQR all the CSA and R3A queues must be registered i.e. Type = R, for the bdocs to flow. • Step 11 - Start initial load • The initial load can be started using transaction R3AS. Here we have to provide the objects for which we want to start the initial load along with the sender and receiving Sites. • Step 12- Monitor the initial load • On starting the initial load, we can monitor the progress and status of the data exchange through transaction R3AM1. • Step 13 – Create Sync request • The synchronization requests can be created through transaction R3AR2. • Step 14 – Start Sync request • The synchronization requests can be started through transaction R3AR4.