cif understanding presentation

83
Agenda Understanding the R/3 - APO CIF Compiled by Andrew Zugay

Upload: h-kumar-ravi

Post on 30-Nov-2015

118 views

Category:

Documents


5 download

DESCRIPTION

CIF Understanding Presentation

TRANSCRIPT

Agenda

Understanding the R/3 - APO CIF

Compiled by Andrew Zugay

2

Outline

• Fundamentals of APO <--> R/3 Integration• Technology behind the CIF• Integration Models• Master Data• Transactional Data• Data Consistency• CIF Maintenance• Troubleshooting• Important Things to Remember• What to do From Here

Agenda

Understanding the R/3 - APO CIFFundamentals

4

FundamentalsThe APO Core Interface (CIF) connects APO to existing R/3 systems.

The APO CIF is an Add-on component to R/3 (either standalone or part of Plug-in)

The CIF communication layer connects APO to R/3 systems in the form of tight coupling.

The key function of the CIF connection between APO and R/3 is to ensure consistent data exchange in a controlled and optimized manner.

Only relevant data objects are transferred from R/3 to APO.

Incremental supply of relevant data changes to APO is guaranteed through the automatic switch.

qRFC ensures that all transaction data is automatically updated in APO without a delay in R/3. However, qRFC does not provide R/3 with the results of these updates.

Master data changes are forwarded to APO in packets via batch jobs.

Transaction data changes are forwarded to APO in real-time

Planning results are returned to R/3 either in real-time or periodically

ATP requests and results are performed online between APO and R/3

5

Fundamentals

Add-on Component to a R/3 system

Data Exchange via qRFC between APO and R/3

Supply APO with Planning and Optimization Relevant Data from R/3 (Master and Transaction)

Return APO Planning Results to R/3

Initial and Incremental Data Transfer (Automatic Switch)

6

Fundamentals

7

Fundamentals

The R/3 system provides planning relevant master data and transaction data to an APO system, and receives back the planning results.

The APO system cannot change the master data in R/3. However, the APO system can modify the master data provided by R/3 and also create its own master data .

The simulation results for the planning runs are not sent to R/3 .

APO is used to offload the planning functionality from R/3.

APO also provides much more powerful enhancements in terms of planning and optimization (than R/3 or other ERP packages).

The integrated systems should not be treated as separate systems. Instead, they should be considered as sub-systems of an extended system.

APO adds significant implications on the overall strategy for the system landscape, especially in terms of system backup/recovery, system copies, system naming conventions.

8

Fundamentals

• For release 3.1H to 4.5B:

– 1. Enter the transaction CIF in the command field in the main screen of the R/3 System.

– 2. Confirm this entry using the return key.

In R/3 release 4.6A the menu path is as follows: SAP Menu Logistics Central Functions SCP Interface SCP Interfaces Core Interface Advanced Planner and Optimizer.

For releases 4.6B on:

• From release 4.6B, the CIF menu is called up via the SAP menu (SAP Easy Access). Choose SAP Menu Logistics Central Functions Supply Chain Planning Interface Core Interface Advanced Planner and Optimizer.

Agenda

Understanding the R/3 - APO CIFTechnology

10

Technology

There are four technical components in the APO CIF Communication Layer:User Controlled: Integration ModelSystem Internal: Active Data Channel

Message Serialization Event Channel (also called Global Supply Chain Agent)

11

Technology (Active Data Channel)

Active Data Channel is a mechanism to transfer data between APO and R/3 system. It performs data transfer in both initial and incremental modes with the help of appropriate integration models.Filtering is the process of data mapping and enforcing the rules needed to integrate two systems together. Consistent data pools in R/3 are defined and maintained for filtered objects at object type and instance level through the use of integration models.

12

Technology (Active Data Channel)

Perform Initial Data Load to APOUsing integration models

Transferring master data and transactional data

Production Operation of R/3 without Interruption

Switch to Active Push of Transactional DataEvent-driven transmission of changes to APO

Real-time notification

Ensure Consistency of Data in APO and R/3

Transfer only New or Changed Data

Access Multiple Integration Models Simultaneously

Ensure consistency of data in APO and R/3 through filtering

13

Technology (Message Serialization)

Processing of Initial Data Load, Recoveries and Model Switches

Enable Incremental Data Load to Increase Speed

Organization of Asynchronous Messages

Parallel Data Channels on the Levels ofObject types

Object instances

Business processes

Keep Transaction Logic Between Different Channels

Message Serialization is a mechanism to send data gradually as needed.

