CRM Middleware Monitoring Cockpit - The Place to befor the CRM Middleware AdminSMOGGEN, 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 andthere 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 , which is often a nightmare when you have quite a few changes with the BDoc. Generation information

v  A double-click will take you to transaction . This will help you monitor the current generationStatus of Generation processes GENSTATUSstatus in the system.

v  is exclusive to this transaction alone where you can see the status of the BDoc segment generation, the successfulGeneration of structuresones and the segments with errors.

v  is also exclusive here which lists down the status of each BDoc based on the runtime objects of theGeneration of other runtime objectsBDoc. The runtime objects include the function group and the function modules relevant for the BDoc type (the generated modules of inboundadapter, outbound adapter, the rejection service, CDB service etc).

v  gives the generation status of the Runtime objects related to the Replication objects for a specific industryReplication objects per Industry(CG, PH or HT). The runtime objects include the lookup tables, data collector tables and the Replication & Realignment modules.

v  gives the generation status of the Runtime objects related to the publications and interlinkagesPublications per Industry: Runtime Objectsfor 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 runproperly and you want to monitor the progress. Runtime Information provides all the necessary details.

v   takes you to transaction which helps you check whether Middleware processing is active orMessage Processing Active MW_MODEinactive. You can Activate/Deactivate the BDoc processing in the system using this option. 

v  – this is probably the item I like the most. You have comprehensive monitoring of all the queues relevantData Exchange using qRFC Queuesin 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 youmonitor the queues in the ERP/ECC system. 

qRFC queues in CRM server

Data exchange with R/3 BackendStart queues for loads from R/3 Backend: You should know that the loads from ERP/ECC to CRM are always initiated fromCRM. This initiation is done via an outbound queue and such queues are either R3AI* or R3AR* queues. These can bemonitored for errors at this point. 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). Loads for R/3 Backend: There are occasions when you want to send data from CRM to ECC/ERP system. This is not the loadinitiation 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 arecontinued to be called as Mobile clients(of course, you can replace the laptop with a Mobile phone and still continue to use the existingframework). Data exchange is always initiated from the Mobile client via the tool ConnTrans.

Loads for Mobile clients: Any data exchange from CRM to a laptop is done via an outbound queue. These are usuallyCRM_SITE* queues.Loads for Mobile clients: Any data exchange from a laptop to CRM is done via an inbound queue. These are usuallyCRM_SITE* queues.

CRM Server Internal queuesStart queues for loads to CDB: Even though CDB is only a logical separation within a CRM system for serving as aConsolidated 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 outboundqueue will have the destination NONE to represent the CRM system because the CRM is the data source here. The queues areusually CDBI*Initial loads to CDB: After successful initiation of the load from CRM to CDB, the actual data gets populated in inbound queueswhich are usually CRI*CDBI.

Other queues of CRM serverSend queues of CRM server applications -- Ever wondered how the CRM Middleware manages to send all the changes that ismade in CRM system exactly in order? The secret is the CSA* inbound queues. For any change that is happening at the CRMsystem, a CSA* inbound queue is written which acts as a reminder/log to be processed for data distribution. This is processedasynchronous 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.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 oneoutbound scheduler.

QIN Schedulers: ErrorsQIN Scheduler Errors: All Clients and Unregistered inbound queues -- Takes you directly to transaction SMQR, the inboundscheduler monitor. This will help you decide on whether to stop processing certain queues or whether to give greater attention tocertain queues or not.

QOUT Schedulers: ErrorsQOUT Schedulers Errors All clients -- Takes you directly to transaction SMQS, the outbound scheduler monitor. This will helpyou 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 serverThis takes you directly to transaction SMQ1 (outbound queue monitor) of the connected ERP/ECC system. This will let you see ifthere are any failures in the ERP/ECC system that are preventing the load (R3AI*) or the delta change (R3AD*) from flowing toCRM

v  Adapter Status Information

Initial load statusThis will directly take you to transaction R3AM1 which lets you see if there are any loads in WAITING, RUNNING, ABORT (or)DONE status.

Request statusThis will directly take you to transaction R3AR3 which lets you see if there are any request loads (which are nothing but loadswith user specified ranges) in WAITING, RUNNING, ABORT (or) DONE status.

Inactive objectsThis will give you the number of inactive parent objects with or without the child objects being active.

Parameters in R/3 BackendsThis will list down all the connected ERP systems.It will let you login to the ERP systems directly (provided the SM59 user is a dialog user).It will take you to ERP SM30 for CRMRFCPAR table which has the settings to control the flow from ERP to CRM in ERP.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 DaemonThis will take you to transaction SMOHQUEUE which lets you control the queue daemon for the processing of the R&R entriesfor the mobile clients (laptops – CRM_SITE* queues).

Status of R & R queuesEach R & R queue’s status is reflected here. If you see any failure, each of the entries will take you to SMOHQUEUE from whereyou can see detailed error information and take corrective action.

v  BDoc messages in the flow

Messages in error statusThis will take you to transaction SMW01 showing the BDocs in Error status (RED E*).

Messages waiting for response from backend systemsThis will take you to transaction SMW01 showing the BDocs in Intermediate state waiting for a response from ERP (YELLOWI02).

This completes the monitoring of We now move on to other with which we can administer the systemsRuntime information. System settingsconnected 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 andadminister, physical or logical systems for each of those types. Every entry will take you to transaction from where you canSMOEACadminister 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 thesystem and look for ways to improve it – will let you collect such information with which you can take decisions onMonitoring tools/Statisticsimproving performance of CRM Middleware.

v  BDoc type/BDoc service Workload statistics

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

v  Mobile client communication statistics

This will take you to transaction to monitor the communication between CRM and Mobile clients (Laptops) by statisticsSMWMCOMMcollected at the Communication station. This will let you view the statistics for a given time period, a given Mobile client, data sent orreceived 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 Middleware’s collection of alerts and monitors under the system wide monitoringCCMS setup (transaction ). This will also take you to the section of CRM Middleware alerts so that you can view them in detail.RZ20

v  Trace status

This element takes you to transaction with which you can enable traces at different stages of Middleware processing and canSMWTAD

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 ofqueue 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 backgroundjob to reorganize all Middleware related monitoring information and traces (including BDoc monitors). The job MW_REORG* is with reportSMO6_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 jobSAP_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 reportRSMWM_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 runtimeobjects 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 jobcorresponding 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 oftime. 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 theCRM Middleware administrator.