CIF Monitoring Guideline V3

[email protected]

CIF Monitoring Guideline V3.doc

of 48 Created on 7/27/2011 3:09:00 PM

Table of Content Table of Content ................................... .........................................................................1

1. Useful transactions ................................ ................................................................3

1.1. OLTP-R/3 .....................................................................................................................................3

1.2. APO-R/3 .......................................................................................................................................3

1. Inbound & Outbound Queues.......................... ......................................................4

1.1. Outbound Scheduler SMQS – Configuration ...............................................................................4

1.2. Outbound Scheduler SMQS - Monitoring.....................................................................................5

1.3. Inbound Scheduler - Configuration .............................................................................................6

1.4. Inbound Scheduler SMQR – Monitoring ......................................................................................7

2. qRFC monitor: Motivation........................... ...........................................................8

2.1. Queue Monitor – APO and R/3 backend......................................................................................9

2.2. Local Outbound Queue Overview ..............................................................................................10

2.3. Display Inbound Queues with Problems ....................................................................................11

2.4. Logic of queue names for CIF....................................................................................................12

3. Application logs: Motivation....................... .........................................................16

3.1. Analyze Application Log.............................................................................................................17

3.2. Maintain Logging Level ..............................................................................................................18

3.3. Search in Application Log...........................................................................................................19

4. Protocol of deleted CIF Entries .................... .......................................................20

5. SCM Queue Manager.................................. ..........................................................21

5.1. SCM Queue Manager - Features...............................................................................................22

5.2. CIF Cockpit - Settings ................................................................................................................23

5.3. CIF cockpit – user profile............................................................................................................24

6. Postprocessing..................................... ................................................................30

6.1. CIF Error Handling Default .........................................................................................................30

6.2. CIF Error Handling with Postprocessing ....................................................................................31

6.3. Postprocessing Facts .................................................................................................................32

6.4. Postprocessing Limitations.........................................................................................................33

6.5. Handling of Postprocessing Records .........................................................................................34

6.6. Usage types for Postprocessing ................................................................................................35

6.7. Alerting for Postprocessing Records..........................................................................................36

6.8. Prerequisites of Enhanced Queue Display ................................................................................37

7. CIF Performance.................................... ...............................................................38

7.1. Check RFC parameters & available resources..........................................................................38

7.2. Resources for tRFC (transaction SMQR / SMQS).....................................................................39

7.3. RFC Parameter settings.............................................................................................................40

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.4. Check Queue status...................................................................................................................44

7.5. SMQ2 : Large number of entries / LUWs...................................................................................45

7.6. Status SYSFAIL in CIF queue....................................................................................................46

7.7. Relationship LUW / CIF queue...................................................................................................47

7.8. Stuck queues..............................................................................................................................48

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

1. Useful transactions

1.1. OLTP-R/3 Transaction Description CFM1 Create/Generate Integration Model

CFM2 Activate or Deactivate Integration Model

CFM3 Activate Integration model (Possible in Background)

CFM4 Display Integration Model

CFM5 Search for Filter Objects in Integration Model

CFM6 Change Integration Model

CFM7 Delete Integration Model

CFS0 Display one or all Outbound queues

CFS1 Display one or all Inbound queues

CFG1 Application log

1.2. APO-R/3 Transaction Description SMQ1 qRFC-Monitor Outbound queues

SMQ2 qRFC-Monitor Inbound queues

/SAPAPO/C3 Application log

/SAPAPO/CCR CIF-Delta Report

/SAPAPO/CQ SCM Queue Manager

/SAPAPO/CC CIF Cockpit

/SAPAPO/CPP1 CIF Postprocessing

SMQS Outbound scheduler

SMQR Inbound scheduler

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

1. Inbound & Outbound Queues

1.1. Outbound Scheduler SMQS – Configuration Use transaction SMQS to register a destination

• The QOUT Scheduler was implemented to improve performance when sending qRFC and tRFC messages. The processing of all queues is scheduled by the QOUT Scheduler. With help of the QOUT Scheduler it is possible to define how many work processes are used for sending the LUWs to a specific destination. The number of simultaneously sent tRFCs and qRFCs is limited and consequently the QOUT scheduler provides a kind of control over the resources on the receiving sys-tem.

• You can enter the following parameters:

o Destination – Enter the name of your destination. o MAXCONN – Maximum number of connections o MAXTIME – Maximum scheduler processing time for a destination in sec-

onds (default is 60 seconds) You can use this setting to allocate more proc-essing time to individual queues and restrict the processing time of others.

o NO_TRFC – This prevents tRFC LUWs from being processed by the Out-bound Scheduler. This means that the tRFCs for this destination are then executed when the Commit Work is executed.

• The parameters set for the different destinations do not depend on the number of

queue entries.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

1.2. Outbound Scheduler SMQS - Monitoring

• Status: Normally, status is Inactive. Manual activation can be forced. • Last update: Check Last update to verify proper function of QOUT scheduler.

• Name of AS group: Use transaction RZ12 to define a group of application servers (AS).

• As soon as a LUW with a registered destination has been created, the QOUT Scheduler in

this client is activated by the qRFC Manager, if it was not already active. The QOUT Scheduler can also be activated manually for the current client.

• To check if the outbound scheduler is running properly, see the column Last update.

• You can use transaction RZ12 to define a group of application servers (AS). You can then