The functions of Message Serialization include:•Initial data loads

•Incremental data loads

•Organization of asynchronous messages

•Parallel communication channels at object and instance levels

•Transaction logic between different levels and channels

14

Technology (Event Channel)

Administration of Publish/ Subscribe Mechanism between APO and R/3 Systems

All Order Change Receipts from APO

Recipient Determination

Data Filtering

Mapping from Internal to External Representation

Transfer Technique Control

Publication Frequency Control

Data Extraction from liveCache

Data Posting to R/3

15

Technology (Queues and LUW’s)

Summary of Components of CIF

Data Selection (Integration Model)

Data Activation (Active Data Channel)

Data/Transaction Processing (Event Channel)

System Communication (Message Serialization)

16

Technology (Queues and LUW’s)

Data is transferred in both directions by means of one or more queued Remote Function Calls (qRFC). The function calls are buffered in the sending system and executed asynchronously in the same sequence they were called. This serialization is controlled by the use of identical queue names and is required to assure consistency. The use of outbound queues enables the processing of saved function calls to be rerun after correction of the problem, without generating data inconsistencies. Multiple qRFCs can be combined into a logical unit of work (LUW), whereby one LUW on the sender side results in one LUW on the receiver side.

17

Technology (Architecture)

Agenda

Understanding the R/3 - APO CIFIntegration Models

19

Integration Models

DefinitionAn integration model gathers together all data that is to be transferred en bloc from R/3 to APO. The integration model has a name and is related to a target system. The integration model is the foundation of APO CIF.

In order to integrate two systems together, data mapping must take place. Data mapping includes matching up table/structure names and field names between systems.

CIF integration models provide automatic data mapping between the complex relational model in R/3 and the object model in APO.

The integration model’s role is to set up and maintain a consistent data pool in both APO and R/3.

The main functions of the integration model are:

• Integrity of data

• Selecting the filter objects to be transferred

• Defining the Target and Source systems

• Trigging the initial and incremental data uploads

20

Integration Models

The integration Model Includes:– Offline creation of a referentially consistent master data model,

– Creation of a selection variant for initial source data coverage for transaction data,– Filtering and routing to APO for incremental transfer of master and transactional

data (only the key and the changed areas)

– Routing APO planning results to execution systems (Distributed via a Publish/Subscribe mechanism and is Results based, real-time)

– Source system determination.

Integration Models Ensure Referential Integrity of Data in APO bySelection of consistent master data and transactional data for initial data load (in packets)

A differentiation is made between master data and transactional data in the integration model for performance.

21

Integration Models (activation(outbound))

Initial transfer from R3

Determining delta modelFinds all relevant data to be sent

Transfer model type: xxxxCreates APO formatted data elements:

•Locations

•Material master data

•Resources

•Production process models

Processing LOAD channel…Calls BAPI’s in APO and sends data - completion of receipt of data on APO is acknowledged - processing results in APO are unknown

User exits

Change pointer and CIF tables are checked to determine the delta model. Once data

is determined it passes through transformation into APO formatted data. During that transformation checks are performed which may drop data elements from the transfer. Most outbound userexits occur after the transformation process is complete. Messaging will occur during transfer and processing steps that can be seen in the application log in APO.

22

Integration Models (activation(outbound))

Incremental Transfer from R3

Determining delta modelFinds all relevant data to be sent

Transfer model type: xxxxCreates APO formatted data elements:

•Locations

•Material master data

•Resources

•Production process models

Processing LOAD channel…Calls BAPI’s in APO and sends data - completion of receipt of data on APO is acknowledged - processing results in APO are unknown

User exits

Change pointer and CIF tables are checked to determine the delta model. Once data

is determined it passes through transformation into APO formatted data sending only the key and fields that have been changed. Most outbound userexits occur after the transformation process is complete. Messaging will occur during transfer and processing steps that can be seen in the application log in APO.

23

Integration Models (activation(outbound))

Incremental Transfer from R3

Incremental Transfer can be set up for real time transfer for some master data using change pointer and message types.

24

Integration Models (activation(inbound))

Inbound into APO

Incoming data Data received in packets and receipt is acknowledged

Process model type: xxxxExecutes BAPI’s for the APO data elements:

•Locations

•Material master data

•Resources

•Production process models

Processing of dataUser exit changes are incorporated and BAPI’s are committed in APO

User exits

Data is received in APO format in BAPI tables and passed to corresponding BAPI’s. Userexits are called prior to BAPI’s committing data to the database tables. Errors at this point are captured in the application log.

