APO Core Interface (CIF)

Contents
Introduction to Core Interface (CIF) Role of CIF Components of CIF Integration Models Data Transfer (Master Data and Transactional Data) CIF Monitoring

Introduction to CIF

What is Core Interface ?

APO Core Interface connects an APO and a standard R/3 system determines source and target systems within complex system environments through Integration Models supplies APO with the relevant master and transaction data transfer of planning relevant data only initial and incremental data transfer real-time interface returns planning results to the OLTP system
APO-CIF is delivered as a plug-in . This is a general product name given by SAP for the R/3 interfaces to the new dimension applications. R/3 Plug-in is name of an R/3 enhancement which enables integration with the mySAP.com components like BW, APO, SEM, etc. APO-CIF interface solution is available for R/3 systems from Release 3.1I.

APO Core Interface (CIF)

APO software includes a communication layer to enable integration between APO and OLTP systems (eg. R/3 system). APO CIF is the communication layer to be applied to R/3 to enable integration of R/3 system with APO system. There is a similar communication layer which comes as a standard function in the APO system. APO CIF is a real-time interface between R/3 & APO system The main roles of CIF are :

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 R/3 objects and

- Determine source and target systems - Initially supply APO with master and transactional data - Incrementally keep on supplying APO with transactional data - Return planning results to R/3 system

the corresponding objects in APO.

Between non-R/3 ERP and APO, other interfaces like BAPI or ALE are used.

CIF Functions
ERP -> APO
Master Data
Locations Products PPMs (BOM+Routing) Characteristics Capacities

Transaction Data
Planned/Production Orders Sales Orders Purchase Orders Stocks ATP Requests

APO -> ERP

Planning Results
ATP Results Manufacturing Orders Procurement Orders VMI Sales Orders

APO

ERP

BW

APO

ERP APO ERP

ERP

CIF Setup and Related Configuration Tasks

R/3 Set up a logical system Assign LS to client Set up RFC destination Define target system (same name as the RFC destination)

APO
Set up a logical system Assign LS to client

Set up business system

group Assign LS to BSG

Note : Details of the CIF configurations are not covered in this training However, the required CIF settings are mentioned in the attached document for reference

Master Data Transfer

R3 to APO

Transfer of Master Data

Initial transfer

R/3
R/3 master data
Plant Customer Vendor Material master Capacity Routing and bill of material

APO
APO master data
Location Product Resource Production process model

Incremental data transfer

Integration Model
Transaction Code : CIF-EA Integration Model distinguishes between Master Data and Transactional Data elements You can have multiple integration models. However, there are certain recommendations in deciding how many integration models to create for an implementation (details given later) In integration model, you select: The data sets (master data objects, transactional data objects) APO target system for data transfer

Creation, Change, Display, Deletion possible

Integration Model Initial Data Transfer

1. Generate integration model
Determine name and APO target system Select master data
Plant Name Target system

Material master
Resource

...

2. Activate integration model

Integration model is active
Start

Master data will be transferred

Integration Model Generation

Integration Model = Name + Application Target System = APO System (it should be a logical system having active RFC connection) Specify data objects to transfer - Filtering criteria available {Examples: Plant, MRP Type (X0 or X1), MRP Controller} Execute system compiles the selected data objects (report available to check compiled objects) Generate (save the model)

Integration Model Activation

Activate integration model (which has been generated in previous step) This initiates data transfer from R3 to APO The integration models are created with time-stamps The active integration model is indicated by the icon

Selection Criteria MRP Type X0

R/3
MRP type MRP procedure X0 X Mat. A X0 ... Mat. B X0 Mat. C X0 Mat. D VB Material master D Material master C Material master B Material master A

Integration model
Name Applic.

PUMP
MATERIALS

Target s. APOCLNT800

Without MRP, with BOM explosion

Material master Customers

Relevant materials Material Plant 1000 X0

APO

Planning in APO

Product C Product B Product A

MRP type Material ... status

Which Products to plan in APO ?

Planning type APO recommended Possible in APO APO not recommended

Externally procured products with long replenishment times

Products manufactured in-house at bottleneck resources Products that are not critical for planning

(Non-critical) products planned with reorder point planning (Non-critical) products planned with KANBAN

Transfer of New APO-Relevant Master Data

New Data Transfer
Integration Model-1 : Products A & B at 10:00 hrs New material (Product Q) to be transferred to APO

