1 CIF Cookbook Version 2

APO Core Interface Monitoring Cookbook
Version 2.0
- Internal use only! -
(This document is subjected to continuous improvement. All feedback please address to [email protected] and/or
[email protected] and/or [email protected])
Date Version Changes

April 2006 2 - New in Chapter 2. CIF Monitoring Tools: CIF Cockpit and CIF Error handling
- New in Chapter 3, contains more information (including figuring CIF traffic load and
special development to improve performance during high CIF loads)
- New in Chapter 5, updating contents with more information and adding new section
‘Queue and performance problem’.
- Updating screen shot with newer release
- Updated: Contents of Appendix 1. List of Transaction and Appendix 2. SAP Notes.
- Deleted: References and Appendix 4. Suggestion of Monitoring Tools Functionality
Enhancement.
Contents
Contents ............................................................................................................................................. 1
Introduction......................................................................................................................................... 4
Necessary Knowledge........................................................................................................................ 5
Chapter 1: APO Core Interface Overview .......................................................................................... 6
Transfer Technique......................................................................................................................... 6
qRFC Without Inbound Queues (Only Outbound Queues) ........................................................ 7
qRFC With Inbound Queues....................................................................................................... 7
Logical Unit of Work and Queued RFC ...................................................................................... 8
Integration Model ............................................................................................................................ 8
Transfer from R/3 to APO ........................................................................................................... 8
Transfer from APO to R/3 ........................................................................................................... 9
Data Transfer and Data Channels .............................................................................................. 9
Serialization Effect .................................................................................................................... 10
Chapter 2: CIF Monitoring Tools ...................................................................................................... 12
SMQ1 (Outbound monitoring) ...................................................................................................... 12
Outbound QUEUE Overview .................................................................................................... 13
Outbound Queue MENU OPTIONS.......................................................................................... 13
Outbound Queue STATUS SCREEN ....................................................................................... 13
Outbound Queue STATUS ....................................................................................................... 14
Outbound Queue LUW DETAIL................................................................................................ 15
SMQ2 (Inbound monitoring) ......................................................................................................... 17
© 2006 SAP AG
Inbound Queue STATUS .......................................................................................................... 17

SMQS (QOUT Scheduler) ............................................................................................................ 18
QOUT Scheduler SCREEN ...................................................................................................... 18
QOUT Scheduler STATUS ....................................................................................................... 19
QOUT Scheduler MENU OPTIONS.......................................................................................... 19
SMQR (QIN Scheduler) ................................................................................................................ 20
QIN Scheduler SCREEN .......................................................................................................... 20
QIN Scheduler STATUS ........................................................................................................... 21
QIN Scheduler MENU OPTIONS.............................................................................................. 21
/SAPAPO/CQ (SCM Queue Manager) ......................................................................................... 21
SCM Queue Manager SELECTION SCREEN ......................................................................... 21
SCM Queue Manager EVALUATING THE RESULT................................................................ 22
/SAPAPO/C3 (Application Log) .................................................................................................... 22
Application Log SELECTION SCREEN .................................................................................... 23
Application Log DISPLAY SCREEN ......................................................................................... 23
/SAPAPO/CC (CIF cockpit) .......................................................................................................... 24
Data Transfer Monitoring Using the CIF Cockpit ...................................................................... 24
Settings Features: ..................................................................................................................... 24
Monitoring Features: ................................................................................................................. 26
/SAPAPO/CPP Error Handling ..................................................................................................... 28
General Information .................................................................................................................. 28
Working with Post Processing Records .................................................................................... 29
Reorganizing Post Processing Records ................................................................................... 30
Chapter 3: Performance and Configuration ..................................................................................... 32
Technical System Settings and Customizing ............................................................................... 32
Optimal settings of RFC and Gateway parameters .................................................................. 32
Latest qRFC version ................................................................................................................. 34
R3 Plug-In version .................................................................................................................... 35
Queue type (Inbound - Outbound) ............................................................................................ 35
Resource Distribution................................................................................................................ 35
Reorganization of Quickly Growing/Shrinking Tables (valid for Oracle database only) ........... 35
Initial Supply ................................................................................................................................. 36
Data Providers in R/3................................................................................................................ 36
Settings of Object Parameters .................................................................................................. 36
‘Obsolete’ Data in R/3 System .................................................................................................. 36
Activated Application Log Writing ............................................................................................. 36
Performance Improvement by Parallel Initial Supply ................................................................ 37
Usage of ALE Change Pointers ................................................................................................ 37
Online Transfer ............................................................................................................................. 38
Design of The Integration Models ............................................................................................. 38
Detailed Logging ....................................................................................................................... 38
Publish Planning Results from APO to R/3 (In-House Production) .......................................... 38
Serialization Effect .................................................................................................................... 38
"Hanging" and "Traffic Jam" Problems ..................................................................................... 39
Special development for performance improvements during high CIF load ................................ 39
Stock update counters .............................................................................................................. 39
Emergency scheduler ............................................................................................................... 39
Figuring out CIF traffic in the system............................................................................................ 39
Monitoring Roadmap ........................................................................................................................ 41
Chapter 4: General Checks.............................................................................................................. 42
Check qRFC processing type (w/o Inbound) and error handling (post-processing) .................... 42
Check qRFC version ................................................................................................................. 42
Check RFC parameters and available resources for qRFC processing ...................................... 42
Check whether qRFC registration is correct. ............................................................................ 44
Chapter 5: CIF Monitoring and Analysis .......................................................................................... 45
Stuck Queues / Queue Problems ................................................................................................. 45
Technical (Communication) Errors ........................................................................................... 46
Application Related Errors ........................................................................................................ 46
Complex Analysis...................................................................................................................... 48
SYSFAIL problems ................................................................................................................... 48
RETRY Problems...................................................................................................................... 49
Queues and Performance problems............................................................................................. 53
© 2006 SAP AG
Tools ......................................................................................................................................... 53
Resources/Setting problems..................................................................................................... 53
Long Accesses to Tables.......................................................................................................... 53
Long Process time of Integration jobs (R/3) ............................................................................. 55
Long processing time of publication job.................................................................................... 57
Long accesses to liveCache ..................................................................................................... 58
Appendix 1: List of Transactions ...................................................................................................... 59
Appendix 2: Related SAP Notes ...................................................................................................... 60
Appendix 3: Troubleshooting Flowchart........................................................................................... 61
© 2006 SAP AG
APO Core Interface Monitoring Cookbook 4
Introduction
This document is intended to provide necessary knowledge and monitoring guideline to identify and
analyze problems related to SAP APO Core Interface (CIF). It is not an expert guide that contains
every minor detail of the corresponding topic. Instead this document provides quick, clearly
structured, step-by-step set of instructions – like a cookbook – as a centralized reference of
information and guideline.
The cookbook is separated into 2 sections. With each chapter in each section covering different
aspects of APO CIF. This structure enables reader from diverse CIF knowledge level to use this
cookbook without having to read the whole document.
The first section is providing necessary information surround APO CIF as an introduction and
background of CIF technology.
Chapter 1 “Core Interface Overview”, discuss about what CIF is, what kind of technology it’s based
on and introduction into CIF related terms and definitions.
Chapter 2 “CIF Monitoring Tools”, focus on specific tools use to monitor CIF
Chapter 3 “Performance and Configuration”, provides SAP recommended configuration for CIF;
including RFC and Gateway parameters setting, Integration setting, information on newest version
of qRFC and plug-ins and much more.
Section two is more focus on the Monitoring of CIF. This section provides instruction and guideline
on how to analyze and pint point CIF related problems.
Chapter 4 “General Checks”, covers CIF general checks that have to be verified before further
analysis of the problems.
Chapter 5 “CIF Monitoring and Analysis”, describes step-by-step actions to drill down further
queues errors and or CIF performance problems.
Last but not least, please find in the Appendix a further list of CIF related transactions, related SAP
notes and flowchart for troubleshooting.
© 2006 SAP AG
Section 1:
Necessary Knowledge
© 2006 SAP AG
Chapter 1: APO Core Interface Overview

The SAP APO Core Interface (CIF) is a standardized interface solution that enables data exchange between
APO and R/3 systems. Only those data objects that are relevant for starting/designing the planning processes
in APO must be transferred from R/3. In addition to initial data transfer, CIF guarantees an incremental supply
of relevant data changes to APO. The CIF is an add-on to the R/3 system that is installed using the relevant
R/3 Plug-In.
As of SAP ECC 6.0, a separate Plug-In is not needed anymore. All interfaces necessary for integration with
other SAP components are contained directly in SAP ECC 6.0 and higher release levels.
The interfaces to non-R/3 systems are implemented as Business Application Programming Interfaces (BAPIs)
that enable object-oriented access to SAP systems.
The main tasks of the SAP APO CIF include determination of the source and the target system, provision of
the APO with the relevant master and transaction data, transfer of data changes, and return of planning results
from APO to the execution system(s).
The SAP APO CIF provides:
• Integration models to specify which data is to be transferred between SAP R/3 and SAP APO
• Techniques for initial, incremental, and real-time data transfer between SAP R/3 and SAP APO
• Alerting (CIF Queue Alert) and monitoring tools (SCM Queue Manager) to supervise the CIF data
transfer
Transfer Technique
The SAP APO CIF uses queued remote function calls (qRFCs) provided by SAP Technology to ensure the
desired sequence and transactional security of data transmissions between SAP R/3 and SAP APO. With
qRFCs, asynchronous data transfers between SAP APO and SAP R/3 are established, thus enabling
business process steps to be finished in either one of the systems, without the need to wait until the data is
actually transferred to the other system(s).
qRFC itself is an enhancement of the tRFC (transaction Remote Function Calls) technology. The qRFC
requests are placed into a queue; they are processed in the correct sequence based on their dependencies to
other qRFC requests. Preceding requests have to be completed before subsequent requests are processed.
The qRFC requests can be collected to LUWs (Logical Unit of Work). One LUW on the sending system will
refer to exactly on LUW in the receiving system.
There is a queue for every logical unit of business objects like material changes, i.e. objects that logically
belong together are in the same queue, and they are processed one after the other (serialization). The queue
sequence will be guaranteed by the usage of identical queue names. The serialization is achieved via a queue
identifier that is comprised of: Client, Queue-Name, and Destination & Queue-Counter
Example:
Goods receipt for purchase orders is processed with a LUW with multiple function calls. The LUW guarantees,
that stock increase will only be processed in combination with the purchase order closing. All queues of the
LUW have to be processed, before the complete LUW can be finished.
qRFC with inbound and outbound queues involves a 3-phase processing and transfer model. All three phases
are completely independent of each other. Separation of these phases ensures that asynchronous processing
is as secure as possible. In the first step, the application data is written to the database in the outbound
queue. When the first step is completed, the data is saved in the database. In the second step, the QOUT
Scheduler transfers this data from the database of the client system, to the inbound queue in the database of
© 2006 SAP AG
the target system. In the third step, the target system QIN Scheduler activates processing of the queue in the
target system. The following diagram illustrates the 3-phase communication concept:
Client system Server system
Application
Application 1) Data security in the outbound queue
Database
Database 3) Processing
2) Transfer
QOUT Scheduler
QIN Scheduler
qRFC Without Inbound Queues (Only Outbound Queues)

Outbound processing means that the sending system controls the correct processing order of
transactions/LUWs. Each request is sent as an LUW to the receiving system. Processing of these LUWs
commences as soon as there is an available dialog work process in the receiving system.
If there is high traffic on the CIF, all work processes in the receiving system could be 100% utilized, leaving
none free for other tasks such as dialog requests.Starting qRFC version 6.10.42, the ability to restrict the
number of work processes used on the receiving system is provided.
WP1 tRFC LUW1 WP1

R/3 tRFC
WP2 LUW2 WP2 APO
WP3 tRFC LUW3 WP3
WP4 tRFC LUW4 WP4
WP5 WP5
WP6 WP6
Outbound
qRFC queue
Q1 – LUW1
• The CIF queues are processed using tRFC
Q2 – LUW2
Q3 – LUW3
(transactional RFC’s). This means that each
Q4 – LUW4 request is sent as a LUW (Logical Unit of Work)
… Q-OUT to the receiving system.
Scheduler • Processing of these LUWs commence as soon
as there is an available work process in the
receiving system.
qRFC With Inbound Queues

Inbound processing means that the receiving system controls when the processing occurs for
transactions/LUWs. The LUWs are not processed immediately in the receiving system, instead the requests
are written directly into its inbound queue. The QIN scheduler controls the processing of the queues/LUWs.
The number of work processes can be configured to avoid 100% utilization of work processes.
© 2006 SAP AG
LUW’s are not processed

WP1 tRFC immediately in the LUW1 WP1
receiving system, instead
R/3 WP2 tRFC the requests are written LUW2 WP2 APO
directly into its inbound
WP3 tRFC LUW3 WP3
queue
WP4 tRFC LUW4 WP4
WP5 WP WP5
WP
WP6 WP6
Q-IN
Scheduler
Outbound Inbound The Q-IN scheduler
qRFC queue qRFC queue controls processing of the
Q1 – LUW1 Fast,
Fast as the LUW’s are queues/LUW’s. The
only written and not Q1 – LUW1
Q2 – LUW2 Q2 – LUW2 number of work processes
Q3 – LUW3 processed immediately, used by the Q-IN
thus little overhead is Q3 – LUW3
… Q6 – LUW6 Q-OUT …Q6 – LUW6 scheduler can be
Scheduler placed on the receiving configured to avoid 100%
system utilisation of all work
processes
Logical Unit of Work and Queued RFC

For each data transfer a Logical Unit of Work (LUW) is created that has to be executed by the RFC scheduler.
As the CIF uses a queued RFC (qRFC) each LUW is shown as an entry in the qRFC queue (/SMQ1 for
outbound, /SMQ2 for inbound).
Each queue entry contains both the data to be transferred and the function modules to be called in APO via
RFC. Until the transfer has been executed successfully the queue can show several statuses
Further explanation of queue status will be discussed in Chapter 2.
Integration Model
An integration model is used to control the data transfer from R/3 to APO. It is created in R/3 and gathers
together the data sets (master and transactional data) that are required for APO planning processes. An
integration model is uniquely defined by its name and application and is related to a dedicated target system.
By activating a generated integration model the actual data transfer is started. Typically there are models for
master data and models for transaction data.
Transfer from R/3 to APO