25

Integration Models (parallelized transfer)

Parallelized Transfer of Data

•Must be coordinated with the BASIS team

•Selection process is distributed among servers in server group and uses available work processes.

•Parallelize Selection in R/3 will utilize application server in Server Group only.

•Parallelize Processing in APO will utilize all application servers that the connected APO system uses.

•Current BASIS guidelines are to use 75% Relative Max. No. Processes and BASIS approved server group

Gsdux01.lvs.dupont.com

Gsdux02.lvs.dupont.com

Gsdux03.lvs.dupont.com

R3aServer group A (application servers)

26

Integration Models (parallelized transfer)

Parallelized Transfer of Data

Parallelized selection can lead to a significant increase in performance. Parallelized selection is currently supported for the following object types:

Material masters Production process models Sales orders All stock types Planned orders and production orders Purchase orders and purchase requisitions

Sources of supply (contracts, purchasing info records, scheduling agreements)

Note If parallelized processing in APO is selected a liveCache lock can be caused in SAP APO if two integration models are activated in parallel for different object types and

they both affect the same material-plant combination or resource.

Agenda

Understanding the R/3 - APO CIFMaster Data

28

Master Data

Overview of R3 to APO master data elements

•Plant

•Resource

•Material Master

•BOM

•Recipe

•Classes

•Location

•Resource

•Product

•Production Process Model

•Classes

29

Master Data

Master Data Selection in Creation of Integration Models

Objects selected are known as filter objects

Filter Objects are included in integration models

Filter Objects have dependencies

CFM1

30

Master Data

Filter object dependencies

31

Master Data

Capacity to Resource Transfer

32

Master Data

Change Pointers for CIF Message Types

BD50 - Activate the CIF message types.

BD52 - List of fields which are included in the message type

33

Master Data

Send Changes to APO (RCPTRANS)

34

Master Data

PPM Transformation

35

Master Data

PPM Transformation

Routing Number in PPM is formed as follows, Plan type ( one character: N for normal routing (PP), R for rate routing (PP) or 2 for PI plan) + Planning group (eight characters) + Group counter ( two characters (the leading zero is suppressed in the R/3-System)) + Production version ( four characters )Product Name in APO is formed as follows, Material name from R/3 + “@” + R/3 System name + R/3 Client numberBefore transferring a PPM to APO, the R/3 materials and resources used in the plan must be maintained in APO. If you have not already maintained them, no PPM can be created in APO and an error message will appear in the transfer log.BOM - Corresponds to the plan in APO.Material - The R/3 material is transferred to the logical component and the product in APO.Routing (PP) - A routing is the description of the production process. Routings and rate routings are transferred.Recipe (PI) - Recipes are general instructions for the use of a production process.Sequence - Sequences are only found in PP in the R/3 System. The information is integrated in the operations in PP. Operations are assigned to the sequence, and sub-operations are assigned to operations.

In R/3 BOMs and routings/recipes are grouped to create a production version. The APO Core Interface uses these versions to group data together in a PPM which is then transferred to APO.

PPM Plan - There is a PPM in APO for each production version transferred from APO. It is does not matter whether it was a routing or a recipe that was transported from the R/3 System.Product Version - Choose Material>>MRP 4>>Production Version >>Details>>Production Version Details, to display details about the production version. The production version in the R/3-System, which includes the BOM and the routing/recipe, corresponds to the PPM in APO. The validity duration that applies to a production version in the R/3 System also applies to the PPM in APO.

36

APO CIP (Itech)

APO CPP (WPMP)

APO CFPD (Flpr)

R/3

WPMP logic

Flpr logic

ITechlogic

RTN2????User Exit

Master Data UserexitsUser exits can be used for different logic by different SBUs.

BP approach to user exits:

• Userexits contain NO business specific logic. User exits contain ONLY flow-control logic.

• Business/SBU specific logic is contained in separate subroutines not directly referenced by user exits or standard programs.

WPMP logic

Flpr logic

ITechlogic

RTN2????User Exit

CIFOutbound

userexit

CIF

RTN20017

RTN20017

APO Data Tables

R3 Data Tables

CIFInbound userexit

Master Data

Agenda

Understanding the R/3 - APO CIFTransactional Data

38

Transactional Data

Transactional Data Selection in Creation of Integration Models

Objects selected are known as filter objects

Filter Objects are included in integration models

Filter Objects have dependencies

If master data and transaction data are included in the same integration model, they will be treated differently.

CFM1

39

