CIF Monitoring Guideline V3

giampiero.gallarate@smart-media.
it
Table of Content
Table of Content ............................................................................................................1 1. Useful transactions ................................................................................................3
1.1. 1.2. OLTP-R/3 .....................................................................................................................................3 APO-R/3 .......................................................................................................................................3
1.
Inbound & Outbound Queues................................................................................4

1.1. 1.2. 1.3. 1.4. Outbound Scheduler SMQS Configuration ...............................................................................4 Outbound Scheduler SMQS - Monitoring.....................................................................................5 Inbound Scheduler - Configuration .............................................................................................6 Inbound Scheduler SMQR Monitoring ......................................................................................7
2.
qRFC monitor: Motivation......................................................................................8

2.1. 2.2. 2.3. 2.4. Queue Monitor APO and R/3 backend......................................................................................9 Local Outbound Queue Overview ..............................................................................................10 Display Inbound Queues with Problems ....................................................................................11 Logic of queue names for CIF ....................................................................................................12
3.
Application logs: Motivation................................................................................16

3.1. 3.2. 3.3. Analyze Application Log .............................................................................................................17 Maintain Logging Level ..............................................................................................................18 Search in Application Log...........................................................................................................19
4. 5.
Protocol of deleted CIF Entries ...........................................................................20 SCM Queue Manager............................................................................................21

5.1. 5.2. 5.3. SCM Queue Manager - Features ...............................................................................................22 CIF Cockpit - Settings ................................................................................................................23 CIF cockpit user profile............................................................................................................24
6.
Postprocessing.....................................................................................................30
6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. CIF Error Handling Default .........................................................................................................30 CIF Error Handling with Postprocessing ....................................................................................31 Postprocessing Facts .................................................................................................................32 Postprocessing Limitations.........................................................................................................33 Handling of Postprocessing Records .........................................................................................34 Usage types for Postprocessing ................................................................................................35 Alerting for Postprocessing Records..........................................................................................36 Prerequisites of Enhanced Queue Display ................................................................................37
7.
CIF Performance ...................................................................................................38

7.1. 7.2. 7.3. Check RFC parameters & available resources ..........................................................................38 Resources for tRFC (transaction SMQR / SMQS) .....................................................................39 RFC Parameter settings.............................................................................................................40
Page 1 of 48 Created on 7/27/2011 3:09:00 PM
CIF Monitoring Guideline V3.doc
giampiero.gallarate@smart-media.it
7.4. 7.5. 7.6. 7.7. 7.8. Check Queue status...................................................................................................................44 SMQ2 : Large number of entries / LUWs ...................................................................................45 Status SYSFAIL in CIF queue....................................................................................................46 Relationship LUW / CIF queue...................................................................................................47 Stuck queues..............................................................................................................................48
Page 2 of 48
Created on 7/27/2011 3:09:00 PM
1. Useful transactions
1.1. OLTP-R/3
Transaction CFM1 CFM2 CFM3 CFM4 CFM5 CFM6 CFM7 CFS0 CFS1 CFG1 Description Create/Generate Integration Model Activate or Deactivate Integration Model Activate Integration model (Possible in Background) Display Integration Model Search for Filter Objects in Integration Model Change Integration Model Delete Integration Model Display one or all Outbound queues Display one or all Inbound queues Application log
1.2. APO-R/3
Transaction SMQ1 SMQ2 /SAPAPO/C3 /SAPAPO/CCR /SAPAPO/CQ /SAPAPO/CC /SAPAPO/CPP1 SMQS SMQR Description qRFC-Monitor Outbound queues qRFC-Monitor Inbound queues Application log CIF-Delta Report SCM Queue Manager CIF Cockpit CIF Postprocessing Outbound scheduler Inbound scheduler
Page 3 of 48
Created on 7/27/2011 3:09:00 PM
1. Inbound & Outbound Queues

