CRM Middleware Monitoring Cockpit - The Place to be for the CRM Middleware Admin

SMOGGEN, GNRWB, SMQS, SMQ1. Sounds familiar and strange at the same time? :) Welcome to the world of CRM Middleware and how many times have you wished that you need not remember all the transactions by heart and there is a one stop shop for your MW checks? Wish is granted and it has been quite a while since it is granted. For a change, Ignorance is not a bliss here. SMWP is the only transaction you had to know to call yourself a CRM MW Admin. As simple as it sounds, it really is that simple, indeed! Just goto transaction SMWP and you will see it for yourself. Look how well it is organized for you and the sequence of organization is by itself an information. First of all stands the Generation information, which is often a nightmare when you have quite a few changes with the BDoc.

v A double-click Status of Generation processes will take you to transaction GENSTATUS. This will help you monitor the current generation status in the system. v Generation of structures is exclusive to this transaction alone where you can see the status of the BDoc segment generation, the successful ones and the segments with errors. v Generation of other runtime objects is also exclusive here which lists down the status of each BDoc based on the runtime objects of the BDoc. The runtime objects include the function group and the function modules relevant for the BDoc type (the generated modules of inbound adapter, outbound adapter, the rejection service, CDB service etc). v Replication objects per Industry gives the generation status of the Runtime objects related to the Replication objects for a specific industry (CG, PH or HT). The runtime objects include the lookup tables, data collector tables and the Replication & Realignment modules. v Publications per Industry: Runtime Objects gives the generation status of the Runtime objects related to the publications and interlinkages for a specific industry (CG, PH or HT). The runtime objects include the subcheck and interlinkage relevant modules.

v Business Tasks (Generation for proxy framework) Now that you have the system all set and ready with the Generation all GREEN, you may want to check whether the system has begun to run properly and you want to monitor the progress. Runtime Information provides all the necessary details.

v Message Processing Active takes you to transaction MW_MODE which helps you check whether Middleware processing is active or inactive. You can Activate/Deactivate the BDoc processing in the system using this option. v Data Exchange using qRFC Queues this is probably the item I like the most. You have comprehensive monitoring of all the queues relevant in a CRM system organized in 2 sections queues in CRM and queues in the connected ERP/ECC backend. Yes, you read it right, it lets you monitor the queues in the ERP/ECC system. qRFC queues in CRM server