Regenerate Data
Integr Model-1 : Products A & B at 10:00 hrs

Deactivate Model
Existing integration model
Execute+ Save

"Activate"
Active/ Inact .

Activate Model
Re-Transfer of Product A, B & Q happens

Integration Model-1 : Products A,B,Q at 11:00 hrs Integration Model-1 : Products A & B at 10:00 hrs Transfer of only Product Q happens

Active

Inactive

Transfer of New APO-Relevant Master Data

New Data Transfer
The system re-generates the existing model (the new master data is also selected here) and then activates it. Two models with the same name are then active, the only differences being the dates and times. If the data transfer starts in this situation, the system simply transfers the difference data. After the data transfer, the system deactivates the "old" integration model, leaving the "new" complete integration model as the active model.

Regenerate Data Transfer

If you want the system to retransfer all the master data of an existing integration model, you must deactivate the old models and activate only the new one. A comparison of all active models then takes place. As in this case, the model with the old time is not active, all data is transferred again.

Periodic Data Transfers through Batch Jobs

Generate integration model
Name Target system Application PUMPS APOCLNT800 MATERIALS

JOB_1
Variant PUMP_MAT
Execute

+
Save

Step 1

...
RIMODGEN report
alternative:

JOB_1_AND_2
Activate integration model
Name PUMPS

JOB_2
Variant
Active/ Inact .

Target system
Application

APOCLNT800 MATERIALS

PUMP_MAT

+
Start

Step 2

RIMODAC2 report

Incremental Data Transfer

Transaction CFC5
Material master Business Transaction Event, ALE change pointer, periodic no incremental data transfer Customers Business Transaction Event, ALE change pointer, periodic no incremental data transfer Vendors Business Transaction Event, ALE change pointer, periodic immed . immed . Changes to R/3 master data objects are recorded and the transfer of the changes is (periodically, for example) triggered immed .

APO
Changed R/3 master data objects are transferred into APO when the changes are saved in real-time

Incremental Data Transfer

no incremental data transfer

Incremental Data Transfer ALE Change Pointers

n The process of incremental data transfer reverts to the ALE change pointer. This change pointer selects the master data for the system to retransfer. When you call up the transaction Incremental data transfer of master data (CFP1), specify the the logical target systems and the master data objects (material masters, vendors, sources of supply, customers), that have changes to be transferred.

ALE Change Pointer Settings

Change pointers are used by the ALE message distribution. Changes to Master Data are recorded and given a change number (if they are in an active message type). Transaction BDCP CIF Message types must be activated for change recording. Transaction BD50 Activate Change Pointers. Transaction BD61 The fields relevant to a message type to be selected. Transaction BD52

Periodic Incremental Data Transfers through Batch Jobs

The settings for an incremental data transfer can be saved as variants and used for periodic scheduling of incremental data transfer as a job. Report RCPTRAN4 is used for that purpose.
Master data change
Material master A
Mat.planning MRP type

Change pointer generally active? Relevant message type active?

Change pointer

X0 Customizing

Matl . ...

B in -house pro. time

Plan. deliv .time 10 days 11 days

Matl . A Plan. deliv . time

Variant DELTA_MAT

Incremental data transfer Target sys. Object types Material master APOCLNT800

Incremental data transfer

Execute

...
Product A Plan. deliv .time 11 days

APO

Changed master data in APO

Delete change pointers regularly

Transactional Data Transfer

R3 to APO APO to R3 (Publication)

Transactional Data Transfer R3 to APO

R/3
R/3 transaction data
Purchase orders Purchase requisitions Sales orders Planned orders Planned ind .reqmts Reservations Stocks ...

APO
Initial data transfer
APO transaction data
Order with category BF ( PchOrd ) AG ( PurRqs ) BM ( SalesOrder ) AI ( PlOrd .) FA (FC req .) AM ( PrdRes ) CC (Stock) ...

Initial data transfer takes through CIF

New transactional data or changes to existing transactional data are transferred automatically (realtime) Methodology of transfer is same (using Integration Models)

Incremental data transfer Realtime

The APO transaction data objects are not generally identical to those of the R/3 System. The system transfers various R/3 transaction data into APO as orders that differ by ATP category

Publication of Planning Results APO to R3

