CRM MIDDLEWARE GUIDEANALYZING BDOCS IN CRM SYSTEMStep 1: Go to T-Code SMW02A and choose BDOC type as BUPA_REL for Relationships, BUPA_MAIN for Customers and PRODUCT_MAT for Products and change the BDOC MSGS Containing error value anything more than 1000 and click on execute.

Step 2:Choose each BDOC Type and click on Detail Analysis, which navigates to the next screen and shows list of BDOC errors.

Step 3:Choose the BDOC and click on the SHOW BDOC MESGERRORS/RECEIVERS which describes about the error.

Step 4: Find the customer Id/Product Id/Customer relation GUID for the respective BDOC.Choose the BDOC and click on SHOW BDOC MESSAGE EXTENDED (EXT.) DATA

Step 5:For Customers we would find the Customer Id on click of SHOW BDOC MESSAGE EXTENDED (EXT.) DATA

For Products we would find the Product Id on click of SHOW BDOC MESSAGE EXTENDED (EXT.) DATA

For Customer Relationship we will not find the customer ID rather we would find the GUID, to find the Customer ID for the relationship to update. Follow below steps.

Choose the GUID

Go to table CRMKUNNR (ECC System) and enter the PARTNER GUID and get the customer ID.

Find the corresponding employee for customer from table KNB1 (ECC System). Verify the employee exist in the CRM System.

Step 6: Identify the root cause of the issue and make the necessary changes in the master data/customization and do the REQUEST DOWNLOAD.

It is not advised to run the initial download because there might be chances of mismatch in the GUIDs rather do the REQUST DOWNLOAD

STEP TO BE FOLLOWED FOR REQUEST DOWNLOAD

Step 1: Create a request using T-code R3AR2. Go to change mode and click on the NEW REQUEST. Enter request name (any name) and choose adaptor object respectivelyNameAdaptor ObjectCUSTOMERCUSTOMER_MAINCUSTOMER RELATIONSHIPCUSTOMER_RELPRODUCTMATERIAL

Choose Request Detail and click on NEW Entries and main the entries as per the screen shot and save.

Note: Incase if there is need to download in the range, choose the option BETWEEN and enter LOW and HIGH values. Enter the exact values as per the database with leading zeros.

Step 2: Execute the request using T-Code: R3AR4.Enter the request name created in the earlier step and execute.

Step 3: Monitor the request using T-Code: R3AR3

Block size indicates the number of blocks replicated.Step 4: Display the BDOC using T-Code: SMW01 and click on execute.

Green color indicates successful replication.Red color indicates not replicated.Yellow color indicates still in progress.

Different Transactions used in Middleware monitoringCRM Server Central MonitoringActivities / FunctionsMonitoring TypeMonitoring FrequencyPeriods and Events

Middleware PortalMonitoring the CRM Middleware Portal with transaction SMWP can be subdivided into the following areas: Generation Information containing:BDocs Types: Generation of structuresBDocs Types: Generation of other runtime objectsReplication objectsPublications: Missing Indexes, Status of Delta/Initial Generation, Flow Definitions Runtime Information containing:Adapter Status InformationReplication and Realignment QueuesBDoc Messages in the FlowSMWP Several times a daydepending on thebusiness process After implementingtransports

qRFC Outbound Queue Monitor: Monitor data transfer between the R/3 back-end and the CRM Server and between the CRM Server and mobile clients and other connected systems Queues destined for the R/3 back-end and other stady connected systems should be relatively short and quicklyprocessed, queues to destinationNONE too Entries destined for the mobile clients and BW remain in the queue until each receiver fetches its data When the queue entries for a client reach 10,000, the queue should be closely monitored (e.g. issue warning). When the entries reach 100,000, severe problems may occur and performance will be affected. Administrative actions must be taken in these cases, any deletion of queuescauses data inconsistencies If a queue that is in use between a mobile client and the CRM Server is deleted, it will cause data inconsistency between the CRM server and the mobile client.SMQ1 Several times a daydepending on thebusiness process Daily

qRFC Inbound Queue Monitor: Monitor data transfer between the R/3 back-end system and the CRM Server and between mobile clients and the CRM Server and all other queues, which have to be stored in the CRM Online DB Messages in the inbound queue are processed according to the capacity of the CRM Server. High number of entries in the inbound queue can indicate insufficient capacity on the CRM server.SMQ2 Several times a day depending on the business process

BDoc Messages / Summary Application error analysis SMW01: Display the data of a BDoc message and possible errors SMW02: Display BDocs message summary in dependency on the site IDSMW01 / SMW02 SMW02: Display BDocs message summary in dependency on the site ID In case of an error message

Request Download Definition Data requests can be defined manually from an R/3 backend.R3AR2 If there are data in the CRM Server or CDB or R/3 back-end missing or incomplete, in exceptional cases, you can use the request to bring your database into a consistent state after a data loss in one the databases.

Request Download trigger Data requests defined can be manually triggered.R3AR4

Monitor Request Used in exceptional cases to bring the database into a consistent state after a data lost.R3AR3 In case of an errormessage, if thedatabases are notconsistent and arequest from the R/3back-end, the CRM

Details of SMWP screen (screen shot is not of the Distell system) This is just to show the functionality of each node in Middleware Portal)QUEUE MONITORINGTr. SMQ2( Inbount queue monitoring ), SMQ1 (Outbound queue Monitoring)The naming convention of the Queue is as follows:Queue NameSystemsDescription

R3AIR/3 CRMInitial. BAPIs destined for theR/3 back-end

R3ADR/3 CRMDelta

R3AR_R/3 CRMRequest

R3AUR/3 CRMUpload

CRM_SITECRM-> Mobile ClientSynchronization BDoc typesfrom the CRM Server going tothe mobile client

CSA_CSA_MASS_CRM-> CRM (simplereplication)Outbound for simplereplication of BDocs toreceivers

BW.. CRM-> BWQueues to BW systems

The transmission of delta information is performed from the R/3 back-end system or othersystems to the CRM Server. When the delta information arrives at the CRM Server, the data isforwarded to the inbound queue. The delta data can be found for instance in the R3AD* queues. The inbound queues are normally empty or small, if the CRM Server has enough resourcesand no errors occur. Mark an entry and press Change View (F8) to detect stopped or hanging queues. Double-click on the queue to display the LUWs belonging to the queue.It is strongly recommended to avoid deleting the queue or queue entries, because this can lead todata inconsistencies!The qRFC Inbound Queue Monitor, SMQ2, is not a critical monitor on the R/3 back-end systembecause there is normally no data to be displayed. Instead, monitor the outbound queue (SMQ1or R3AM1) on the CRM Server.Transaction: SMQ21) Select the entry you want to view.

2) To view the details, press the Change View button (F8) and check for stopped or hangingqueues.

It displays the details of the queue like status, date , sender id etc.Double click on the queue, it will show all the entries in it.

We can delete the entry which is in error state to continue the processing of other entries in the queue.

Come back to the previous screen and select the queue from which the entry was deleted and select Unlock Queue (F5).

After this the next entry in the queue will be processed.