Professional Documents
Culture Documents
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
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.
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
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
Planning Results
ATP Results Manufacturing Orders Procurement Orders VMI Sales Orders
APO
ERP
BW
APO
ERP
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
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
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
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
Material master
Resource
...
Integration model
Name Applic.
PUMP
MATERIALS
Target s. APOCLNT800
APO
Planning in APO
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
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
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
APO
Changed R/3 master data objects are transferred into APO when the changes are saved in real-time
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
Change pointer
X0 Customizing
Matl . ...
Variant DELTA_MAT
Incremental data transfer Target sys. Object types Material master APOCLNT800
...
Product A Plan. deliv .time 11 days
APO
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) ...
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
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).
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 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 :
However for the following objects, distribution definitions has to be defined irrespective of them being created in R/3 or not :
+ + +
Consistency check
You can check the consistency of the selected data in the integration model
CIF Monitoring
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.
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).
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.
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
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
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)
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
RFC
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
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
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*
Yes
Correct error
Correct error
Correct error
Correct error
Database
Questions
Thank You