Cif monitoring-guideline-v3

giampiero.gallarate@smart-media.it
CIF Monitoring Guideline V3.doc Page 1 of 48 Created on 7/27/2011 3:09:00 PM
Table of Content
Table of Content ............................................................................................................1
1. Useful transactions ................................................................................................3
1.1. OLTP-R/3 .....................................................................................................................................3
1.2. APO-R/3 .......................................................................................................................................3
1. Inbound & Outbound Queues................................................................................4
1.1. Outbound Scheduler SMQS – Configuration ...............................................................................4
1.2. Outbound Scheduler SMQS - Monitoring.....................................................................................5
1.3. Inbound Scheduler - Configuration .............................................................................................6
1.4. Inbound Scheduler SMQR – Monitoring ......................................................................................7
2. qRFC monitor: Motivation......................................................................................8
2.1. Queue Monitor – APO and R/3 backend......................................................................................9
2.2. Local Outbound Queue Overview..............................................................................................10
2.3. Display Inbound Queues with Problems ....................................................................................11
2.4. Logic of queue names for CIF....................................................................................................12
3. Application logs: Motivation................................................................................16
3.1. Analyze Application Log.............................................................................................................17
3.2. Maintain Logging Level ..............................................................................................................18
3.3. Search in Application Log...........................................................................................................19
4. Protocol of deleted CIF Entries ...........................................................................20
5. SCM Queue Manager............................................................................................21
5.1. SCM Queue Manager - Features...............................................................................................22
5.2. CIF Cockpit - Settings ................................................................................................................23
5.3. CIF cockpit – user profile............................................................................................................24
6. Postprocessing.....................................................................................................30
6.1. CIF Error Handling Default.........................................................................................................30
6.2. CIF Error Handling with Postprocessing ....................................................................................31
6.3. Postprocessing Facts.................................................................................................................32
6.4. Postprocessing Limitations.........................................................................................................33
6.5. Handling of Postprocessing Records.........................................................................................34
6.6. Usage types for Postprocessing ................................................................................................35
6.7. Alerting for Postprocessing Records..........................................................................................36
6.8. Prerequisites of Enhanced Queue Display ................................................................................37
7. CIF Performance...................................................................................................38
7.1. Check RFC parameters & available resources..........................................................................38
7.2. Resources for tRFC (transaction SMQR / SMQS).....................................................................39
7.3. RFC Parameter settings.............................................................................................................40

7.4. Check Queue status...................................................................................................................44
7.5. SMQ2 : Large number of entries / LUWs...................................................................................45
7.6. Status SYSFAIL in CIF queue....................................................................................................46
7.7. Relationship LUW / CIF queue...................................................................................................47
7.8. Stuck queues..............................................................................................................................48

1. Useful transactions
1.1. OLTP-R/3
Transaction Description
CFM1 Create/Generate Integration Model
CFM2 Activate or Deactivate Integration Model
CFM3 Activate Integration model (Possible in Background)
CFM4 Display Integration Model
CFM5 Search for Filter Objects in Integration Model
CFM6 Change Integration Model
CFM7 Delete Integration Model
CFS0 Display one or all Outbound queues
CFS1 Display one or all Inbound queues
CFG1 Application log
1.2. APO-R/3
Transaction Description
SMQ1 qRFC-Monitor Outbound queues
SMQ2 qRFC-Monitor Inbound queues
/SAPAPO/C3 Application log
/SAPAPO/CCR CIF-Delta Report
/SAPAPO/CQ SCM Queue Manager
/SAPAPO/CC CIF Cockpit
/SAPAPO/CPP1 CIF Postprocessing
SMQS Outbound scheduler
SMQR Inbound scheduler

1. Inbound & Outbound Queues
1.1. Outbound Scheduler SMQS – Configuration
Use transaction SMQS to register a destination
• The QOUT Scheduler was implemented to improve performance when sending
qRFC and tRFC messages. The processing of all queues is scheduled by the
QOUT Scheduler. With help of the QOUT Scheduler it is possible to define how
many work processes are used for sending the LUWs to a specific destination. The
number of simultaneously sent tRFCs and qRFCs is limited and consequently the
QOUT scheduler provides a kind of control over the resources on the receiving sys-
tem.
• You can enter the following parameters:
o Destination – Enter the name of your destination.
o MAXCONN – Maximum number of connections
o MAXTIME – Maximum scheduler processing time for a destination in sec-
onds (default is 60 seconds) You can use this setting to allocate more proc-
essing time to individual queues and restrict the processing time of others.
o NO_TRFC – This prevents tRFC LUWs from being processed by the Out-
bound Scheduler. This means that the tRFCs for this destination are then
executed when the Commit Work is executed.
• The parameters set for the different destinations do not depend on the number of
queue entries.

1.2. Outbound Scheduler SMQS - Monitoring
• Status: Normally, status is Inactive. Manual activation can be forced.
• Last update: Check Last update to verify proper function of QOUT scheduler.
• Name of AS group: Use transaction RZ12 to define a group of application servers (AS).
• As soon as a LUW with a registered destination has been created, the QOUT Scheduler in
this client is activated by the qRFC Manager, if it was not already active. The QOUT
Scheduler can also be activated manually for the current client.
• To check if the outbound scheduler is running properly, see the column Last update.
• You can use transaction RZ12 to define a group of application servers (AS). You can then
use transaction SMQS to assign this server group to the QOUT Scheduler. The scheduler
will then only use the application servers assigned in the server group to process the
LUWs.
• To exclude a destination from being handled through the outbound scheduler, register the
destination in SMQS and then select the destination and choose Edit >> Exclude. The des-
tination then appears as type N, like destination PRD in the example above.

