ERP Technology Blog

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
- 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.
- 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 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.
- Loads for Mobile clients: Any data exchange from CRM to a laptop is done via an outbound queue. These are usually CRM_SITE* queues.
- 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*
- 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
- 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.
- 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
- 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
- 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
- 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
- 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
- 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
- This will give you the number of inactive parent objects with or without the child objects being active.
Parameters in R/3 Backends
- This 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 Daemon
- 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
- Each R & R queue’s 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
- This will take you to transaction SMW01 showing the BDocs in Error status (RED E*).
Messages waiting for response from backend systems
- 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 Middleware’s 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.