use transaction SMQS to assign this server group to the QOUT Scheduler. The scheduler will then only use the application servers assigned in the server group to process the LUWs.

• To exclude a destination from being handled through the outbound scheduler, register the

destination in SMQS and then select the destination and choose Edit >> Exclude. The des-tination then appears as type N, like destination PRD in the example above.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

1.3. Inbound Scheduler - Configuration Use transaction SMQR to register a queue name

• The QIN scheduler is configured on the basis of queue names. So if new queue names are used, they must be registered, otherwise their entries will not be processed. The inbound scheduler does not process the LUWs but triggers their processing in asynchronously started work processes.

• Parameters for the inbound scheduler are:

o EXEMODE: D for dialog, B for background, depending on the type of the work proc-ess that should be used for processing queue entries.

o MAXTIME: Time spent by the inbound scheduler for working on the queue. If this time limit is exceeded,

o LUWs of other registered queues are distributed to work processes by the inbound scheduler.

o USERDEST: Logical destination (defined in transaction SM59) for processing LUWs in this

o queue. This enables you to change the client, user, and language for all qRFC LUWs.

o NRETRY: Number of retries o TDELAY: Delay between retries (CPICERR)

• The QIN scheduler limits the number of processes used for processing function modules from inbound queues. The QIN scheduler can of course only be used if inbound queues are used.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

1.4. Inbound Scheduler SMQR – Monitoring

• Status: Normally, status is Inactive. Manual activation can be forced. • Last update: Status is updated every 2 minutes. • Name of AS group: Use transaction RZ12 to define a group of application servers

(AS).

• If a qRFC LUW has been written in a registered queue, and the QIN Scheduler is not al-ready running, the QIN Scheduler is activated by the qRFC Manager. There is one QIN Scheduler for each client (inbound queues are client-specific).

• If the scheduler is active, the status is updated every two minutes. Every change of status

automatically causes an update, to show that the scheduler is active.

• The QIN scheduler processes all the registered queues using all the application servers of the local SAP system (AS group DEFAULT). Transaction RZ12 can be used to define a RFC server group with application servers (instances) to be used by the IB scheduler.

• This group can be assigned in transaction SMQR by choosing Edit / Change AS Group.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

2. qRFC monitor: Motivation

• The communication between R/3 and SCM is based on the asynchronous transfer technol-ogy of the queued Remote Function Call (qRFC). A Remote Function Call (RFC) enables calling a function module on a remote server. This technology is used in the integration be-tween SCM and R/3 both for the initial data supply and incremental data transfer (from R/3 to SCM) as well as for the publication of planning results (from SCM to R/3).

• The data is first buffered by the sending system and then transferred to the target system.

The major advantage is that the application that triggers the data transfer does not have to wait until the update has been completed in the target system. However, this means that re-turn parameters cannot be passed on, and potential error messages cannot be returned to the application directly.

• Two types of errors are distinguished for the processing of qRFC modules:

o Communication errors : This includes network problems, as non-existing RFC destinations and so on. Since the data transfer is repeated after certain periods, most of these communication er-rors should disappear once the network connection is available again.

o Application errors : This includes: program errors, failed data update in the target system, locking of ob-jects, missing master data for specific transaction data. Application errors cannot be solved by the system and must be dealt with by the system administrator.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

2.1. Queue Monitor – APO and R/3 backend

• SMQ1 - qRFC Monitor for the outbound queue. Use this transaction to monitor the status of the LUWs in the outbound queue and restart any hanging queues manually.

• SMQ2 - qRFC Monitor for the inbound queue. Use this transaction to monitor the status of

the LUWs in the outbound queue. • Both in OLTP and APO, you can start the qRFC monitor for inbound queues with transac-

tion SMQ2 (report RSTRFCM3) and for outbound queues with transaction SMQ1 (report RSTRFCM1). Queue name CF* is related to the CIF.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

2.2. Local Outbound Queue Overview Transaction SMQ1 handles like SMQ2

• Both in OLTP and APO, you can start the qRFC monitor for outbound queues with transac-tion SMQ1 (report RSTRFCM1). Alternatively, in the OLTP system, you can call transaction CFQ1, but this only shows queues within the current client.

• The qRFC monitor presents an overview of queues that are not empty, the number of

LUWs in each one, and the target system. For more detailed information (status, date/time of the first and last LUW written into the queue, and possibly the name of a queue that must be processed first), choose a queue and select Display selection. In the next screen, dou-ble-clicking the queue displays the individual calls. Queue names are generated by the ap-plication programs.

• The qRFC monitor only displays the waiting calls. Because of message serialization, if an

error occurs, the highest entry in the queue blocks all other entries.

• For any qRFC error, a detailed error log is always saved in the application log of the sys-tem. To find this entry in the application log:

o For the call with the qRFC error, copy the value in field TID (transaction ID). o In the selection screen of transaction /SAPAPO/C3 (APO application log) or CFG1

(OLTP application log), enter this value in the field External ID, select a time period, and execute. The next screen displays all messages related to the erroneous qRFC call.

• An error can appear in the APO application log without appearing in the qRFC monitor. • In OLTP, you can also monitor CIF channels with transaction CFP2 (report RCPQUEUE):