1.3. Inbound Scheduler - Configuration
Use transaction SMQR to register a queue name
• The QIN scheduler is configured on the basis of queue names. So if new queue names are
used, they must be registered, otherwise their entries will not be processed. The inbound
scheduler does not process the LUWs but triggers their processing in asynchronously
started work processes.
• Parameters for the inbound scheduler are:
o EXEMODE: D for dialog, B for background, depending on the type of the work proc-
ess that should be used for processing queue entries.
o MAXTIME: Time spent by the inbound scheduler for working on the queue. If this
time limit is exceeded,
o LUWs of other registered queues are distributed to work processes by the inbound
scheduler.
o USERDEST: Logical destination (defined in transaction SM59) for processing LUWs
in this
o queue. This enables you to change the client, user, and language for all qRFC
LUWs.
o NRETRY: Number of retries
o TDELAY: Delay between retries (CPICERR)
• The QIN scheduler limits the number of processes used for processing function modules
from inbound queues. The QIN scheduler can of course only be used if inbound queues are
used.

1.4. Inbound Scheduler SMQR – Monitoring
• Status: Normally, status is Inactive. Manual activation can be forced.
• Last update: Status is updated every 2 minutes.
• Name of AS group: Use transaction RZ12 to define a group of application servers
(AS).
• If a qRFC LUW has been written in a registered queue, and the QIN Scheduler is not al-
ready running, the QIN Scheduler is activated by the qRFC Manager. There is one QIN
Scheduler for each client (inbound queues are client-specific).
• If the scheduler is active, the status is updated every two minutes. Every change of status
automatically causes an update, to show that the scheduler is active.
• The QIN scheduler processes all the registered queues using all the application servers of
the local SAP system (AS group DEFAULT). Transaction RZ12 can be used to define a
RFC server group with application servers (instances) to be used by the IB scheduler.
• This group can be assigned in transaction SMQR by choosing Edit / Change AS Group.

2. qRFC monitor: Motivation
• The communication between R/3 and SCM is based on the asynchronous transfer technol-
ogy of the queued Remote Function Call (qRFC). A Remote Function Call (RFC) enables
calling a function module on a remote server. This technology is used in the integration be-
tween SCM and R/3 both for the initial data supply and incremental data transfer (from R/3
to SCM) as well as for the publication of planning results (from SCM to R/3).
• The data is first buffered by the sending system and then transferred to the target system.
The major advantage is that the application that triggers the data transfer does not have to
wait until the update has been completed in the target system. However, this means that re-
turn parameters cannot be passed on, and potential error messages cannot be returned to
the application directly.
• Two types of errors are distinguished for the processing of qRFC modules:
o Communication errors:
This includes network problems, as non-existing RFC destinations and so on. Since
the data transfer is repeated after certain periods, most of these communication er-
rors should disappear once the network connection is available again.
o Application errors:
This includes: program errors, failed data update in the target system, locking of ob-
jects, missing master data for specific transaction data. Application errors cannot be
solved by the system and must be dealt with by the system administrator.

2.1. Queue Monitor – APO and R/3 backend
• SMQ1 - qRFC Monitor for the outbound queue. Use this transaction to monitor the status of
the LUWs in the outbound queue and restart any hanging queues manually.
• SMQ2 - qRFC Monitor for the inbound queue. Use this transaction to monitor the status of
the LUWs in the outbound queue.
• Both in OLTP and APO, you can start the qRFC monitor for inbound queues with transac-
tion SMQ2 (report RSTRFCM3) and for outbound queues with transaction SMQ1 (report
RSTRFCM1). Queue name CF* is related to the CIF.

2.2. Local Outbound Queue Overview
Transaction SMQ1 handles like SMQ2
• Both in OLTP and APO, you can start the qRFC monitor for outbound queues with transac-
tion SMQ1 (report RSTRFCM1). Alternatively, in the OLTP system, you can call transaction
CFQ1, but this only shows queues within the current client.
• The qRFC monitor presents an overview of queues that are not empty, the number of
LUWs in each one, and the target system. For more detailed information (status, date/time
of the first and last LUW written into the queue, and possibly the name of a queue that must
be processed first), choose a queue and select Display selection. In the next screen, dou-
ble-clicking the queue displays the individual calls. Queue names are generated by the ap-
plication programs.
• The qRFC monitor only displays the waiting calls. Because of message serialization, if an
error occurs, the highest entry in the queue blocks all other entries.
• For any qRFC error, a detailed error log is always saved in the application log of the sys-
tem. To find this entry in the application log:
o For the call with the qRFC error, copy the value in field TID (transaction ID).
o In the selection screen of transaction /SAPAPO/C3 (APO application log) or CFG1
(OLTP application log), enter this value in the field External ID, select a time period,
and execute. The next screen displays all messages related to the erroneous qRFC
call.
• An error can appear in the APO application log without appearing in the qRFC monitor.
• In OLTP, you can also monitor CIF channels with transaction CFP2 (report RCPQUEUE):
choose Logistics / Central functions / Supply Chain Planning Interface / Core Interface Ad-
vanced Planner and Optimizer / Integration Model / Change Transfer / Transaction Data.