• Initial transfer (supply):
The initial data supply means the first data transfer from R/3 to APO. With this transfer, planning
relevant data (master and transaction) is loaded from the R/3 execution System into SAP APO. After
finishing this step, the system switches to an incremental data transfer, which means that only data
changes are transmitted.
• Incremental transfer (change transfer):
The incremental transfer distinguishes between change transfer for master data and change transfer
for transactional data. Necessary incremental transfers of master data are filtered and routed towards
APO either periodically or, if needed, immediately. How the strategy for transferring master data
actually works is a matter of customizing. Either so-called Business transaction events (BTE) are
used to immediately notify CIF about changes to SAP R/3 master data (Material, Customer, and
Vendor Masters) or ALE change pointers are recorded for the corresponding message types. Those
pointers have to be processed regularly in order to notify the APO of a changed master data
situation. The ALE Customizing settings for change pointers are needed for the transfer to be
executed successfully. The incremental transfer of transaction data is event-driven in order to reflect
the current planning situation as close to real-time as possible. This means that within each
transaction containing a change of a planning relevant object in R/3 (e.g. production orders, sales
orders), the change is sent to APO immediately.
• Delta transfer:
This means the transfer of new planning-relevant objects that have to be transferred to APO. Here,
the so-called delta logic is in place. Only objects are transferred which are not in an active integration
© 2006 SAP AG
model. Thus, fewer amounts of data have to be transferred. Objects that have been changed in the
meantime are transferred, too. The ALE change pointers are evaluated for materials, customers,
vendors and sources of supply. Defining jobs enables the system to regenerate and then activate the
integration models in regular intervals in order to notify APO about a changed master data situation.
Transfer from APO to R/3

The retransmission of APO planning results into the R/3 execution system is result-based. All changes are
distributed according to a publish/subscribe mechanism. Depending on the application, the planning results
are either extracted immediately then sent to the connected R/3 system (valid for PP/DS) or they are
published using a certain report/transaction to be scheduled periodically (valid for SNP). These modes are the
delivered SAP standard settings for the relevant applications.
Data Transfer and Data Channels

The data transfer to a logical system is executed by the Active Data Channel (ADC), which contains several
channels. Its status of activity/operations mode can be controlled in transaction /CFC1.
During the initial data transfer the operations mode shows ‘initial data transfer active’.
After a successful activation the incremental data transfer is activated and the operations mode switches to
‘transactional events active (standard)’. It uses a separate a channel for each object type. The names are
different for the transfer direction.
Names for direction APO => R/3
Queue name Description

CFCD* Delivery confirmation
CFCF* Confirmation, APO Backflush
CFCO* Sales Orders
CFDLV* Delivery
CFEP* External Procurement APO - R/3 (purchase order /
purchase requisition)
CFFO* Planned independent Requirements
CFHE* Scheduling agreement confirmation
CFIP* In-house Production APO - R/3 (planned order,
production order, process order)
CFMO* / CFMW* Maint plan order
CFPC* Production Campaign
CFPJ* Project order
CFRP* Reporting points
CFRV* Manual Reservations
CFSHP* Shipment
CFTO* Stock transport order
*) Logic of queue names: CFFIPXXXXXXXXXXXX
• First 2 letters CF for CIF
• Next 2 letters for object type, e.g. IP = In-house Production
• Following 20 digits: first 10 pertinent chars of the order GUID
Names for direction R/3 => APO
© 2006 SAP AG
Queue name Description

CFLD<logical source Initial data transfer
system>_<counter><subcounter>
CFBTC* Batches
CFCAPA* / CFCAPA_TS* Resources
CFCB* CBase Configuration
CFCD* CDP Configuration
CFCR* CBase Configuration, special case
CFCHR* Characteristics
CFCLA* Classes
CFCL* Classification
CTBW* InfoSource
CFCUS* Customer
CFCUVT* Planning tables
CFFCC* Reduction of PIRs (if separate Imod is used)
CFLOT* Inspection lots
CFMAT* Material master data (Reduction of PIRs if NO separate Imod
is used)
CFNETWORK* Network
CFPCM* Production campaigns
CFPIR* Planned independent requirements (created in R/3)
CFPLO* Planned orders / Production orders / Confirmation
CFPO* Purchase orders / Purchase requisition
CFPPO* Confirmation*
CFPVB* Supply area
CFRSV* Manual reservations
CFSDS* Scheduling agreement item
CFSHP* Shipments
CFSLS* Sales orders
CFSTG* Setup groups
CFSTK* Stock
CFTG* Deletion of temporary quantity assigments GATP (in one LUW
with CFSLS*)
CFTL* Transport locks (TP/VS scenario)
CFVEN* Vendors
FC* Fulfillment coordination (only if qRFC consumption is used)
*) Logic of queue names CFSLS<n>
• First letters stand for the object type (see table above)
• Followed by the order number, e.g. CFSLS0000010003 for a sales order
For a complete list see Note 786446.
Serialization Effect
When using qRFCs for a data transfer, the system adheres strictly to the sequence of objects to be transferred
(serialization), in contrast to the transfer using tRFC. Serialization applies if queues entries from different
logical units of work (LUWs) are being processed in this queue. For example, this could be the case if a
number of changes are made for an order in SAP R/3 at different points in time. The changes are in the same
queue due to the queue name and they are therefore subject to serialization. However, since the postings took
place at different points in time, the corresponding queue entries are in different LUWs. If a queue contains a
faulty queue entry, the subsequent queue entries will also not be transferred. This leads to a queue block. A
queue block not only affects the LUW containing the faulty queue entry, but also all LUWs containing
subsequent queue entries. This effect is called the serialization effect. This is a potential consequence of a
faulty queue entry during a data transfer using qRFC.
© 2006 SAP AG
Serialization effect can be suppressed (minimized) by new functionality of CIF Error Handling. For further
details see chapter 2 subchapter CIF Error Handling.
© 2006 SAP AG
Chapter 2: CIF Monitoring Tools

As part of SAP software components, CIF also contributes loads to overall system performance. The general
monitoring tools such as ST03n, ST02, ST06, SM21, ST22, etc are also necessary to monitor CIF contribution
to the overall system response time. However assuming that those tools are quite familiar to us, this chapter is
dedicated for discussing only specific tools to monitor APO CIF and only focusing on the tools related
functionality for CIF monitoring.
The tools are not only for monitoring but also enable us to administer qRFC/tRFC, such as to restart “crashed”
LUWs or delete them from the queue and/or to reactivate a blocked queue. Those transactions are:
• SMQ1 - qRFC Monitor for the outbound queue. This transaction is to monitor the status of the LUWs in
the outbound queue. This allows you to display, activate, debug or delete queues.
• SMQ2 - qRFC Monitor for the inbound queue. This transaction is to monitor the status of the LUWs in
the inbound queue. This allows you to display, activate, debug or delete queues.
• SMQS – Outbound Queue Scheduler This transaction is to administer outbound queue such as
register, deregister, and exclude destinations.
• SMQR – Inbound Queue Scheduler This transaction is to administer inbound queue such as register,
deregister, and exclude queues.
• /SAPAPO/CQ – SCM Queue Manager. Only valid in the APO side, this transaction is a cockpit of APO
qRFC monitoring and administration. This allows the queue to be monitored centrally and processed in
both the sending and receiving system. You can navigate to the qRFC Monitor and application log for
all connected systems.
• /SAPAPO/C3 (or CFG1 in R/3 side) – Application Log. This transaction is used as additional check for
application error related to CIF. This allows you to trace who (user) transferred what (data object and
integration model) and when (date/time). The application log provides a detailed error message for
queues with errors.
• /SAPAPO/CC - CIF Cockpit. This transaction refers to as a central entry point for checking all settings
and current system states relevant to CIF. Additionally, it offers the possibility to perform a detailed
analysis and correction by branching to single transactions.
• /SAPAPO/CPP - CIF Post-processing (valid as of SCM 4.0). This transaction is used to display and
process so-called post-processing records that are automatically generated during CIF error handling.
Prerequisite: CIF error handling must be active. CIF error handling is a new feature to avoid queue
blocks during transfer of transactional data. Using this, faulty queue entries are logged in post-
processing records and can be processed at a later point in time.
SMQ1 (Outbound monitoring)

This transaction is for monitoring the contents of the outbound queues. Queues will be shown depending on
the selection criteria on the selection screen. If the queue were not filled with at least one LUW then the result
would be empty.
© 2006 SAP AG
Outbound QUEUE Overview

It shows queue entries, which are currently in the outbound queue.
Jump to hanging
queues display
Columns explanation:
• Cl: Client number where the qRFC was generated.
• Queue name: Name of the queue (generated from the application program). Clicking on this will
open a detailed screen for the corresponding queue.
• Destination: Destination that will be used within the R/3 or APO system, this destination name must
be present in SM59. Clicking on this will forward you to SM59.
• Entries: Number of LUWs in the queue.
Outbound Queue MENU OPTIONS

Under QRFC menu, the following options are available:
• Trace: In addition to the existing RFC traces, you can activate a trace specifically for the qRFC. This
trace displays qRFC LUW information, such as TID, function name, queue name, time of transfer, and
time of execution. Application data is not listed. If you require this data, the trace flag in SM59 must be
activated. For each LUW processed, several entries are written for each TID (for example, for a
successfully processed TID, the following five entries are written in the trace: Recorded, Sending,
Running, Finish, Confirmed).
• LOG: In the LOG, only the TIDs are listed for which a problem has occurred during transfer or
processing. Activation of the LOG can occur for each queue individually or generically.
• REORGANIZE: Delete all registered entries of qRFC administration (Log, Trace, Events)
Under Information menu, you have the following options:

• Version: Displays the current qRFC version. The current qRFC version can be different to the R/3
kernel version!
Outbound Queue STATUS SCREEN

Show the queue status with and the number of LUWs.
Jump to running
queues display
Additional to the output screen you can see:

• Status: The queue status of the queues will be shown. For the possible status values please read
the SAP note 378903.
• 1Date/ 1.Time: Shows the date/time when the first LUW was written into the queue.
• NxtDate/NxtTim: Tells when the last LUW was written into the queue.
• 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 is shown in the status field you can get more detailed information when you double click the status.
© 2006 SAP AG
Outbound Queue STATUS

Please also refer to SAP note 378903.
READY
The queue is ready for transmission. This status should only be a temporary status. However, in the following
case this status can also be a permanent status: a queue was locked manually via transaction SMQ1 or via a
program and then unlocked without being activated at the same time. This queue must be activated explicitly.
RUNNING
The first LUW of this queue is currently being processed. If a queue in this STATUS hangs for more than 30
minutes, this may mean that the work process responsible for sending this LUW has terminated. In this case
you can activate this queue again. Note that activating a queue in status RUNNING may cause a LUW to be
executed several times if this LUW is processed in the target system at that time. We therefore recommend a
waiting time of at least 30 minutes before you activate the queue again.
EXECUTED
The first LUW of this queue is processed. The system waits for a qRFC-internal confirmation from the target
system before further LUWs are processed. If a queue in this STATUS hangs for more than 30 minutes, this
might mean that the work process responsible for sending this LUW has terminated. In contrast to status
RUNNING, this current LUW has definitely been executed successfully. You can activate this queue again
without problems. The qRFC Manager will automatically delete the LUW already executed and send the next
LUW.
SYSLOAD
At the time of the qRFC call, no DIALOG work processes were free in the sending system for sending the
LUW asynchronously. A batch job for subsequent sending has already been scheduled (see SAP Note
319860 for more details).
SYSFAIL
A serious error occurred in the target system while the first LUW of this queue was executed. The execution
was interrupted. When you double-click on this status, the system displays an error text. You can find
additional information on this error in the corresponding short dump in the target system (ST22). No batch job
is scheduled for a repetition and the queue is no longer processed. To solve the problem, information from the
affected application is required. Refer to SAP Note 335162 for the special error text "connection closed".
CPICERR
During transmission or processing of the first LUW in the target system, a network or communication error
occurred. When you double-click on this status, the system displays an error text. You can find additional
information on this error in the syslog (SM21), the trace files dev_rd or dev_rfc*. Depending on the definition in
transaction SM59 for the destination used. A batch job is scheduled for subsequent sending. Status CPICERR
may also exist in the following cases although no communication error occurred: a qRFC application finds out
that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the
RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution
of this LUW and to repeat this LUW later in accordance with the specification in transaction SM59.In this case,
qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again." If
this error occurs very often, you must contact the corresponding application team.
STOP
On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ1 or programs). Note
that the qRFC never locks a queue in its processing. After having informed the corresponding application
team, you can unlock and activate this queue using transaction SMQ1.
WAITSTOP
The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently
still locked.
WAITING
The first LUW of this queue has dependencies to other queues, and at least one of these queues contains
other LUWs with higher priorities.
NOSEND
LUWs of this queue are never sent but retrieved by a special application. These queues are only used
internally at SAP (BW or CRM during communication with Mobile Clients). Even if a LUW was read by the
corresponding application (BW, CRM), this status does not change. This LUW is only deleted from the queue
if this application confirms collection (collective confirmation possible). Under no circumstances should this
status be reset using transaction SMQ1 and the queue activated.
NOSENDS
During the qRFC call, the application determines at the same time that the current LUW is not sent
immediately. This is used to debug the execution of an LUW via transaction SMQ1. Contact the corresponding
qRFC application to clarify this status since this is either a programming or configuration problem.
WAITUPDA
This status is set if qRFC is called within a transaction that also contains one or more update functions. As a
result of this status, the LUW and thus the queue is blocked until the update has been completed successfully.
If this status takes longer than a few minutes, check the status of the update or the update requests using
transaction SM13. After a successful retroactive update, the blocked LUW is sent automatically. You can also
restart the LUWs manually in the WAITUPDA status without a successful retroactive update (via transaction
SMQ1, Reset status, Activate queue). However, you may only perform this action after having informed the
© 2006 SAP AG
qRFC application (for example, APO, BW, CRM). You must do this to avoid possible inconsistencies. This
WAITUPDA problem may be avoided as follows: If both qRFC calls and update calls occur within a
transaction, qRFC must be executed exclusively within the update. In this case, the qRFC LUW is only
created after the update has been completed successfully. Caution: If you are using SAP Basis Releases
4.0x, 4.5x, 4.6A or 4.6B, and an update function with the "collective run" type exists in a LUW, an error in the
kernel may cause this status. The queue also hangs in this case. This error has already been corrected with a
kernel patch (see SAP Note 333878).
RETRY / ARETRY
During LUW execution the application has diagnosed a temporary problem and has prompted the qRFC
Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition on the basis of
the definition in transaction SM59 (Menu: Destination > TRFC Options)
ANORETRY
During the LUW execution, the application has found a serious error and prompted the qRFC Manager via a
specific qRFC call to cancel processing of this LUW. Information from the affected application is required to
solve the problem.
MODIFY
Processing this queue is locked temporarily because the LUW data is being modified.
Remark: Report RSQOWKEX reset the status of all queues (CPICERR, RETRY, SYSFAIL) and
restarts the outbound scheduler. This report can be used in exceptional cases; do not schedule this
report on regular basis, investigate the error before restarting the queue.
Outbound Queue LUW DETAIL