choose Logistics / Central functions / Supply Chain Planning Interface / Core Interface Ad-vanced Planner and Optimizer / Integration Model / Change Transfer / Transaction Data.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

2.3. Display Inbound Queues with Problems

• To display queue problems and dependencies between waiting queues in transaction SMQ1/SMQ2 click once on the bell button or use F8 key. Another click on the bell button will show the running queues.

• Additionally to the output screen you can see:

o Status: The queue status of the queues will be shown. For the possible status val-ues please read the SAP note 378903.

o 1Date/ 1.Time : Shows the date/time when the first LUW was written into the queue. o NxtDate/NxtTim : Tells when the last LUW was written into the queue. o Wait for queue : Contains the queue name that must be processed before the

queue could be started. The queue name of the “high priority” queue can be a single or generic queue name.

• If an error (SYSFAIL) is shown in the status field you can get more detailed information

when you double click the status.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

2.4. Logic of queue names for CIF Real-time transfer in general:

o CF<CIF object ID><serialization character string> Direction R/3 � APO: CFSLS<n>

o First 2 letters CF for CIF o Next letters represent the object type o Followed by the order number, e.g. CFSLS0000010003 for a sales order

Direction APO � R/3: CFIPXXXXXXXXXXXXXXXXXXXX

o First two digits letters CF for CIF o Next 2 letters for object type, e.g. IP = In-house Production o Following digits: first 20 pertinent characters of the order GUID

Initial transfer:

o CFLD<logical source system>_<counter><subcounter> Initial transfer aborted:

o CF_LOAD_ABORT<counter><subcounter> QRFC queue names for the CIF real-time transfer are always set up according to the following rules:

o CF<CIF object ID><serialization character string> For the initial data upload, the qRFC queue name is set up according to the following rule:

CF_LOAD_ABORT<counter><subcounter> The <counter> counter changes from initial data transfer to initial data transfer. You only have the second <subcounter> counter if there are parallel settings in the SCM APO in-bound. It then changes from block to block of an initial data transfer.

The queue names differ for the direction R/3 => APO and APO => R/3. See following pages & SAP Note 786446 for a list of queue names and their meaning.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Queue names R/3 => SCM (for a complete list see Note 786446) Queue name Description CFSTK* Stock CFPO* Purchase orders and purchase requisition CFPLO* Planned orders/Production orders CFSLS* Sales orders CFRSV* Manual reservations CFCNF* Confirmations CFPIR* Planned independent requirements (created i n R/3) CFMAT* Reduction of PIRs CFFCC* Reduction of PIRs (if separate Imod is used ) CFPCM* Production campaigns CFCLA* Master data for classes CFCHR* Master data for characteristics CFCUVT* Planning tables CFSHP* Transports (TP/VS scenario) CFTL* Transport locks (TP/VS scenario) CFTG* Deletion of temporary quantity assigments GA TP (in one LUW with

CFSLS*) FC* Fulfillment coordination (only if qRFC consump tion is used) CFCB* CBase Configuration CFCR* CBase Configuration, special case CFCD** CDP Configuration CFCL* Classification

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Queue names SCM => R/3 (for a complete list see Note 786446) Queue name Description CFEP* External Procurement APO - R/3 CFIP* In-house Production APO - R/3 CFFO* Planned independent Requirements CFCO* Sales Orders CFPC* Production Campaign CFSH* Transport CFDL* Delivery CFRV* Reservations CFPF* Planning file entry (IS Automotive) CFCF* Confirmation (IS Automotive) CFCD* Confirmation of deletions (IS Automotive) CFRP* Reporting points (IS Automotive)

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Common Queue Status – Note 378903

READY Queue is ready for transmission. If a queue was locked manually and then unlocked with-out being activated, the queue stays ready until it is activated explicitly.

RUNNING The first LUW of the queue is currently being processed. If a queue in this status hangs for more than 30 minutes, activate it again.

WAITING The first LUW of this queue has dependencies on other queues, and at least one of these queues contains other LUWs with higher priority.

STOP A lock was set explicitly (via SMQ2 or a program). This status never appears without “exter-nal” interference.

SYSFAIL A serious error occurred in the target system while the first LUW of the queue was exe-cuted. The execution was interrupted. No batch job is scheduled for an automatic retry, and the queue is stopped.

CPICERR During transmission or processing of the first LUW in the target system, a network or communication error occurred. Depending on the registration of this queue in SMQR, a batch job may be scheduled for repetition.

READY Not yet executed (only temporary) RUNNING Execution active

WAITING Waiting until the LUWs with a higher priority are executed SYSLOAD No free DIALOG work processes in the sending system RETRY Temporary problem during execution (locking issue), background job sched-uled

STOP Execution explicitly stopped NOSENDS Outbound: LUW is not sent (only used for debugging) NOEXEC Inbound : LUW is not processed (only used for debugging)

SYSFAIL A serious error has occurred in the target system (APO) while the LUW was executed CPICERR An error occurred during establishing the connection

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

3. Application logs: Motivation

• The Application Log is a tool for collecting messages, exceptions and errors in a log and displaying them. An Application Log log comprises a log header and a set of messages. The log header contains general data (type, created by/on, etc.). All this information is stored in certain tables on the database (BALHDR, BALM).

• You can use the application log to trace when (time), and what (data objects and integration

model) was transferred by whom (user). In addition, the application log provides a detailed error message if an application error occurred. As a prerequisite, logging must have been switched on. If errors occurred during transfers, detailed error messages are stored in the application log of the target system.