2.3. Display Inbound Queues with Problems
• To display queue problems and dependencies between waiting queues in transaction
SMQ1/SMQ2 click once on the bell button or use F8 key. Another click on the bell button
will show the running queues.
• Additionally to the output screen you can see:
o Status: The queue status of the queues will be shown. For the possible status val-
ues please read the SAP note 378903.
o 1Date/ 1.Time: Shows the date/time when the first LUW was written into the queue.
o NxtDate/NxtTim: Tells when the last LUW was written into the queue.
o Wait for queue: Contains the queue name that must be processed before the
queue could be started. The queue name of the “high priority” queue can be a single
or generic queue name.
• If an error (SYSFAIL) is shown in the status field you can get more detailed information
when you double click the status.

2.4. Logic of queue names for CIF
Real-time transfer in general:
o CF<CIF object ID><serialization character string>
Direction R/3 APO: CFSLS<n>
o First 2 letters CF for CIF
o Next letters represent the object type
o Followed by the order number, e.g. CFSLS0000010003 for a sales order
Direction APO R/3: CFIPXXXXXXXXXXXXXXXXXXXX
o First two digits letters CF for CIF
o Next 2 letters for object type, e.g. IP = In-house Production
o Following digits: first 20 pertinent characters of the order GUID
Initial transfer:
o CFLD<logical source system>_<counter><subcounter>
Initial transfer aborted:
o CF_LOAD_ABORT<counter><subcounter>
QRFC queue names for the CIF real-time transfer are always set up according to the following
rules:
o CF<CIF object ID><serialization character string>
For the initial data upload, the qRFC queue name is set up according to the following rule:
CF_LOAD_ABORT<counter><subcounter>
The <counter> counter changes from initial data transfer to initial data transfer. You only
have the second <subcounter> counter if there are parallel settings in the SCM APO in-
bound. It then changes from block to block of an initial data transfer.
The queue names differ for the direction R/3 => APO and APO => R/3. See following pages & SAP
Note 786446 for a list of queue names and their meaning.

Queue names R/3 => SCM (for a complete list see Note 786446)
Queue name Description
CFSTK* Stock
CFPO* Purchase orders and purchase requisition
CFPLO* Planned orders/Production orders
CFSLS* Sales orders
CFRSV* Manual reservations
CFCNF* Confirmations
CFPIR* Planned independent requirements (created in R/3)
CFMAT* Reduction of PIRs
CFFCC* Reduction of PIRs (if separate Imod is used)
CFPCM* Production campaigns
CFCLA* Master data for classes
CFCHR* Master data for characteristics
CFCUVT* Planning tables
CFSHP* Transports (TP/VS scenario)
CFTL* Transport locks (TP/VS scenario)
CFTG* Deletion of temporary quantity assigments GATP (in one LUW with
CFSLS*)
FC* Fulfillment coordination (only if qRFC consumption is used)
CFCB* CBase Configuration
CFCR* CBase Configuration, special case
CFCD** CDP Configuration
CFCL* Classification

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

Common Queue Status – Note 378903
READY Queue is ready for transmission. If a queue was locked manually and then unlocked with-
out being activated, the queue stays ready until it is activated explicitly.
RUNNING The first LUW of the queue is currently being processed. If a queue in this status hangs
for more than 30 minutes, activate it again.
WAITING The first LUW of this queue has dependencies on other queues, and at least one of
these queues contains other LUWs with higher priority.
STOP A lock was set explicitly (via SMQ2 or a program). This status never appears without “exter-
nal” interference.
SYSFAIL A serious error occurred in the target system while the first LUW of the queue was exe-
cuted. The execution was interrupted. No batch job is scheduled for an automatic retry, and the
queue is stopped.
CPICERR During transmission or processing of the first LUW in the target system, a network or
communication error occurred. Depending on the registration of this queue in SMQR, a batch job
may be scheduled for repetition.
READY Not yet executed (only temporary)
RUNNING Execution active
WAITING Waiting until the LUWs with a higher priority are executed
SYSLOAD No free DIALOG work processes in the sending system
RETRY Temporary problem during execution (locking issue), background job sched-
uled
STOP Execution explicitly stopped
NOSENDS Outbound: LUW is not sent (only used for debugging)
NOEXEC Inbound: LUW is not processed (only used for debugging)
SYSFAIL A serious error has occurred in the target system (APO) while the LUW
was executed
CPICERR An error occurred during establishing the connection

3. Application logs: Motivation
• The Application Log is a tool for collecting messages, exceptions and errors in a log and
displaying them. An Application Log log comprises a log header and a set of messages.
The log header contains general data (type, created by/on, etc.). All this information is
stored in certain tables on the database (BALHDR, BALM).
• You can use the application log to trace when (time), and what (data objects and integration
model) was transferred by whom (user). In addition, the application log provides a detailed
error message if an application error occurred. As a prerequisite, logging must have been
switched on. If errors occurred during transfers, detailed error messages are stored in the
application log of the target system.
• Application log is used by various applications and consists of several tables.
o BALHDR, BALHDRP
Log header with a unique log number: Information that clearly indicates who trig-
gered which event using which transaction/program.
o BALDAT
Log messages and status: Stored in compressed form (as of R/3 Release 4.6C).
• When transferring data via CIF, logs are recorded with object CIF (Core interface applica-
tion log object). All logs are given an expiry date by the application itself (for CIF it is 1 week
in the future).

