The CIF provides real-time integration between APO and R/3 systems by transferring both master and transactional data. It uses integration models to determine which data objects to transfer and map them between the systems. Planning results from APO are published back to R/3 using a similar process. The CIF monitors data transfers which occur asynchronously using queued RFCs to ensure consistency between the systems.

1. APO Core
Interface (CIF)

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

3. Introduction to CIF

4. 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.

5. 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.

6. CIF Functions
ERP -> APO APO -> ERP
Master Data Transaction Data Planning Results
 Locations  Planned/Production  ATP Results
 Products Orders  Manufacturing Orders
 PPMs (BOM+Routing)  Sales Orders  Procurement Orders
 Characteristics  Purchase Orders  VMI Sales Orders
 Capacities  Stocks
 ATP Requests
APO
APO
ERP BW
ERP ERP
APO ERP

7. CIF Setup and Related
Configuration Tasks
► R/3 ► APO
 Set up a logical system
 Set up a logical system
 Assign LS to client
 Assign LS to client
 Set up RFC destination
 Set up business system
 Define target system (same name as
group
the RFC destination)
 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

8. Master Data Transfer
R3 to APO

9. 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

10. 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

11. Integration Model – Initial Data
Transfer
1. • Generate integration model •Name
•Target system
•Determine name and APO
•Plant
•target system
•Material master
•Resource
•Select master data •...
2. •Activate integration model
•Integration model is active
•Start •Master data will be transferred

12. 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)

13. 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

14. Selection Criteria – MRP Type X0
R/3 Material master D
Material master C
Integration model
Name PUMP
Material master B Target s. APOCLNT800
MRP type X0 Material master A
Applic. MATERIALS
MRP procedure X
Without MRP, Mat. A Material master
with BOM explosion X0
... Customers
Relevant materials
Mat. B Mat. C Mat. D Material
X0 X0 VB Plant 1000
MRP type X0
Material
Planning in Product C ...
status
APO Product B
APO
Product A

15. Which Products to plan in APO ?
Planning type APO Possible APO not
recommended in APO recommended
Externally procured products X
with long replenishment times
Products manufactured X
in-house at bottleneck
resources
Products that are not X
critical for planning
(Non-critical) products X
planned with reorder
point planning
(Non-critical) products X
planned with KANBAN

16. Transfer of New APO-Relevant
Master Data
New Data Transfer
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
Active
Integration Model-1 : Products A & B at 10:00 hrs
Inactive
Transfer of only Product Q happens

17. Transfer of New APO-Relevant
Master Data
New Data Transfer Regenerate Data Transfer
The system re-generates the existing
model (the new master data is also If you want the system to retransfer all
selected here) and then activates it. the master data of an existing
integration model, you must deactivate
Two models with the same name are the old models and activate only the
then active, the only differences being new one.
the dates and times. If the data
transfer starts in this situation, the A comparison of all active models then
system simply transfers the difference takes place. As in this case, the model
data. with the old time is not active, all data
is transferred again.
After the data transfer, the system
deactivates the "old" integration model,
leaving the "new" complete integration
model as the active model.

18. Periodic Data Transfers through
Batch Jobs
Generate integration model
Name PUMPS JOB_1
Target system APOCLNT800 Variant
Execute
PUMP_MAT
Application MATERIALS + Step 1
... Save
RIMODGEN report alternative:
JOB_1_AND_2
Activate integration model
JOB_2
Name PUMPS
Variant
APOCLNT800 Active/ Inact .
Target system
PUMP_MAT + Step 2
Application MATERIALS
Start
RIMODAC2 report

19. Incremental Data Transfer
Transaction CFC5
APO
Material master
Changed R/3 master data
Business Transaction Event, immed . objects are transferred into
ALE change pointer, periodic APO when the changes are
saved in real-time
no incremental data transfer
Customers
Business Transaction Event, immed . Changes to R/3 master data
ALE change pointer, periodic objects are recorded and the
transfer of the changes is
no incremental data transfer (periodically, for example)
triggered
Vendors
Business Transaction Event, immed .
Incremental Data Transfer
ALE change pointer, periodic
no incremental data transfer

20. 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.
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