• Application log is used by various applications and consists of several tables.

o BALHDR, BALHDRP Log header with a unique log number: Information that clearly indicates who trig-gered which event using which transaction/program.

o BALDAT Log messages and status: Stored in compressed form (as of R/3 Release 4.6C).

• When transferring data via CIF, logs are recorded with object CIF (Core interface applica-

tion log object). All logs are given an expiry date by the application itself (for CIF it is 1 week in the future).

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

3.1. Analyze Application Log

• The application log can be called up in SAP APO (/SAPAPO/C3) or in SAP R/3 (transaction CFG1). The application log provides a detailed error message for queues containing errors. If errors occur during data transfer they are logged even the setting is ‘No logging’.

• Display entries in the Application log to get detailed information about:

o Date and time of transmission o Data object and integration model o Source system, user, and SAP transaction o Application success and error messages

• In general logs are written in the source and the destination system, if the logging is acti-

vated in the user settings. The name of the sending RFC user is recorded in the application log of the receiving system. The current user is recorded in the application log of the send-ing system. Logs in the receiving system are more informative (exception: initial supply of PPMs).

• Usually, it is sufficient to evaluate the application log on the side where the error occurred.

You can select different sub objects for the CIF object in the R/3 and APO application log. These include, for example, EP External procurement (inbound), IP In-house production (inbound), or INITIAL Initial supply and LOCATION Location: customer, plant, vendor (For performance reasons, the entries for an initial supply and an incremental data transfer are grouped under the sub object INITIAL). For more sub objects, choose F4 for the Sub object field on the initial screen of the application log.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

3.2. Maintain Logging Level

• The logging level can be maintained user-specific using the following transactions: o CFC2 in R/3 o /SAPAPO/C4 in APO

• There are different logging levels:

o Normal Only the number of data records transferred is logged.

o Detailed The number and content of the data records transferred is logged.

o No logging Only errors are recorded.

• The application log provides a detailed error message for queues containing errors. If errors

occur during data transfer they are logged even the setting is ‘No logging’. • Detailed logging can cause large database tables and a loss in performance in productive

operation. For that reason, it should only be activated when the data is required. For pro-duction operation, SAP recommends ‘No logging’.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

3.3. Search in Application Log

• APO: Report /SAPAPO/CIF_APPL_LOG_SEARCH _2

• R/3: Report CIF_APPL_LOG_SEARCH_2

• For error analysis in the APO-R/3 integration environment, it is often necessary to search for character strings in the CIF application logs. Precondition: Detailed Logging.

• Using the mentioned reports, it is possible to search for character strings in the application

log. This provides improved error analysis if errors occur between APO and R/3.

• To be consistent with good performance, it is recommended to restrict date and time as closely as possible.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

4. Protocol of deleted CIF Entries Transaction SM21 – Tcode SMQ1 and SMQ2

Deletion of CIF Queues Do NOT simply delete queues entries : this may cause inconsistencies

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

5. SCM Queue Manager Transaction /SAPAPO/CQ:

