8/10/2019 FAQ -Queueing

http://slidepdf.com/reader/full/faq-queueing 1/5

SAP Note 

Header Data

Symptom 

You require information on the queue names used and their respectivefunctions in the CRM server and R3 backend.

Other Terms 

Reason and Prerequisites 

Solution 

Helpful Tips on Using this Note:

The field names used in this note for tables CRMQNAMES and SMOFQFINDare as they appear in SM30. This is because these fields can only beedited using SM30 and not via SE16.

The information provided in this note is classified under the followingcategories:

1. How to Find What a Queue Name Means:(i) CRM Outbound Queues (ii) CRM Inbound Queues (iii) R3 Backend Outbound Queues(iv) R3 Backend Inbound Queues 

2. CRM Outbound Queue Types:(i) Outbound Queues from the Start of an Initial Load (ii) Outbound Queues from the Start of a Request (iii) Other Queues

3. Outbound Queues that Should No Longer Exist in CRM 4.0:(i) Mass Queue for Updates from CRM to R/3 (ii) Mass Queues from Validation 

4. CRM Inbound Queue Types (SMQ2):(i) Inbound Queues of an Initial Load from R/3 to CRM (ii) Inbound Queues of an Initial Load from CRM to CDB (iii) Inbound Queues of an Initial Load from CRM to R/3(iv) Inbound Queues from Delta Changes on the R3 Backend 

5. R3 Backend Outbound Queue Types (SMQ1):(i) Outbound Queues for all Loads Except Delta Load (ii) Request and DIMa Outbound Queues (with more Recent SPs and PIs) (iii) R3 Delta Load Outbound Queues(iv) Inbound Queues 

6. Parallelizing and Serializing Queues:

7. Related Notes:(i) Parallelization and Serialization (ii) Other Notes 

1. How to Find What a Queue Name Means:

(i) CRM Outbound Queues

Prefix: If this is R3A, an R3 system is involved; CDB indicates a load from CRM to CDB; CR denotes aload from CRM to R3, before the data is sent (except in the case of CRM_SITE* queues).

Next Character: 'I' stands for 'initial load', 'R' for request and 'U' for upload.

The next part is the adapter object name (initial load or request), or part of the object name asdefined in table SMOFQFIND (upload).

765236 - FAQ: Queueing in CRM and R/3 

Version  3 Validity: 07.09.2004 - active Language  English (Master)

Released On  08.09.2004 16:40:48

Release Status  Released for Customer

Component  CRM-MW Middleware

BC-MID-RFC RFCPriority  Recommendations / Additional Info

Category  FAQ

Other Components

8/10/2019 FAQ -Queueing

http://slidepdf.com/reader/full/faq-queueing 2/5

 The destination can be checked to determine whether the queue is usedfor the start of an initial load from R3 to CRM or vice versa. A load from R3 to CRM will have thedestination of the R3 system; a load from CRM to R3 the destination of the CRM server.

Mass queue names are taken from SMOFQFIND. In releases before 4.0, the prefix CSA indicates avalidation queue. (From 4.0 onwards, this prefix should only appear in inbound queue entries.)

(ii) CRM Inbound Queues

Prefix: If this is R3A, an R/3 system is involved; CRI indicates aload from CRM to CDB or from CRM to R/3, after the data wasextracted.

Postfix: This indicates whether the queue corresponds to a load fromCRM to CDB, in which case the postfix is CDB, or from CRM to R/3, inwhich case the postfix R3A is used.

If the prefix is R3A, check the next character of the prefix. If it isCRI, check the last letter of the postfix. In both cases, 'I' stands for initial Load, 'R' for Request and 'D' (R3A prefix only) stands forDelta.

For an Initial or Request Load, the next part is the object name. In thecase of loads going from CRM to R3, it represents the Initial Load nameas defined in SMOFQFIND. For Delta Loads, the next part is a part of theobject name, as defined in CRMQNAMES.

For Delta Loads there is a keypart that is determined via tableCRMQNAMES. Please refer to Section 4 (iv) for further details.

(iii) R3 Backend Outbound Queues

The type of load is indicated by the fourth character of the prefix.'I' denotes an Initial Load, 'R' stands for Request, 'D' for deltaload, 'H' for Header Compare and 'T' for Detail Compare.

The next part is the object name (in the case of an Initial Load or- for older Support Package levels - Request or DIMA Load), part of theobject name (in the case of Delta Loads) as defined in CRMQNAMES, orthe name of the Request or instance (for Requests or DIMa loads usingmore recent Support Package levels).

For Delta Loads there is a keypart that is determined via tableCRMQNAMES. Please refer to section 5 (iii) for further details.

PLEASE NOTE: When an Initial Load or Request is started on the CRMServer, then a corresponding R3AD* outbound queue with a STOP entry iscreated on the R3 Backend. This entry contains no data, but is used