There you have the detailed status text. If there was an error the status field of the first LUW will be red
marked and an error text tells you what the problem is. Only the left side could be shown in one picture. The
right side will be depicted below.
Left Side Screen
Jump to debugging
mode
Right Side Screen
Additional columns are:

• User: User name, which has started the qRFC.
• Function module: Name of the function module that will be called in the destination system, which is
shown in the column destination.
• Date/Time: Point of time when the LUW was written into the queue
• Status txt: Status text of the LUW (not to mistake with the status of the queue )
• TID: Transaction Identifier for the LUW
• Tktn: Transaction which was active at creation time of the LUW
• Program: Program that produced the LUW.
© 2006 SAP AG
• Rpts: Repeats that are planned in. Only if a CPIC error was detected repeats will be planned in. This
could be steered in SM59 (TRFC Options). If no entries were made the default values will be used
(30 attempts, one each 2 minutes).
When you are in the detailed view of a LUW (as shown in the screenshot above) the content of the LUW can
be shown by double clicking on the queue name. Depending on the setup of the system you will get a queue
display in binary mode (which is not very helpful for analyzing purposes) or you will get a clear overview of all
related tables in DDIC format and their content.
Queue display in binary mode
New Queue display

The prerequisite for the new queue display is that the customer has registered the program
/SAPAPO/CIF_QUEUE_EVENT2 in transaction SMQE as a display program (in the APO/SCM system) or the
program CIFQEV02 at R/3 side.
There’s also the possibility to jump from a queue entry directly to the application log by double clicking the
queue entry name TID field in the detailed view of the LUW (if the above mentioned programs are registered;
(if the system is correctly set up for this, see also notes 717280 and 717282).
Queue display is not relevant for support, whereas application log is.
Queue display with all related

tables and their content in DDIC
format on SCM side
© 2006 SAP AG
Queue display on R/3 side (planned order with all relevant data, e.g. activities, BOM)
SMQ2 (Inbound monitoring)

Inbound Queue monitoring screens and menus are more or less the same as the Outbound Queue monitoring
tool. But instead of monitoring the Outgoing queues, this tool is designed to monitor the incoming queues. For
further details please refer to above subchapter.
A hanging queue is defined as a queue:
• Where the first LUW is not processed longer than 30 minutes
• Where a system error occurred (SYSFAIL or CPIC error)
Inbound Queue STATUS

Please also refer to SAP note 378903.
READY
The queue is ready for processing. This status should only be a temporary status. However, in the following
case this status can also be a permanent status: a queue was locked manually via transaction SMQ2 or via a
program and then unlocked without being activated at the same time. This queue must be activated explicitly.
RUNNING
The first LUW of this queue is currently being processed. If a queue in this status hangs for more than 30
minutes, this may mean that the work process responsible for sending this LUW has terminated. In this case
you can activate this queue again. Note that activating a queue in status RUNNING may cause a LUW to be
executed several times if this LUW is processed in the target system at that time. We therefore recommend a
waiting time of at least 30 minutes before you activate the queue again.
SYSFAIL
A serious error occurred in the target system while the first LUW of this queue was executed. The execution
was interrupted. When you double-click on this status, the system displays an error text. You can find
additional information on this error in the corresponding short dump in the target system (ST22).No batch job
is scheduled for a repetition and the queue is no longer processed. Information from the affected application is
required to solve the problem. Refer to SAP Note 335162 for the special error text "connection closed".
CPICERR
During transmission or processing of the first LUW in the target system, a network or communication error
occurred. When you double-click on this status, the system displays an error text. You can find additional
information on this error in the syslog (SM21), the trace files dev_rd or dev_rfc*. Depending on the registration
of this queue (SMQR) a batch job is scheduled for repetition. Refer to SAP Note 369524 for the error text "R/3
logon failed". Status CPICERR may also exist in the following cases although no communication error
occurred: a qRFC application finds out that a LUW cannot be processed any further due to a temporary error
in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module in order to
prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance
with the specification in transaction SM59.In this case, qRFC simulates a communication error with the text
"Command to tRFC/qRFC: Execute LUW once again.". If this error occurs very often, you must contact the
corresponding application team.
© 2006 SAP AG
STOP
On this queue or a generic queue (for example, BASIS_*) a lock was set explicitly (SMQ2 or programs). Note
that the qRFC never locks a queue in its processing. After having informed the corresponding application team
you can unlock and activate this queue using transaction SMQ2.
WAITSTOP
The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently
still locked.
WAITING
The first LUW of this queue has dependencies to other queues, and at least one of these queues contains
other LUWs with higher priorities.
NOEXEC
During the qRFC call, the application team simultaneously determines that the current LUW is not processed
automatically even if the queue to the QIN Scheduler (SMQR) is registered. This is used to debug the
execution of an LUW via transaction SMQ2. Contact the corresponding qRFC application to clarify this status
since this is either a programming or configuration problem.
RETRY
During LUW execution, the application has diagnosed a temporary problem and has used a specific qRFC call
to prompt the qRFC manager in the sending system to schedule a batch job. This batch job schedules a
repetition after two minutes.
ARETRY
During LUW execution the application has diagnosed a temporary problem and has prompted the qRFC
Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition on the basis of
the registration in transaction SMQR.
ANORETRY
During the LUW execution, the application has found a serious error and prompted the qRFC Manager via a
specific qRFC call to cancel processing of this LUW. Information from the affected application is required to
solve the problem.
MODIFY
Processing this queue is locked temporarily because the LUW data is being modified.
Remark: Report RSQIWKEX reset the status of all queues (CPICERR, RETRY, SYSFAIL) and
restarts the inbound scheduler. This report can be used in exceptional cases; do not schedule this
report in regular basis, investigate the error before restarting the queue.
SMQS (QOUT Scheduler)

This transaction is for displaying the state of the QOUT-Scheduler and for registering or deregistering queue.
The scheduler status could be seen at the top of the screen.
Remark: To distribute resources on the receiving system a logon group should be defined, using
/SMLG. In this way, you can exclude a specific server from the RFC processing (e.g. the database
server) to avoid overload
QOUT Scheduler SCREEN
Jump to /SMQ1
• Scheduler Status: Status of the Scheduler. To see the current status you should refresh the screen.
• Last update: Time and date of the last activation of the scheduler.
• Name of AS group: Shows the name of the used RFC server group. The group name ‘DEFAULT’ is
standard and uses all available application servers in the R/3 system. The RFC server group can be
changed via menu ‘Edit’ ‘Change AS group’. Please be sure that the here used RFC group is
available in RZ12. It is not necessary to maintain AS group ‘DEFAULT’ in RZ12.
• Number of Entries Displayed: Number of the registered destinations
© 2006 SAP AG
Columns explanation:
• Clt.: Client where the scheduler works for
• Dest.: Registered destination
• Type: Shows whether the destination is registered ( R ) or unregistered ( U ). You can change to
unregistered, if you first mark the queue and then select the Deregistration button.
• Max. connection: determine maximum work processes that are used in sending system (and target
system, if inbound is not set) to transfer the qRFC LUWs to the specified destination.
• Max. runtime: determine maximum time (in seconds) the scheduler needs to process/sort the
queues in one roundtrip. This is necessary for the scheduler to have a fair handling of a large number
of different registered destinations. New coming queues will not be included in the process until the
max time is reached or scheduler finish sorting/processing the current queues. When the max
runtime is reached, queues that are not yet sorted/processed will be process together with the new
coming queues.
• (In later Scheduler release, addition column is added) Act. Conn.: determine how many active
connections currently exist (active).
• Status: Status of the scheduler for a certain destination.
QOUT Scheduler STATUS

The following statuses are possible:
• INACTIVE: The QOUT Scheduler is not active.
• STARTING: The QOUT Scheduler is currently in the START phase.
• ACTIVE: The QOUT Scheduler is active.
• WAITING: The QOUT Scheduler waits for free DIALOG work process.
• SYSFAIL: A serious error occurred in the current operation of the QOUT Scheduler. Double-clicking
the status displays the respective error text. Other analyses of the syslog (SM21) or development
traces (dev_w*, dev_rfc* and dev_rd) may be required for the fault determination. After solving the
problem the QOUT Scheduler will not automatically restart the LUW of the registered destination. You
have manually reset the queue status (sysfail) of dedicated queues. This can be done in transaction
SMQ1.
• CPICFAIL: A communication error occurred in the current operations of the QOUT Scheduler. Double
clicking the statuses displays the respective error text. Other analyses of the syslog (SM21) or
development traces (dev_rd, dev_rfc* and dev_w*) may be required for the fault determination. In
this case a batch job will be scheduled as defined in sm59 (TRFC Options).
QOUT Scheduler MENU OPTIONS

In transaction SMQS; you have the following menu options:
Under Registration Table:
Reorganize Deletes all registrations. This does not affect the content of the tRFC/qRFC.
Under Edit, you have the following menu options:
Deregister To deregister the selected destination. The registered destination is not

processed by the QOUT Scheduler. The collected LUWs remain in the
queue. This enables you to collect single LUWs in the queue and analyze
them (for example, debugging a single LUW).
Exclusive A destination can be excluded from QOUT Scheduler processing, and is
therefore no longer processed by the QOUT Scheduler. The LUW is then
processed by the tRFC Manager at the time of the “COMMITWORK”. The
processing for LUWs of this destination then occurs on any application
server of the system.
Delete Delete the selected registration entry. You can also use the trash can icon in
the top left hand corner for the same purpose. The registered destination is
deleted. If a tRFC or qRFC still runs using this destination, the system
recreates the destination. Prerequisite for this is that the logon data must
be complete for the destination SM59: language, client, user, and password
must be entered. The target system must not be NONE or Space.
© 2006 SAP AG
Change AS group The Scheduler starts a server group for processing LUWs. The application
server group used is displayed in the third column. If the name of the
application server group has been changed (#DEFAULT), ensure that the
server group exists in transaction RZ12.
Activate Scheduler Start the Scheduler. The last start time is displayed in the second line in the
top left corner. The status in the top line changes throughout the runtime.
The status is now Active.
Change View Displays the status of the Scheduler.
Under Goto, you have the following menu options:
QRFC Administration Navigate to the menu for starting qRFC events.

QRFC Resources Jump to the information of resources availability of the corresponding
system
SMQR (QIN Scheduler)

Remark: To distribute resources on the receiving system an RFC server group can be set up. So it
is possible to exclude or include one or more application server to process the tRFC/ qRFC. As
default it is defined as server group DEFAULT (as shown in the screenshot below). This means that
all active application servers will be used to process the tRFC/ qRFC. For customizing RFC server
group, use transaction /RZ12.
This transaction is for displaying the state of the QIN-Scheduler and for register or deregister a queue. The
scheduler status could be seen at the top of the screen.
QIN Scheduler SCREEN
• Cl: Client where the scheduler works

• Queue name: Name of the inbound queue. Queue name * means all received queues will be
automatically executed by the QIN-Scheduler.
• Type: Shows whether the inbound queue is registered ( R ) or unregistered ( U ). You can change to
unregistered, if you first mark the queue and then select the Deregistration button.
• Mode: Specify the executing mode via parameter EXEMODE to 'D' or 'B' to execute the qRFC-LUWs
in this queue in a DIALOG-WP or in a BATCH-WP (WP: work process).
• Max. runtime: determine maximum time (in seconds) the scheduler needs to process/sort the
queues. New coming queues will not be included in the process until the max time is reached or
scheduler finish sorting/processing the current queues. When the max runtime is reached, queues
that are not yet sorted/process will be process together with the new coming queues.
• Local dest.: You can specify a "logic destination" (Parameter USERDEST) that has the Standard-
Destination "NONE" as reference. Using SM59 define client, user and language for this "logic
destination". The processing of these queues is then carried out with this logon data. If USERDEST
is not defined, you can carry out Queue processing under the user ID that currently describes a
registered queue (it does not need to be the same queue). The Logon data of a queue processing
may be different in this case.
• Attempts.: determine how many attempts the RETRY queues can be rescheduled (in batch job)
before permanently in status RETRY (in this case you need to restart the status again to activate the
queue).
© 2006 SAP AG
By double clicking the corresponding line you can reach the first sub screen of SMQ2 to see more details
about the inbound queue content.
QIN Scheduler STATUS
The following statuses are possible:
• INACTIVE: The QIN Scheduler is not active.
• BATCHJOB SCHEDULED: The QIN Scheduler has scheduled a batch job.
• STARTING: The QIN Scheduler is currently in the START phase.
• ACTIVE: The QIN Scheduler is active.
• WAITING: The QIN Scheduler waits for free DIALOG work process.
• SYSFAIL: A serious error occurred in the current operations of the QIN Scheduler. Double-clicking
the status displays the respective error text. Other analyses of the syslog (SM21) or development
traces (dev_w*, dev_rfc* and dev_rd) may be required for the fault determination.
• CPICERR: A communication error occurred in the current operations of the QIN Scheduler. Double
clicking the statuses displays the respective error text. Other analyses of the syslog (SM21) or
Development traces (dev_rd, dev_rfc* and dev_w*) may be required for the fault determination.
QIN Scheduler MENU OPTIONS

As of QOUT Scheduler but with Incoming queue instead of Outgoing queues.
/SAPAPO/CQ (SCM Queue Manager)

The SCM Queue Manager 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
example, 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.
SCM Queue Manager SELECTION SCREEN
Under screen section Systems:

• You can specify in which systems the check is to take place. If there’s no entry under System, your
own system and all systems entered in the table /SAPAPO/SYSDIR will be selected as default.
• Setting the indicator Expand nodes, means all selected systems will be directly analyzed and will be
displayed expanded on the subsequent results screen. By not setting the Expand nodes means the
system will only be analyzed when you choose it in the results screen. This can lead to a significant
improvement in the initialization of the results screen
• Setting the indicator Only Display Locked Queues, means only queues that are blocked or contain
errors will be displayed on the results screen. If you set the indicator Only Display Locked Queues,
this leads to a significant increase in performance on the following results screen.
• Setting the indicator Monitor Inbound Queues will also display the inbound queues on the result
screen.
© 2006 SAP AG
Under screen section Object types:

• You can specify the object types that are to be checked. By pressing F4 button you can choose the
object types for both APO publishing type and Plug-in publishing type (this means publishing type on
the R/3 side)
SCM Queue Manager EVALUATING THE RESULT

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.
Jump to application log Jump to SMQ1

for specific queue entry or SMQ2
Queue status
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.
A symbol tells you the queue status of the individual objects:
No queues with errors
Queues are recorded
Queues manually stopped
Queues with errors
Queues are being processed
Queue is waiting for another queue to be processed
Column explanation:
• Queue name: Name of the relevant queue
• 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.
• Error text: Description of the queue status
• User: Person responsible for the queue
• Function module: Function module concerned
• Date/time: Time of the queue error
• Waiting: Queue is dependent on other queues
/SAPAPO/C3 (Application Log)

For further analysis, the application log provides a detailed error message for queues with errors. The
application log can be called up in both SAP APO and SAP R/3 (transaction /CFG1). It records data transfers
that can be used to trace:
• Who initiated the transfer (user)
• When the transfer was made (time/date)
• What was transferred (data object and integration model)
Prerequisite: Switch ON the system logging (/SAPAPO/C41) which also provides different level of logging
(from NO logging activity until DETAILED logging).
© 2006 SAP AG
Application Log SELECTION SCREEN
Selection screen explanation:

• On the selection screen set Object as CIF (to analyze only CIF log messages). For more focus
analysis you can also specify the sub-object (press F4 button to get the list of sub-object and the
explanation). Caution: For performance reasons, in the case of the initial transfer and change
transfer of master data, the entries are grouped together under the sub-object INITIAL.
• The transaction ID of the sending system (field TID in the qRFC row of the qRFC monitor of the
sending system) is used as the key for error messages. Using this number, you can display all
messages for this qRFC call in the target system. Enter the number of the transaction ID in the field
External ID. This displays all messages for the call of this specific transaction ID.
• To show only important error message select the indicator only very important logs on the Log class
section. This will definitely give a faster result.
Application Log DISPLAY SCREEN
Clicking on the triangular sign will open further logs

details. Clicking on the problem class (or press the
glasses button) will open problem’s explanation, which
is displayed as message text on the bottom part of the
screen. Clicking on the message text (or press the
glasses button) will open a pop up window for further
detailed error message.
Remark: you can also use transaction /SAPAPO/OM10
to get more explanation on the meaning of the return
code error.
© 2006 SAP AG
/SAPAPO/CC (CIF cockpit)

Data Transfer Monitoring Using the CIF Cockpit
You can use the CIF cockpit (SAPAPO/CC) to centrally monitor the data transfer between an SAP APO
system and all the connected SAP R/3 systems and to get a quick access to CIF relevant settings of each
system. You gain a quick cross-system and cross-client overview of the following areas:
• Monitoring
Here you get information about the current situation of the data transfer and the transfer load.
• Settings
Here you get information about Customizing settings that are relevant to the transfer.
If required, you can jump directly from the display to the relevant transaction where you can get detailed
information or rectify a problem.
To call the CIF cockpit, choose from the SAP Easy Access screen for mySAP Supply Chain Management:
Advanced Planning and Optimization → APO Administration → Integration → Monitor → CIF Cockpit
(transaction /SAPAPO/CC).
If you enter the transaction the system at first reads a profile which determines the amount of data to be read.
This profile also defines from which R/3 systems data is collected. You can enter the profile after you have
started the transaction through the menu by choosing Settings -> User Profile. The profile also defines
selection criteria which are used to collect the data from the different systems.
The entry screen of the CIF cockpit displays the navigation tree on the left side with all the considered R/3
systems plus the APO system and all the CIF channels between these systems as a node. You can double-
click on a node and detailed information are displayed in the right side of the screen. You can also open a
node to see additional information categories.
You can use the icon Details to go to the relevant transaction where the settings can be maintained. If this
icon is missing, there is no transaction for this information. If the icon is grayed out, you do not have
authorization for this transaction.
Prerequisites
To use the CIF cockpit, you need an RFC user and dialog authorization for every connected 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 of SAP SCM and SAP R/3 → Basic Settings for Creating the System Landscape → Assign RFC
Destinations to Various Application Cases.
Settings Features:
© 2006 SAP AG
In the ‘Settings’ area of the CIF cockpit you find the following information:
• SAP APO system
o Distribution Settings
Object specific settings for publication are read from the customizing (SAPAPO/CP3)
o Enhancement Projects
all user-exits (active and inactive) are shown (not only CIF related)
o under further settings
user parameter: user specific parameter from /SAPAPO/C4 are shown
strategy profiles: gives an overview of the existing strategy profiles used in PPDS for
scheduling
SNP settings: shows the setting regarding the transfer of SNP orders to an OLTP
system
• SAP R/3 system
o Block Sizes of Initial Data transfer
shows the settings regarding the filter and selection block size maintained in CFC3
o Enhancement Projects
All user-exits (active and inactive) are shown (not only CIF related)
o Further settings
Additional CIF related settings regarding change transfer of master data, initial data
transfer and change transfer for Resources. All of these settings are maintained in the
customizing transaction CFC9 in the R/3 system
• Transfer from SAP R/3 system to SAP APO system
o Integration model
Provides a list of all integration models (active and inactive) in the connected R/3
system with destination to the APO system. The list contains also the information about
the number of specific objects in each model.
o qRFC
Information about the installed qRFC version in the R/3 system and its supplement is
given. Also the queue type (inbound or outbound) is shown and the overall number of
resources (dialogue processes) and the number of resources which are reserved for
qRFC only.
o Inspection Lots
Setting regarding inspection lots is shown (transfer inspection lots or not)
o Returns
Setting for transferring SD returns from R/3 to APO (returns and return deliveries in
SAP APO Transportation Planning/Vehicle Scheduling (TP/VS)) => release information
to be added
• Transfer from SAP APO system to SAP R/3 system
o Distribution Criteria
Display of the distribution definition (maintained in customizing)
o qRFC
Information about the installed qRFC version in the APO and its supplement is given.
Also the queue type (inbound or outbound) is shown and the overall number of
resources (dialogue processes) and the number of resources which are reserved for
qRFC only.
o Error Handling
The type of error handling for CIF queues is shown (post processing records yes/no)
which is maintained in customizing in the maintenance transaction for ‘Assignment of
Logical System to Business System Group’.
© 2006 SAP AG
Monitoring Features:
In the ‘Monitoring’ section of the CIF cockpit you will find the following information:
• SAP APO system (in the example screen shot from system SMACLNT800)
information about installed software components, release and patch level
• CIF Background Jobs
you will get the information about the status of jobs which are scheduled in the APO system.
Only those jobs are shown for which an entry has been made in the user profile of the CIF
cockpit. Every type of program can be entered here, not only CIF related programs.
• Application Log
the application log of the APO is read according to the settings in the profile
• Comparison of Routing information (independent from target system)
unnecessary routing information from table /SAPAPO/CIFBEFCR are shown (look-up
information without a corresponding entry in table /SAPAPO/CIFLOOKU)
If there are entries shown: note 567601 provides a correction report to delete those entries.
• SAP R/3 system (in the example screen shot: form system GSBCLNT801)
information about installed software components, release and patch level
o CIF Background Jobs
you will get the information about the status of jobs which are scheduled in the R/3
system. Only those jobs are shown for which an entry has been made in the user profile
of the CIF cockpit. Every type of program can be entered here, not only CIF related
programs.
o Application Log
the application log of the R/3 system is read according to the settings in the profile
o Superfluous Filter Objects
The number of superfluous filter objects is shown for every type of filter object. From
the display of these objects you can jump to the corresponding R/3 system into the
report RCIFIMDL which can be used then to delete these filter objects (for more
information on this report see also note 593355).
o Inconsistent APO Indicators

This check is showing the number of materials for which the APO indicator (field
APOKZ in table MARC) is not active although these materials are part of an integration
model, or those materials which contain this indicator although they are not part of an
integration model. You can jump from here to the connected R/3 system and do the
necessary corrections with the report RAPOKZFX
© 2006 SAP AG
o Existing ALE-Change Pointers

Shows the unprocessed change pointers of the corresponding R/3 system.
You can jump to the connected R/3 system into the transaction CFP1 and process
these change pointers.
• Transfer from SAP R/3 system to SAP APO system

(in the example screen shot from system GSBCLNT801 – SMACLNT800)
o qRFC
shows the Queue Monitor of the APO system
o Post processing Records
Shows the existing post processing records in the APO system
o Integration Model Consistency
Checks the runtime version of integration models in the connected R/3 system
o Performance/Applications
Shows data concerning the data volume and the performance on the timely basis you
have 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).
The measurement of CIF performance data has to be activated explicitly using
transaction /ASACT, flag parameter ‘SAP-Functions’.
With this function, the runtime is measured inside the CIF inbound function modules
itself (e.g. /SAPAPO/CIF_ORDER_INBOUND). The results can be evaluated in the CIF
Cockpit with different granularity (day, hour, minute) depending on the settings made in
the user profile.
• Transfer from SAP APO system to SAP R/3 system

(in the example screen shot: SMACLNT800 – GSBCLNT801)
o qRFC
shows the Queue Monitor of the R/3 system
o Post processing Records
Shows the existing post processing records in the R/3 system
o CIF Comparison/Match for Transaction Data
Shows the saved results of a delta report run (according to the settings in the profile), if
there are any.
o Comparison of Routing Information
Her you will get superfluous entries in table /SAPAPO/CIFLOOKU based on entries
maintained in the distribution definitions /SAPAPO/CIFDISTR (transaction
/SAPAPO/CP1. All entries are determined where a distribution definition does not exist
anymore (entries related to obsolete logical systems, entries related to obsolete GUIDs
in liveCache).
© 2006 SAP AG
/SAPAPO/CPP Error Handling

General Information
The data transfer between SAP R/3 and SAP APO is based on the qRFC technology.
This means that every change to an object (e.g. production order, purchase order, stock) is sent to the
corresponding target system via remote function calls (RFC) and these RFC’s are processed in the order in
which they were sent to the target system. For this purpose the RFC calls related to the same object are
stored in a queue where the name of the queue is derived from the object which has been changed in the
source system.
If several objects are changed simultaneously (in one logical unit of work = LUW) then these changes also
have to be done simultaneously in the target system (within one LUW).
Therefore every entry of a queue contains also an identifier for the LUW in which it was created. This identifier
is the transactional ID (TID). Several entries with the same TID are related to the same LUW and have to be
processed together.
In the case that one qRFC call is failing due to an error this queue will remain in the inbound/outbound with
status SYSFAIL.
Every RFC related to the same object (which means: within the same queue) and which has to be processed
after the failed RFC will remain in the inbound/outbound in status waiting until the faulty queue is processed.
Additionally also those queues which are in the same LUW like a queue with the status SYSFAIL or WAITING
will remain in the inbound/outbound until the first faulty queue is processed successful.
By this mechanism a few faulty queues can cause the blockade of the processing of a huge amount of
dependent queues.
The next screen shot shows an example for a queue jam which was created by the following steps:
• Sending production order 600003371 from R/3 to APO fails due to unknown error
-> queue CFPLO00060003371 created with SYSFAIL
• Creating a confirmation on production order 60003371 with automatic goods issue for the component
HP-ROH01 (triggers 3 Queues in one LUW)
-> additional entry in queue CFPLO000060003371 created and additional dependent queues
CFSTKLHP01HP-ROH01 and CFRSV000060003371 (for updating stock and reservations in SCM)
with status ‘WAITING’ (for queue CFPLO000060003371)
• Creating a confirmation for a second order (60003372) with automatic goods issue. This order also
has the same component as the first order and therefore creates a second entry in the already
existing queue CFSTKLHP01HP-ROH01
-> all queues which are in the LUW for order 60003372 stay in status ‘WAITING’ and the complete
order is not send to the receiving system
Example for queue jam without activated CIF error handling
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 and the above shown situation should not occur anymore.
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.
© 2006 SAP AG
Prerequisites
CIF error handling has to be switched on in IMG or in transaction /SAPAPO/C2 (Post processing, no splitting
of LUWS). By default it is switched off.
It is only necessary to switch it on for the SCM system. CIF post processing always works for both directions.
Restrictions
CIF error handling is not available in the following situations, which means that CIF queues hang when errors
occur:
• At the initial data transfer
• At the transfer of master data (initial and change transfer)
• At short dumps
• When the target system or the liveCache is unavailable
• When an object is locked in the target system (as before for the repetition of the transfer)
• If errors occur in customer exits or BAdIs that run in CIF inbound function modules during integration
You can find information about restrictions to CIF error handling when using certain applications and functions
in SAP Note 602484.
Working with Post Processing Records

The post-processing is exclusively started in the SCM system using transaction to /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)
The next picture shows the result screen from where the processing of the post processing records can be
triggered.
The screen is divided into 4 areas: on the left side the navigation tree, on the right side the work list of post
processing records on top, then a list with objects for which the re-processing was started in the current
session and on the bottom a list with messages regarding already processed records.
By clicking on one of the entries in the navigation tree you see the related post processing records in the work
list on the right side (in this case 4 records that were created during the CIF transfer from the system SMA to
GSB).
Note that the ‘Time of Error’ shown for the post processing record is shown in UTC (which might be different
from the system time).
The status of the record is indicated by the color of the line in the work list.
© 2006 SAP AG
Records in status 1 (not processed) are shown in light blue, status 2 (already processed) is shown in green
and status 3 and 4 ( status obsolete, set manually or automatically by the system) is indicated by the color
grey.
Records can also be marked as obsolete in the work list or the obsolete indicator can be withdrawn from here.
The reprocessing can be triggered by pressing the button for sending the record to APO or the
button for sending to R/3. The reprocessing can only be successful if the error cause for writing the
post processing record has been solved. You can check the reason by analyzing the application log. The
application log for every post processing record can be accessed by the appropriate button on the top of the
work list. If you observe any problems in using this functionality please check note 799647.
Reprocessing a post processing record means that the object for which the error occurs is read once again
from the source system and send to the target system with the actual data. By this way all changes which
were made on this object since the post processing record was written are taken into account.
Once the reprocessing is triggered the chosen records are moved from the work list to the list beneath:
Objects processed in this session.
The refresh button has to be used here to get the information if the reprocessing was successful or not (Note
that the reprocessing will never finish if you have maintained in your user settings that queues are only
recorded. Then in addition you have to execute the queue manually in the queue monitor).
If the reprocessing was successful the record becomes the status 2 (already processed). The record is not
deleted automatically from database, it has to be reorganized by the report
/SAPAPO/CIF_POSTPROC_REORG.
Sending objects from R/3 to APO

An additional post-processing record is written if a post processing record for this object already exists and the
error in the receiving system still occurs.
If the error does not occur anymore then the object is transferred successfully to the receiving system but the
existing post processing record remains in status 1 (not processed).
Sending objects from APO to R/3

If the transfer of this object proceeds without any error then existing post processing records for this object will
become the status 4 (obsolete).
If the transfer fails then a new post processing record is written and the status of existing post processing
records is changed to 4 (obsolete).
As a result only one post processing record per object with status 1 (not processed) can exist in this
processing direction.
It is possible to set up the system in a kind that automatically a message is sent to a recipient if post
processing records are created (CIF Post processing Alert). The customer can schedule the program
/SAPAPO/CIF_POSTPROC_ALERT as a job to achieve this. Only for those records which are created new
since the last run of this job a message is sent to the recipient.
It is also possible to start the transaction /SAPAPO/CPPA to create a variant for this program or to trigger the
sending of these messages manually.
It is recommended to schedule this program on a regular basis (e.g. daily).
Note that activating CIF error handling leads to a different approach to the monitoring of integration. If CIF
error handling is not active, you first call the SCM queue manager and then the CIF comparison/reconciliation
of transaction data.
If CIF error handling is active, you first check whether post processing records exist, then call the SCM queue
manager, and then the CIF comparison/reconciliation of transaction data.
In case of performance problems based on a high reading time on table CIFERRLOG please see the
recommendation given by note 802980.
Reorganizing Post Processing Records

Post processing records that have been processed or that have been set to obsolete (manually or
automatically by the system) are not deleted automatically by the system. They are still on the database
(tables /SAPAPO/CIFERRLG in APO and CIFERRLOG in R/3) and have to be deleted by using the report
/SAPAPO/CIF_POSTPROC_REORG (transaction /SAPAPO/CPPR is similar to this report).
You can only delete records with the following (processing) status:
2 (Processed)
3 (Obsolete set manually)
4 (Obsolete set automatically by the system)
© 2006 SAP AG
You have to enter a value for the target system (the R/3 system). If you don’t see any values in the F4-Help for
this field, then the CIF error handling is not switched on in the customizing (see also note 652885).
On the bottom of the selection-screen you see the flag ‘Select Data from R/3’. This flag is activated in
standard and has the effect that reprocessing records in R/3 are also considered.
In certain scenarios (e.g. APO system is only used for GATP) the activation of this flag will cause the
termination of this program because in such scenarios there is no valid RFC connection defined from APO to
the R/3 system. In these cases the flag has to be deactivated.
You can use a retention period (in days) for the selection of the records which means that only those records
are selected which are older then the given period.
The report can be used for deleting post processing records and also to change the processing status to 3
(Obsolete set manually). But it is not possible to change the status to obsolete and delete the record in one
step.
It is recommended to define a variant for this report and run it on a daily basis as a background job.
© 2006 SAP AG
Chapter 3: Performance and Configuration

Generally speaking, SAP Core Interface consists of three layers:
3. qRFC (Queued RFC)

===========================
2. RFC; tRFC (Transactional RFC)
===========================
1. CPI-C and Gateway,
To optimize the performance, correct configuration for all layers is needed. This chapter discusses the definition
and recommendation on how to set the parameters, important jobs that have to be scheduled, and other tips and
tricks to optimize CIF performance.
During troubleshooting, these setting recommendations should be verified and exercised to match customer
conditions.
Technical System Settings and Customizing

Optimal settings of RFC and Gateway parameters
Parameter settings as per Note 384971 must be applied to all connected systems. Those parameters are as
explained in the table below. In particular, the number of dialog work processes used by qRFC/other requests at
the sending side.
Parameter Meaning Recommended
rdisp/tm_max_no Number of connections to an instance, including both 2000
dialog users and interfaces.
rdisp/max_comm_entries Number of communications from and to an instance 2000
(not including dialog users).
gw/max_conn Number of logical connections to a gateway, that is, 1000 (can be increased to
the number of connected gateways and external 2000 if necessary)
programs.
gw/max_overflow_size Maximum swap space for CPIC requests in the 25000000 (can be
gateway, uses swap space on the disk, will be used increased to 100000000)
from SAP Basis Release 4.6D instead of the Please note for AS/400:
gw/max_shm_req for all TCP/IP connections. for releases <= 4.5B, this
parameter can be set to a
maximum of 16000000.
gw/max_shm_req Maximum number of CPIC requests in the gateway 400
that are in the shared memory. From Core 4.6D it will
only be used for SNA connections (for example R2),
it will be ignored everywhere else. If the system does
not have any SNA connections, the parameter does
not need to be set as from Release 4.6D.
rdisp/appc_ca_blk_no TCP/IP communication buffer. Warning! This at least 500, if there is
parameter uses space in the shared memory. Pay enough space in the
attention to the operating system dependent shared memory, then set
requirements for some of the 32-bit operating to 2000 for interface-
systems regarding pool size and shared memory intensive instances.
segments and/or the size of the entire shared
memory area (see Note 103747, Note 79478 for
AS/400 among others). You can view the current size
of the key containing the rdisp/wp_ca_blk_no by
using Transaction ST02, Detail Analysis menu,
Storage, and the "Shared Memory Detail" button.
Look for key 3, Dispatcher Communication Areas.
Here you can find the current size of key 3 (which
contains the rdisp/appc_ca_blk_no). Now calculate
the value of key 3 after increasing the
rdisp/appc_ca_blk_no, like this: (New value
rdisp/appc_ca_blk_no) - (previous value
rdisp/appc_ca_blk_no from instance profile) = (delta
from increase) (Delta from increase) * 40KB = (value
in KB that key 3 is increased by)
rdisp/wp_ca_blk_no DIAG communication buffer 1000 (300 for AS/400 or
Warning! This parameter uses space in the shared according to Note 79478)
memory (see above). Like disp/appc_ca_blk_no this
is also in key 3. The size of key 3 can be determined
© 2006 SAP AG
in Transaction ST02 as described above. The value

key 3 increases by after the increase of
disp/wp_ca_blk_no is calculated like this: (New value
rdisp/wp_ca_blk_no) - (current value
rdisp/wp_ca_blk_no from instance profile) = (delta
from increase) (Delta from increase) * 32KB = (value
in KB that key 3 is increased by)
rdisp/rfc_use_quotas, Switch to activate or deactivate the resource default = 1, activated (for
determination both parameters)
Valid values: 0 / 1
You should NEVER
change the default value.
If the parameter has the
value 0, then you can no
longer work with the
parallel RFC since no
server can be determined
for the next RFC.
rdisp/rfc_max_queue Quota for the full utilization of the dispatcher request Default: 5 (percent)
queue. When the number of pending requests Valid values: 0 – 100
exceeds this quota, no resources are given to the
calling program.
The size of the dispatcher request queue is set by the
profile parameter rdisp/elem_per_queue.
rdisp/rfc_max_login Quota for logon to the application server. When the Default: 90 (per cent)
total number of logons exceeds this quota, no further Valid values: 0 - 100
resources are given to the calling program.
The maximum number of logons is set by the profile
parameter rdisp/tm_max_no.
rdisp/rfc_max_own_login Quota for the number of own logons to the application Default: 25 (per cent)
server. When the number of own log-ons exceeds Valid values: 0 - 100
this quota, no further resources are given to the
calling program.
The number of logons is set by the profile parameter
rdisp/tm_max_no.
rdisp/rfc_max_comm_entries Quota for the number of used communication entries. Default: 90 (Percent)
If the number of used entries exceeds this quota, no Valid values: 0 - 100
resources are given to the calling program.
The number of communication entries is set by the
profile parameter rdisp/max_comm_entries.
rdisp/rfc_max_own_used_wp Quota for the number of dialog work processes used Default: 75 (per cent)
by the user. If the number of work processes Valid values: 0 – 100
surpasses this quota, no resources are returned to
the caller. This parameter is only checked in the
dialog. It is ignored in the background or in the
update.
The number of dialog work processes is set by the
profile parameter rdisp/wp_no_dia.
© 2006 SAP AG
rdisp/rfc_min_wait_dia_wp Quota for the number of dialog work processes Default: 1

that should be kept free for users. When no more Valid values: 1 - (total
dialog work processes are free, no resources are dialog work processes)
given to the calling program.
The number of dialog work processes is set by
the profile parameter rdisp/wp_no_dia.
If enough dialog work process are configured
you must increase this value.
The dispatcher controls the transfer of RFC
requests. The RFC request is only transferred to
a dialog work process if the defined number of
free dialog work processes is guaranteed.
Otherwise the request is stored for later
processing in the dispatcher queue. You must
make sure that the value of parameter
rdisp/rfc_min_wait_dia_wp is always smaller
than rdisp/wp_no_dia. Otherwise no RFC
requests can be processed.
rdisp/rfc_max_wait_time Maximum number in seconds that a work
process is asleep if it does not receive any
resources. In some cases the work process is
asleep for a long time although resources have
been available in the meantime. This parameter
is only available as of a certain patch level.
Waiting time in seconds is set by profile
parameter rdisp/rfc_max_wait_time
rdisp/rfc_check This parameter controls the check as to whether The check can be set to
sufficient dialog work processes are free for various levels:
processing asynchronous RFC calls.
The number of available dialog work processes Level 0: no check
depends on the number of free dialog work Level 1: start of all
processes and the number of work processes to asynchronous RFCs is
be kept free for dialog application (see monitored
rdisp/rfc_min_wait_dia_wp ).
If no free work process is available at that point, With 4.6D kernel patch
the request is put into a queue and processed at level 1473 and 6.20 kernel
a later time. patch level 711
respectively, the following
values were added:
Level 2: In addition to
level 1, all RFCs which
were started from
asynchronous RFC
sessions are monitored.
This also includes
synchronous RFCs. To
allow applications with a
lot of RFC calls
to run on this level, the
number of dialog
processes usable for
RFC may have to be
increased
Level 3: All RFCs
(synchronous and
asynchronous) are
monitored.
These settings are only effective on the receiver side IF the CIF communication has been switched to inbound.
Please also refer to SAP Note 74141 for setting the above parameters.
Latest qRFC version

To ensure best performance customers should use always the latest qRFC version with the most recent
supplement in both - R/3 and APO (the current-latest version is 6.20.045. with supplement 11). See Note 438015.
Below are some notes relevant to qRFC processing performance (within supplement 11).
© 2006 SAP AG
SAPNote Description
697884 Queues in SMQ2 are not processed
744869 Performance Optimization Inbound Scheduler
742950 Performance Decrease on Oracle DBs
R3 Plug-In version
It’s relevant for data integration capability between R/3 and APO. For releases of R/3 and ECC 5.0, it‘s delivered
in R/3 Plug-in (PI) component. The last development of R/3 plug-in is 2004.1 SP 10. For releases > = ECC 6.0,
it‘s delivered in SAP application component (SAP_APPL). For further information regarding this, please refer to
service.sap.com alias ‘r3-plug-in’.
Queue type (Inbound - Outbound)

The customizing setting (R/3: until and including PI Release 2002.1: transaction /CFC1, as of PI Release 2002.2:
Integration with Other mySAP.com Components => Advanced Planner and Optimizer (SAP APO) => Basic
Settings for Settings Up the System Landscape => Set Target System and Queue Type, APO: transaction
/SAPAPO/C2) determines whether the qRFC processing is controlled by the sending (outbound) or receiving
(inbound) system.
Outbound queues are set by default and should be used. To avoid 100% utilization of work processes, the QOUT
scheduler (available as of qRFC version 42, see Note 400330) should be set up. It is able to limit the number of
work processes used in the sending system, but not in the receiving one.
If severe load balancing problems occur, inbound queues can help, because the scheduler is running on the
processing system and therefore better informed about system resources. In general, the conversion to inbound
queues leads to a better load distribution on the receiving side and consequently improves overall performance
and system availability.
In consequence of the conversion from outbound to inbound be aware that the following things have to be
adjusted:
• Monitoring (SMQ2 instead of SMQ1)
• qRFC alert (/SAPAPO/CQINW instead of /SAPAPO/CW)
• Jump from queue entry directly to application log
Resource Distribution
Use transaction RZ12 to define a group of application servers and their DIALOG work processes that is allowed to
use a QIN/QOUT scheduler. The group name must be assigned to the respective QIN/QOUT scheduler using
SMQR/SMQS. Doing so the qRFC calls are processed on a separate instance without disturbing dialog users.
Screen view of transaction /RZ12
Click on one of the line will open a detail view

of instance resources configuration.
Reorganization of Quickly Growing/Shrinking Tables (valid for Oracle database only)

There are numbers of table involved in integration that are growing and shrinking very quickly. Maltreatment of
these tables can cause performance problems. Below are some notes that describe and provide solutions for
such.
• Note 371068 describes and provide solutions of such problems of: Incorrect DB access paths because
of Cost Based Optimizer; Unfavorable table indexes and programming in qRFC; several unnecessary
entries in the tRFC/qRFC tables.
• Note 407125 and 454912 describes and provide solution for tables which has Storage quality problem
which causing the indexes associated with these tables degenerate leading to unnecessarily complex
and slow database accesses.
• Note 375566 describe and provide solution for problem with many entries in RFC related tables, which
causing poor performance during the tRFC/qRFC processing.
• Starting qRFC supplement 11, tRFC tables needs to have statistics to be created once and then frozen
(using report RSTRFCCS). Please refer to SAP Note 742950 for further information.
© 2006 SAP AG
• Note 328355 describes and provides solution of long access to tables relevant to change pointer
(BDCPV, BDCP, BDCPS), due to storage quality index and table size.
• Note 436687 describes and provide solution of long access to integration model tables (CIF_IM*).
• Starting Oracle 10.G, Rule based optimizer is no longer exists. Due to this, SAP provides a predefined
statistics for those aRFC and tRFC tables. See SAP note 932975
Initial Supply
The initial supply of master and transaction data enables the planning in APO and has to be performed once
before Go Live. Once it is completed only deltas are transferred which is usually not a problem.
Recommendations that require a repeated initial load should be avoided (e.g. initialization of liveCache). Factors
influencing runtime are specified in the following subchapters.
Data Providers in R/3

Experience has shown that depending on the object type (integration model) runtime of initial supply can be very
different.
Usually fast:
• Material and location master data
• Stocks
• Purchase orders and requisitions
• Reservations
• Independent requirements (PIRs)
• Classes and characteristic master data
Usually slow:
• Sales orders including SD scheduling agreements
• PPMs
• MM scheduling agreements, contracts, purchasing info records
Be aware, that the runtimes highly depend on the customer’s data structure and that there is no rule of thumb in
this area.
Settings of Object Parameters

The object parameters Filter Block Size and Select Block Size (transaction /CFC3) are influencing the runtime of
initial supply. All parts of the initial supply (selection in R/3, data transfer via qRFC, ABAP processing in APO,
processing in liveCache) are sensitive to the amount of data to be processed. If the amount is too large, various
errors might occur, e.g. time outs and liveCache errors. To avoid such problems, the object parameters should be
set to optimal values depending on the customer situation.
‘Obsolete’ Data in R/3 System

Only planning-relevant data has to be integrated/transferred to APO. That means, during initial supply the system
has to separate those data out of the complex data structures in R/3. That could cause long runtime when
selecting data, in particular for the following objects:
• Sales orders: Sales orders with open requirements (driving table is VBBE) have to be separated from
completed ones. That requires extended readings on tables that contain SD documents, e.g. VBAP.
• Production/Process orders: Orders with status DLFL (deletion flag indicator) will not be sent to the
APO system. This status is the most effective way to reduce CIF traffic and the creation of unnecessary
production orders in APO.
Orders with status TECO are sent to the APO system with method D (delete), so they are part of the CIF
traffic but will not be created in the APO system. This status helps to reduce the amount of data created
in APO but it does not reduce the CIF traffic during initial load.
Orders with status LKD (locked) or with the final delivery flag are fully taken into account during the initial
load, so these status/flag do not help to reduce the data traffic.
• Purchase orders/Purchase requisitions: Orders with ‘delivery completed’ are transferred.
In R/3 it is a general recommendation to archive completed data in regular intervals in order to keep the system
performance optimal. Having a huge amount of old data leads to the following consequences:
• R/3 system performance decreases in general
• Integration with APO is slowed down
For that reason, the Best practice in easy words is: Archive old/completed data BEFORE installing APO.
Activated Application Log Writing

Application log is used by various applications and consists of several tables.
• BALHDR, BALHDRP: Log header with a unique log number: Information that clearly indicates who
triggered which event using which transaction/program
• BALM, BALMC,…: Log messages with status: Number of entries depends on user settings (up to and
including R/3 Release 4.6B)
• BALDAT: Log messages and status: Stored in compressed form (as of R/3 Release 4.6C)
© 2006 SAP AG
When transferring data via CIF, logs are recorded with object CIF (Core interface application log object). All logs
are given an expiry date by the application itself (for CIF it is 1 week in the future). After the expiry date is passed
logs can be deleted from the database. In order to keep performance optimal it is highly recommended to
schedule the appropriate delete jobs regularly/daily. The following reports are available:
R/3 APO
CIF application logs RDELALOG /SAPAPO/RDELLOG
Other application logs SBAL_DELETE SBAL_DELETE
/SLG2 /SLG2
The amount of recorded logs/messages depends on the following:

• User setting for the CIF (transaction /CFC2 respectively /SAPAPO/C4): When logging is set to Detailed,
a high number of messages are written into BALM/BALDAT, which slows down performance.
• Configuration of CIF application log (transaction /CFC6 => choose function module, as of PI Release
2002.2 via customizing per object type*): A message is recorded for each field chosen in the
configuration. A high number of fields to be logged slows down performance and causes initial supply to
run “eternally”.
*) Integration with other mySAP.com components => Advanced Planner and Optimizer => Basic Settings for the Data Transfer
=> Configure Application log
For more information on deletion of logs, see Note 195157.
Performance Improvement by Parallel Initial Supply