• CIF queue monitoring for APO and R/3 backend system s • Appropriate for application monitoring (queues are classified according object

type

• The SCM Queue Manager is called up in SAP APO (transaction /SAPAPO/CQ ). It enables you to check from SAP APO the local system as well as all connected systems. For this, the output queues are sorted according to their assignment to a publishing type (for exam-ple, in-house production, planned independent requirement, planning file entry, and so on). This facilitates the assignment of the listed output queue.

• As with the qRFC Monitor, the SCM Queue Manager monitors application errors in its own

system AND in all connected systems. The SCM Queue Manager is significantly more user friendly than the qRFC Monitor, due to the way in which its results are,displayed.

• From the SCM Queue Manager you can also call up the most important functions of the

qRFC Monitor (activate/stop/delete queue) or the qRFC Monitor of a target system. For queues with errors you can navigate to the application log of the receiving system directly from the SCM Queue Manager.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

5.1. SCM Queue Manager - Features

• The results screen consists of a navigation window with a tree structure (left window) and a main window. In the tree structure, the systems that have been checked are represented as root nodes and the individual object types as branches.

• Expand the root nodes by clicking on the node. The object types of the selected system are

displayed. The main window will display all queues for a particular system by double-clicking on the system name.

• For each queue, the following information is shown:

o Queue name: Name of the relevant queue o Destination: Destination system of the queue. By double-clicking on the destination

column brings you to the transaction SM59. Here, you can edit the settings for the connection to the relevant system.

o Error text: Description of the queue status o User: Person responsible for the queue o Function module: Function module concerned o Date/time: Time of the queue error o Waiting: Queue is dependent on other queues

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

5.2. CIF Cockpit - Settings

• As of SCM 4.1, the new transaction Core Interface Cockpit is available (transaction code . This transaction refers to as a central entry point for checking all settings and current system states relevant to CIF. Examples of current system states shown in the cockpit are the number of existing queue entries including possibly arisen proc-essing errors and application logs or results of the last delta report run.

• Examples of relevant CIF settings shown in the cockpit are the number and extend

of the integration models, the strategy concerning change transfer of master data and the block sizes used for initial data transfer.

• The CIF cockpit provides an excellent overview about the settings and additionally

offers the possibility to perform a detailed analysis and correction by branching to single transactions. Many of the necessary data are determined thereby from the connected R/3 systems. Detail transactions, which run off in the R/3, are started di-rectly from the CIF cockpit if the user has the corresponding authorization. For documentation please refer to the SCM 4.1 documentation.

• The CIF queue manager is not actively supported since SCM 4.0 release. The CIF

cockpit replaces the CIF queue manager, but does not include information on the mapping of the queue name with the corresponding semantic.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

5.3. CIF cockpit – user profile

• To use the CIF cockpit, you need an RFC user and dialog authorization for every con-nected R/3 system. It is recommended to create a special RFC destination for the CIF cockpit application for each system connected to SAP APO. By this way the authorization of the user using the CIF cockpit can be restricted specifically for using the CIF cockpit. You can do this in the mySAP SCM Implementation Guide (IMG) under Integration with SAP Components � Integration via APO Core Interface (CIF) � Basic Settings for Creating the System Landscape � Assign RFC Destinations to Various Application Cases.

• CIF cockpit has a central default profile. Personalized setting can be maintained per user in

separate user profiles.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

CIF Cockpit – Performance measurement

• Performance/Applications (direction Backend R/3 system => APO) shows data concerning the data volume and the performance on the timely basis specified in the user settings (per minute, hour, day or month).

• The data is shown for the following documents: purchase documents (purchase orders and

purchase requisitions), in-house production (planned orders and production orders), planned independent requirements, stocks, sales documents, inspection lots, reservation items, GI-posted document items, location products and locations (master data).

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

APO: qRFC Alert Monitor

• The qRFC alert monitor checks chosen local or remote outbound queues for chosen desti-nation systems. If there are incorrect queue entries, the report sends a message regarding any such queue to specified users.

• To view the qRFC alert monitor in an APO system, call transaction /SAPAPO/CW and

choose Tools � APO Administration � Integration � Monitor � QRFC Alert or run report /SAPAPO/RCIFQUEUECHECK.

• There is no such monitor in SAP OLTP systems. To monitor the SAP OLTP systems con-

nected to an APO system, monitor them as remote systems from within the APO system.

• It is a good idea to schedule the qRFC alert monitor as background job using report /SAPAPO/RCIFQUEUECHECK to run every 15 minutes.

• If you have implemented inbound queues and wish to implement alert monitoring for them,

create report /SAPAPO/RCIFINQUEUECHECK as an advanced development according to SAP Note 392197. If you do this, check also SAP Note 393574.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Example: RZ20 with qRFC Monitors NOT Authorized

• The Alert Monitor monitors the number of requests in the outbound and inbound queues.

• The queues contain error messages.

• You can append function modules to the collection run for the Alert Monitor. o These function modules can be executed with every run. o Alternatively, you can use them for analyzing the results of the collection run.

• For example, because status Stop is not an error status, you can use a function module to

ignore Stop messages in queues.

• For details, see SAP Note 441269

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Standard System Monitoring

• Standard SAP Basis Monitoring (APO, OLTP) o � System log - SM21 o � ABAP dump - ST22 o � System process overview - SM50, SM66, SM51 o � Locking - SM12, DB01 o � Update - SM13 o � Batch - SM37 o � Database - DB02 o � RFC destination - SM59 o � Gateway - SMGW

• To monitor the inbound qRFC of the CIF user specified in the RFC destinations, use trans-

action SM50.

• If there is a qRFC communication error, check it using transaction SM59.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

qRFC Monitoring qRFC monitor

o � Display transfer queues o � Display waiting qRFC calls o � Restart waiting calls

qRFC problem causes:

o � Communication errors o � Network problems o � Dialog work processes unavailable

o � Application errors ( non-posting of data to APO) o � Bugs o � Missing master data o � Locking of objects

• Use the qRFC monitor to monitor a variety of errors connected with data transfer through

the CIF, including: o Communication/network problems (status CPICERR) o Failure of the application to post data to the target system because of missing master

data for transaction data, locking of objects, or program errors or bugs (status SYSFAIL)

• In the case of a connection error, the data can usually be transferred successfully after cor-

recting the problem simply by executing the function call again. However, application errors require intensive analysis. Under some conditions, the function call in the target system cannot be made to run correctly and the entry must be deleted from the queue to enable transfer of the data following it. Deletion of function calls from queues may result i n in-consistencies, so this should be avoided if possible.

• As return parameters cannot be delivered back to the sending system for qRFC activities,

potential error messages cannot be directly returned there. For example, even if you find no error related to CIF in the qRFC monitor on the SAP OLTP side, you may find errors re-corded in the application log on the APO side.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6. Postprocessing

6.1. CIF Error Handling Default

• A Logical Unit of Work (LUW) is only processed in the receiving system if all data within that LUW can be sent. If one or more LUW entries cannot be transferred, a queue entry with the status ‚SYSFAIL‘ is created for the entire LUW. This can quickly lead to ,serialization‘ effect.

• One queue error might block a large number of subsequent entries. This may lead to blocks

of nearly unrelated business data. A single error might cause inconsistencies between the systems (even LUWs without errors are WAITING).

• Example:

Because of the error in order 1111111111 the entire LUW is stopped. Orders 2222222222 and 11111111111, both have requests in the stock transfer queue CFSTKXXX. Because of this dependency, the LUW containing order 222222222222 will be stopped, too.

• Danger, that all related queues will be stopped --> Data transfer may be stopped.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.2. CIF Error Handling with Postprocessing

• The new CIF EH looses the strict coupling of LUWs for the transfer. Business data unre-lated to the error is still integrated. Business data without errors is still consistent between APO and R/3.

• If the CIF error handling is active, the system does not create faulty queues in the inbound

or outbound queue anymore. If a change to transaction data cannot be posted in the target system due to an error, the system creates a post processing record with the processing status 1 (Still for Processing) and the error status 2 (error).

• The system also creates post processing records for all other objects of the qRFC LUW in

which the error occurred (dependent post processing records).

• This has the advantage that queues in the inbound/outbound of a system are no longer-blocked because of SYSFAIL’s.

Example:

Because of the problem in order 1111111111 the entire LUW will be skipped. A post processing record is written in the receiving system. This record acts as a notifica-tion to try it again after the responsible user investigated and removed the reason for the failure. As a result order 222222222 can be processed after that though both orders 11111111111 and 2222222222 have requests in the stock transfer queue CFSTKXXX.

The post-processing record is always stored in the target system. On APO side the record is stored in table /SAPAPO/CIFERRLG, on R/3 side in table CIFERRLOG.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.3. Postprocessing Facts

• After activation of CIF error handling, the chance of blocked queues after online data transfers of transactional data will decrease

• Improved analysis of qRFC warnings and errors without automatic inter-

ruption of queue transfer process

• Instead of blocked queues a so called CIF error log will be created

• Warnings/Errors can be solved offline without stopping data transfers

• Integration of new CIF Error Handling in CCMS is currently not planned

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.4. Postprocessing Limitations

• No Postprocessing possible for o initial loads o integration of master data ( transaction data only ! ) o ABAP dumps o APO system / liveCache not available o IS-specific objects (e.g. DI-backflush)

• Application specific limitations

o See note 602484

• System Administrator has to monitor the CIF post processing records. If there are any re-cords they should be analysed.

• The danger that all queues are stopped due to interdependencies will be decreased.

• Due to the restrictions, it is however still necessary to monitor CIF queues

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.5. Handling of Postprocessing Records Postprocessing screen as result of /SAPAPO/CPP

• The post-processing is exclusively started in the SCM system using transaction /SAPAPO/CPP (single user access to post processing records) or /SAPAPO/CPP1 (for multiple access to post processing records).

• In the selection screen you have to enter the target system. If the F4-Help for this field does

not provide any data usually the cause is that post processing is not active.

• If the flag ‘Select data from R/3’ is active then also the post processing records from R/3 are taken into account.

• In the display options area of the selection screen you can use the field ‘nodes in navigation

tree’ to define the grouping of the selected post processing records (by product, location user, APO object type and transaction ID)

• If a postprocessing record was processed it gets the postprocessing status “currently being

transferred” and stays in that status as long as the refresh button is pressed.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.6. Usage types for Postprocessing

• CIF error handling is called via APO Administration � Integration� CIF error handling. Al-ternatively you may use the following transactions: o /SAPAPO/CPP : CIF Postprocessing o /SAPAPO/CPP1 : CIF Postprocessing: multiple call o /SAPAPO/CPP2 : Display CIF Postprocessing Records o /SAPAPO/CPPR : Reorganize CIF Postprocessing Records o /SAPAPO/CPPA : CIF Error Handling: Alert

• The reorganization of postprocessing records (transaction /SAPAPO/CPPR) should be done as regular batch job. The underlying report is /SAPAPO/CIF_POSTPROC_REORG.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.7. Alerting for Postprocessing Records Postprocessing alert screen /SAPAPO/CPPA

• To get information about skipped LUWs you should switch on CIF postprocessing alert in transaction /SAPAPO/CPPA. Please decide which user should obtain the alert.

• F4-Help for the Target System just shows logical systems for which Postprocessing for Er-

rors in Error Handling is activated in transaction /sapapo/c2.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

6.8. Prerequisites of Enhanced Queue Display SMQE on SCM side

SMQE on ECC side

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7. CIF Performance

7.1. Check RFC parameters & available resources

Transaction : ST13 Service Tool for CIF Queue Managem ent

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.2. Resources for tRFC (transaction SMQR / SMQS)

• In transaction SMQR and SMQS you can see the resources available according to the set-tings of the rdisp/rfc* parameters. Call transaction SMQR and select ‚Goto‘ >> ‚QRFC re-sources‘. The result displays the number of work processes that can be used for processing the RFC request.

• If DIA WPs for tRFC/qRFC are constantly exhausted (DIA-WPs for tRFC/qRFC = 0), this

indicates a resource problem. Either the RFC resources are not sufficient to accommodate the load or the qRFC processing is too slow. Note that the number of available resources in the system is a snapshot which relates to the load status of the system.

• For tRFC and qRFC calls, the tRFC layer reacts by switching to synchronous RFCs instead

of tRFCs or qRFCs. When the RFC is executed synchronously no further processes are needed for RFC processing. After finishing the processing for asynchronous tRFCs the program may again obtain free resources for further asynchronous tRFC calls.

• To avoid overload situation the application can check the currently available resources us-

ing function module TH_ARFC_REQUESTS before calling RFCs.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.3. RFC Parameter settings Transaction: SARFC > Choose Server Name Transaction: RZ12 > Choose RFC server group and Ser ver

• The profile parameter rdisp/rfc_check can be used to strengthen the usage of quotas. Commonly, the problem is that only asynchronous RFC calls will heed to the quotas being set. If there is a synchronous RFC call which is placed from within an asynchronous RFC, the quotas will not be adhered to by the synchronous RFC call.

• By setting the parameter rdisp/rfc_check to 2, this will change. Any RFC cascade that starts

with an asynchronous RFC call will be handled as if all of the RFCs in the cascade where asynchronous RFC calls. You can even increase the value to 3 which would result in ALL RFCs being forced to adhere to the quotas being set. However, this setting must be tested carefully, because it may result in resource shortage by means of free dialog work proc-esses.

• RFC parameters may be changed dynamically (transaction RZ11 or via RFC server groups

transaction RZ12) if resources are continuously exhausted. However, the changes are lost during restart.

• Wrong configuration of CIF setting/parameters and lack of resources can slow down the

CIF transfer/process or even worst, block the whole system.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Parameter rdisp/rfc_min_wait_dia_wp Parameter rdisp/rfc_min_wait_dia_wp : This parameter is used to reserve a number of dia-log work processes for dialog mode. It prevents parallel RFCs from occupying all the proc-esses. The parameter rdisp/wp_no_dia specifies the absolute number of dialog work processes. Example shown: rdisp/rfc_min_wait_dia_wp = 4, rdisp /wp_no_dia = 55 Available DIA work processes for tRFC / qRFC are ca lculated : No of configured DIA work processes - No of reserved DIA work processes = (55 – 4 ) = 51.

• The parameter 'rdisp/rfc_min_wait_dia_wp' indicates how many dialog work processes cannot be blocked using RFC. This prevents all dialog processes being occupied by paral-lel RFC requests. The default value is 1.

• If 55 dialog work processes are configured on an instance (rdisp/wp_no_dia = 55) and the

parameter rdisp/rfc_min_wait_dia_wp is set to 4, maximal 51 dialog processes can be used for processing tRFC/qRFC call. In either case, 4 dialog processes are kept free for ‘real’ dialog activities.

• In the system, this can be verified as follows:

o Determine the AS group which is assigned to the QIN scheduler (transaction SMQR) o Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding

AS group) o Determine the number of configured DIA work processes (Min. no of free WPs) Attention :

This number is taken from the active operation mode, not necessarily from the instance pro-file !

• These numbers are visible in transaction SMQR => Goto => QRFC Resources

Careful : the number of dialog work processes can change with

operation modes

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Parameter rdisp/rfc_max_own_used_wp Example: rdisp/rfc_max_own_used_wp = 75 (%), rdisp/ wp_no_dia = 55 Available DIA work processes for tRFC / qRFC used b y one user at a time: Share of config-ured DIA work processes (75 % of 55) = 41.

• To avoid that all available RFC resources are used by one user, the parameter rdisp/rfc_max_own_used_wp can be set. When a user issues an RFC call it is checked how many processes the user has already occupied (RFCs or online dialog steps). The value is specified as a percentage of the configured dialog work processes. The default value is 75 (%).

• Example: There are 55 dialog work processes configured. If parameter

rdisp/rfc_max_own_used_wp is set to 75, maximal 41 dialog processes can be used by a certain RFC user / application at the same time. This is the Maximum of the number of dia-log work processes than can be used for tRFC/qRFC (55-5=51) and the share defined by rdisp/rfc_max_own_used_wp (75 % of 55 = 41).

• In the system, this can be verified as follows:

o Determine the AS group which is assigned to the QIN scheduler (transaction SMQR) o Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding

AS group) o Determine the number of configured DIA work processes (Max. no of WPs used) Attention :