3.1. Analyze Application Log
• The application log can be called up in SAP APO (/SAPAPO/C3) or in SAP R/3 (transaction
CFG1). The application log provides a detailed error message for queues containing errors.
If errors occur during data transfer they are logged even the setting is ‘No logging’.
• Display entries in the Application log to get detailed information about:
o Date and time of transmission
o Data object and integration model
o Source system, user, and SAP transaction
o Application success and error messages
• In general logs are written in the source and the destination system, if the logging is acti-
vated in the user settings. The name of the sending RFC user is recorded in the application
log of the receiving system. The current user is recorded in the application log of the send-
ing system. Logs in the receiving system are more informative (exception: initial supply of
PPMs).
• Usually, it is sufficient to evaluate the application log on the side where the error occurred.
You can select different sub objects for the CIF object in the R/3 and APO application log.
These include, for example, EP External procurement (inbound), IP In-house production
(inbound), or INITIAL Initial supply and LOCATION Location: customer, plant, vendor (For
performance reasons, the entries for an initial supply and an incremental data transfer are
grouped under the sub object INITIAL). For more sub objects, choose F4 for the Sub object
field on the initial screen of the application log.

3.2. Maintain Logging Level
• The logging level can be maintained user-specific using the following transactions:
o CFC2 in R/3
o /SAPAPO/C4 in APO
• There are different logging levels:
o Normal
Only the number of data records transferred is logged.
o Detailed
The number and content of the data records transferred is logged.
o No logging
Only errors are recorded.
• The application log provides a detailed error message for queues containing errors. If errors
occur during data transfer they are logged even the setting is ‘No logging’.
• Detailed logging can cause large database tables and a loss in performance in productive
operation. For that reason, it should only be activated when the data is required. For pro-
duction operation, SAP recommends ‘No logging’.

3.3. Search in Application Log
• APO: Report /SAPAPO/CIF_APPL_LOG_SEARCH_2
• R/3: Report CIF_APPL_LOG_SEARCH_2
• For error analysis in the APO-R/3 integration environment, it is often necessary to search
for character strings in the CIF application logs. Precondition: Detailed Logging.
• Using the mentioned reports, it is possible to search for character strings in the application
log. This provides improved error analysis if errors occur between APO and R/3.
• To be consistent with good performance, it is recommended to restrict date and time as
closely as possible.

4. Protocol of deleted CIF Entries
Transaction SM21 – Tcode SMQ1 and SMQ2
Deletion of CIF Queues
Do NOT simply delete queues entries : this may cause inconsistencies