It is possible to run initial data supply in parallel. There are 3 types of parallelization possible:
• Activate several integration models at the same time (more then one initial supply runs at the same time)
• Select data from R/3 in parallel work processes
• Process the queues in APO in parallel work processes
The following points have to be considered carefully when deciding on parallel supply:
• System load R/3 <=> APO: Does APO has to ‚wait‘ for data extraction in R/3? If so, run selection in
parallel to improve performance.
• Filter block size and maximum number of work processes: Larger blocks result in fewer blocks per filter
object type => fewer work processes can run in parallel Smaller blocks allow higher degree of parallel
runs => fewer objects transferred to APO per block
• Setup and size of integration models: The parallel selection of data is recommendable for the following
object types: Sales orders, Production/Process orders, PPMs
Attention: liveCache locks can occur when separate APO processes try to access liveCache objects referring to
the same material/plant combination (pegging area). Typical object types causing locks are: Production orders
with operations and components, subcontracting purchase requisitions/orders, stock transport orders/requisitions.
To avoid locks it must be ensured that
• Only different material/plant combinations or resources are processed in parallel
• Identical material/plant combinations or same resources are run sequentially
Usage of ALE Change Pointers

During transfer of master data, the change pointers are evaluated for the different message types. Change
pointers are stored in the database view BDCPV (tables BDCP and BDCPS) and marked as ‘Processed’ once
they are transferred. To prevent them from taking up too much memory space, you must periodically call up report
© 2006 SAP AG
RBDCPCLR (transaction /BD22) to delete them. If obsolete and processed change pointers are not deleted
periodically, performance could slow down significantly.
Online Transfer
The Online transfer means the data exchange of transaction data between R/3 and APO. Factors influencing
runtime are specified in the following.
Design of The Integration Models