Data exchange with R/3 Backend o Start queues for loads from R/3 Backend: You should know that the loads from ERP/ECC to CRM are always initiated from CRM. This initiation is done via an outbound queue and such queues are either R3AI* or R3AR* queues. These can be monitored for errors at this point. o Loads from R/3 Backend: Any loads from ERP/ECC will fetch data from ERP/ECC via inbound queues after successful initiation discussed in the section before. The queues are usually R3AI* (for loads) and R3AD* (for individual object changes (or) delta changes, as it is usually called and these are usually preceded by a load). o Loads for R/3 Backend: There are occasions when you want to send data from CRM to ECC/ERP system. This is not the load initiation discussed earlier but rather actual data being sent from CRM out to ECC/ERP system. The queues are usually R3AU*. Data exchange with Mobile clients -- (Mobile clients is a misnomer here and it is the laptops. For historical reasons, the laptops are continued to be called as Mobile clients(of course, you can replace the laptop with a Mobile phone and still continue to use the existing framework). Data exchange is always initiated from the Mobile client via the tool ConnTrans. o Loads for Mobile clients: Any data exchange from CRM to a laptop is done via an outbound queue. These are usually CRM_SITE* queues. o Loads for Mobile clients: Any data exchange from a laptop to CRM is done via an inbound queue. These are usually CRM_SITE* queues. CRM Server Internal queues

Start queues for loads to CDB: Even though CDB is only a logical separation within a CRM system for serving as a Consolidated DB for the laptops, it is best to consider it as a separate system when we talk about the loads and data exchange. So, just as with ERP/ECC, loads involving CRM and CDB are always initiated from CRM via an outbound queue. This outbound queue will have the destination NONE to represent the CRM system because the CRM is the data source here. The queues are usually CDBI* o Initial loads to CDB: After successful initiation of the load from CRM to CDB, the actual data gets populated in inbound queues which are usually CRI*CDBI. Other queues of CRM server o Send queues of CRM server applications -- Ever wondered how the CRM Middleware manages to send all the changes that is made in CRM system exactly in order? The secret is the CSA* inbound queues. For any change that is happening at the CRM system, a CSA* inbound queue is written which acts as a reminder/log to be processed for data distribution. This is processed asynchronous to the actual data change, which ends up in generating the actual data transfer queue to the connected systems. The asynchronous nature actually makes sure your CRM application keeps running completely independent of data exchange. o Start queues for Loads to External systems -- If you are making use of this, you are already a master of CRM Middleware. These are the queues meant for any external system (special system configured as EXT) from/to which you want to initiate load. The queues are usually EXT*.

We have so many queues, inbound and outbound. Who controls the execution of these queues? We have one inbound scheduler and one outbound scheduler.

QIN Schedulers: Errors o QIN Scheduler Errors: All Clients and Unregistered inbound queues -- Takes you directly to transaction SMQR, the inbound scheduler monitor. This will help you decide on whether to stop processing certain queues or whether to give greater attention to certain queues or not. QOUT Schedulers: Errors o QOUT Schedulers Errors All clients -- Takes you directly to transaction SMQS, the outbound scheduler monitor. This will help you decide on whether to stop processing certain destinations (or) whether to give greater attention to certain destinations or not.

qRFC queues in R/3 Backends

Loads for CRM server o This takes you directly to transaction SMQ1 (outbound queue monitor) of the connected ERP/ECC system. This will let you see if there are any failures in the ERP/ECC system that are preventing the load (R3AI*) or the delta change (R3AD*) from flowing to CRM

v Adapter Status Information

Initial load status o This will directly take you to transaction R3AM1 which lets you see if there are any loads in WAITING, RUNNING, ABORT (or) DONE status. Request status o This will directly take you to transaction R3AR3 which lets you see if there are any request loads (which are nothing but loads with user specified ranges) in WAITING, RUNNING, ABORT (or) DONE status. Inactive objects o This will give you the number of inactive parent objects with or without the child objects being active. Parameters in R/3 Backends o This will list down all the connected ERP systems. o It will let you login to the ERP systems directly (provided the SM59 user is a dialog user). o It will take you to ERP SM30 for CRMRFCPAR table which has the settings to control the flow from ERP to CRM in ERP. o The other customizing settings controlling the ERP to CRM communication can be found in CRMPAROLTP table in ERP via Entries in table CRMPAROLTP.

v Replication & Realignment queues

R&R queue Daemon o This will take you to transaction SMOHQUEUE which lets you control the queue daemon for the processing of the R&R entries for the mobile clients (laptops CRM_SITE* queues). Status of R & R queues o Each R & R queues status is reflected here. If you see any failure, each of the entries will take you to SMOHQUEUE from where you can see detailed error information and take corrective action.

v BDoc messages in the flow

Messages in error status o This will take you to transaction SMW01 showing the BDocs in Error status (RED E*). Messages waiting for response from backend systems o This will take you to transaction SMW01 showing the BDocs in Intermediate state waiting for a response from ERP (YELLOW I02).

This completes the monitoring of Runtime information. We now move on to other System settings with which we can administer the systems connected to our CRM system.

v Number of sites per site type

There are several different type of systems that CRM Middleware understands and here at this element, you can monitor and administer, physical or logical systems for each of those types. Every entry will take you to transaction SMOEAC from where you can administer all the properties of a given type and system.

The Runtime information and System settings are all fine and the system has been running well. Now, you want to gauge the performance of the system and look for ways to improve it Monitoring tools/Statistics will let you collect such information with which you can take decisions on improving performance of CRM Middleware.

v BDoc type/BDoc service Workload statistics

This will take you to transaction SMWMFLOW which will let you access Kernel statistics and also queue performance statistics at BDoc level and queue level (BDoc message flow processing statistics).

v Mobile client communication statistics

This will take you to transaction SMWMCOMM to monitor the communication between CRM and Mobile clients (Laptops) by statistics collected at the Communication station. This will let you view the statistics for a given time period, a given Mobile client, data sent or received and also will let you see if there were failures during communication.

v Status of CRM Middleware alert Monitor

This element will consolidate the alerts from the CRM Middlewares collection of alerts and monitors under the system wide monitoring CCMS setup (transaction RZ20). This

will also take you to the section of CRM Middleware alerts so that you can view them in detail. v Trace status

This element takes you to transaction SMWTAD with which you can enable traces at different stages of Middleware processing and can view those traces via transaction SMWT.

There are several batch jobs for CRM Middleware which should be running to have statistics collected regarding communication and execution of queue entries. There is an element to monitor all such monitoring jobs and collector jobs Background jobs.

v Middleware Reorganization

As important as collecting statistics and monitoring information is the reorganization of such information regularly. There is a background job to reorganize all Middleware related monitoring information and traces (including BDoc monitors). The job MW_REORG* is with report SMO6_REORG2 and this element shows the status of that job.

v Collector for Monitoring Cockpit

The information shown in SMWP by itself has to be collected periodically and there is a background job to do that. The job SAP_MW_COCKPIT_COLLECTOR* is with report SMWP_BATCH.

v Collector for BDoc Message/Site statistics

The statistics that you see in SMWMFLOW are collected with job RSMWM_BSTAT_COLLECTOR report RSMWM_BSTAT_COLLECTOR.

v Check Generation status of objects

There is a background job to check the generation status periodically job MW_CHECK_P, report GN_GENERATE_CHECK

v Periodical Background generation

In a development environment it is good to have the generation triggered at regular intervals to make sure all the design time and runtime objects are consistent. To do this, there is a job MW_GENERATE_P, report GN_WORKLIST_GENERATE.

v Administration Console Subscription Agent

If you are using Subscription agents for your Mobile clients (laptops) to have the subscriptions generated periodically, the job corresponding to it is SMOE_SUBSCRIPTION_AGENT*, report SMOE_SUBSCR_AGENT_EXECUTE_JOB.

v Administration Console Site Scheduling

When using Mobile clients (laptops), there may be occasions when you want to activate or deactivate them during a defined period of time. This can be done with Job SMOE_SCHEDULING* and report SMOE_SCHEDULING_EXECUTE_JOB.

This completes a summary of all you can see and do with SMWP. The idea is to consolidate all the data in one transaction making it easy for the CRM Middleware administrator.

Issues during Business Partner replication between CRM and ERP

Added by Prathiba A, last edited by Gregor Wolf on Apr 13, 2009 (view change) show comment

During Business partner replication Sales area is missing

Solution:

1. Check if you have generated ECC org structure without errors through CRMC_R3_ORG_GENERATE. 2. If yes, go to tcode- PPOMA_CRM, select your SALES ORG go to ATTRIBUTES Tab Assign the distribution channels and divisions manually if they are not available. Select the Object permitted in determination check box. 3. Run the tcode - CRMD_DOWNLOAD_SB, Go to table SMOTVKOV and check if the entries match after running the above tcode. 4. Run the report CRM_MKTBP_ZCACL_UPDATE_30 in SA38. 5. Run the report CRM_ORG_INDEX_CREATE in SA38 for values 'O' & 'S'. (Organization and Position) 6. Create buffer for sales area by running the report HRBCI_ATTRIBUTES_BUFFER_UPDATE in SA38 7. Now download object DNL_CUST_S_AREA through R3AS and check for the sales area.

BUPA_MAIN bdoc "Error 0055 - Fill in all required entry fields"

Method to Debug-

When we are replicating a business partner from CRM to R/3 there are certain mandatory fields in ECC system which are not entered during creation of Business partner in CRM. 1) Check the field groupings done on both the systems , In ECC system check tcode- OVT0 against the respective account group (eg:Sold-to-party) In CRM use the following path to check the field groupings: SPRO-> IMG>Cross-Application Components SAP Business Partnerer -->Basic Settings -> Configure Field Attributes per BP Role Identify the missing field and enter it in the created BP in CRM and try to resend. If we are not able to identify the actual field causing the issue use the below mentioned steps to debug. 2) We can debug using the following method to find out the mandatory fields in R/3 that are causing this issue: Go to tcode- SMW01and display the BDOC. Enter /h in the transaction code field Press the 'retry to process message' button. In the debugger - select the Settings button and 'In background task do not process' Press F8 Open tcode-SMQ1 in a new session and select the entry R3AUBUPA** or CSA_BUPA* Double-Click on this queue and choose Debug for the CRM_UPLOAD_TRIGGER In the debugger, set a breakpoint at statement 'CALL TRANSACTION' and then press F8. At this statement double-click on the statement CALL_TRANSACTION and change the variable CALL_TRANSACTION_MODE from N to A, press the 'change field content' button and then press F8 Now you will be in the R/3 System and you can see the batch input