Planning Results are transferred from APO to R3, which is termed as Publication Configuration in APO : Basic settings (publication of planning results) specify for each plant and publication type (example, in-house production or external procurement,etc), which R/3 System (logical system) to publish planning results. For SNP, you set the form for transferring SNP planning results to the R/3 System with the Customizing operation: Set transfer to OLTP system. The default setting for SNP is that the changes are collected and transferred periodically. For PPDS : In APO transaction /SAPAPO/C4 you set how (in what form) new transaction data is to be transferred from APO PP/DS into R/3. It is usually a real-time transfer (this is the default setting for PP/DS data). There is also the possibility of collecting the changes in APO first, then transferring them to the R/3 as a collected group (transaction /SAPAPO/C5).

Publication of Planning Results

Report T-Code Function Module

: /SAPAPO/RDMCPPROCESS : /SAPAPO/C5 : /SAPAPO/DM_CP_PUB

Orders that have been created, changed or deleted in APO applications are published back to R/3 through the above function module. APO applications that can create, change, delete orders are: PP/DS : Direct Publication SNP : Periodic Publication

Publication of Planning Results

Publication settings (distribution definitions) in APO IMG needs to be done for all objects (like planned order, planned order with conversion indicator, etc) that have been created in APO. In case the following objects have been created in R/3 and then changed in APO, the changed parameters can be published back to R/3 without any need to maintain the distribution definitions :

# Sales Order # External Procurement

# Inhouse Production # Production Campaign

However for the following objects, distribution definitions has to be defined irrespective of them being created in R/3 or not :

# PIR # Confirmation (IS Auto) # Reservations

# Delivery # Confirmation Deletion (IS Auto) # Reporting Points (IS Auto)

Integration Model Other Functions

+
Deactivate integration model
Connection between R/3 and APO for the relevant master and transaction data will be cancelled

+ + +

Delete integration model

Deactivated models can be deleted

Filter object search

Check whether the data objects are already contained within an integration model

Consistency check
You can check the consistency of the selected data in the integration model

CIF Monitoring

Data Transfer Technique

Data transferred in both directions (from R/3 to APO as well as from APO to R/3) 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. 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.

Steps for Data Transfer (1)

The system transfers only the planning of the active planning version '000'. Product and location are assigned to the same business system group.In the R/3 system, an active integration model exists for the respective material and plant. The application (for example the PP/DS or the SNP) in the APO system creates an event.The event includes the Type of Change (Add, Change, Delete) and the Internal Order Number.The system sends the event to a module of integration module CIF (Core Interface) and stores it there temporarily. The system transfers the changes to the R/3 system at a certain time.Generally, the system transfers changes as mentioned below: PP/DS : immediately (that is if you save the schedule in the APO system) SNP : The system collects changes of the SNP and transfers them in blocks. You can define deviations from this in Customizing.To do this, call Transaction /SAPAPO/C4.In column 'Recording' you can define whether the system collects changes or not. If the system collects changes, it has to transfer all collected changes via Transaction /SAPAPO/C5. Alternatively, you can schedule a job periodically.Use report /SAPAPO/RDMCPPROCESS to do this.

Steps for Data Transfer (2)

If the changes are collected, an order may be repeatedly changed between two transfers. The system collects the events of an order, for which the following applies: Creating + Changing -> Creation Creating + Deleting -> No Transfer Changing + Deleting -> Deletion
A conversion into CIF structures follows.This is especially a conversion of APO-intern product numbers and location numbers (Guids) into the external R/3 material numbers and plants. If order numbers are included (like in changes of existing orders), the system also converts the APO-internal order number into the R/3 order number. Then the system determines the receiver. The system then sends the order data via qRFC to the R/3 system (the q in qRFC stands for queue).

Steps for Data Transfer (3)

In the R/3 system, the system first converts the order data coming from the APO into R/3 format. The system converts them into a date and a time.
During creation of new orders in the R/3 system, the system performs a number assignment in the R/3.The system must transfer this new number back into the APO system, together with other changes to the order, which may have been made in the R/3 system.The APO system then makes the assignment (mapping) between the R/3 order and the APO order and stores it.

Communication Method The queue for communication might be of two types :

Outbound

Queue Inbound Queue

Communication Method Outbound Queue

Calling system sends the queues to the receiving system without taking care of the system load of the receiving system. No scheduling of the processes happen in the receiving system. Effect : - Overloading of receiving system - CIF performance deteriorates with high data volume