to ensure that no Delta Load can be started for the same object - orfrom other objects containing corresponding data - until the InitialLoad or Request has finished processing. This is necesasry to ensurethat data consistency is maintained. The entry is removed automaticallyonce the Initial Load or Request has finished. A Synchronization Load(Compare) works in the same way in this respect.

(iv) R3 Backend Inbound Queues

Inbound queues are not normally used on the Backend system. However, itmay be useful to have such queues for debugging purposes. This isdescribed in section 5(iv).

2. CRM Outbound Queue Types(i) Outbound Queues from the Start of an Initial Load:

These have the following structure:

<prefix>I_<objectname>

<prefix> is either R3A (if an R3 system is involved) or elsethe Consumer of the target site (eg CDB, EXT), and <objectname> isthe name of the adapter object.

Examples: R3AI_SALESDOCUMENT, CDBI_DNL_CUST_UNITS, EXTI_BUPA_MAIN

(ii) Outbound Queues from the Start of a Request

These have the following structure:

<prefix>R_<objectname>

Once more, <prefix> is either R3A (if an R3 system is involved) or else the Consumer of the targetsite (eg CDB, EXT).

Examples: R3AR_SALESDOCUMENT, CDBR_DNL_CUST_UNITS, EXTR_BUPA_MAIN

(iii) Other Queues

8/10/2019 FAQ -Queueing

http://slidepdf.com/reader/full/faq-queueing 3/5

 

Outbound Queues from Delta Changes in CRM:

R3AU_<objectpart><keypart>

where <objectpart> is defined in table SMOFQFIND, and <keypart> is taken from the data fieldspecified in field "segment field" of table SMOFQFIND.

Examples: R3AU_BUPA0000004711

Outbound Queues from an Initial Load from CRM to R/3, before Sending the Data to R3:

CRI_<initial load queue>R3AU

where <initial load is defined in SMOFQFIND.

Outbound Queues from DIMa in CRM:

<prefix><type>_<name>

where <prefix> can take the value R3A or CDB, <type> can take the value'H' for 'Header' or 'T' for 'Detail Compare', and name refers to theadapter object name or (with newer Support Packages) the instance name.

Examples: R3AH_DIMANAME

3. Outbound Queues that Should No Longer Exist in CRM 4.0

(i) Mass Queue for Updates from CRM to R/3:Name is taken from SMOFQFIND

Example: CSA_MASS_BUPA

(ii) Mass Queues from Validation:

Name is taken from SMOFQFIND

Example: CSA_MASS_BUPA

(iii) Outbound Queues from Validation (in 4.0 the inbound queue is used):

* Mass Queue for Updates from CRM to R/3. Name is taken from SMOFQFIND

Example: CSA_MASS_BUPA

* Mass Queues from Validation:

Example: CSA_MASS_BUPA (also from SMOFQFIND)

* Outbound Queues from Validation:

<prefix><objectpart><keypart>

where the <prefix> and <objectpart> are taken from SMOFQFIND and<keypart> is taken from the data field specified in field "segmentfield" of table SMOFQFIND.

Examples: CSA_BUPA0000004711

4. CRM Inbound Queue Types (SMQ2)

(i) Inbound Queues of an Initial Load from R/3 to CRM:

R3AI_<objectname>

Example: R3AI_SALESDOCUMENT 

(ii) Inbound Queues of an Initial Load from CRM to CDB:

CRI_<objectname>_CDBI

Example: CRI_DNL_CUST_UNITS_CDBI

(iii) Inbound Queues of an Initial Load from CRM to R/3:

CRI_<Initial Load Queue>_R3AI

where <Initial Load Queue> is taken from SMOFQFIND.

Example: CRI_CSA_BUPA_INIT_R3AI

8/10/2019 FAQ -Queueing

http://slidepdf.com/reader/full/faq-queueing 4/5

PLEASE NOTE:In cases (i) and (ii) above, the same convention is used for Request and DIMa queuesexcept that 'R' (request), 'H' (DIMa - Header) and 'T' (DIMa - Detailed Compare) are used instead oftheprefix (case i) or postfix (case ii) 'I'. In more recent Support Packages, the object name isreplaced by the name of the request/DIMa instance.

(iv) Inbound Queues from Delta Changes on the R3 BackendR3AD_<objectpart><keypart>

where <objectpart> is defined by the field 'QRFC object part' in table CRMQNAMES, and <keypart> istaken from the data field specified in field "segment field" of table CRMQNAMES.

Please note that CRMQNAMES has a field sort order. If with the first entry no keypart can bedetermined, the next is tried and so on. This way, if an error occurs and no keypart can bedetermined, it is possible to create an error queue. For example, where normally the queueR3AD_CUSTOME0000004711 would be created for a delta load, if an error is detected the queue would benamed R3AD_CUS_ERR0000004711.

5. R3 Backend Outbound Queue Types (SMQ1):

(i) Outbound Queues for all Loads Except Delta Load:

<prefix><type of load>_<objectname>

Where the <prefix> is R3A (for consumer CRM) or else the consumer value (for other values - eg EBP);

<type of load> is either 'I' for Initial Load, 'R' for request, 'H'for Header Compare or 'T' for Detail Compare.