Traditionally, if data is changed in R/3 it has to be determined whether data needs to be sent to APO and if so,
what data needs to be send. To do this the system checks whether the object is included in one or more active
integration models and to which system the object has to send. So far, for each of these checks, the database
table CIF_IMOD has to be read which is quite performance intensive. To improve performance the new table
CIF_IMAX is used with the following advantages:
• Buffered (thus not database access necessary)
• Only one entry per object type and target system (optimized access and compressed data)
The runtime version is adjusted after each activation or deactivation of integration models. To check data
consistency between the runtime version and integration model, the report with the Consistency Check indicator
should be scheduled regularly. See online documentation of report RCIFIMAX for closer details.
Detailed 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. The records in the application log are not
automatically deleted by the system. To prevent the database from overflowing, the records have to be deleted at
regular intervals. See section ‘Application log writing’ under Initial Supply for more information.
Publish Planning Results from APO to R/3 (In-House Production)

Collect changes
In case of large amounts of planning results as well as in scenarios with long time planning runs - with the
typically behavior that the successor run overwrites results (events) of the predecessor - the entire planning run
should be performed with a certain user who is sending the events periodically (Collect Changes). After finishing
the planning run the publishing has to be performed explicitly (transaction /SAPAPO/C5 or report
/SAPAPO/RDMCPPROCESS).
See Note 695534 how to apply this recommendation.
Optimized block size