This number is taken from the active operation mode, not necessarily from the instance pro-file !

• The available resources are visible in transaction SMQR => Goto => QRFC Resources.

Note that the number of available resources in the system is a snapshot which relates to the load status of the system.

• It is reasonable and recommended to restrict the resources for one RFC user / application

because there may be other applications working with RFC calls and occupy dialog work processes, for example IDoc processing.

Important: Display shows only a sna p-shot of currently free dialog work

processes for tRFC / qRFC

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

Other RFC Parameters rdisp/rfc_use_quotas Activate / Deactivate resource determination

Must be set to 1, NEVER change it ! Default: 1

rdisp/rfc_max_queue Quota (%) of RFC requests in dispatcher queue (rdisp/elem_per_queue) Default: 5

rdisp/rfc_max_login Quota (%) for RFC logons of the total number of logons per instance (rdisp/tm_max_no) Default: 90

rdisp/rfc_max_own_login Quota (%) for RFC logons of one dedicated user Default: 25

rdisp/rfc_max_comm_entries Quota for the number of used communication entries (rdisp/max_comm_entries), ~100 Byte shared memory Default: 90

rdisp/rfc_max_wait_time Maximum number in seconds that a work process is asleep after unssuccessful resource determination.

• If the parameter rdisp/rfc_use_quotas is set to 1 the RFC resource parameters are used.