Business partner <GUID> does not exist

Solution1. In SMW01 choose the line with the error and hit "Error segments". Copy the partner number or GUID from there. 2. Call Transaction CRMM_BUPA_MAP (in the CRM server system): enter the BP number or BP GUID and hit return. o Case 1: CRM GUID, CRM BP number and R/3 BP number are displayed: this means that the BP exists both in CRM and R/3 and you have to find out whether CRM or R/3 hold the latest version of the business partner. If the BP is newer in R/3, hit "Gather BP data" If the BP is newer in CRM, hit "Send BP data". o Case 2: No BP number is displayed. This means the business partner only exists in CRM.

Therefore you have to hit "Send BP data" 3. When you are finished with the above procedure retry the BDoc in SMW01 by marking the error line and hitting "Retry to process message".

Issues during Material replication from ERP to CRM

Added by Prathiba A, last edited by Gregor Wolf on Apr 13, 2009 (view change) show comment

Category contains set types that are maintained for the product
After downloading products from ECC system, the above error may occur when we create a new product and try to assign a set type which has already been assigned to a category which is used by another product.
Solution:

1) You want to delete the assignment of the product to a category. This is not possible because the category contains a set type which has already been maintained for the product. 2) You can delete the assignment of the product to a category or reassign the product to another category by choosing Recategorize Products in the user menu (transaction code COMM_PROD_RECATEG) 3) After you have repaired the Customizing problem, retry the BDoc by marking the line in SMW01 and hitting "Retry to process message". 4) In order to delete a product do the followingFirst we need to register in COMC_PR_TOOL_REGgo to transaction SE16Enter table name- COMC_PR_TOOL_REG, choose create iconThen enter all details with program nameCOM_PRODUCT_DELETE_SINGLE and save Go to tcode: SE38, enter programCOM_PRODUCT_DELETE_SINGLE, and click on execute icon.Remove check mark from Simulation- no deletion and execute The product gets deleted.

Sales area for product not replicated.

Solution:

1. Check if you have generated ECC org structure without errors through CRMC_R3_ORG_GENERATE. 2. If yes, go to tcode- PPOMA_CRM, select your SALES ORG go to ATTRIBUTES Tab -

Assign the distribution channels and divisions manually if they are not available. Select the Object permitted in determination check box. 3. Run the tcode - CRMD_DOWNLOAD_SB, Go to table SMOTVKOV and check if the entries match after running the above tcode. 4. Run the report CRM_MKTBP_ZCACL_UPDATE_30 in SA38. 5. Run the report CRM_ORG_INDEX_CREATE in SA38 for values 'O' & 'S'. (Organization and Position) 6. If sales area still not replicated from R/3 go to R3AC1 and access the object MATERIAL and choose tab tables/structures and remove the check mark for the column "inactive" of table MVKE.
ERP product hierarchy not downloaded from ERP during initial load of object DNL_CUST_PROD1 Solution:

Go to tcode-R3AC3 and check if the tables T179 and T179T are marked inactive under the tables/structures tab for object DNL_CUST_PROD1.