The block size used for publishing planning results from R/3 to APO should be set to an optimal value using
transaction /SAPAPO/CP3. Low values generate a high number of independent queues (LUWs). Though these
can be processed in parallel, they may cause a very large load on the receiving R/3 system. That is, many dialog
work processes are occupied when publishing the results of planning runs. Moreover, the runtime of publishing
might get worse. High values generate large LUWs. If one object in this LUW encounters an error, the entire LUW
is not transferred to R/3. This may cause a significant serialization effect and prevent other LUWs from being
transferred. For information refer to Note 446866.
Tests should be performed to determine the optimal block size (default value 100).
Serialization Effect
As explained in the first Chapter, serialization effect can severely restrict data transfer and some data cannot be
transferred at all. Consequently, there are inconsistencies between source and target system.
Consequences:
• Data is completely missing in the target system
• Incorrect of incomplete transfer of data changes due to not transferred data
• Transfer of obsolete data in case queue entries are transferred later after they have been parked/saved
For that reason, it is of utmost importance to rectify incorrect queue entries in time. Monitoring concept/handbook
suitable to the Business Process (BP) is absolutely necessary and has to be established before go live involving
system administration AND business department as well.
The following Notes describe procedures how to prevent queue blockades:
© 2006 SAP AG
524419 Procedure for large-scale queue jams

555130 Restarting inbound queues and automatic saving (Released Internally only)
However, these procedures should only be used in emergency cases! Since they cause entire LUWs not being
processed inconsistencies are likely to occur between source and target system.
The serialization effect can be suppressed for the most part if the new CIF error handling is used. Please refer to
chapter /SAPAPO/CPP (Error Handling).
"Hanging" and "Traffic Jam" Problems

The serialization effect can easily lead to a very high number of queue entries (up to 10000 and more!). In
particular, if the data is heavily nested (same LUW is in a high number of queues) few blocked queues might
block many others. The qRFC tables will grow and the resulting "traffic jam" slows down performance.
“Traffic jams” are likely to occur, if transactions touch a lot of objects at the same time resulting in a lot of LUWs
containing qRFCs with the same queue names. The scheduler is busy scanning the queues to determine the first
LUW to be processed (serialization).
Because of the dependencies and the growing number of entries this step takes more and more time and results
in plenty sequential reads of table TRFCQIN/TRFCQOUT. Though sufficient WP’s are available for qRFC
processing only few are busy and the qRFC processing is not really going forward.
Most of the time, the scheduler remains in WAIT status. This problem mainly occurs during post GI in R/3. In this
case, stock updates are transferred (CFSTK*) combined with changes in deliveries/customer orders (CFSLS*)
and often reduction of PIRs (CFFCC* / CFMAT*). Because stock updates are working with absolute values, the
postings must be performed in the correct chronological sequence anyway. If GIs are performed more or less
parallel (e.g. delivery due list in R/3) the posting in APO is serialized by using only few (one) work process that
processes one LUW after each other. This problem cannot be solved by technical settings, but by organizational
measures.
Another reason for “traffic jams” is that APO system itself processes the data not fast enough. That is the data is
sent from R/3 in a reasonable time, but the bottleneck occurs in the APO inbound while posting the data. There
might be various reasons, e.g. long-running COM routines. In opposite to the situation described before all work
processes are occupied most of the time. “Traffic jams” are also possible on R/3 side if the APO sends lots of
newly created/changed objects to the R/3 (e.g. publishing of planning or BOP results). “Traffic jams” causes the
receiving system losing several hours behind the sending one, which is crucial for the customer’s Business
Process.
Special development for performance improvements during high

CIF load
Stock update counters
So-called stock update counters can be used as of Plug-In 2004.1 and SCM 4.1. This functionality was down
ported, see Note 784128.
During high CIF load, many logical units of work (LUWs) may collect in the qRFC queue. As a result, the LUWs
are processed very slowly with only a few work processes regardless of the available qRFC resources. Mass
transactions that are touching orders referring to the same material / plant combinations (e.g. goods issue of very
large sales orders) can easily cause a CIF backlog.
In this situation, update counters can significantly improve the CIF performance. The serialization using the stock
changes is removed by assigning anonymous CIF queues (CFST<GUID>) and update counters to stock changes.
The update counters are responsible to provide SAP APO with the current stock quantity in case the current
quantity was overwritten by an older version processed with delay. In this way, no stock inconsistencies occur
between the sending ERP system and SAP APO.
Stock update counters are advisable if always large quantities of transaction data are transferred from ERP
systems to SAP APO via CIF and batches are use rarely in inventory management.
See Note 492591 for a detailed explanation and how to implement stock update counters.
Emergency scheduler
Due to technical problems or downtime of one or several components, a huge number of queue entries has been
accumulated in SCM inbound. With a huge number of queue entries (> 100.000), the inbound scheduler tends to
get very slow in processing them and becomes a bottleneck. To speed up CIF queue processing in SCM inbound
in such situations, the report /SAPAPO/CIF_EMRG_QINSCHED can be scheduled. See Note 869399 for
availability and implementation of this report.
Figuring out CIF traffic in the system

To figure out how many CIF traffic sent from APO, you need to check in R3 part.
To figure out how many CIF traffic sent from R3, you need to check in APO part.
© 2006 SAP AG
Prerequisite:
Set user logging at least to normal (standard) if not detailed logging. (in APO system use transaction /sapapo/C4
and/or in R3 system use transaction CFC2).
Step by step:
- Go to SE16 and enter table name: BALHDR
- Enter the OBJECT as CIF

- Enter SUBOBJECT if you want to know exact data that was sent. Press F4 to get the explanation of what sub
object exist
- Enter corresponding ALDATE and ALTIME
- Press button 'Number of Entries' to get the traffic of that particular condition.
For APO system (but not for R3), you can refer to SAP Note 780034 for creating a report (program) to do this job
in more automatic way.
© 2006 SAP AG
Section 2:
Monitoring Roadmap
© 2006 SAP AG
Chapter 4: General Checks