Enhanced Integration between R/3 and APO

R/3Cluster specific

Transaction execution

APOSBU

Planning

Master data (CIF)•Location•Materials•Resource•Recipe•Transportation lanes?

Transaction (CIF)•Sales orders•ATP Requests•Purchase orders•Planned orders•Process orders•Stock transfers•Stock

Sales Order

Process order

Master data

Demand Planning

SupplyNetworkPlanning

ATP

ProductionPlanning

Detailed Scheduling

Collaboration

Transaction (CIF)•Purchase reqs.•Stock transfers reqs.•Planned orders•ATP Answers

Real timeBatch

Delivery notes

Purchase order

Stock

Stock transfer

Outbound

user exits

Inbound user exits

Outbound

user exitsInbound user exits

Inbound user exits

Outbound

user exits

Transactional Data (R/3 and APO Integration)

40

Transactional Data

The changeover between initial transfer and change transfer for transactional data is a

smooth one. As soon as the integration model is activated, the R/3 system changes over

from initial transfer to incremental transfer. Creating, changing or deleting an APO-relevant

document immediately starts the transfer process to APO.

41

Transactional Data

R/3 > APO (Transaction Data)•Stocks (receipt, issue, transfer)•Purchase Orders, Purchase Requisitions•Sales Orders (sales order, delivery note)•Planned Orders, Production Orders•Reservations, Reuirements, ATP RequestsAPO > R/3 (Planning Results, Transaction Data Only)•ATP Results (planned order)•Stock Transfer Orders/Requisitions, Transport Orders•Planned/Production Orders, Purchase Orders/Requisitions, VMI Sales Orders

42

Transactional Data

Print pull listYou print the pull list in the R/3 System.Withdraw componentsThe requirements and component stock are reduced in both APO and R/3.ConfirmationWhen you confirm completion of an operation in R/3 , the operation is updated with the confirmed start, the finish date and quantities are reduced. APO is updated with the same info. Completion confirmation or final delivery leads to deletion of the corresponding order in APO. This means that if you cancel the completion confirmation, the order must be created as a new order in APO.Post goods receiptThe order for the receipt is reduced and the stock is increased in both APO and R/3

Convert planned orders into production ordersPlanned Order is deleted in R/3 and APO. The Production Order is created in R/3 and APO. The Production Order dates are calculated via PPDS (No Multilevel ATP) A known problem is dates are only copied when manually changing the planning in APOConvert part of planned order into production order ( See above)ATP CheckThe ATP check, which is triggered by the conversion is carried out in APOScheduling to determine costs (Controlling)Scheduling is performed to determine costs. This information is only required by Controlling. The dates determined here are not used for production planning.

Process Flow of an order

43

Transactional Data

StocksThe CIF can be used to transfer the following stock data from R/3 to APO:• Unrestricted-use stock

• Stock in quality inspection

• Blocked stock

• Restricted-use stock

• Stock in transit

• Stock in transfer (plant)

You can use the integration model to transfer all of the stocks above or just individual stock

types, such as sales order stocks.

If the push transfer function is activated, only those stock changes that result from material

movements are transferred to APO.

The filter objects required to transfer the stock data are generated at the material/plant level.

The advantage of this is that objects that are not created until the first goods movement, e.g.

the storage location, can be easily transferred to SAP APO using push technology. This

means that you do not have to activate a separate integration model for each new batch or

storage location.

Agenda

Understanding the R/3 - APO CIFData Consistency

45

Data Consistency

Data Distribution Inside APO- The APO system uses 2 database servers, the traditional APO DB and the memory-based liveCache- To achive maximum speed due to the planning complexity, the planning relevant data from R/3 (Master Data and Transactional) is distributed between the APO DB and the liveCache•A complete set of APO Master Data resides in the APO DB•A subset of APO Master Data resides in the liveCache for speedy planning operations•All Transaction Data resides in the liveCache•Only the Keys or Anchors of the Transaction Data in the liveCache are kept in the APO DB

46

Data Consistency

• Data Redundancy: data redundantly distributed among R/3 DB, APO DB, and liveCache

• Data Consistency has to be maintained due to this Data Redundancy

• Various methods are available for reestablishing the data consistency. Each production environment is different, always evaluate different methods fully by performing full scale tests.

• Check for the data consistency and the total processing time. Choose the one that will produce the desired data consistency with the shortest processing time.

• Operation procedures have to be established to bring the system back into the consistent state in the shortest time if such a data inconsistency occurs.

