1

2
 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 system.
You can enter the following parameters:
Destination Enter the name of your destination.
Max. Conn. Maximum number of connections, according to SAP Note 1403974 it is
recommended to set it to 25% of the dialog work processes defined in the TARGET system (
minimum value of all used operation modes ) to avoid flooded dialogs due to CIF traffic.
Max Runtime Maximum scheduler processing time for a destination in seconds (default is 60
seconds).
According to SAP Note 1272327 it is recommended to increase Max. Runtime to 1800 seconds
to enable the processing of complex LUWs.
W/o trfc This prevents tRFC LUWs from being processed by the Outbound Scheduler. This
means that the tRFCs for this destination are then executed when the Commit Work is
executed.
Scheduler Monitoring - Enables the processing time of queues to exceed 1800 seconds. Value
0 equals 1800 seconds. Please check coding corrections according to SAP Note 1500048
before setting this parameter higher than 1800 seconds.
The parameters set for the different destinations do not depend on the number of queue
entries.

3
 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
destination then appears as type N.

4
 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:
Mode : D for dialog, B for background, depending on the type of the work process that should
be used for processing queue entries.
Max Runtime :Time spent by the inbound scheduler for working on the queue. If this time limit is
exceeded, LUWs of other registered queues are distributed to work processes by the inbound
scheduler. The default value of 60 seconds should be increased to 1800 seconds in case of
large LUWs ( see SAP note 1272327 ).
Logical Destination : Logical destination (defined in transaction SM59) for processing LUWs in
this queue. This enables you to change the client, user, and language for all qRFC LUWs.
Attempts : Number of retries
Pause : Delay between retries (CPICERR)
Scheduler Monitoring - Enables the processing time of queues to exceed 1800 seconds. Value
0 equals 1800 seconds. Please check coding corrections according to SAP Note 1500048
before setting this parameter higher than 1800 seconds.
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.

5
 If a qRFC LUW has been written in a registered queue, and the QIN Scheduler is not
already 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.

6
 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
transaction SMQ2 (report RSTRFCM3) and for outbound queues with transaction
SMQ1 (report RSTRFCM1). Queue name CF* is related to the CIF.

8
 QRFC queue names for the CIF real-time transfer are always set up according to the
following rules:
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 inbound. It then changes from block to block of an initial data transfer.
The queue names differs for the direction R/3 => APO and APO => R/3. See the
attachment and SAP Note 786446 for a list of queue names and their meaning.

9
 Both in OLTP and APO, you can start the qRFC monitor for outbound queues with
transaction 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, double-clicking the queue displays the individual calls. Queue names are
generated by the application 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
system. To find this entry in the application log:
For the call with the qRFC error, copy the value in field TID (transaction ID).
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 Advanced Planner and Optimizer Integration Model Change
Transfer Transaction Data.

10
 To display queue problems 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:
Status : The queue status of the queues will be shown. For the possible status values please
read the SAP note 378903.
Date 1 / Time 1 : Shows the date/time when the first LUW was written into the queue.
Double click on the status shows more detailed information about the SYSFAIL.

11
 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:
Date and time of transmission
Data object and integration model
Source system, user, and SAP transaction
Application success and error messages
In general logs are written in the source and the destination system, if the logging is
activated 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 sending 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.

13
 The logging level can be maintained user-specific using the following transactions:
CFC2 in R/3
/SAPAPO/C4 in APO
There are different logging levels:
Normal
Only the number of data records transferred is logged.
Detailed
The number and content of the data records transferred is logged.
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 production operation, SAP recommends No logging.

14
 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 urgently recommended to restrict date
and time as closely as possible.

15
 If queue entries are deleted, the information is logged into the system log with
transaction code SMQ1/SMQ2.

16
17
 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 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.

18
 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:
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

19
 As of SCM 4.1, the new transaction Core Interface Cockpit is available (transaction
code /SAPAPO/CC. 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 processing 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
directly 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.

20
 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.
CIF cockpit has a central default profile. Personalized setting can be maintained per
user in separate user profiles.

21
 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).

