SAP CRM Middleware

Concept of SAP CRM Middleware - Business Documents 

First of all stands the generation information, which is often a nightmare when you have quiet a few changes with the bdoc.

find the above screen.
Transaction code SMWP - Sap middleware cockpit.

we will go to one by one.
just double click on the status of generation process will take to you transaction GENSTATUS. This is help to you monitor the current generation status in the system.

Generation Structures:- is exclusive this transaction alone where you can see the status of the bdoc segment generation, the successfully once and the segments with errors.

Generation of the runtime objects:- this also exclusive here which list down the status of each bdoc based on the runtime object of the bdoc. the runtime objects includes the function group and module relevant for the bdoc type ( generate module of inbound adapter, outbound adapter, rejection service, cdb etc).

Replication object for industry:- gives the generation status of runtime objects related to the replication of objects per specified industry.

the runtime objects include the lookup table, data collector and replication & realignment modules.

Publication per industry:- gives the generation status of runtime objects related to the publication and inter linkages for specific industry.

Business tasks:- now that you have all set and ready with the generation all green , you may want to check whether the system has begun to run properly.

Runtime information Provides all neccessary details.

Message Processing active:- takes you transaction MW_MODE which help you to check whether middleware processing or not.you can activate and deactivate the bdoc processing in the system.

Data exchanging with QRFC quoes:- 
this is the probably the item like most. you have compressive monitoring of all the queues relevant in the Crm system organization in 2 sections.



QRfc queus in the CRM server:-

DAta exchange with R/3 backend:- You should know that load from ERP/ECC
to crm are always initiated from crm. the initiated done via outbound queue.
ex:- (R3AI*, R3AR*).

Loads from R/3 backend:- they are occasion when want to send data from crm to ecc they queue are usually r3au*.

Data Exchange with mobile clients:

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 Queue:

        

Start queue 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 load of crm server

A

fter 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*.

qRFC queues in R/3 Backbends

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

Adapter Status information

Initial load status

Tcode is R3AM1 which lets you see if they are any load in Waiting , Running, abort or done status.

Request Status

Tcode is R3AR3 which lets you see if they are any request status

Parameters in R/3 Backbends

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”.

 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.

Bdoc messages in the flow

Messages in error status

This will take you to transaction SMW01 showing the Bdoc in Error status (RED E*).

Messages waiting for response from backend systems

This will take you to transaction SMW01 showing the Bdoc in Intermediate state waiting for a response from ERP (YELLOW I02).

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.

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).

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.

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.

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.

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.

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.

Collector for BDoc Message/Site statistics

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

Check Generation status of objects

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

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.

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.

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.