Examples: R3AI_SALESDOCUMENT, EBPR_MATERIAL

PLEASE NOTE: Request and DIMa queues are created with a differentnaming convention in later Support Package and Plug-in Levels.From CRM release 3.0, SP 16; release 3.1, SP6; 4.0, SP 2 and higher, in conjunction with PI 2003.1,patch 3; Basis PI 2003.1 SP2, and higher.

(ii) Request and DIMa Outbound Queues (with more Recent SPs and PIs):

<prefix><type of load>_<Instance Name>

where the <prefix> is R3A (for consumer CRM) or else the consumer value(for other values - eg EBP);

<type of load> is either 'R' for request, 'H' for Header Compare or 'T'for Detail Compare; 

and <Instance Name> is the name of the Request or DIMa instance.

(iii) R3 Delta Load Outbound Queues:

<prefix><objectpart><keypart>

Where the <prefix> is R3A (for consumer CRM) or else the consumer value (for other values - eg EBP);

<objectpart> is defined by field 'QRFC object part' in CRMQNAMES,

and <keypart> is taken from the data field specified in field "segment field" of table CRMQNAMES.

(iv) Inbound Queues

Inbound Queues in R/3 do not normally exist. Nevertheless, for the

purposes of error finding and debugging it may be useful to use aninbound queue. This can be done by entering the phrase 'DEBUG_LOAD'structure I_BAPICRMDH1, field INFO in CRM before calling the R/3.This can only done from within debug mode!

You will then have an Inbound Queue in R/3 with the nameDEBUG_<load type>L_<objectname>.

Note: This functionality is available with Plug-In 2002.2, SP4 and PI-BASIS 2003.1. With earlier PIreleases it can be obtained byimplementing note 608843.

6. Parallelizing and Serializing Queues

Queues can be parallelized and, in the case of a delta load, serializedusing parameters in tables SMOFPARSFA (CRM) and CRMPAROLTP (R3 backend).

To parallelize queue processing during the Initial Load, parameter CRM_MAX_QUEUE_NUMBER_INITIAL mustbe maintained in CRMPAROLTP on theR3 Backend.

For parallelizing Request Loads, refer to note 426159.

Parallel instances for the same object can be used during DIMa loads as long as the prerequisitesdescribed in note 628949 are satisfied.

For Delta Load, parameter CRM_MAX_QUEUE_NUMBER_DELTA in table CRMPAROLTP of the R3 Backend can be

8/10/2019 FAQ -Queueing

http://slidepdf.com/reader/full/faq-queueing 5/5

 

used to serialize the corresponding outbound queues in the R3. Parameter CRM_IN_EQUAL_OUT_QUEUE mustalso be set in order to serialize the inbound queues on the CRM. Please refer to note 624436 foradditional information.

7. Related Notes

(i) Parallelization and Serialization:

350176 Performance Improvements for Initial Load426159 Parallelize Request525651 Parallelize Initial Load from CRM to R/3624436 Serialize Delta Queues

(ii) Other Notes:

539305 No mass queues356228 QRFC uses all work processes763680 CSA* qRFC queues occupy all work processes on CRM483301 and 646978 Remove leading Zeros in Queuename531217 Data Integrity Manager (DIMa)621297 and 628943 DIMa and Request Name in Queuename619885 Initial Load changes User in SMQR608843 Use SMQ2 in R/3 for debugging

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

SAP Notes 

This document is referenced by:

SAP Notes (13) 

1019446 Wrong queue names formed in Unicode ERP server  

763680 CSA* qRFC queues occupy all work processes on CRM 

624436 Serialization of the CRM inbound queue 

621297 Timeout of a DIMa instance/SYSFAIL in the inbound queue 

619885 Request/initial load changes user for R3A* queue 

608843 Debugging inbound queues in the R/3 Backend system 

539305 Performance problems with CSA_MASS queues 

531217 Data Integrity Manager (DIMa) 

525651 Parallel initial load from CRM Server into R/3 Back End 

483301 Suppressing leading zeros in queue name 

426159  Adapter: Running requests in parallel 

356228 qRFC occupies all work processes on the R/3 backend or the C 

350176 CRM/EBP: Performance improvement during exchange of data 

539305 Performance problems with CSA_MASS queues 

531217 Data Integrity Manager (DIMa) 

624436 Serialization of the CRM inbound queue 

621297 Timeout of a DIMa instance/SYSFAIL in the inbound queue 

619885 Request/initial load changes user for R3A* queue 

608843 Debugging inbound queues in the R/3 Backend system 

525651 Parallel initial load from CRM Server into R/3 Back End 

1019446 Wrong queue names formed in Unicode ERP server  

763680 CSA* qRFC queues occupy all work processes on CRM 

426159  Adapter: Running requests in parallel 

356228 qRFC occupies all work processes on the R/3 backend or the C 

350176 CRM/EBP: Performance improvement during exchange of data 

483301 Suppressing leading zeros in queue name