• Routine maintenance can be scheduled to sync up the system periodically to guarantee the data consistency in the system.

• Data Inconsistency could occur even if liveCache is recovered from a crash using liveCache logging.

47

Data Consistency

Master DataInternal Data Consistency• /SAPAPO/OM17, or report /SAPAPO/OM_LC_DB_SYNC

• Function Module /SAPAPO/DM_LC_MASTER_DATA_LOAD

External Data Consistency• Re-load All Master Data from R/3 via report RIMODINI

Transactional DataInternal Data Consistency• /SAPAPO/OM17, or report /SAPAPO/OM_LC_DB_SYNC

External Data Consistency• Re-load All Transaction Data from R/3 via report RIMODINI

• Re-load Missing Data Objects from R/3 via /SAPAPO/CIF_DELTAREPORT (2,3)

• Re-load Missing Data Objects from R/3 via the Compare/Adjust Report (PI2000.1)

Other Methods may include generating a new model and activating, or deactivating

and reactivating existing integration models.

48

Data Consistency

RIMODINI

•This report transfers all the objects of the model according to the last generated version unless it is set to active.

•The selection variant can be used for running this report in the batch mode.

•When running this report, it is preferred all related models to be deactivated first to avoid any potential conflicts.

49

Data Consistency

CIF Delta Report

•This report only applies to the movement data in liveCache.

•It checks data object existence in APO and R/3, but not its content

•If a data object missing in APO, it will be sent to APO from R/3 again.

•If a data object missing in R/3, it will be possible to selectively send them to R/3 in a future service package

•Its processing time is proportional to the number of objects.

50

Data Consistency

LC Consistency Check

•When the light is red, there are inconsistencies need to be corrected.

•When the light is green, there is no inconsistency problem.

•The log button is enabled after some individual inconsistencies are corrected directly.

Agenda

Understanding the R/3 - APO CIFCIF Maintenance

52

CIF Maintenance (qRFC queues)

• Information is sent in packets or LUW’s from outbound to inbound queue• Point of time of transmission (time & date)• SMQ1 - Outbound qRFC monitor• SMQ2 - Inbound qRFC monitor• Usually only one queue per direction is used

R3 APOInbound queue

Inbound queue

Outbound queue

Outbound queue

qRFC

53

CIF Maintenance (qRFC queues)

The technical name for transfer channels relevant to R/3 – APO integration starts with CF.

•CF_ADC_LOAD – the name of the transfer channel for the initial supply•CFSLS0000010003 – the name of the incremental supply for the sales order number 10003

•Point of time of transmission (time & date)•SMQ1 - Outbound qRFC monitor•SMQ2 - Inbound qRFC monitor

54

CIF Maintenance (tRFC queues)

Transaction SM58.•Displays all transactions using tRFC channel•Provides same functionality as qRFC•Access may be limited to BASIS team

tRFC Monitor:

55

CIF Maintenance (qRFC Monitor)

The system differentiates between two types of errors when processing qRFC modules:

1. Communication errors. These include:– Network problems, dialog WP’s not available– A non-existent RFC destination, tRFC retries, etc.

Due to periodic repetition of the data transfer, communication problems should disappear of their own accord as soon as the network connection is available again.

2. Application errors. These include:– Program errors– Non-posting of data to the target system– Locking of objects– Missing master data for transaction data

Application problems must be solved by a system administrator.

The qRFC is the central instance for monitoring application errors. It is available in both R/3 and APO. All transfer channels (queues) are displayed for all target systems.

56

CIF Maintenance (qRFC Monitor)

Detailed error messages are stored in the destination system’s application log. Thetransaction ID of the sending transaction is used as the key for the error messages: field TID in the qRFC line (SMQ1 of the sending system). You can use this number to find all messages in the destination system for the corresponding qRFC callsSub-object DescriptionANY All other objectsATP Global ATPCF Confirmations (inbound)CO Sales orders (inbound)CONF ConfirmationDL Delivery (inbound)EC Event channel/retransmissionEP External procurement (inbound)FO Planned independent requirement(inbound)INITIAL Initial supplyIP In-house production (inbound)IRQ Independent requirementsLOCATION Location: customer, plant, supplierORDER Planned order/production orderPC Production campaign (inbound)PCM Production campaignPF Planning file entry (inbound)