1.1. Outbound Scheduler SMQS Configuration
Use transaction SMQS to register a destination
The QOUT Scheduler was implemented to improve performance when sending qRFC and tRFC messages. The processing of all queues is scheduled by the QOUT Scheduler. With help of the QOUT Scheduler it is possible to define how many work processes are used for sending the LUWs to a specific destination. The number of simultaneously sent tRFCs and qRFCs is limited and consequently the QOUT scheduler provides a kind of control over the resources on the receiving system. 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 seconds (default is 60 seconds) You can use this setting to allocate more processing time to individual queues and restrict the processing time of others. o NO_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. 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 destination then appears as type N, like destination PRD in the example above.
Page 5 of 48
Created on 7/27/2011 3:09:00 PM
1.3. Inbound Scheduler - Configuration

Use transaction SMQR to register a queue name
The QIN scheduler is configured on the basis of queue names. So if new queue names are used, they must be registered, otherwise their entries will not be processed. The inbound scheduler does not process the LUWs but triggers their processing in asynchronously started work processes. Parameters for the inbound scheduler are: o EXEMODE: D for dialog, B for background, depending on the type of the work process 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.
Page 6 of 48
Created on 7/27/2011 3:09:00 PM
1.4. Inbound Scheduler SMQR Monitoring
Status: Normally, status is Inactive. Manual activation can be forced. Last update: Status is updated every 2 minutes. Name of AS group: Use transaction RZ12 to define a group of application servers (AS).
If a qRFC LUW has been written in a registered queue, and the QIN Scheduler is not 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.
Page 7 of 48
Created on 7/27/2011 3:09:00 PM
2. qRFC monitor: Motivation
The communication between R/3 and SCM is based on the asynchronous transfer technology 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 between 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 return 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 errors 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 objects, missing master data for specific transaction data. Application errors cannot be solved by the system and must be dealt with by the system administrator.
Page 8 of 48
Created on 7/27/2011 3:09:00 PM
2.1. Queue Monitor APO and R/3 backend
SMQ1 - qRFC Monitor for the outbound queue. Use this transaction to monitor the status of the LUWs in the outbound queue and restart any hanging queues manually. SMQ2 - qRFC Monitor for the inbound queue. Use this transaction to monitor the status of the LUWs in the outbound queue. Both in OLTP and APO, you can start the qRFC monitor for inbound queues with transaction SMQ2 (report RSTRFCM3) and for outbound queues with transaction SMQ1 (report RSTRFCM1). Queue name CF* is related to the CIF.
Page 9 of 48
Created on 7/27/2011 3:09:00 PM
2.2. Local Outbound Queue Overview

Transaction SMQ1 handles like SMQ2
Both in OLTP and APO, you can start the qRFC monitor for outbound queues with 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: 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 Advanced 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 values 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.
Page 11 of 48
Created on 7/27/2011 3:09:00 PM
2.4. Logic of queue names for CIF