Check qRFC processing type (w/o Inbound) and error handling
(post-processing)
Check how the qRFC processing is performed.
Find the logical system names belonging to the business system group (R/3 and APO) and communicating via
RFC.
Find the queue processing type (Inbound or Outbound).
R/3: Execute transaction /CFC1, check column QType:
Alternative, you can check field QUEUETYPE of table CIFOPMODE for the appropriate logical system:
QUEUETYPE = I Inbound queues
QUEUETYPE = ‘ ‘ Outbound queues
APO Execute transaction /SAPAPO/C2, check column ‘Queue Type’ and column ‘Err.Hndlg.’:
If post-processing is used (see chapter /SAPAPO/CPP Error Handling), faulty queue entries are to be
checked using transaction /SAPAPO/CPP. In this case, it is very unlikely that queues are blocked.
Check qRFC version

Call transaction /SMQR or /SMQS, choose Information -> Version. The following popup shows the qRFC
version and the supplement.
The qRFC versions and supplements are compatible with each other. It is not necessary for the sending
system or receiving system to have the same version or supplement number.
Check RFC parameters and available resources for qRFC

processing
If RFC profile parameters are configured incorrectly, qRFC (or tRFC) calls are not processed. Incorrect
configuration provokes a couple of different symptoms, for example:
© 2006 SAP AG
- Queue entries remain in state READY and scheduler (inbound / outbound) is continuously in state
WAITING.
- Destinations (outbound) or queue names (inbound) are not registered properly.
Determine the number of work processes available for qRFC / tRFC. Call transaction /SMQR or / SMQS,
choose Goto -> Queue RFC resources:
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 to
slow. Note that the number of available resources in the system is a snapshot which relates to the load status
of the system.
Check the entire RFC configuration of the connected systems (R/3 and SCM) according SAP Note 527481.
The following general rules must be fulfilled to guarantee that sufficient resources (work processes) are
available for qRFC processing:
- The number of DIA processes must be greater than or equal to the non-DIA processes for each instance
that is available for RFC processing and must be configured across all operation mode switches.
- The number of DIA processes available for RFC processing must be configured large enough to
accommodate the load of cascading RFC calls (e.g. function modules using ‘UPDATE TASK LOCAL’).
See Note 726148.
Use transaction RZ12 to verify the relevant parameters of the RFC server group assigned for RFC processing
(if is different from DEFAULT).
rdisp/rfc_use_quotas
rdisp/rfc_max_queue
rdisp/rfc_max_login
rdisp/rfc_max_own_login
rdisp/rfc_max_own_used_wp
rdisp/rfc_min_wait_dia_wp
rdisp/rfc_max_comm_entries
rdisp/rfc_max_wait_time
Additionally, check the setting of parameter rdisp/rfc_check using transaction RZ11.
© 2006 SAP AG
Having the necessary authorization, the values can be changed dynamically in transaction RZ12 (or RZ11).
Alternatively, the report RSARFCLD can be used to dynamically configure the RFC quotas on the server to
which you are logged on. Unlike parameter changes in the profile, these settings are lost when you next
restart the instance.
Using these transactions you are able to examine whether CIF problems are caused by a lack of available
RFC resources as well as configure them correctly to accommodate the CIF load.
Check whether qRFC registration is correct.

Go to transaction SMQR (for inbound) and check whether queue names are registered correctly. Check as
well in SMQS (for outbound in sending system) whether target destination is registered and remote connection
works.
© 2006 SAP AG
Chapter 5: CIF Monitoring and Analysis

Stuck Queues / Queue Problems
Basic analysis should be concentrate to find the reason for stuck queues / queue problems.
As long as the incorrect entry remains in the queue, the following transfers using the same queue are blocked.
If a queue is blocked for an extended period, R/3 and APO are not in sync and data gets inconsistent. For that
reason it is of utmost importance to take corrective action as soon as possible.
Monitoring steps:
1. Queue overview:
TA /SMQ2 (inbound) or /SMQ1 (outbound), leave field client as it is, enter CF* in field queue name, press
Execute.
2. Display all hanging queues:

Press button ‘Change view (F8)‘ 1.time => all erroneous queues are displayed (SYSFAIL, RETRY,
CPICERR)
3. Display all running queues:

Press button ‘Change view (F8)‘ 2.time => all running queues are displayed
4. Continue analysis depending on error type:

Technical (communication) or application error.
© 2006 SAP AG
Technical (Communication) Errors

CPICERR:
If a technical problem occurs during data transfer the queue receives status CPICERR (Communication error
or invalid ABAP/4 command in the LUW). The periodic repetition of the data transfer should solve those
problems as soon as technical problem is solved.
For detailed explanation on error CPICERR see chapter Monitoring tools, queue status inbound/outbound.
If inbound technology is used and the connection is not available qRFC entries are collected in the outbound
queue of the sending system (TA /SMQ1).
Example:
Connection is not possible because receiving system is down.
Monitoring step:
TA /ST11: Obtain further information from trace files dev_rd, dev_rfc* and dev_wp<n>, if problem persist for
longer time.
Application Related Errors

If a serious error occurs during LUW execution, the queue receives the error status SYSFAIL or RETRY. For those queue
entries, no automatic processing occurs through the QIN/QOUT scheduler.
SYSFAIL
A high number of SYSFAIL entries in connection with the serialization effect (queues are in state WAITING on erroneous
queue) might lead to stuck queues. Since the number of entries is continuously growing the qRFC processing is slowed
down.
Monitoring steps:
1. Find error text:
Double-click on SYSFAIL.
2. Identify object type, object and name of function module:

a. Identify object type and object from queue name (see chapter 1 APO Core Interface Overview,
section Data transfer and data channels).
b. Identify object type and object using the queue manager /SAPAPO/CQ.
The name of the function module is shown in the detail view of the queue monitor.
3. Find information in application log:

a. Select queue and details => Select the SYSFAIL entry and details => Double-Click on
‘StatusText’ to jump to application log:
b. TA /CFG1 (R/3) or TA /SAPAPO/C3 (APO), enter TID obtained from the queue monitor, press
Execute. If you cannot determine the TID, restrict the time frame as far as possible.
© 2006 SAP AG
c. Alternatively, the reports CIF_APPL_LOG_SEARCH_2 (R/3) or

/SAPAPO/CIF_APPL_LOG_SEARCH_2 (APO) could be used to search for certain strings (e.g.
material R-1001). Time frame should also be restricted as far as possible.
4. Find detailed error message:

Double-click error message in application log. Determine message number and long text, if existing.
5. Find further information on error:

If no entries are recorded into application log, probably there was a termination. Find related short dumps
(TA /ST22) or system log entries (TA /SM21).
© 2006 SAP AG
Complex Analysis
SYSFAIL problems
SYSFAIL errors may have various reasons. They must be rescheduled manually after the error was solved.
Those errors are always recorded in the application log independent of the user settings (No logging, Normal,
Detailed logging).
Common message classes for transfer direction R/3 -> APO:

/SAPAPO/OM Error text for liveCache return codes from om_error_codes
/SAPAPO/CIF Message class for the Core Interface
Common message class for transfer direction APO -> R/3:
XC Message Class for Core Interface
When transferring objects from APO to R/3, also various other messages might be popup depending on the
step to be performed during processing (e.g. post an updated sales order sent from APO to R/3 after BOP).
Monitoring steps:
1. Find detailed error message:
Double-click error message in application log. Determine message number and long text, if existing.
2. Get detailed information about error codes, if not in application log visible:
a. For messages of type /SAPAPO/OM:
Transaction /SE38: display the report /SAPAPO/OM_ERROR_CODES and find your error code.
Transaction /SAPAPO/OM10, enter the error number. Detailed error message is shown (only
available in GERMAN).
Detailed LC error messages and their meaning can be obtained in SAPNet on the APO
developer page LC application errors. Number and short description should be included in case
an OSS message has to be created.
b. For all other messages of types:
Transaction /SE91, enter message class and number.
3. Check whether object is contained in an active integration model:

This step is mandatory and only advisable in case of missing data.
R/3: /CFM5 => enter object name (product, location) under ‘General Selection Options for Materials (right
hand side) and cross object type under ‘Material-dependent Objects (left hand side) => press execute
As result a list is shown with the number of integration models, where the object is contained in. From
here, drill-down is possible to the integration models.
© 2006 SAP AG
4. Open OSS message on component BC-DB-LCA or SCM-APO-INT respectively:

Include all relevant information obtained from application log etc.
RETRY Problems
The RETRY status occurs in general when another user or process already locks data (usually on location
product level); therefore the queue processing is stopped. The queue gets the status RETRY and the inbound
scheduler will restart the queue depending on its settings.
Entries in status RETRY are not properly processed by the inbound scheduler, but must be triggered and
executed by a background job. This job named QRFC:<TID> schedules a repetition with a fixed period of 2
minutes. If locks frequently occurs that leads to enormous delay in inbound processing and to heavy system
load (CPU utilization).
Further bottlenecks are likely to occur because the number of background work processes in the system is
limited and the background scheduler assigns them work with a period of 60 seconds (default value for
rdisp/btc_time) though the runtime of the qRFC jobs is usually very short. Between 2 starts of the background
scheduler a lot of new entries might be created which leads to the consequence that the jobs are delayed up
to several hours.
Product allocation
A blocking conflict can happen during an update of sales orders and/or deliveries that contain items, which are
using product allocations within their ATP set up. That is, customers are working with product allocation with a
direct link to the planning area.
Locks are set only for the characteristics combination (location product) of the order that is currently
processed. If there are several sales orders (in different queues) having identical characteristics combinations
those cannot be processed in parallel but have to be processed one after the other. When events for such
orders are send simultaneously only the first will get the lock and will be processed, but all the following ones
will have to wait and will get the RETRY status because of the lock.
Typical business process step:

Backorder Processing in SCM with subsequent key completion from R/3
Forecast consumption
In a very general sense, forecast consumption is the comparison of two order types. Often SAP APO planned
independent requirements are consumed by other order types, such as sales orders, dependent demand, or
transfer requests. This functionality is fully integrated which means that a change of a consuming requirement
(e.g. sales order) is taken into account immediately.
Anyway, the pegging area of the corresponding product stored in liveCache needs to be updated.
To ensure consistency of data changes (forecast quantities and/or pegging area), SAP locks are set during
forecast consumption. If several sales orders arrive with identical location products, this can result in lock
problems and thus repetitive posting of the sales order. The higher the parallel load the more sales orders can
not be posted and are sent to RETRY by the qRFC scheduler.
This proceeding leads to problems in the area of consumer goods. Typically, those customers are having a
small number of products contained in nearly each order (top-sellers).
Typical business process steps:

Transfer of sales orders/deliveries from R/3 to APO with usage of forecast consumption in SCM
Common error codes:

/SAPAPO/ATP102: Plng object &1 and basic method &2 have been locked (check not possible)
/SAPAPO/OM042: Object is locked at present
Monitoring actions:
© 2006 SAP AG
1. Determine number of RETRYs:

Transaction /SMQ2 (inbound) or /SMQ2 (outbound) => Number of RETRY entries, compare with overall
entries in the queue (threshold: 50%).
2. Verify background scheduling of qRFC* jobs:

Transaction /SM37 check for scheduled qRFC jobs. Check their frequency and delay in start time.
Check, whether the same LUW is schedule several times as a background job.
3. This leads to enormous processing delay (Example: LUW processed 5 times, first start time of LUW
03:27:51, last start time 03:43:51 => 15 minutes delay).
Alternatively, obtain number of qRFC jobs scheduled per day/per hour using /SE16, table TBTCP, enter
the fields JOBNAME (= qRFC*), SDLDATE and SDLTIME, press ‘Number of entries’:
4. Check for occurrence of locks (SAP enqueues):

TA /SM12 check for existing lock entries and their remaining time.
© 2006 SAP AG
5. Verify the application log:

Select ‘only important logs’ and analyze whether the following entries occurs frequently for one LUW (one
TID):
"LiveCache access block: Data requested again from system <SIDcln>"
"Object is locked at present"
Logging must be set to ‘Detailed’ for the CIF user.
© 2006 SAP AG
These monitoring steps are useful to find out that massive occurrence of RETRYs hinder the CIF queue
processing. A general solution how to solve those problems cannot be provided in this document as it requires
deep knowledge of the business process in general and how the customer has implemented it. For that
reason, do NOT recommend any notes or workarounds without discussing the problem with application back
office.
BASIS Workaround for Basis release < 7.0 (you need the cooperation with back office to set this):
If application solution is exhausted, then other option is to speed up background scheduling:
• Setting the parameter rdisp/btctime to 30 seconds, which can be done using transaction /RZ11
without restarting the instance.
• Or by the usage of the so-called quick start program. This program serves as a job starter; see Note
599835 for details.
Report RSBTCSEXE:
With SAP Note 923228, this workaround become obsolete as enhancement of background job
scheduling (see SAP Note 923228 for details) is provided. This enhancement is delivered by default
starting basis release 7.0. For basis release below 7.0, a step by step configuration and coding
correction is needed to activate this enhancement.
© 2006 SAP AG
Queues and Performance problems

Tools
System Monitoring (APO, OLTP)
System log - SM21
ABAP dump - ST22
System process overview - SM50, SM66, SM51
Locking (enqueue/database) - SM12/DB01
Update - SM13
Batch - SM37
Database - DB02/ST04
Database Index and statistics – DB05 and DB21
RFC server & resources configuration – RZ12
HW resources – ST06
RFC destination - SM59
RFC and SQL Trace – ST05
ABAP Trace – SE30
liveCache - LC10 (only in APO)
Gateway - SMGW
Resources/Setting problems
Wrong configuration of CIF setting/parameters and lack of resources can slow down the CIF transfer/process
or even worst, block the whole system.
We can monitor this using transaction /SM50 during CIF transfer/process. Observe work processes with RFC
user (i.e. ALEREMOTE).
All Work processes are occupied in the sending system

