Professional Documents
Culture Documents
Cif Monitoring Guideline v3 160625184201 PDF
Cif Monitoring Guideline v3 160625184201 PDF
it
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
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
The parameters set for the different destinations do not depend on the number of
queue entries.
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.
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.
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.
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.
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.
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.
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.
CIF Monitoring Guideline V3.doc Page 10 of 48 Created on 7/27/2011 3:09:00 PM
giampiero.gallarate@smart-media.it
If an error (SYSFAIL) is shown in the status field you can get more detailed information
when you double click the status.
Initial transfer:
o CFLD<logical source system>_<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 names SCM => R/3 (for a complete list see Note 786446)
WAITING Waiting until the LUWs with a higher priority are executed
RETRY Temporary problem during execution (locking issue), background job sched-
uled
SYSFAIL A serious error has occurred in the target system (APO) while the LUW
was executed
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.
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.
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).
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.
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.
The logging level can be maintained user-specific using the following transactions:
o CFC2 in R/3
o /SAPAPO/C4 in APO
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.
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.
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.
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.
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.
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.
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).
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.
NOT Authorized
The Alert Monitor monitors the number of requests in the outbound and inbound queues.
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.
To monitor the inbound qRFC of the CIF user specified in the RFC destinations, use trans-
action SM50.
qRFC Monitoring
qRFC monitor
o Display transfer queues
o Display waiting qRFC calls
o Restart waiting calls
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
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.
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 SYSFAILs.
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.
After activation of CIF error handling, the chance of blocked queues after
online data transfers of transactional data will decrease
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.
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.
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
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.
7. CIF Performance
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.
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.
Available DIA work processes for tRFC / qRFC are calculated : No of configured DIA work
processes - No of reserved DIA work processes = (55 4 ) = 51.
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.
These numbers are visible in transaction SMQR => Goto => QRFC Resources
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 (%).
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.
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.
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.
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
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.
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!