You should NEVER change the default value. If the parameter is set to 0, then you can no longer work with the parallel RFC since no server can be determined for the next RFC.

• The parameter rdisp/rfc_max_queue is percentage of the RFC entries that are allowed in

the dispatcher queue until no further resources are given to RFC processing. However, the elements in the dispatcher queue are only increasing significantly if all work processes are used. Vice versa, as long as work processes are free, the dispatcher queue is (almost) empty. Therefore, as long as other RFC parameters are set, this parameter is not effec-tively controlling RFC load.

• The parameter rdisp/rfc_max_login and rdisp/rfc_max_own_login are percentages of the

logins of a single RFC user and the total of all RFC users compared to the maximum num-ber of logins allowed. A dialog user usually stays logged on for a long time, usually all the time while working with the SAP System. Therefore, the number of total connections al-lowed is usually much higher than the work processes configured. An RFC user however, usually logs off, when the RFC is processed. The total connections of RFC users is close to the number of active work processes processing RFCs. Therefore, this parameter is not ef-fectively controlling RFC load as long as other parameters are set.

• For more information on these parameters see SAP note 74141.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.4. Check Queue status

Possible Problems: R/3 -> APO Error Symptom Where to look first Data not even sent No queue generated Active integ ration model? Data sent, but not Received Stuck queue Application log of receiving