1. Check if the parameters are configured correctly (refer to Chapter 4: “General Checks”).
2. Check if the resources are sufficient (refer to Chapter 4: “General Checks” and Chapter 3: “CIF
Performance and Configuration”).
All Work processes are occupied in the receiving system
1. Check if Inbound is in use (refer to Chapter 4: “General Checks”).
2. Check if the parameters are configured correctly (refer to Chapter 4: “General Checks”).
3. Check the resource distribution (/RZ12, refer to Chapter 3: “CIF Performance and Configuration”).
Check if the resources are sufficient (refer to Chapter 4: “General Checks” and Chapter 3: “CIF Performance
and Configuration”).
Long Accesses to Tables

In transaction SM50 and/or SM66 you notice long running CIF process with sequential read to tables, etc
which cause performance problem of your CIF processing. Below are some scenarios what might go wrong
and how to handle the problem:
Long accesses to ARFC* Tables (ORACLE)

Long accesses to tables ARFC* (using ORACLE database), i.e.:
ARFCSSTATE
ARFCSDATA
ARFCRSTATE
1) For Oracle release < 10.x these tables should not have any statistics.
Check transaction DB20
© 2006 SAP AG
Check transaction DB21
2) Check storage quality, transaction DB02 (see SAP Note 407125)

See sap note 332677 and 771929 for index fragmentation and how to handle it
Transaction DB02 > Detailed Analysis > put the related table name in object name field > Click on button
‘Table <-> Index’ > mark the relevant index, then press button ‘Detailed Analysis’ > go to menu ‘ Analyze
Index’, then choose Storage quality.
Long accesses to TRFC* Tables (ORACLE)

Long accesses to tables TRFC* (using ORACLE database), i.e.:
TRFCQOUT
TRFCQIN
TRFCQSTATE
TRFCQDATA
1) Check storage quality of those indexes (see SAP Note 407125)

2) For qRFC supplement < 11 no statistics for these tables, for qRFC supplement >=11 statistics needs to be
created once and frozen. See SAP Note 742950.
Program RSTRFCCS (New enhanced version, available in SCM 5.0. Screenshot taken from test system Q1P)
© 2006 SAP AG
Long Accesses to Integration Tables:

Please refer to section Long Process time of Integration jobs (R/3)
Long access time to application log tables (both R/3 and SCM)
1. Check the logging level of the users used for RFC communication in the affected system (transactions
R/3 CFC2, SCM /SAPAPO/C4).
2. For Oracle databases: Check index storage quality of these tables. If index storage quality is bad,
recommend to recreate indexes regularly.
3. Check the size or the number of entries. If size or number of entries is huge check whether the delete
jobs are scheduled regularly (SBAL_DELETE in both systems, R/3: RDELALOG, SCM:
/SAPAPO/RDELLOG).
Long Process time of Integration jobs (R/3)

Sometimes, customer complains that the runtime of generating / activating integration models in the R/3
system is far too long. These jobs have to be executed periodically (most common: daily) to adjust the
integration models to a changed master data situation and to reflect these changes in the SCM system.
Because that must be done before executing any planning function this might become a serious problem in
case of tight batch windows.
Usually, the adjustment is done in background using a 2-step-procedure:
RIMODGEN => generation:
Generation of an integration model means the selection of all data objects from the total dataset in R/3 for
the transfer to APO. Each generation creates a new version of the integration model distinguished by date
and time of creation, as well as by the filter objects that they contain.
RIMODAC2 => activation:
The activation of an integration model starts the actual data transfer. During activation, the integration
models are compared with their previous version and with all integration models of the same object type
that are already active. In this way, the transfer restricts itself to difference, in other words, only data for
filter objects that are not contained in any active integration models is transferred. This is referred to as
so-called delta logic. The flag ‘Activate latest version’ should be set in the variant
Long runtime of generation

Review the variant used for the report RIMODGEN. Check whether the customer has specified ‘General
Selection Options for Materials’.
The lack of those options may cause high database request time because a large number of material /plant
combinations have to be read.
© 2006 SAP AG
Long runtime of activation

The activation runs as an initial supply (with delta logic). The runtime of the initial supply is influenced by:
Setting of object parameters (transaction CFC3), see chapter ‘Settings of Object parameters’
Number and amount of application logs written, see chapter ‘Activated application log writing’
If the customizing is set to periodic transfer of master data changes (material, customer, vendor) the
appropriate change pointers are evaluated and processed as last step during activation of the appropriate
integration model.
If long access times to change pointer tables are recognized (BDCPV, BDCP, BDCPS), proceed as follows:
1. For Oracle databases: Check index storage quality of these tables. If index storage quality is bad,
recommend to recreate indexes regularly using report RBDCPIDXRE.
2. Check the size or the number of entries. If size or number of entries is huge check whether report
RBDCPCLR (deletion of obsolete change pointers) is scheduled. If not, recommend the regular
reorganization of obsolete change pointers.
It has to figured out which part of the initial supply (selection in R/3, data transfer via qRFC, ABAP processing
in APO, processing in liveCache) is causing the problem.
In general, the performance of initial supply can be improved by using parallel options. For details, refer to
chapter ‘Performance improvement by parallel initial supply’ to check the different options.
The delta logic can be suppressed by executing report RIMODINI, see Note 533755.
Long access times to integration tables CIF_IM*

The most important integration tables are:
CIF_IMOD: Basis Table of Integration Model for APO Interface
CIF_IMAX: Maximum Vectors for Target System and Publishing Type
Besides, there are various reference tables per filter object type (e.g. CIF_IMSLS Integration Model Reference
Table for Sales Orders). The reference (or filter object) tables are growing if the number of objects relevant to
APO is varying widely (in other words: integration models are often deactivated / activated with changing filter
objects).
In this case, there are many superfluous objects that are not used in active integration models anymore.
Long access times to reference (filter object tables):

1. Check the size of the affected tables by executing report RCIFIMDL with flag ‘Display Unused Filter
Types’.
2. A high number of superfluous filter objects hinder performance during activation of integration models. For
that reason it is recommended to delete unused entries for the appropriate tables. If the number of
unused filter objects is very high (> 200.000) the deletion must be performed in several steps. For details,
see Note 593355.
3. Check access path used if SQL trace is available. In some cases, indexes are missing (see Notes
844325, 799678).
Consistency of Runtime version of the integration models

The table CIF_IMAX stores the runtime version of the active integration models. It contains all active entries of
CIF_IMOD in a compressed form (see chapter Design of the integration models).
To speed up accesses the runtime version of an integration model must be valid and consistent. If it is not, the
system continues to access table CIF_IMOD which is time-consuming. Inconsistencies in the runtime version
can also provoke that objects are transferred which are not in active integration model (deactivated) anymore
or vice versa.
1. Check the consistency using report RCIFIMAX.
ATTENTION: This report must not run in parallel with activation of integration models!
© 2006 SAP AG
2. Correct inconsistencies by executing the report with flag ‘Generation’.
Too many inactive integration models

A large number of inactive integration models / integration model versions can lead to performance loss during
activation.
Check the number of active (field ACTIVE = ‘I’) / inactive entries in table CIF_IMOD (field ACTIVE = space).
Inactive versions and models can be deleted with report RIMODDEL / transaction CFM7.
Long processing time of publication job

Publication is the sending of planning results from SCM to R/3 (purchase requisitions and / or planned orders).
Usually, this is done with report /SAPAPO/RDMCPPROCESS (transaction /SAPAPO/C5).
The runtime depends on:
- number of objects
- type of object
1. The runtime per object type (purchase requisition = external procurement, planned / production order = in-
house production) depends on the block size for publication.
Check the block size using transaction /SAPAPO/CP3 and refer to Chapter 3 ‘Performance and
Configuration’ subchapter ‘Initial Supply’ and/or ‘Online Transfer’.
2. The publication job itself works in packages, that means a package of <n> objects is processed and sent
to R/3. The standard value for package size is 1000 and this should not be changed. The processing of
each package is recorded in the job-log of the appropriate background job:
Date Time Message text

18.08.2005 01:44:43 Job started
18.08.2005 01:44:43 Step 001 started (program /SAPAPO/RDMCPPROCESS, variant
SAMMEL-000, user ID DU_SCHWAJER)
18.08.2005 01:47:02 1.000 change pointer was processed
…. … …
18.08.2005 03:42:57 454 change pointer was processed
18.08.2005 03:42:57 Job finished
© 2006 SAP AG
3. Various selection options are available to set up variants for the job. It is possible to run disjoint variants in
parallel if the queues are processed fast enough.
Check the variant.
If you need to evaluate the runtime in detail, ask for creation of a variant with a limited number of change
pointers to be published.
Long accesses to liveCache

How to identify this: in SM50 and/or SM66 you see plenty of CIF processes accessing ‘dbproc…..’
Long liveCache access may caused by:

- liveCache HW and/or Network bottleneck
- UKT contention
- Collision, Object lock, etc
- Wrong setting of liveCache
Further analysis is not covered in this cookbook and should be carried on by liveCache expert.
© 2006 SAP AG
Appendix 1: List of Transactions
© 2006 SAP AG
Appendix 2: Related SAP Notes

SAP Note Description
505304 Disk space for Core interface communication
527481 TRFC or qRFC calls are not processed
384077 APO: Optimizing CIF Communication
74141 Resource management for tRFC and aRFC
384971 Gateway parameters for a high interface load
193515 QRFC description (queued remote function call)
369007 QRFC: Configuration for the QIN Scheduler
400330 Outbound Scheduler/qOUT Scheduler
460235 TRFC/qRFC: Low-speed processing
371068 TRFC/qRFC: Measures for better performance
407125 Poor performance of Q and TRFC on ORACLE
375566 Many entries in tRFC and qRFC tables
378903 Queue status in SMQ1, SMQ2 and table ARFCRSTATE
454912 Poor performance of tables used by APO (Oracle only)
438015 Latest qRFC version and supplement for 3.x, 4.x, 6.10, 6.20)
366869 HOLD/EXECUTED/WCONFIRM entries in ARFCRSTATE
195157 Application log: Deletion of logs
328355 BD21: Long access times for the BDCPV view
319860 tRFC/qRFC: Improved performance after SYSLOAD
335162 Error "connection closed" in tRFC/qRFC monitors
786446 Setting up qRFC queue names for CIF
333878 Transactional RFC is not executed
717280 APO: No navigation from qRFC monitor into CIF applic. log
717282 R/3: No navigation from qRFC monitor into CIF applic. log
369524 qRFC: Error text "R/3 logon failed" in SMQ2
567601 Unnecessary entries in the table /SAPAPO/CIFBEFCR
602484 Restrictions with CIF error handling/post processing (CA)
799647 CPP: Problems calling remote R/3 transactions
802980 CPP: Performance problems when you access table CIFERRLOG
652885 F4 help for target system only shows some logical systems
697884 Queues in SMQ2 are not processed
744869 Optimizing the performance of inbound scheduler
742950 Performance affected on Oracle DB with Supplement 11
932975 Oracle statistics for RFC tables with Oracle 10g
695534 Long runtime for the optimization or MRP run
446866 Documentation on runtime information for publishing
524419 Procedure for large-scale queue jams
555130 Restarting inbound queues and automatic saving
784128 Update counter for stocks: Down port to 4.1 (R/3 Plug In)
492591 FAQ: Stock forwarding
780034 Improved CIF Monitoring
726148 SAPLARFC occupies all work processes, RFC cascade
599835 Problems because of too many short jobs
332677 Reorganizing degenerated Indexes
771929 FAQ: Index fragmentation
407125 Poor performance of Q and TRFC on ORACLE
533755 Description of the delta logic or the program RIMODINI
593355 Filter object tables too large
844325 Database accesses on CIF_IMMBOM, CIF_IMIPRT not optimal
799678 Database accesses on CIF_IMSDS / CIF_IMSDLS not optimal
786150 Deletion in the queue manager without a SYSLOG entry
923228 Background job sched.: Using processes that have become free
© 2006 SAP AG
Appendix 3: Troubleshooting Flowchart
© 2006 SAP AG

1 CIF Cookbook Version 2

Uploaded by

Copyright:

Available Formats

1 CIF Cookbook Version 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 CIF Cookbook Version 2

Uploaded by

Copyright:

Available Formats

What are the different monitoring tools discussed in the document?

What are the different monitoring tools discussed in the document?

What are the different transfer techniques used in APO core interface?

What are the different transfer techniques used in APO core interface?

APO Core Interface Monitoring Cookbook

APO Core Interface Monitoring Cookbook

- Internal use only! -

Date Version Changes

Inbound Queue STATUS .......................................................................................................... 17

Chapter 1: APO Core Interface Overview

Client system Server system

qRFC Without Inbound Queues (Only Outbound Queues)

WP1 tRFC LUW1 WP1

qRFC With Inbound Queues

LUW’s are not processed

Logical Unit of Work and Queued RFC

Further explanation of queue status will be discussed in Chapter 2.

Transfer from R/3 to APO

Transfer from APO to R/3

Data Transfer and Data Channels

Names for direction APO => R/3

Queue name Description

Names for direction R/3 => APO

Queue name Description

Chapter 2: CIF Monitoring Tools

SMQ1 (Outbound monitoring)

Outbound QUEUE Overview

Outbound Queue MENU OPTIONS

Under Information menu, you have the following options:

Outbound Queue STATUS SCREEN

Additional to the output screen you can see:

Outbound Queue STATUS

Outbound Queue LUW DETAIL

Right Side Screen

Additional columns are:

Queue display in binary mode

New Queue display

Queue display with all related

SMQ2 (Inbound monitoring)

Inbound Queue STATUS

SMQS (QOUT Scheduler)

QOUT Scheduler SCREEN

QOUT Scheduler STATUS

QOUT Scheduler MENU OPTIONS

Under Edit, you have the following menu options:

Deregister To deregister the selected destination. The registered destination is not

Under Goto, you have the following menu options:

QRFC Administration Navigate to the menu for starting qRFC events.

SMQR (QIN Scheduler)

QIN Scheduler SCREEN

• Cl: Client where the scheduler works

QIN Scheduler MENU OPTIONS

/SAPAPO/CQ (SCM Queue Manager)

SCM Queue Manager SELECTION SCREEN

Under screen section Systems:

Under screen section Object types:

SCM Queue Manager EVALUATING THE RESULT

Jump to application log Jump to SMQ1

/SAPAPO/C3 (Application Log)

Application Log SELECTION SCREEN