Real-time transfer in general: o CF<CIF object ID><serialization character string> Direction R/3 APO: CFSLS<n> o First 2 letters CF for CIF o Next letters represent the object type o Followed by the order number, e.g. CFSLS0000010003 for a sales order Direction APO R/3: CFIPXXXXXXXXXXXXXXXXXXXX o First two digits letters CF for CIF o Next 2 letters for object type, e.g. IP = In-house Production o Following digits: first 20 pertinent characters of the order GUID
Initial transfer: o CFLD<logical source system>_<counter><subcounter> Initial transfer aborted: o CF_LOAD_ABORT<counter><subcounter>
QRFC queue names for the CIF real-time transfer are always set up according to the following rules: o CF<CIF object ID><serialization character string> For the initial data upload, the qRFC queue name is set up according to the following rule: CF_LOAD_ABORT<counter><subcounter> The <counter> counter changes from initial data transfer to initial data transfer. You only have the second <subcounter> counter if there are parallel settings in the SCM APO inbound. 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.
Page 12 of 48
Created on 7/27/2011 3:09:00 PM
Queue names R/3 => SCM (for a complete list see Note 786446)
Queue name CFSTK* CFPO* CFPLO* CFSLS* CFRSV* CFCNF* CFPIR* CFMAT* CFFCC* CFPCM* CFCLA* CFCHR* CFCUVT* CFSHP* CFTL* CFTG* FC* CFCB* CFCR* CFCD** CFCL* Description Stock Purchase orders and purchase requisition Planned orders/Production orders Sales orders Manual reservations Confirmations Planned independent requirements (created in R/3) Reduction of PIRs Reduction of PIRs (if separate Imod is used) Production campaigns Master data for classes Master data for characteristics Planning tables Transports (TP/VS scenario) Transport locks (TP/VS scenario) Deletion of temporary quantity assigments GATP (in one LUW with CFSLS*) Fulfillment coordination (only if qRFC consumption is used) CBase Configuration CBase Configuration, special case CDP Configuration Classification
Page 13 of 48
Created on 7/27/2011 3:09:00 PM
Queue names SCM => R/3 (for a complete list see Note 786446)
Queue name Description
CFEP* CFIP* CFFO* CFCO* CFPC* CFSH* CFDL* CFRV* CFPF* CFCF* CFCD* CFRP*
External Procurement APO - R/3 In-house Production APO - R/3 Planned independent Requirements Sales Orders Production Campaign Transport Delivery Reservations Planning file entry (IS Automotive) Confirmation (IS Automotive) Confirmation of deletions (IS Automotive) Reporting points (IS Automotive)
Page 14 of 48
Created on 7/27/2011 3:09:00 PM
Common Queue Status Note 378903

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 scheduled
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
READY Queue is ready for transmission. If a queue was locked manually and then unlocked without 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 external interference. SYSFAIL A serious error occurred in the target system while the first LUW of the queue was executed. 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.
Page 15 of 48
Created on 7/27/2011 3:09:00 PM
3. Application logs: Motivation
The Application Log is a tool for collecting messages, exceptions and errors in a log and displaying them. An Application Log log comprises a log header and a set of messages. The log header contains general data (type, created by/on, etc.). All this information is stored in certain tables on the database (BALHDR, BALM). You can use the application log to trace when (time), and what (data objects and integration model) was transferred by whom (user). In addition, the application log provides a detailed error message if an application error occurred. As a prerequisite, logging must have been switched on. If errors occurred during transfers, detailed error messages are stored in the application log of the target system. Application log is used by various applications and consists of several tables. o BALHDR, BALHDRP Log header with a unique log number: Information that clearly indicates who triggered 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 application log object). All logs are given an expiry date by the application itself (for CIF it is 1 week in the future).
Page 16 of 48
Created on 7/27/2011 3:09:00 PM
3.1. Analyze Application Log
The application log can be called up in SAP APO (/SAPAPO/C3) or in SAP R/3 (transaction CFG1). The application log provides a detailed error message for queues containing errors. If errors occur during data transfer they are logged even the setting is No logging. Display entries in the Application log to get detailed information about: o Date and time of transmission o Data object and integration model o Source system, user, and SAP transaction o Application success and error messages In general logs are written in the source and the destination system, if the logging is 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.
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 production operation, SAP recommends No logging.
Page 18 of 48
Created on 7/27/2011 3:09:00 PM
3.3. Search in Application Log
APO: Report /SAPAPO/CIF_APPL_LOG_SEARCH_2

R/3: Report CIF_APPL_LOG_SEARCH_2
For error analysis in the APO-R/3 integration environment, it is often necessary to search for character strings in the CIF application logs. Precondition: Detailed Logging. Using the mentioned reports, it is possible to search for character strings in the application log. This provides improved error analysis if errors occur between APO and R/3. To be consistent with good performance, it is recommended to restrict date and time as closely as possible.
Page 19 of 48
Created on 7/27/2011 3:09:00 PM
4. Protocol of deleted CIF Entries

Transaction SM21 Tcode SMQ1 and SMQ2
Deletion of CIF Queues
Do NOT simply delete queues entries : this may cause inconsistencies
Page 20 of 48
Created on 7/27/2011 3:09:00 PM
5. SCM Queue Manager