5. SCM Queue Manager
Transaction /SAPAPO/CQ:
• CIF queue monitoring for APO and R/3 backend systems
• Appropriate for application monitoring (queues are classified according object
type
• The SCM Queue Manager is called up in SAP APO (transaction /SAPAPO/CQ). It enables
you to check from SAP APO the local system as well as all connected systems. For this,
the output queues are sorted according to their assignment to a publishing type (for exam-
ple, in-house production, planned independent requirement, planning file entry, and so on).
This facilitates the assignment of the listed output queue.
• As with the qRFC Monitor, the SCM Queue Manager monitors application errors in its own
system AND in all connected systems. The SCM Queue Manager is significantly more user
friendly than the qRFC Monitor, due to the way in which its results are,displayed.
• From the SCM Queue Manager you can also call up the most important functions of the
qRFC Monitor (activate/stop/delete queue) or the qRFC Monitor of a target system. For
queues with errors you can navigate to the application log of the receiving system directly
from the SCM Queue Manager.

5.1. SCM Queue Manager - Features
• The results screen consists of a navigation window with a tree structure (left window) and a
main window. In the tree structure, the systems that have been checked are represented as
root nodes and the individual object types as branches.
• Expand the root nodes by clicking on the node. The object types of the selected system are
displayed. The main window will display all queues for a particular system by double-
clicking on the system name.
• For each queue, the following information is shown:
o Queue name: Name of the relevant queue
o Destination: Destination system of the queue. By double-clicking on the destination
column brings you to the transaction SM59. Here, you can edit the settings for the
connection to the relevant system.
o Error text: Description of the queue status
o User: Person responsible for the queue
o Function module: Function module concerned
o Date/time: Time of the queue error
o Waiting: Queue is dependent on other queues

5.2. CIF Cockpit - Settings
• As of SCM 4.1, the new transaction Core Interface Cockpit is available (transaction
code . This transaction refers to as a central entry point for checking all settings and
current system states relevant to CIF. Examples of current system states shown in
the cockpit are the number of existing queue entries including possibly arisen proc-
essing errors and application logs or results of the last delta report run.
• Examples of relevant CIF settings shown in the cockpit are the number and extend
of the integration models, the strategy concerning change transfer of master data
and the block sizes used for initial data transfer.
• The CIF cockpit provides an excellent overview about the settings and additionally
offers the possibility to perform a detailed analysis and correction by branching to
single transactions. Many of the necessary data are determined thereby from the
connected R/3 systems. Detail transactions, which run off in the R/3, are started di-
rectly from the CIF cockpit if the user has the corresponding authorization. For
documentation please refer to the SCM 4.1 documentation.
• The CIF queue manager is not actively supported since SCM 4.0 release. The CIF
cockpit replaces the CIF queue manager, but does not include information on the
mapping of the queue name with the corresponding semantic.

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

CIF Cockpit – Performance measurement
• Performance/Applications (direction Backend R/3 system => APO) shows data concerning
the data volume and the performance on the timely basis specified in the user settings (per
minute, hour, day or month).
• The data is shown for the following documents: purchase documents (purchase orders and
purchase requisitions), in-house production (planned orders and production orders),
planned independent requirements, stocks, sales documents, inspection lots, reservation
items, GI-posted document items, location products and locations (master data).

APO: qRFC Alert Monitor
• The qRFC alert monitor checks chosen local or remote outbound queues for chosen desti-
nation systems. If there are incorrect queue entries, the report sends a message regarding
any such queue to specified users.
• To view the qRFC alert monitor in an APO system, call transaction /SAPAPO/CW and
choose Tools APO Administration Integration Monitor QRFC Alert or run report
/SAPAPO/RCIFQUEUECHECK.
• There is no such monitor in SAP OLTP systems. To monitor the SAP OLTP systems con-
nected to an APO system, monitor them as remote systems from within the APO system.
• It is a good idea to schedule the qRFC alert monitor as background job using report
/SAPAPO/RCIFQUEUECHECK to run every 15 minutes.
• If you have implemented inbound queues and wish to implement alert monitoring for them,
create report /SAPAPO/RCIFINQUEUECHECK as an advanced development according to
SAP Note 392197. If you do this, check also SAP Note 393574.

Example: RZ20 with qRFC Monitors
NOT Authorized
• The Alert Monitor monitors the number of requests in the outbound and inbound queues.
• The queues contain error messages.
• You can append function modules to the collection run for the Alert Monitor.
o These function modules can be executed with every run.
o Alternatively, you can use them for analyzing the results of the collection run.
• For example, because status Stop is not an error status, you can use a function module to
ignore Stop messages in queues.
• For details, see SAP Note 441269

Standard System Monitoring
• Standard SAP Basis Monitoring (APO, OLTP)
o System log - SM21
o ABAP dump - ST22
o System process overview - SM50, SM66, SM51
o Locking - SM12, DB01
o Update - SM13
o Batch - SM37
o Database - DB02
o RFC destination - SM59
o Gateway - SMGW
• To monitor the inbound qRFC of the CIF user specified in the RFC destinations, use trans-
action SM50.
• If there is a qRFC communication error, check it using transaction SM59.

qRFC Monitoring
qRFC monitor
o Display transfer queues
o Display waiting qRFC calls
o Restart waiting calls
qRFC problem causes:
o Communication errors
o Network problems
o Dialog work processes unavailable
o Application errors (non-posting of data to APO)
o Bugs
o Missing master data
o Locking of objects
• Use the qRFC monitor to monitor a variety of errors connected with data transfer through
the CIF, including:
o Communication/network problems (status CPICERR)
o Failure of the application to post data to the target system because of missing master
data for transaction data, locking of objects, or program errors or bugs (status
SYSFAIL)
• In the case of a connection error, the data can usually be transferred successfully after cor-
recting the problem simply by executing the function call again. However, application errors
require intensive analysis. Under some conditions, the function call in the target system
cannot be made to run correctly and the entry must be deleted from the queue to enable
transfer of the data following it. Deletion of function calls from queues may result in in-
consistencies, so this should be avoided if possible.
• As return parameters cannot be delivered back to the sending system for qRFC activities,
potential error messages cannot be directly returned there. For example, even if you find no
error related to CIF in the qRFC monitor on the SAP OLTP side, you may find errors re-
corded in the application log on the APO side.

6. Postprocessing
6.1. CIF Error Handling Default
• A Logical Unit of Work (LUW) is only processed in the receiving system if all data within
that LUW can be sent. If one or more LUW entries cannot be transferred, a queue entry
with the status ‚SYSFAIL‘ is created for the entire LUW. This can quickly lead to
,serialization‘ effect.
• One queue error might block a large number of subsequent entries. This may lead to blocks
of nearly unrelated business data. A single error might cause inconsistencies between the
systems (even LUWs without errors are WAITING).
• Example:
Because of the error in order 1111111111 the entire LUW is stopped.
Orders 2222222222 and 11111111111, both have requests in the stock transfer queue
CFSTKXXX. Because of this dependency, the LUW containing order 222222222222 will be
stopped, too.
• Danger, that all related queues will be stopped --> Data transfer may be stopped.

6.2. CIF Error Handling with Postprocessing
• The new CIF EH looses the strict coupling of LUWs for the transfer. Business data unre-
lated to the error is still integrated. Business data without errors is still consistent between
APO and R/3.
• If the CIF error handling is active, the system does not create faulty queues in the inbound
or outbound queue anymore. If a change to transaction data cannot be posted in the target
system due to an error, the system creates a post processing record with the processing
status 1 (Still for Processing) and the error status 2 (error).
• The system also creates post processing records for all other objects of the qRFC LUW in
which the error occurred (dependent post processing records).
• This has the advantage that queues in the inbound/outbound of a system are no longer-
blocked because of SYSFAIL’s.
Example:
Because of the problem in order 1111111111 the entire LUW will be skipped.
A post processing record is written in the receiving system. This record acts as a notifica-
tion to try it again after the responsible user investigated and removed the reason for the
failure.
As a result order 222222222 can be processed after that though both orders 11111111111
and 2222222222 have requests in the stock transfer queue CFSTKXXX.
The post-processing record is always stored in the target system. On APO side the record is stored
in table /SAPAPO/CIFERRLG, on R/3 side in table CIFERRLOG.

6.3. Postprocessing Facts
• After activation of CIF error handling, the chance of blocked queues after
online data transfers of transactional data will decrease
• Improved analysis of qRFC warnings and errors without automatic inter-
ruption of queue transfer process
• Instead of blocked queues a so called CIF error log will be created
• Warnings/Errors can be solved offline without stopping data transfers
• Integration of new CIF Error Handling in CCMS is currently not planned

6.4. Postprocessing Limitations
• No Postprocessing possible for
o initial loads
o integration of master data ( transaction data only ! )
o ABAP dumps
o APO system / liveCache not available
o IS-specific objects (e.g. DI-backflush)
• Application specific limitations
o See note 602484
• System Administrator has to monitor the CIF post processing records. If there are any re-
cords they should be analysed.
• The danger that all queues are stopped due to interdependencies will be decreased.
• Due to the restrictions, it is however still necessary to monitor CIF queues

6.5. Handling of Postprocessing Records
Postprocessing screen as result of /SAPAPO/CPP
• The post-processing is exclusively started in the SCM system using transaction
/SAPAPO/CPP (single user access to post processing records) or /SAPAPO/CPP1 (for
multiple access to post processing records).
• In the selection screen you have to enter the target system. If the F4-Help for this field does
not provide any data usually the cause is that post processing is not active.
• If the flag ‘Select data from R/3’ is active then also the post processing records from R/3
are taken into account.
• In the display options area of the selection screen you can use the field ‘nodes in navigation
tree’ to define the grouping of the selected post processing records (by product, location
user, APO object type and transaction ID)
• If a postprocessing record was processed it gets the postprocessing status “currently being
transferred” and stays in that status as long as the refresh button is pressed.

6.6. Usage types for Postprocessing
• CIF error handling is called via APO Administration Integration CIF error handling. Al-
ternatively you may use the following transactions:
o /SAPAPO/CPP : CIF Postprocessing
o /SAPAPO/CPP1 : CIF Postprocessing: multiple call
o /SAPAPO/CPP2 : Display CIF Postprocessing Records
o /SAPAPO/CPPR : Reorganize CIF Postprocessing Records
o /SAPAPO/CPPA : CIF Error Handling: Alert
• The reorganization of postprocessing records (transaction /SAPAPO/CPPR) should be
done as regular batch job. The underlying report is /SAPAPO/CIF_POSTPROC_REORG.

6.7. Alerting for Postprocessing Records
Postprocessing alert screen /SAPAPO/CPPA
• To get information about skipped LUWs you should switch on CIF postprocessing alert in
transaction /SAPAPO/CPPA. Please decide which user should obtain the alert.
• F4-Help for the Target System just shows logical systems for which Postprocessing for Er-
rors in Error Handling is activated in transaction /sapapo/c2.

6.8. Prerequisites of Enhanced Queue Display
SMQE on SCM side
SMQE on ECC side

7. CIF Performance
7.1. Check RFC parameters & available resources
Transaction : ST13 Service Tool for CIF Queue Management

7.2. Resources for tRFC (transaction SMQR / SMQS)
• In transaction SMQR and SMQS you can see the resources available according to the set-
tings of the rdisp/rfc* parameters. Call transaction SMQR and select ‚Goto‘ >> ‚QRFC re-
sources‘. The result displays the number of work processes that can be used for processing
the RFC request.
• If DIA WPs for tRFC/qRFC are constantly exhausted (DIA-WPs for tRFC/qRFC = 0), this
indicates a resource problem. Either the RFC resources are not sufficient to accommodate
the load or the qRFC processing is too slow. Note that the number of available resources in
the system is a snapshot which relates to the load status of the system.
• For tRFC and qRFC calls, the tRFC layer reacts by switching to synchronous RFCs instead
of tRFCs or qRFCs. When the RFC is executed synchronously no further processes are
needed for RFC processing. After finishing the processing for asynchronous tRFCs the
program may again obtain free resources for further asynchronous tRFC calls.
• To avoid overload situation the application can check the currently available resources us-
ing function module TH_ARFC_REQUESTS before calling RFCs.

7.3. RFC Parameter settings
Transaction: SARFC > Choose Server Name
Transaction: RZ12 > Choose RFC server group and Server
• The profile parameter rdisp/rfc_check can be used to strengthen the usage of quotas.
Commonly, the problem is that only asynchronous RFC calls will heed to the quotas being
set. If there is a synchronous RFC call which is placed from within an asynchronous RFC,
the quotas will not be adhered to by the synchronous RFC call.
• By setting the parameter rdisp/rfc_check to 2, this will change. Any RFC cascade that starts
with an asynchronous RFC call will be handled as if all of the RFCs in the cascade where
asynchronous RFC calls. You can even increase the value to 3 which would result in ALL
RFCs being forced to adhere to the quotas being set. However, this setting must be tested
carefully, because it may result in resource shortage by means of free dialog work proc-
esses.
• RFC parameters may be changed dynamically (transaction RZ11 or via RFC server groups
transaction RZ12) if resources are continuously exhausted. However, the changes are lost
during restart.
• Wrong configuration of CIF setting/parameters and lack of resources can slow down the
CIF transfer/process or even worst, block the whole system.

Parameter rdisp/rfc_min_wait_dia_wp
Parameter rdisp/rfc_min_wait_dia_wp : This parameter is used to reserve a number of dia-
log work processes for dialog mode. It prevents parallel RFCs from occupying all the proc-
esses.
The parameter rdisp/wp_no_dia specifies the absolute number of dialog work processes.
Example shown: rdisp/rfc_min_wait_dia_wp = 4, rdisp/wp_no_dia = 55
Available DIA work processes for tRFC / qRFC are calculated : No of configured DIA work
processes - No of reserved DIA work processes = (55 – 4 ) = 51.
• The parameter 'rdisp/rfc_min_wait_dia_wp' indicates how many dialog work processes
cannot be blocked using RFC. This prevents all dialog processes being occupied by paral-
lel RFC requests. The default value is 1.
• If 55 dialog work processes are configured on an instance (rdisp/wp_no_dia = 55) and the
parameter rdisp/rfc_min_wait_dia_wp is set to 4, maximal 51 dialog processes can be used
for processing tRFC/qRFC call. In either case, 4 dialog processes are kept free for ‘real’
dialog activities.
• In the system, this can be verified as follows:
o Determine the AS group which is assigned to the QIN scheduler (transaction SMQR)
o Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding
AS group)
o Determine the number of configured DIA work processes (Min. no of free WPs) Attention:
This number is taken from the active operation mode, not necessarily from the instance pro-
file !
• These numbers are visible in transaction SMQR => Goto => QRFC Resources
Careful : the number of dialog work
processes can change with
operation modes

Parameter rdisp/rfc_max_own_used_wp
Example: rdisp/rfc_max_own_used_wp = 75 (%), rdisp/wp_no_dia = 55
Available DIA work processes for tRFC / qRFC used by one user at a time: Share of config-
ured DIA work processes (75 % of 55) = 41.
• To avoid that all available RFC resources are used by one user, the parameter
rdisp/rfc_max_own_used_wp can be set. When a user issues an RFC call it is checked
how many processes the user has already occupied (RFCs or online dialog steps). The
value is specified as a percentage of the configured dialog work processes. The default
value is 75 (%).
• Example: There are 55 dialog work processes configured. If parameter
rdisp/rfc_max_own_used_wp is set to 75, maximal 41 dialog processes can be used by a
certain RFC user / application at the same time. This is the Maximum of the number of dia-
log work processes than can be used for tRFC/qRFC (55-5=51) and the share defined by
rdisp/rfc_max_own_used_wp (75 % of 55 = 41).
• In the system, this can be verified as follows:
o Determine the AS group which is assigned to the QIN scheduler (transaction SMQR)
o Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding
AS group)
o Determine the number of configured DIA work processes (Max. no of WPs used) Attention:
This number is taken from the active operation mode, not necessarily from the instance pro-
file !
• The available resources are visible in transaction SMQR => Goto => QRFC Resources.
Note that the number of available resources in the system is a snapshot which relates to
the load status of the system.
• It is reasonable and recommended to restrict the resources for one RFC user / application
because there may be other applications working with RFC calls and occupy dialog work
processes, for example IDoc processing.
Important: Display shows only a snap-
shot of currently free dialog work
processes for tRFC / qRFC