22
 The qRFC alert monitor checks chosen local or remote outbound queues for chosen
destination 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
connected 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.

23
 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.
These function modules can be executed with every run.
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.

24
 To monitor the inbound qRFC of the CIF user specified in the RFC destinations, use
transaction SM50.
If there is a qRFC communication error, check it using transaction SM59.

25
 Use the qRFC monitor to monitor a variety of errors connected with data transfer through
the CIF, including:
Communication/network problems (status CPICERR)
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
correcting 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 inconsistencies, 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 recorded in the application log on the APO side.

26
27
28
 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.

29
 The new CIF EH looses the strict coupling of LUWs for the transfer. Business data
unrelated 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 SYSFAILs.
Example:
Because of the problem in in order 1111111111 the entire LUW will be skipped.
A post processing record is written in the receiving system. This record acts as a notification
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.

30
31
 System Administrator has to monitor the CIF post processing records. If there are any
records 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.

32
 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.
Postprocessing an object does not reprocess the content of the failed CIF entry, but
schedules a retransfer of the current object value.

33
Please note that postprocessing

34
35
36
37
 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 times are stored in application
statistic file (ASTAT). Inbound scheduler time necessary to read, dispatch and start
the queue entries are not taken into account.
The results can be evaluated in the CIF Cockpit with different granularity (day, hour,
minute) depending on the settings made in the user profile.

38
 Depending on the setting in the user profile, the CIF cockpit evaluates the
performance measurements in certain intervals. You can use the Save and Delete
CIF Cockpit Performance Data (/SAPAPO/CC_SAVE_PERF_DATA ) program to
save these evaluations over a certain period of time. You can then have the system
display the saved evaluations in the CIF cockpit (smallest evaluation interval = 1
hour).
You can also run this function as a background job.
(Integrated in customizing: SAP Integration with SAP Components =>Integration via
APO Core Interface (CIF) => Basic Settings for Data Transfer => Save CIF Cockpit
Performance Data)

39
 By default CIF error handling is not switched on, so it has to be switched on explicitly in IMG
of the SCM system
( Transaction SPRO -> SAP Reference IMG -> Advanced Planning and Optimization ->
Basis Settings -> Integration -> Business System Group -> Assign Logical System and
Queue Type ) or in transaction /SAPAPO/C2.
To activate CIF error handling the row for the connected R/3 system(s) must be used. It
always activates CIF error handling for BOTH directions ( to R/3 and SCM ).
Every created CIF entry contains the information about the CIF error handling so the ERP
target system scheduler ( and the executed function modules ) know how to proceed in
case a CIF error.

40
 CIF error handling is called via APO Administration Integration
CIF error handling. Alternatively you may use the following transactions:
/SAPAPO/CPP : CIF Postprocessing
/SAPAPO/CPP1 : CIF Postprocessing: multiple call
/SAPAPO/CPP2 : Display CIF Postprocessing Records
/SAPAPO/CPPR : Reorganize CIF Postprocessing Records
/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.

41
 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
Errors in Error Handling is activated in transaction /sapapo/c2.

42
 To use the enhanced display functionality the queue name CF* has to be registered with
the display program /SAPAPO/CIF_QUEUE_EVENT2 on SCM and with program
CIFQEV02 on OLTP side in transaction SMQE.

43
 Delete entries in the application log regularly by scheduling the following as background
jobs:
In the OLTP system, report RDELALOG
In the APO system, report /SAPAPO/RDELLOG
Alternatively, in both OLTP and APO you can schedule report SBAL_DELETE. It gives
you more control of what is deleted.
To delete entries manually, do the following:
In OLTP, choose Logistics Central functions Supply Chain Planning Interface Core
Interface Advanced Planner and Optimizer Monitoring Application Log Delete Entries
(transaction CFGD)
In APO, choose Tools APO Administration Integration Monitor Application Log
Delete Entries (transaction /SAPAPO/C6)

44
45
46
47
48
49
50
51
52
53
54
55