Transaction /SAPAPO/CQ:
CIF queue monitoring for APO and R/3 backend 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 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.
Page 21 of 48
Created on 7/27/2011 3:09:00 PM
5.1. SCM Queue Manager - Features
The results screen consists of a navigation window with a tree structure (left window) and a main window. In the tree structure, the systems that have been checked are represented as root nodes and the individual object types as branches. Expand the root nodes by clicking on the node. The object types of the selected system are displayed. The main window will display all queues for a particular system by doubleclicking 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
Page 22 of 48
Created on 7/27/2011 3:09:00 PM
5.2. CIF Cockpit - Settings
As of SCM 4.1, the new transaction Core Interface Cockpit is available (transaction code . This transaction refers to as a central entry point for checking all settings and current system states relevant to CIF. Examples of current system states shown in the cockpit are the number of existing queue entries including possibly arisen 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.
Page 23 of 48
Created on 7/27/2011 3:09:00 PM
5.3. CIF cockpit user profile
To use the CIF cockpit, you need an RFC user and dialog authorization for every 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 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.
Page 24 of 48
Created on 7/27/2011 3:09:00 PM
CIF Cockpit Performance measurement
Performance/Applications (direction Backend R/3 system => APO) shows data concerning the data volume and the performance on the timely basis specified in the user settings (per minute, hour, day or month). The data is shown for the following documents: purchase documents (purchase orders and purchase requisitions), in-house production (planned orders and production orders), planned independent requirements, stocks, sales documents, inspection lots, reservation items, GI-posted document items, location products and locations (master data).
Page 25 of 48
Created on 7/27/2011 3:09:00 PM
APO: qRFC Alert Monitor
The qRFC alert monitor checks chosen local or remote outbound queues for chosen 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.
Page 26 of 48
Created on 7/27/2011 3:09:00 PM
Example: RZ20 with qRFC Monitors NOT Authorized
The Alert Monitor monitors the number of requests in the outbound and inbound queues. The queues contain error messages. You can append function modules to the collection run for the Alert Monitor.
o o 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
Page 27 of 48
Created on 7/27/2011 3:09:00 PM
Standard System Monitoring
Standard SAP Basis Monitoring (APO, OLTP)

o o o o o o o o
o
System log - SM21 ABAP dump - ST22 System process overview - SM50, SM66, SM51 Locking - SM12, DB01 Update - SM13 Batch - SM37 Database - DB02 RFC destination - SM59 Gateway - SMGW
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.
Page 28 of 48
Created on 7/27/2011 3:09:00 PM
qRFC Monitoring
qRFC monitor
o o
o
Display transfer queues Display waiting qRFC calls Restart waiting calls
qRFC problem causes:

o
o
Communication errors
Network problems Dialog work processes unavailable Application errors (non-posting of data to APO) o Bugs o Missing master data o Locking of objects o o
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 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.
Page 29 of 48
Created on 7/27/2011 3:09:00 PM
6. Postprocessing
6.1. CIF Error Handling Default
A Logical Unit of Work (LUW) is only processed in the receiving system if all data within that LUW can be sent. If one or more LUW entries cannot be transferred, a queue entry with the status SYSFAIL is created for the entire LUW. This can quickly lead to ,serialization effect. One queue error might block a large number of subsequent entries. This may lead to blocks of nearly unrelated business data. A single error might cause inconsistencies between the systems (even LUWs without errors are WAITING). Example: Because of the error in order 1111111111 the entire LUW is stopped. Orders 2222222222 and 11111111111, both have requests in the stock transfer queue CFSTKXXX. Because of this dependency, the LUW containing order 222222222222 will be stopped, too. Danger, that all related queues will be stopped --> Data transfer may be stopped.
Page 30 of 48
Created on 7/27/2011 3:09:00 PM
6.2. CIF Error Handling with Postprocessing
The new CIF EH looses the strict coupling of LUWs for the transfer. Business data 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 longerblocked 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 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.
Page 31 of 48
Created on 7/27/2011 3:09:00 PM
6.3. Postprocessing Facts

After activation of CIF error handling, the chance of blocked queues after online data transfers of transactional data will decrease Improved analysis of qRFC warnings and errors without automatic interruption 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
Page 32 of 48
Created on 7/27/2011 3:09:00 PM
6.4. Postprocessing Limitations

No Postprocessing possible for
o o o o o initial loads integration of master data ( transaction data only ! ) ABAP dumps APO system / liveCache not available 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 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
Page 33 of 48
Created on 7/27/2011 3:09:00 PM
6.5. Handling of Postprocessing Records

Postprocessing screen as result of /SAPAPO/CPP
The post-processing is exclusively started in the SCM system using transaction /SAPAPO/CPP (single user access to post processing records) or /SAPAPO/CPP1 (for multiple access to post processing records). In the selection screen you have to enter the target system. If the F4-Help for this field does not provide any data usually the cause is that post processing is not active. If the flag Select data from R/3 is active then also the post processing records from R/3 are taken into account. In the display options area of the selection screen you can use the field nodes in navigation tree to define the grouping of the selected post processing records (by product, location user, APO object type and transaction ID) If a postprocessing record was processed it gets the postprocessing status currently being transferred and stays in that status as long as the refresh button is pressed.
Page 34 of 48
Created on 7/27/2011 3:09:00 PM
6.6. Usage types for Postprocessing
CIF error handling is called via APO Administration ternatively you may use the following transactions:
o o o o o
Integration
CIF error handling. Al-
/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.
Page 35 of 48
Created on 7/27/2011 3:09:00 PM
6.7. Alerting for Postprocessing Records

Postprocessing alert screen /SAPAPO/CPPA
To get information about skipped LUWs you should switch on CIF postprocessing alert in transaction /SAPAPO/CPPA. Please decide which user should obtain the alert. F4-Help for the Target System just shows logical systems for which Postprocessing for Errors in Error Handling is activated in transaction /sapapo/c2.
Page 36 of 48
Created on 7/27/2011 3:09:00 PM
6.8. Prerequisites of Enhanced Queue Display

SMQE on SCM side
SMQE on ECC side
Page 37 of 48
Created on 7/27/2011 3:09:00 PM
7. CIF Performance
7.1. Check RFC parameters & available resources
Transaction : ST13 Service Tool for CIF Queue Management
Page 38 of 48
Created on 7/27/2011 3:09:00 PM
7.2. Resources for tRFC (transaction SMQR / SMQS)
In transaction SMQR and SMQS you can see the resources available according to the settings of the rdisp/rfc* parameters. Call transaction SMQR and select Goto >> QRFC resources. 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 using function module TH_ARFC_REQUESTS before calling RFCs.
Page 39 of 48
Created on 7/27/2011 3:09:00 PM
7.3. RFC Parameter settings

Transaction: SARFC > Choose Server Name Transaction: RZ12 > Choose RFC server group and 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 processes. 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.
Page 40 of 48
Created on 7/27/2011 3:09:00 PM
Parameter rdisp/rfc_min_wait_dia_wp
Parameter rdisp/rfc_min_wait_dia_wp : This parameter is used to reserve a number of dia-
log work processes for dialog mode. It prevents parallel RFCs from occupying all the processes. 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.
Careful : the number of dialog work processes can change with operation modes
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 parallel 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 o o Determine the AS group which is assigned to the QIN scheduler (transaction SMQR) Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding AS group) 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 profile !
These numbers are visible in transaction SMQR => Goto => QRFC Resources
Page 41 of 48
Created on 7/27/2011 3:09:00 PM
Parameter rdisp/rfc_max_own_used_wp
Example: rdisp/rfc_max_own_used_wp = 75 (%), rdisp/wp_no_dia = 55 Available DIA work processes for tRFC / qRFC used by one user at a time: Share of configured DIA work processes (75 % of 55) = 41.
Important: Display shows only a snapshot of currently free dialog work processes for tRFC / qRFC
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 dialog 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 o o Determine the AS group which is assigned to the QIN scheduler (transaction SMQR) Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding AS group) 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 profile !
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.
Page 42 of 48
Created on 7/27/2011 3:09:00 PM
Other RFC Parameters