21. 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 pointer generally active?
change Relevant message type
active?
Material master A
Mat.planning Change pointer
MRP type X0 Matl . B in-house pro. time
Plan. deliv .time 10 days
Customizing Matl . A Plan. deliv . time
...
11 days
Incremental data transfer
Variant Incremental
DELTA_MAT Target sys. APOCLNT800 data transfer
Object types Execute
Material master ...
Changed master Product A
APO data in APO Plan. deliv .time 11 days
Delete change pointers regularly

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

23. Transactional Data Transfer –
R3 to APO
APO Initial data transfer
R/3 takes through CIF
Initial data
R/3 transaction data APO transaction data
transfer Order with category New transactional data
Purchase orders
BF (PchOrd ) or changes to existing
Purchase requisitions
AG (PurRqs ) transactional data are
Sales orders BM (SalesOrder ) transferred
Planned orders AI (PlOrd .) automatically (real-
FA (FC req.)
Planned ind.reqmts time)
AM (PrdRes )
Reservations
Incremental CC (Stock)
Stocks ... Methodology of transfer
data transfer
... is same (using
Real- Integration Models)
time
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

24. 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).

25. Publication of Planning Results
► Report : /SAPAPO/RDMCPPROCESS
T-Code : /SAPAPO/C5
Function Module : /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

26. 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 # Inhouse Production
# External Procurement # Production Campaign
► However for the following objects, distribution definitions has to be defined irrespective
of them being created in R/3 or not :
# PIR # Delivery
# Confirmation (IS Auto) # Confirmation Deletion (IS Auto)
# Reservations # Reporting Points (IS Auto)

27. 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

28. CIF Monitoring

29. 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.

30. 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.

31. 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).

32. 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.

33. Communication Method
The queue for communication
might be of two types :
►Outbound Queue
►Inbound Queue

34. 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

35. 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

36. 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)

37. 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

38. CIF Monitoring
Application
R/3 log
APO
R/3:
Error
RFC
- Communication errors
Master/
transaction data
transaction data - Application errors
APO master/
Core Interface
Core Interface RFC
transaction data
live
Application
Cache
Cache
log
APO:
Error

39. CIF Monitoring – An Example
Example:
Example: Application Log in APO
Example: Application Log in APO
► A planned order for a
APO qRFC Monitor
Refresh finished product and
Client User Function module Status text purchase requisitions
800 MUSTER CIF_ORDER_INBOUND_30A No active integration model for the components
800 MUSTER CIF_ORDER_INBOUND_30A Transaction recorded
of the finished
APO Application Log product have been
Date User Number Subobject type created in APO.
02.10.2002 MUSTER 120 In-house production ► However, they were
Function: /SAPAPO/CIF_IP_OUTBOUND: Order material P-102, plant 1000 not included in any
active integration
R/3 Application Log
model in the R/3
Date User Number Subobject type System at the time
02.10.2002 USERADMIN 1 In-house production when the order was
Problem class: very important
Problem class: medium
created in APO.
Problem class: additional information ► Therefore, the orders
Inbound R3CLNT800: For system APOCLNT800 no active integration
were not created in
R/3 but kept in the
queue

40. 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.

41. Data Channels Data-Object-wise
► Initial supply CF_ADC_LOAD
► Stock CFSTK*
► Purchase orders and purchase reqn CFPO*
► Planned orders/Production orders CFPLO*
► Sales orders CFSLS*
► Manual reservations CFRSV*
► Confirmations CFCNF*
► Planned independent Rqmnt CFPIR*
► Materials CFMAT*
► Production campaigns CFPCM*
► Master data for classes CFCLA*
► Master data for characteristics CFCHR*

42. Steps to follow – Data Transfer
from R3 to APO
Data not found in
APO
No
Check R/3 Check existence of
application log active integration
(T-Code: CFG1) model
Yes
Yes
Check R/3 qRFC Check queue status Correct error Reactivate queue
Monitor in R/3 and
(T-Code: SMQ1) retransfer
No
Check APO application log Correct error
(T-Code: /SAPAPO/C3)

43. Steps to follow – Data Transfer
from APO to R3
Data not found
in R/3
No
Check APO application Check existence of
log active integration
(T-Code: /SAPAPO/C3) model
Yes
Yes
Check APO qRFC Check queue status Correct error Reactivate queue
Monitor in APO and
(T-Code: SMQ1) retransfer
No
Check R/3 application log Correct error
(T-Code: CFG1)

44. 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
... ...
Compare live
Database Cache

45. Questions
Thank You