Other RFC Parameters
rdisp/rfc_use_quotas Activate / Deactivate resource determination
Must be set to 1, NEVER change it !
Default: 1
rdisp/rfc_max_queue Quota (%) of RFC requests in dispatcher queue
(rdisp/elem_per_queue)
Default: 5
rdisp/rfc_max_login Quota (%) for RFC logons of the total number of
logons per instance (rdisp/tm_max_no)
Default: 90
rdisp/rfc_max_own_login Quota (%) for RFC logons of one dedicated user
Default: 25
rdisp/rfc_max_comm_entries Quota for the number of used communication entries
(rdisp/max_comm_entries), ~100 Byte shared memory
Default: 90
rdisp/rfc_max_wait_time Maximum number in seconds that a work process is
asleep after unssuccessful resource determination.
• If the parameter rdisp/rfc_use_quotas is set to 1 the RFC resource parameters are used.
You should NEVER change the default value. If the parameter is set to 0, then you can no
longer work with the parallel RFC since no server can be determined for the next RFC.
• The parameter rdisp/rfc_max_queue is percentage of the RFC entries that are allowed in
the dispatcher queue until no further resources are given to RFC processing. However, the
elements in the dispatcher queue are only increasing significantly if all work processes are
used. Vice versa, as long as work processes are free, the dispatcher queue is (almost)
empty. Therefore, as long as other RFC parameters are set, this parameter is not effec-
tively controlling RFC load.
• The parameter rdisp/rfc_max_login and rdisp/rfc_max_own_login are percentages of the
logins of a single RFC user and the total of all RFC users compared to the maximum num-
ber of logins allowed. A dialog user usually stays logged on for a long time, usually all the
time while working with the SAP System. Therefore, the number of total connections al-
lowed is usually much higher than the work processes configured. An RFC user however,
usually logs off, when the RFC is processed. The total connections of RFC users is close to
the number of active work processes processing RFCs. Therefore, this parameter is not ef-
fectively controlling RFC load as long as other parameters are set.
• For more information on these parameters see SAP note 74141.