Sub-object DescriptionPIR Planned independent requirementsPLORD Planned order (not used by the system)PO Purchase orderPRODUCT Material in APOQUOTA Product allocationRESOURCE Resource: work center, capacityRSV ReservationRV Reservations (inbound)SALES Sales dataSATD Goods receipt/goods issue to APO scheduling agreementSH Transport (inbound)STOCK Stock dataT_CHR CharacteristicT_CLA ClassesT_PPR Planning productT_SRCC ContractsT_SRCD Delivery plansT_SRCI Purchasing info records

57

CIF Maintenance (qRFC Monitor)

qRFC Monitor•You can double click on the rows to display all the function calls for the selected transfer channel. The highest function call blocks all other entries if an error occurs.•You can call up the current status text via the error short text. A detailed error log is always saved in the application log of the target system.•You can also call up the data in the queue as seen below.

58

CIF Maintenance (qRFC Monitor)

• Check for errors by looking at the status field. In the case shown, all of the queues are stopped also known as “blocked.” Generally you will see two types of errors CPICERR and SYSFAIL. CPICERR is a communication error that can be easily corrected by highlighting the red CPICERR and selecting the activate icon . To evaluate a SYSFAIL error double click on the red SYSFAIL to display the error. Some messages are clearer than others, but by in large all SYSFAIL errors can be traced back to a master data deficiency. You should correct the error and activate the queue.

• You can lock an error in the queue so the CIF can continue. To do this highlight the error and select the lock icon . When the error is corrected you can unlock the queue with immediate activation or without activation . If choosing without activation you will have to manually activate by selecting the activation icon .

59

CIF Maintenance (qRFC queues)

READY - Queue is ready for transmission. This status should only be a temporary status. However, in the following case this status can also be a permanent status: A queue was locked manually via SMQ1 or via a program and then unlocked without being activated at the same time. This queue must be activated explicitly.

RUNNING - The first LUW of this queue is currently being processed. If a queue in this status hangs for more than 30 minutes, this might mean that the work process responsible for sending this LUW has terminated. In this case you can activate this queue again. Note that activating a queue in status RUNNING might cause a LUW to be executed several times if this LUW is processed in the target system at that time. We therefore recommend a waiting time of at least 30 minutes before you activate the queue again.

EXECUTED - The first LUW of this queue is processed. The system waits for an qRFC-internal confirmation from the target system before further LUWs are processed. If a queue in this STATUS hangs for more than 30 minutes, this might mean that the work process responsible for sending this LUW has terminated. In contrast status RUNNING, this current LUW has definitely been executed successfully. You can activate this queue again without problems. The qRFC Manager will automatically delete the LUW already executed and send the next LUW.

SYSLOAD - At the time of the qRFC call, no DIALOG work processes were free in the sending system for sending the LUW asynchronously. A batch job for subsequent sending has already been scheduled (see Note 319860 for more details).

SYSFAIL - A serious error occurred in the target system while the first LUW of this queue was executed. The execution was interrupted. When you double-click on this status, the system displays an error text. You can find additional information on this error in the corresponding short dump in the target system (ST22). No batch job is scheduled for a repetition and the queue is no longer processed. To solve the problem you need information from the affected application. Refer to Note 335162 for the special error text "connection closed".

60

CIF Maintenance (qRFC queues)

CPICERR - During transmission or processing of the first LUW in the target system, a network or communication error occurred. When you double-click on this status, the system displays an error text. You can find additional information on this error in the syslog (SM21), the trace files dev_rd or dev_rfc*. Depending on the definition in SM59 for the destination used, a batch job is scheduled for subsequent sending. Status CPICERR might also exist in the following cases although no communication error occurred: An qRFC application finds out that a LUW cannot be processed any further due to a temporary error in theapplication and therefore calls function module RESTART_OF_BACKGROUNDTASK in order to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance with the specification in SM59. In this case, qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again.". If this error occurs very often, you must contact the corresponding application.

STOP - On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ1 or programs). Note that the qRFC never locks a queue in its processing. After having informed the corresponding application you can unlock and activate this queue using SMQ1.

WAITSTOP - The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently still locked.

WAITING - The first LUW of this queue has dependencies to other queues, and at least one of these queues contains other LUWs with higher priorities.

NOSEND - LUWs of this queue are never sent but picked up by a special application. These queues are only used internally at SAP (BW or CRM during communication with Mobile Clients).

NOSENDS - During the qRFC call, the application at the same time determines that the current LUW should not be sent immediately. This is used to debug the execution of a LUW in the target system.

61

CIF Maintenance (qRFC queues)