Communication Method Inbound Queue

Calling system sends the queues to the entrance (inbound) of the receiving system which allows the receiving system to control the system queue load on its own. Scheduling of the processes happen in the receiving system. Effect : - Better CIF performance To change from Outbound to Inbound Queue : Refer Notes 388001, 388528, 388677

CIF Monitoring Applications at a Glance

On R3 side qRFC Monitor (Transaction CFQ1) Application Log (Transaction CFG1)

On APO side qRFC Monitor (Transaction SMQ1) Application Log (Transaction /n/SAPAPO/C3)

Monitoring both R3 and APO from within APO SCM Queue Manager (Transaction /n/SAPAPO/CQ) qRFC Alert (Transaction /n/SAPAPO/CW)

Important Pre-Requisite at R3 and APO end (1)

Logging Mode to be switched on : Transaction in R3 : CFC2 Transaction in APO : /SAPAPO/C41

Normal
the number of data records transferred is logged

Detailed
the number and content of the data records transferred is logged

Delete entries: You can delete logs of the application log in R/3 and APO. The system does not delete the logs automatically. You can delete logs of the application log in R/3 and APO. Recommendation : Deleting the logs periodically (schedule background processing) Refer Next slide for further details

CIF Monitoring
R/3
Application log R/3: Error

APO

RFC

Master/ transaction data transaction data

- Communication errors - Application errors

Core Interface Core Interface

RFC

APO master/ transaction data

live Cache Cache

Application log APO: Error

CIF Monitoring An Example

Example: Application Log in APO Example: Application Log in APO
APO qRFC Monitor Refresh Client 800 800 User MUSTER MUSTER Function module CIF_ORDER_INBOUND_30A CIF_ORDER_INBOUND_30A Status text No active integration model Transaction recorded

APO Application Log Date User Number 120 Subobject type In-house production

02.10.2002 MUSTER

Function: /SAPAPO/CIF_IP_OUTBOUND: Order material P-102, plant 1000 R/3 Application Log Date User Number Subobject type In-house production

02.10.2002 USERADMIN 1

Problem class: very important Problem class: medium Problem class: additional information Inbound R3CLNT800: For system APOCLNT800 no active integration

Example: A planned order for a finished product and purchase requisitions for the components of the finished product have been created in APO. However, they were not included in any active integration model in the R/3 System at the time when the order was created in APO. Therefore, the orders were not created in R/3 but kept in the queue

Monitor Change Transfer

Report : RCPQUEUE (Use T-Code : SE38) This report is used to monitor the transfer of Transaction Data. This report can be used for : Checks the status of the active data channels - accordingly various data channels can be closed or opened. Display and analyze the objects to be transferred for each filter object

The list of the data channels are given in next slide.

Data Channels Data-Object-wise

Initial supply Stock Purchase orders and purchase reqn Planned orders/Production orders Sales orders Manual reservations Confirmations Planned independent Rqmnt Materials Production campaigns Master data for classes Master data for characteristics

CF_ADC_LOAD CFSTK* CFPO* CFPLO* CFSLS* CFRSV* CFCNF* CFPIR* CFMAT* CFPCM* CFCLA* CFCHR*

Steps to follow Data Transfer from R3 to APO

Data not found in APO Check R/3 application log (T-Code: CFG1) Yes No Check existence of active integration model

Check R/3 qRFC Monitor (T-Code: SMQ1) No

Yes

Check queue status

Correct error

Reactivate queue in R/3 and retransfer

Check APO application log (T-Code: /SAPAPO/C3)

Correct error

Steps to follow Data Transfer from APO to R3

Data not found in R/3 No

Check APO application log (T-Code: /SAPAPO/C3) Yes Yes

Check existence of active integration model

Check APO qRFC Monitor (T-Code: SMQ1) No

Check queue status

Correct error

Reactivate queue in APO and retransfer

Check R/3 application log (T-Code: CFG1)

Correct error

Data Inconsistency between R3 and APO CIF Delta Report

R/3
APO
Report /SAPAPO/CIF_DELTAREPORT2 Partner system (R/3) Material Plant Integration model Objects to be checked Sales orders Production/process orders ... Purchase requisition ... R3CLNT800 P-102 100 Pump (optional) (optional) (optional)

Storage location stocks Sales order stocks ... ... Compare

live Cache

Database

Questions

Thank You