rdisp/rfc_use_quotas rdisp/rfc_max_queue rdisp/rfc_max_login rdisp/rfc_max_own_login rdisp/rfc_max_comm_entries rdisp/rfc_max_wait_time
Activate / Deactivate resource determination Must be set to 1, NEVER change it ! Default: 1 Quota (%) of RFC requests in dispatcher queue (rdisp/elem_per_queue) Default: 5 Quota (%) for RFC logons of the total number of logons per instance (rdisp/tm_max_no) Default: 90 Quota (%) for RFC logons of one dedicated user Default: 25 Quota for the number of used communication entries (rdisp/max_comm_entries), ~100 Byte shared memory Default: 90 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 effectively 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 number 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 allowed 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 effectively controlling RFC load as long as other parameters are set. For more information on these parameters see SAP note 74141.
Page 43 of 48
Created on 7/27/2011 3:09:00 PM
7.4. Check Queue status
Possible Problems: R/3 -> APO

Error Data not even sent Data sent, but not Received Data sent, but not Received Symptom No queue generated Stuck queue Waiting queue Where to look first Active integration model? Application log of receiving system QRFC Monitor: Find out for which queue your queue is waiting Sending log in R/3 (if available)
Error in data selection, i.e. No queue generated when activating an integration model
Page 44 of 48
Created on 7/27/2011 3:09:00 PM
7.5. SMQ2 : Large number of entries / LUWs