WAITUPDA - The current LUW was executed in a transaction that also contains update functions. Therefore, this LUW may only be sent after the update has been successfully completed. If this status is retained for more than a couple of minutes, go to SM13 and check whether an update termination has occurred. After successful subsequent posting this LUW is automatically restarted. You can reset this status from qRFC Monitor SMQ1 and activate the queue again. Note that this might cause inconsistencies in the application data between the two systems.

ARETRY - During LUW execution the application has diagnosed a temporary problem and and has prompted the qRFC Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition on the basis of the definition in SM59.

ANORETRY - During the LUW execution, the application has found a serious error and prompted the qRFC Manager via a specific qRFC call to cancel processing of this LUW. To solve the problem, information from the affected application is required.

MODIFY - Processing of this queue is locked temporarily because of the LUW data being modified.

62

CIF Maintenance (Application Logs)

R3 - CFG1 APO - /SAPAPO/C3

Display Entries to get detailed informationPoint of time of transmission (time & date)Data object information (data object & integration model)Source System, User, TransactionApplication success and error messages

Level of Detailstable CIFGPARAMS in R/3table /SAPAPO/CIFGPARV in APO

Delete entries

63

CIF Maintenance (Application Logs)

CIF Application Logs

Application logs should be deleted routinely to improve efficiency of logging and reviewing logs.

• Delete Application Log in APO:– APO Administration >> Monitoring

>> Application Log >> Delete Entries, or

– transaction /SAPAPO/C6, or report /SAPAPO/RDELLOG

– transaction CFGD, or report RDELALOG

Open up entry and double click the error/warning to view messages

64

CIF Maintenance

tRFC Monitor for R/3 and APO: transaction SM58, report RSARFCRD

qRFC Monitor only displays the waiting calls. Because of message serialization, the highest entry in the queue blocks all other entries in that queue if an error occurs.For any qRFC error, a detailed error log is always saved in the application log of the target system.

• find the value in the field TID of the qRFC monitor for the qRFC error• enter this value in the field External Identification for the transaction /SAPAPO/C3 (APO Application Log) and make the selection. This displays all messages for related to this erroneous qRFC call.

There are instances, an error shows up in the APO Application Log without a corresponding qRFC error in the qRFCmonitor.Alternatively, monitor CIF channel

• CIF Integration Model Change Transfer Transaction Data (CFP2, rpt: RCPQUEUE)

65

CIF Maintenance (Data Channel Control)

CIF Data Channel Control (1)

CIF >> Integration Model >> Change Transfer >> Transaction Data

Transaction: CFP2, or Report: RCPQUEUE

Start / Stop Data Channels without Losing Data Changes

Monitor / Display Details

66

CIF Maintenance (Data Channel Control)

Alternatively, activation and deactivation of the integration model can be used to start and stop the relevant CIF queues. However, when the model is deactivated, no incremental transfer is performed and the data changes are not stored in the CIF queues as well.

67

CIF Maintenance (Data Channel Control)

CIF Data Channel Control (2)Report RSTRFCQ1: to stop selected CIF queues

Report RSTRFCQ3: to start selected CIF queues

Better Control than Report RCPQUEUE

Start / Stop without Losing Data Changes

Run as Batch Jobs with Selection Variants

68

CIF Maintenance (Data Channel Control)

When using CFSTK* in the selection screen for RSTRFCQ1 and RSTRFCQ3, it has the same effect as using RCPQUEUE to start and stop CFSTK* data channel.

RSTRFCQ1 is very useful in stopping a long running CIF queue.

Sometimes, RSTRFCQ3 may need to be run several times if all CIF queues are stopped at the same by using RSTRFCQ1 with the force mode. It is because some of the CIF queues are dependent on the other queues and could not be restarted at the same time.

When “NO_ACT” is specified in RSTRFCQ3, it will also activate the corresponding queues.

When restarting erroneous CIF queues, if possible, try to restart them not at the same time, instead, one after another due to the multiple threading situation in the CIF queues.

The CIF queues can also be started and stopped through the qRFC monitor.

Agenda

Understanding the R/3 - APO CIFImportant Transactions

70

Important Transactions - R/3

• CFM1 - Create integration model• CFM2 - Activate/deactivate integration models• CFM3 - Activate/deactivate integration models batch mode• CFM4 - Display Integration Models• CFM5 - Filter object search in integration models• CFG1 - View CIF application log• CFC1 - Define logical systems as APO systems• CFC2 - User parameters for CIF• CFC3 - Block sizes for initial transfer• CFP2 - Monitor of data transfer channels• NDV2 - Setting of release level of APO systems• SMQ1 - qRFC outbound monitor• SMQ2 - qRFC inbound monitor• SALE - Definition of logical systems• SM59 - Definition of RFC destinations• BD50 - Change pointers for message types (BD51 will list the fields involved)• BD61 - Change pointer status

