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

Transaction Data

Locations
Products
PPMs (BOM+Routing)

Characteristics

Capacities

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

ERP
APO

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

Master Data
Transfer
R3 to APO

Transfer of Master Data

Initial transfer

R/3

APO

R/3 master data

APO master data

Plant

Location

Customer

Product

Vendor
Resource

Material master
Capacity

Production
process model

Routing and
bill of material

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

Name
Target system

Determine name and APO

Plant

target system

Material master

Select master data

2. Activate integration model

Integration model is active
Start

Master data will be transferred

Resource

...

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

X0

MRP procedure

Without MRP,
with BOM explosion

Material master D
Material master C
Material master B
Material master A

Integration model
Name

PUMP

Target s. APOCLNT800
Applic.

MATERIALS

Material master

Mat. A
X0

... Customers
Relevant materials

Mat. B
X0

APO

Planning in
APO

Mat. C
X0

Mat. D
VB

Product C
Product B
Product A

Material
Plant
MRP type
Material
...
status

1000
X0

Which Products to plan in APO ?

Planning type

APO
recommended

Externally procured products

with long replenishment times

Products manufactured
in-house at bottleneck
resources

Products that are not

critical for planning

Possible
in APO

APO not
recommended

(Non-critical) products
planned with reorder
point planning

(Non-critical) products
planned with KANBAN

Transfer of New APORelevant Master Data

New Data Transfer

Regenerate Data

Integration Model-1 : Products A & B at 10:00 hrs

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

New material (Product Q) to be

transferred to APO

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 APORelevant 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

PUMPS

Target system

APOCLNT800

Application

MATERIALS

JOB_1
Variant
PUMP_MAT

Execute

...

Step 1

Save

RIMODGEN report

alternative:

JOB_1_AND_2
Activate integration model
Name

PUMPS

Target system

APOCLNT800

Application

MATERIALS

RIMODAC2 report

JOB_2
Variant
PUMP_MAT

Active/

Inact .

+
Start

Step 2

Incremental Data Transfer

APO

Transaction CFC5
Material master
Business Transaction Event,

immed .

ALE change pointer, periodic

no incremental data transfer

Changed R/3 master data

objects are transferred into
APO when the changes are
saved in real-time

Customers
Business Transaction Event,

immed .

ALE change pointer, periodic

no incremental data transfer

Changes to R/3 master data

objects are recorded and the
transfer of the changes is
(periodically, for example)
triggered

Vendors
Business Transaction Event,
ALE change pointer, periodic
no incremental data transfer

immed .

Incremental Data Transfer

Incremental Data Transfer

ALE Change Pointers
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.

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

Change pointer generally active?

Relevant message type
active?

Material master A

Change pointer

Mat.planning
MRP type

X0

Plan. deliv .time 10 days

Matl .

Customizing

B in-house pro. time

Matl . A Plan. deliv . time

...

11 days

Variant
DELTA_MAT

Incremental data transfer

Target sys.

APOCLNT800

Object types
Material master

APO

Incremental
data transfer
Execute

...

Changed master
data in APO

Product A
Plan. deliv .time 11 days

Delete change pointers regularly

Transactional Data
Transfer
R3 to APO
APO to R3 (Publication)

Transactional Data Transfer

R3 to APO
APO

R/3
R/3 transaction data
Purchase orders

Initial data
transfer

Purchase requisitions
Sales orders
Planned orders
Planned ind.reqmts
Reservations
Stocks
...

Incremental
data transfer
Realtime

Initial data transfer

takes through CIF

APO transaction data

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

New transactional data

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

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, inhouse production or external procurement,etc), which R/3
System (logical system) to publish planning results.
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
transaction data
data

Core
Core Interface
Interface

- Communication errors
- Application errors

APO master/
transaction data

RFC

Application
log
APO:
Error

live
live
Cache
Cache

CIF Monitoring An Example

Example:
Example: Application
Application Log
Log in
in APO
APO
APO qRFC
Monitor
Refresh
Client

User

800
800

MUSTER
MUSTER

Function module

Status text

CIF_ORDER_INBOUND_30A
CIF_ORDER_INBOUND_30A

No active integration model

Transaction recorded

APO Application Log

Date

User

02.10.2002 MUSTER

Number

Subobject type

120

In-house production

Function: /SAPAPO/CIF_IP_OUTBOUND: Order material P-102, plant 1000

R/3 Application Log
Date

User

Number

Subobject type

02.10.2002 USERADMIN 1
In-house production
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-Objectwise

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)

No

Check existence of
active integration
model

Yes

Check R/3 qRFC

Monitor
(T-Code: SMQ1)

Yes

Check queue status

No

Check APO application log

(T-Code: /SAPAPO/C3)

Correct error

Correct error

Reactivate queue
in R/3 and
retransfer

Steps to follow Data

Transfer from APO to R3
Data not found
in R/3

Check APO application

log
(T-Code: /SAPAPO/C3)

No

Check existence of
active integration
model

Yes

Check APO qRFC

Monitor
(T-Code: SMQ1)

Yes

Check queue status

No

Check R/3 application log

(T-Code: CFG1)

Correct error

Correct error

Reactivate queue
in APO and
retransfer

Data Inconsistency between

R3 and APO CIF Delta
Report
APO

R/3

Report /SAPAPO/CIF_DELTAREPORT2
Partner system (R/3)

R3CLNT800

Material

P-102

(optional)

Plant

100

(optional)

Integration model

Pump

(optional)

Objects to be checked
Sales orders
Production/process orders
...

Purchase requisition
...

Storage location stocks

Sales order stocks
...
...

Database

Compare

live
Cache