Queue information: o Number of Entries Displayed = Number of entries in all queues o Number of Queues Displayed = Number of different 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 objects types. Number of queues = Number of entries:
o o Each object is sent in a separate queue and consequently one LUW uses exactly one queue. There are no dependencies to other queues. 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 processing block each other. In other words, there is no serialization at all. 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. The QIN scheduler determines which LUW can be processed first to keep the right sequence. In case of highly dependent LUWs this step needs more time. The parallel degree of processing is limited even though enough resources are available. 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.
Page 45 of 48
Created on 7/27/2011 3:09:00 PM
7.6. Status SYSFAIL in CIF queue

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
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 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). Short dump analysis ST22: In case of short dumps, no application log is recorded as this is done after LUW processing is finished. System log SM21 and dev_* trace files
Page 46 of 48
Created on 7/27/2011 3:09:00 PM
7.7. Relationship LUW / CIF queue

SMQ2 => Execute => click bell button twice
A LUW is uniquely defined by the same TID. The LUW may contain several objects that are transferred via different queue names. One LUW can only be processes in exactly one work process. An error in transferring or processing of the LUW causes the whole queue to be stopped. Such a queue block not only affects the LUW containing the faulty queue entry, but also all LUWs containing subsequent queue entries. This is called serialization effect. Due to this the data transfer may be severely restricted and some data cannot be transferred 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. Monitoring 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.
Page 47 of 48
Created on 7/27/2011 3:09:00 PM
7.8. Stuck queues

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

CIF Monitoring Guideline V3

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CIF Monitoring Guideline V3

Загружено:

Авторское право:

Доступные форматы

giampiero.gallarate@smart-media.

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

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

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

Protocol of deleted CIF Entries ...........................................................................20 SCM Queue Manager............................................................................................21

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

CIF Monitoring Guideline V3.doc

CIF Monitoring Guideline V3.doc

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

CIF Monitoring Guideline V3.doc

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

1. Inbound & Outbound Queues

CIF Monitoring Guideline V3.doc

1.2. Outbound Scheduler SMQS - Monitoring

CIF Monitoring Guideline V3.doc

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

1.3. Inbound Scheduler - Configuration

CIF Monitoring Guideline V3.doc

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

1.4. Inbound Scheduler SMQR Monitoring

CIF Monitoring Guideline V3.doc

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

2. qRFC monitor: Motivation

CIF Monitoring Guideline V3.doc

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

2.1. Queue Monitor APO and R/3 backend

CIF Monitoring Guideline V3.doc

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

2.2. Local Outbound Queue Overview

CIF Monitoring Guideline V3.doc

2.3. Display Inbound Queues with Problems

CIF Monitoring Guideline V3.doc

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

2.4. Logic of queue names for CIF

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

CIF Monitoring Guideline V3.doc

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

CIF Monitoring Guideline V3.doc

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

CIF Monitoring Guideline V3.doc

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

Common Queue Status Note 378903

CIF Monitoring Guideline V3.doc

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

3. Application logs: Motivation

CIF Monitoring Guideline V3.doc

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

3.1. Analyze Application Log

CIF Monitoring Guideline V3.doc

3.2. Maintain Logging Level

CIF Monitoring Guideline V3.doc

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

3.3. Search in Application Log

APO: Report /SAPAPO/CIF_APPL_LOG_SEARCH_2

CIF Monitoring Guideline V3.doc

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

4. Protocol of deleted CIF Entries

Deletion of CIF Queues

Do NOT simply delete queues entries : this may cause inconsistencies

CIF Monitoring Guideline V3.doc

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

5. SCM Queue Manager

CIF Monitoring Guideline V3.doc