7.4. Check Queue status
Possible Problems: R/3 -> APO
Error Symptom Where to look first
Data not even sent No queue generated Active integration model?
Data sent, but not Received Stuck queue Application log of receiving
system
Data sent, but not Received Waiting queue QRFC Monitor: Find out for
which queue your queue is
waiting
Error in data selection, i.e.
when activating an integra-
tion model
No queue generated Sending log in R/3 (if avail-
able)

7.5. SMQ2 : Large number of entries / LUWs
• Queue information:
o Number of Entries Displayed = Number of entries in all queues
o Number of Queues Displayed = Number of different queues (=>objects)
• Problem:
o The number of entries in the queue is growing faster as they are processed.
• The data constellation inside the CIF queue varies widely and depends highly on the ob-
jects types.
• Number of queues = Number of entries:
o Each object is sent in a separate queue and consequently one LUW uses exactly one
queue. There are no dependencies to other queues.
o If the RFC resources are sufficient the QIN scheduler can process the LUWs with a high
parallel degree. The processing is usually fast and there is no risk that errors in queue proc-
essing block each other. In other words, there is no serialization at all.
o In this case, a resource problem can be assumed.
• Number of queues << Number of entries:
o The queues contain a high number of objects or one LUW owns objects in multiple queues.
There are many dependencies to other queues as the LUWs are touching the same objects.
The queue monitor does not show that LUWs share queues.
o The QIN scheduler determines which LUW can be processed first to keep the right se-
quence. In case of highly dependent LUWs this step needs more time. The parallel degree
of processing is limited even though enough resources are available.
o The risk that errors in queue processing block each other is very high. In opposite to the
situation above, additional resources have only limited effect on CIF processing speed.

