CRM MIDDLEWARE GUIDE

ANALYZING BDOCS IN CRM SYSTEM

Step 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 respectively
Name Adaptor Object
CUSTOMER CUSTOMER_MAIN
CUSTOMER RELATIONSHIP CUSTOMER_REL
PRODUCT MATERIAL

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 monitoring
CRM Server Central Monitoring
Activities / Functions
Monitoring Type Monitoring Frequency
Periods and Events
Middleware Portal
Monitoring the CRM Middleware
Portal with transaction SMWP
can be subdivided into the
following areas:
Generation Information
containing:
BDocs Types: Generation of
structures
BDocs Types: Generation of
other runtime objects
Replication objects
Publications: Missing Indexes,
Status of Delta/Initial
Generation, Flow Definitions
Runtime Information
containing:
Adapter Status Information
Replication and Realignment
Queues
BDoc Messages in the Flow
SMWP
Several times a day
depending on the
business process
After implementing
transports
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 quickly
processed, queues to destination
NONE 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
SMQ1 Several times a day
depending on the
business process
Daily
actions must be taken in these
cases, any deletion of queues
causes 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.
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 ID
SMW01 / 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 error
message, if the
databases are not
consistent and a
request from the R/3
back-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 MONITORING
Tr. SMQ2( Inbount queue monitoring ), SMQ1 (Outbound queue Monitoring)
The naming convention of the Queue is as follows:
Queue Name Systems Description
R3AI<Object name>
R/3 CRM
Initial. BAPIs destined for the
R/3 back-end
R3AD<Object name>
R/3 CRM
Delta
R3AR_<Object name>
R/3 CRM
Request
R3AU<Object name>
R/3 CRM
Upload
CRM_SITE<Queue number>
CRM-> Mobile Client
Synchronization BDoc types
from the CRM Server going to
the mobile client
CSA_<Object name>
CSA_MASS_<Object name>
CRM-> CRM (simple
replication)
Outbound for simple
replication of BDocs to
receivers
BW.. <Object name>
CRM-> BW Queues to BW systems

The transmission of delta information is performed from the R/3 back-end system or other
systems to the CRM Server. When the delta information arrives at the CRM Server, the data is
forwarded 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 resources
and 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 to
data inconsistencies!
The qRFC Inbound Queue Monitor, SMQ2, is not a critical monitor on the R/3 back-end system
because there is normally no data to be displayed. Instead, monitor the outbound queue (SMQ1
or R3AM1) on the CRM Server.
Transaction: SMQ2
1) Select the entry you want to view.

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

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.