71

Important Transactions - APO

• /sapapo/c1 - Create business system group• /sapapo/c2 - Assign logical systems to a business system group• /sapapo/c3 - View CIF application log• /sapapo/c4 - Setting of user parameters CIF• /sapapo/c5 - Send planning results to R3 (select and copy orders)• /sapapo/CCR - Comparison/reconciliation tool• OM17 - LC consistency check• SMQ1 - qRFC outbound monitor• SMQ2 - qRFC inbound monitor• SALE - Definition of logical systems• SM59 - Definition of RFC destinations

Agenda

Understanding the R/3 - APO CIFTroubleshooting

73

Troubleshooting

Common CIF error examples:

1. Master data not setup in APO and request doesn’t exist

Example: master data was created in R/3 (especially resources) and the materials / ppm’s assigned to that resource were brought over to R/3 before the resource was properly set up.

2. Material marked ND and/or flagged for deletion in R/3 but not deleted in APO.

3. Material not set up in APO.

There are several cases included here. This can include those cases where the material does not exist in R/3; where the material exists in R/3 but does not have an MRP view created; where the material exists in R/3 but has some MRP setting other than APO relevant; delivery where material is in APO at one location but not at another.

4. Material not set up in APO (but will come over on next CIF).

This is a special case for #4 where the material has been set up properly in APO but hasn’t come over yet on the next delta CIF. Activity for a material (creating a purchase order as an example) will cause a transactional CIF error. No action is required for this type of CIF error.

74

Troubleshooting

Common CIF error examples:

5. Vendor not maintained by purchasing organization.

If the vendor / source relationship does not include the vendor having the proper purchasing organization, this will occur. When it does it may result in many failures as each planned order will bring about a failure.

6. Material List in Process Order is not the same as the BOM and PPM or Recipe does not match PPM

This can occur when a change has been made in the BOM, planning done on the material in APO, but the updated BOM has not been sent to APO. There are several variants of the wording of this CIF error.

7. No active Integration Model for category Purchasing

The error code means literally is that the material is in APO, so the PPR created purchase reqs, but it is not in an Transactional Integration Model. The reason for this is that the MRP type is "PD". It should be changed to be APO relevant, or removed from APO.

8. Invalid unit of measure for components

Inconsistency between the UOM on the BOM and the material master.

9. Differences between planned orders in APO and R/3.

When MRP was run instead of relying upon APO, small (rounding error?) differences developed between the planned orders. This blocked the transactional CIF.

75

Troubleshooting

Common CIF error examples:

10. PPM D11460459 AA9G ----- Activity network is incoherent.

Number of operation in PPM and recipe/Proc order does not match. R/3 Recipe/Proc order has more number of Scheduling relevant operations.

11. PPM component deleted at a location.

Error message will look like this:

PPM explosion for source D11512395 YF13 25001505601011:

log. comp. A00627664 M00014575000000070000 contains no valid material.

76

Troubleshooting

Other References:– CIF COE documents in Bulletin Board

– troubleshooting-CIF.pdf

– OSS- 563806

– Creation of CIF error tracking spreadsheet

Agenda

Understanding the R/3 - APO CIFImportant Things to Remember

78

Important things to remember

• The APO CIF is a real time interface. Only those data objects that are needed in APO's streamlined data structures for individual planning and optimization processes must be transferred from R/3's complex data set.

• The bottom line is that data inconsistency will appear in your system from time to time for various reasons. It can not be avoided whether you like it or not. We need to learn how to handle it.

• Each SBU has its own unique business requirements. The handling of the CIF and data consistency problems may be different for each SBU, but solutions to common errors and problems must be shared and leveraged.

• The APO system cannot change the master data in R/3. However, the APO system can modify the master data provided by R/3 and also create its own master data .

• After your implementation is completed the maintain team will be assuming responsibility for R3-APO integration. Please forward CIF related issues in a production support turnover document.

• When defect or change controls are created please inform and work with developers to insure they are using a model that will not impact other areas of the

project, contains relevant data and has data consistency.

79

What to do from here

• Use online documentation• Check the CIF COE on the Bulletin Board• Log issues in the CIF COE on the Bulletin Board• Read OSS notes/create OSS notes

Agenda

CIF

Agenda

Material

Planned Order

PPM

CIFCertified

CIF

Agenda