7.6. Status SYSFAIL in CIF queue
Status SYSFAIL:
• A serious error occurred in the target system while executing the LUW. For those queue
entries, no automatic re-processing occurs through the QIN/QOUT scheduler. When you
double-click on this status, the system displays an error text.
• SYSFAIL errors may have various reasons. They can be caused by missing or incomplete
master data, liveCache errors (e.g. scheduling), termination of function modules / reports
responsible for LUW processing.
• Additional information about error reason can be found using the following transactions:
o Application log /SAPAPO/C3 (APO system) or CFG1 (R/3 system): Errors are recorded in
the application log independent of the user settings (No logging, Normal, Detailed logging).
o Short dump analysis ST22: In case of short dumps, no application log is recorded as this is
done after LUW processing is finished.
o System log SM21 and dev_* trace files
• Check number of faulty queues entries / LUWs
using queue monitor
• SMQ2 => Execute => click bell button once
Problem : Error in LUW processing block the entire queue and
subsequent LUWs cannot be processed -> Serialization effect

7.7. Relationship LUW / CIF queue
SMQ2 => Execute => click bell button twice
• A LUW is uniquely defined by the same TID. The LUW may contain several objects that are
transferred via different queue names. One LUW can only be processes in exactly one
work process.
• An error in transferring or processing of the LUW causes the whole queue to be stopped.
Such a queue block not only affects the LUW containing the faulty queue entry, but also all
LUWs containing subsequent queue entries. This is called serialization effect.
• Due to this the data transfer may be severely restricted and some data cannot be trans-
ferred at all. Consequently, there are inconsistencies between source and target system.
For that reason, it is of utmost importance to rectify incorrect queue entries in time. Monitor-
ing concept/handbook suitable to the Best Practices is absolutely necessary and has to be
established before go-live involving system administration AND business department as
well.

7.8. Stuck queues
Queues with status SYSFAIL
Try to restart the queue.
If error occurs again:
First hint: error message which is displayed with the queue in the qrfc monitor
• Be careful: Message number in the queue monitor is always SR053 !! You do not get the
real message number in the queue monitor!
Application log in receiving system (APO)
• Either access via double click on TID ( preconditions: enhanced queue display customized )
• Or (better) log on to APO and search for log in Transaction /SAPAPO/C3
o Enter TID obtained from the queue monitor in the field External ID (Attention: not in
the field Transaction code)
• Search for OSS notes suitable for the error messages
If no application log found, it is usually a dump
• Search for dump in APO with Transaction ST22
• Search for OSS notes suitable for the dumps

Cif monitoring-guideline-v3

More Related Content

What's hot

Viewers also liked

Similar to Cif monitoring-guideline-v3

Recently uploaded

In this document

Cif monitoring-guideline-v3