system Data sent, but not Received Waiting queue QRFC Moni tor: Find out for

which queue your queue is waiting

Error in data selection, i.e. when activating an integra-tion model

No queue generated Sending log in R/3 (if avail-able)

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.5. SMQ2 : Large number of entries / LUWs

• Queue information:

o Number of Entries Displayed = Number of entries in all queues o Number of Queues Displayed = Number of different qu eues (=>objects)

• Problem:

o The number of entries in the queue is growing faste r as they are processed.

• The data constellation inside the CIF queue varies widely and depends highly on the ob-jects types.

• Number of queues = Number of entries:

o Each object is sent in a separate queue and consequently one LUW uses exactly one queue. There are no dependencies to other queues.

o If the RFC resources are sufficient the QIN scheduler can process the LUWs with a high parallel degree. The processing is usually fast and there is no risk that errors in queue proc-essing block each other. In other words, there is no serialization at all.

o In this case, a resource problem can be assumed. • Number of queues << Number of entries:

o The queues contain a high number of objects or one LUW owns objects in multiple queues. There are many dependencies to other queues as the LUWs are touching the same objects. The queue monitor does not show that LUWs share queues.

o The QIN scheduler determines which LUW can be processed first to keep the right se-quence. In case of highly dependent LUWs this step needs more time. The parallel degree of processing is limited even though enough resources are available.

o The risk that errors in queue processing block each other is very high. In opposite to the situation above, additional resources have only limited effect on CIF processing speed.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.6. Status SYSFAIL in CIF queue

Status SYSFAIL:

• A serious error occurred in the target system while executing the LUW. For those queue entries, no automatic re-processing occurs through the QIN/QOUT scheduler. When you double-click on this status, the system displays an error text.

• SYSFAIL errors may have various reasons. They can be caused by missing or incomplete

master data, liveCache errors (e.g. scheduling), termination of function modules / reports responsible for LUW processing.

• Additional information about error reason can be found using the following transactions:

o Application log /SAPAPO/C3 (APO system) or CFG1 (R/3 system): Errors are recorded in the application log independent of the user settings (No logging, Normal, Detailed logging).

o Short dump analysis ST22: In case of short dumps, no application log is recorded as this is done after LUW processing is finished.

o System log SM21 and dev_* trace files

• Check number of faulty queues entries / LUWs using queue monitor

• SMQ2 => Execute => click bell button once

Problem : Error in LUW pr ocessing block the ent ire queue a nd subsequent LUWs cannot be processed -> Serializatio n effect

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.7. Relationship LUW / CIF queue SMQ2 => Execute => click bell button twice

• A LUW is uniquely defined by the same TID. The LUW may contain several objects that are transferred via different queue names. One LUW can only be processes in exactly one work process.

• An error in transferring or processing of the LUW causes the whole queue to be stopped.

Such a queue block not only affects the LUW containing the faulty queue entry, but also all LUWs containing subsequent queue entries. This is called serialization effect.

• Due to this the data transfer may be severely restricted and some data cannot be trans-

ferred at all. Consequently, there are inconsistencies between source and target system. For that reason, it is of utmost importance to rectify incorrect queue entries in time. Monitor-ing concept/handbook suitable to the Best Practices is absolutely necessary and has to be established before go-live involving system administration AND business department as well.

[email protected]


of 48 Created on 7/27/2011 3:09:00 PM

7.8. Stuck queues Queues with status SYSFAIL � Try to restart the queue. If error occurs again: First hint: error message which is displayed with the queue in the qrfc monitor

• Be careful: Message number in the queue monitor is always SR053 !! You do not get the real message number in the queue monitor!

Application log in receiving system (APO)

• Either access via double click on TID ( preconditions: enhanced queue display customized ) • Or (better) log on to APO and search for log in Transaction /SAPAPO/C3

o Enter TID obtained from the queue monitor in the field External ID (Attention: not in the field Transaction code)

• Search for OSS notes suitable for the error messages If no application log found, it is usually a dump

• Search for dump in APO with Transaction ST22 • Search for OSS notes suitable for the dumps

CIF Monitoring Guideline V3

Documents

Transcript of CIF Monitoring Guideline V3