CIF – The Core Interface

by Shaun Snapp on May 21, 2008

puzzle
The CIF integrates SAP ERP and SCM.

What Is It?

CIF (or core interface) is the standard method by which you move data between SCM and ECC. The systems are “loosely coupled.” That is that master data and transaction data must be moved between the systems periodically and in only a few situations (such as GATP) is immediate interaction necessary. However as SCM becomes increasingly transactionally oriented (i.e. the areas outside of APO such EWM), we can see the CIF being increasingly transactionally real time. Whether the CIF is ready for that is hard to say. It is by in large not a very impressive solution with many problems especially in the area of error checking (which have been significantly enhanced in 5.1, but its functionality still lags open even source tools) and is the worst middleware software I can recall using or ever seeing demonstrated. SAP makes a big deal about the CIF, but is doing nothing more sophisticated than what myself or other people who work in integration do with simple AWK scripts and UNIX batch jobs. The CIF succeeds in making completely elementary things exceedingly difficult and time consuming to do, and is a boon for consulting billing hours on APO projects across the country. Secondly, companies are live for years and have the CIF as a continual maintenance item. Because so many SAP consultants are so intensively brainwashed by SAP and have never seen quality middleware before, they don’t know what it is. Anyone who wants to understand how middleware should actually be designed can check out Informatica.

However, as much as everyone hates working with the CIF is an unfortunate fact of life for APO projects, and this post is assuming you decide to use the CIF. Its going to be painful, but let’s get on with it.

Background

The CIF is both a frontend (GUI) and a container where multiple (Remote Function Calls) RFCs that are batched into logical units of work that are collected for a data transfer using the core interface CIF. CIF has its own configuration transaction (PIMG) This is a highly recommended transaction to go into for managing the CIF, it is much more efficient than going into SPRO and does not waste you time navigating through items that have nothing to do with the CIF. However, it does not have any extra functionality over that of SPRO, it is just a specialized transaction to give you access to all ECC CIF functionality and nothing else.

I found a nice slide on the CIF from SlideShare, so we thought we would start there.

cif-intro.jpg
http://www.slideshare.net/srinatha/14-integration-40

One of the advantages of using SCM is that you can “CIF” or send over data from SAP ERP where it is maintained often as the system of record (although that can change per implementation) the CIF always requires configuration and often some enhancements, however, it is the standard integration harness between SCM and SAP ERP. The integration includes:

From SAP ERP to SCM Master Data

  1. Plant
  2. Material Master
  3. BOM / PPM / iPPE
  4. Schedule Agreement

Transaction Data

  1. Requirements
  2. Planned Orders
  3. Production Orders
  4. Purchase orders
  5. Confirmations

From SCM to SAP ERP Transactional Data

  1. Purchase Order Req
  2. Stock Transfer Order Req
  3. Production Order
  4. Planned Order
  5. ATP Request

Integration Models

There is also an overriding organization principle the integration models that should be followed. SAP recommends the following:

  1. ATP customizing and product allocation customizing
  2. Plants
  3. Characteristics and Classes
  4. Material Masters and Characteristics and Classes
  5. MRP Areas, Material Masters for MRP Areas, Characteristics and Classes
  6. Planning Product
  7. Availability Check
  8. Product Allocation
  9. Customer and Suppliers
  10. Work Centers
  11. PPM
  12. Schedule Agreement, Contracts, Purchase Info Records,

CIF uses a queuing system (like other middleware products) and comes with a consistency checking transaction that allows for the monitoring of the transfer.

Creation of Initial System Settings for Data Transfer

Oftentimes much of the following paragraphs have been setup already if you arrive on a site. However, if not, this work has to be done before you even go into the CIF and start creating integration models. They are both on the SCM side and on the ECC side. We will address the ECC configuration first.

SAP ERP Side

The SAP ERP side of the CIF is much bigger with more transactions and much more feature rich. The first we will look at is Name Logical Systems.

SAP ERP SPRO – SAP Customizing Implementation Guide – Integration with Other MySAP Components – Advanced Planning and Optimization – Name Logical System

ecc-cif-name-logical-systems.jpg
Next is assigning to a client

ecc-spro-cif-assign-to-a-client.jpg
Next setting up an RFC destination is SM59.

ecc-rfc-destination-setup.jpg
After the RFC destination has been created we assign it to application cases.

Goto this path…

ECC SPRO – SAP Customizing Implementation Guide – Integration with Other MySAP Components – Advanced Planning and Optimization – Assign RFC Destination to Different Application Cases

ecc-spro-cif-assing-to-rfc-destination.jpg
Next is setting the target system model type. This is between (transactional events, down or initial transfer active). Transactional events are the standard and is most the time what we see.

ecc-spro-cif-set-target-system.jpg
There are other settings, such as setting number ranges, but these were the major ones for setting up the system. Now we will move on to the SCM side of the CIF.

SCM Side

Transfers happen between logical system names. Typical logical system names would be SCMCLNT400, ECCCLNT40. The logical names are first created with the program SAPLBD41.

Goto this path…

SAP SCM Implementation Guide – Advanced Planning and Optimization – Master Data – Integration with SAP Components -

Integration via Core Interface (CIF) – Name Logical Systems

scm-spro-create-logical-system-name.jpg
Then the logical names assigned then to physical clients.

Goto this path…

SAP SCM Implementation Guide – Advanced Planning and Optimization – Master Data – Integration with SAP Components – Integration via Core Interface (CIF) – Assign Logical Systems to a Client

scm-spro-rfc-assign-logical-destinations.jpg
Next is setting up RFC destinations…..

As a planning application, and SCM box can be integrated to multiple ECC boxes, although the opposite would probably never happen. In these cases a master data issue comes up particularly with the material master. Integrating multiple ECC systems and normalizing master data is one of the reasons for the application MDM. However, if MDM is not in the footprint, there are other ways of performing his normalization with customer exits.

Goto this path…

SPRO – Integration with other mySAP Components – Advanced Planning and Optimization – Application Specific Settings and Enhancements

Also, Business System Groups (BSUs) allow you to group physical systems. This allows a segmentation of their master data, within a single Planning Version and Model. Of course another option is to create another Planning Version and Model for the second SAP ERP system data. Creating a BSG is easy.

scm-spro-bsg.jpg
However the complexity comes with assigning the BSG to a logical system. We get there by following the path below.

Goto this path…

SAP SCM Implementation Guide – Integration with SAP Components – Integration via Core Interface – Basic Settings for Creating the System Landscape – Assign Logical System and Queue Type

scm-spro-bsg-2.jpgHowever, a logical system can only be assigned to one BSG, as you can see from the error below.

Goto this path…

SAP SCM Implementation Guide – Integration with SAP Components – Integration via Core Interface – Basic Settings for Creating the System Landscape – Maintain Business System Group

Inbound vs. Outbound Queues

You can use either inbound or outbound queues. Inbound queues can handle a much bigger data volume than outbound queues. What this means is that the receiving system controls the data transfer. The transfer between the two (inbound vs. outbound) takes place in ECC (CFC1).

Important CIF Transactions in ECC

After the base transfer settings in SPRO have been initialized, the next step is to go to the CIF GUI. The CIF transactions can be conveniently segmented into those initiated from ECC and those initiated from SCM. The major transactions for integration model management are the following:

(All of these transactions are initiated in ECC where all model management is performed. The APO CIF transactions are primarily deal with troubleshooting the CIF, so the majority of CIF code actually resides in SAP ERP, and not in APO)

  1. CFM1 – Create the model
  2. CFM2 – Activate the model
  3. CFM4 – Display the model
  4. CFM5 – Search for the model
  5. CFM6 – Change the model
  6. CFM7  – Delete the model

Now I will the screen shots for these. The integration models are created and activated in ECC.

  • CFM1: Create integration model. Notice from this screen that multiple categories of items can be selected, and that each combination of selections can be saved as a different variant.

cif-create-model.jpg
There is no change integration model. The way to change is to use the same transaction (CFM1) but to call up a saved variant by selecting the Goto menu item and then open a saved variant. It is different from how variants are generally used in SAP. Essentially variants are different integration models. Which of course is confusing.

cif-variant1.jpg

  • CFM2: Activate or deactivate integration model
  • CFM3: Activate integration model

During activation, a consistency check can be performed for the model.

ctm-profile-consistency-check.jpg

CIF Errors

However the problem with this is that while the CIF may show errors, it still will often bring over the objects in any case. The CIF errors actually say more about the ability of the objects to be used once they get into SCM than about whether CIF intends to bring over the objects. You can find out by activating the model. See below.

cif-activate-model1.jpg
Importance of the Variant to the CFM1 Transaction

You can also create a variant on the CFM2 transaction. However that variant will have to do with the options on this screen and will not affect the combination of product location or the objects to be brought over. That is controlled by the integration model. Those items are set as variants on the CFM1 transaction. Because the model defining options are on the CFM1 screen, that variant is much more important and really, because there is no CIF change transaction (at least in SCM 5.0), a variant should be created every time you create a model in CFM1. In fact, the variant really is the model particularly if you ever want to change it, which you certainly will. However, I do not suggest that you create multiple variants per integration model. This is because in order to activate and run a model, you type in the model name into transaction CFM2, you do not grab a variant. Therefore, it is less confusing to simply save a single variant per integration model.

If you want to make a different, but similar integration model, name it a new integration model rather than using the variant function. The variant function, at least in this case, is best used to bring up and save and change a single integration model.

  • CFM4:Display Integration Model

ecc-display-integration-model-2.jpg
This takes you to this screen which shows you how many of each type of data is part of the integration model. You can drill into any of these to see an itemized view.

ecc-display-integration-model-3.jpg Just double-click the numbers.

ecc-display-integration-model-4.jpg

  • CFM5: Filter Objects in integration model
  • CFM6: Change integration model

CIF Transactions in SCM

All of the qRFC transactions are centralized here in the SCM directory structure. They are primarily error checking and monitoring in nature:

cif-all-monitors-for-scm.jpg

  • /SAPAPO/CC
  • /SAPAPO/CW
  • /SAPAPO/CQINW
  • SMQ1
  • SMQ2
  • RZ20 – CCMS – Commonly the admin will lock you out of this. The area that is of great interest is called error handling.

Errors

There are two types of errors that are distinguished for the processing of qRFC calls. With RFC the triggering application does not have to wait for the update to be completed in the target system. However this means that the return parameters cannot be based on and potential error messages cannot be directly returned to the application.

  1. Communication errors – this includes network problems, non-existant RFC destination
  2. Application errors – program errors, missing master data at a transaction date

The way to view this is:

Logistics – Central Functions – Supply Chain Planning Interface – Core Interface Advanced Planner and Optimizer – Monitoring – qRFC MonitorThe qRFC Outbound Queue

This is very important because just like a printer queue, once you have one bad item in the queue, it blocks any other items from being processed. So occasionally it becomes necessary to delete the items in the queue using this transaction (SMQ1).

Here you will see queues that are blocked. Select the queue that is related to your material and select Display Selection

Application log for error processing. Goto this path…

Logistics – Central Functions – Supply Chain Planning Interface – Core Interface Advanced Planner and Optimizer – Monitoring – Application Log

ecc-qrfc-outbound-queues.jpg
The CIF Cockpit

The CIF Cockpit (/SAPAPO/CC) is supposed to be easy to read, but in reality it is anything but easy. Below is a snapshot of the CIF Cockpit. Really, what was SAP development thinking when they created this interface. Someone please guess what the donught icon means.

This CIF Cockpit is a container for CIF background jobs, qRFC (remote function call, the CIF is a way of setting up remote function calls), CIF Comparison, etc..This transaction is strange and actually gives a lot of false errors when you attempt to login (for some reason you need to login to this transaction) However, if you hit the green checkbox several times and get rejected, simply hit the yellow up arrow and you will be allowed in.

cif-cockpit.jpg
CIF Postprocessing

CIF Postprocessing transaction = /SAPAPO/CPP2

Here you can see we have no records processed, which is a concern because we should as we put several POs through in our CIF model. No sign of them yet.

cif-postprocessing-in-scm.jpg

cif-postprocessing-in-scm1.jpg

cif-postprocessing-3.jpg
Queue Manager

/SAPAPO/CQ- Queue Manager – this is a strange transaction and brings up login issues. You are supposed to be able to login to a remote system, but we had repeated problems using it.

scm-queue-manager.jpg
The errors come when you try to login to the remote system.

scm-qm-error.jpg

Even when we get it to work, it is not amazingly detailed in information. It seems to show nothing in queue (what we have up is from a different user number)

scm-queue-manager-2.jpg

SCM back to ECC The CIF usage typically starts off with configuring CFM1 in ECC. This makes sense as the intial master data and even transaction data transfer is from ECC to SCM. SAP calls ECC the dominant master data system. Not that master data can not be created in SCM, and not that SCM does not have master data that does not exist in ECC (it does) only that it is primarily configured in ECC. However, after planning is complete, there has to be a way to get the results from SCM back to ECC, thus it becomes necessary to configure the second leg – or back to the mother ship. In order for this to occur, first it is necessary to configure SCM SPRO.

Goto this path…

APO SPRO – Integration with SAP Components – Integration Via Core Interface – Basic Settings for Data Transfer – Publication – Maintain Distribution Definition

scm-spro-cif-maintain-distribution-definition.jpg
This is actually a clumsy transaction. It asks for me to enter the types of objects we want to be able to come over for each location. It also gives a strange error when we first insert our object and logical system.

scm-spro-cif-error-for-distributed-definitions1.jpg
However, eventually, I was able to enter all of our locations.

scm-spro-cif-maintain-distribution-definition-2.jpg
Now I should be able to move these objects between the systems. This is a location specific setup. So it can not be configured for the entire Planning Version or Planning Model.

Change Pointers

CIF has a series of change pointers that are described in this post.

http://www.scmfocus.com/sapplanning/2008/09/20/cif-change-pointers-and-transactions/

Non SAP Integration

The BApi Explorer for managing non SAP integration is listed under the CIF as well. See this post for more details.

http://www.scmfocus.com/sapplanning/2008/05/25/bapi-explorer/

Calendars

To learn more about setting up the transfer of calendars from SAP ERP to SCM, see this post.

http://www.scmfocus.com/sapplanning/2008/09/12/cif-calendar-setup/

Setting Up the SAP ERP Sales Org and CIF

Organization setup and synchronization is one of the most important parts of setting up the CIF.

http://www.scmfocus.com/sapplanning/2008/09/01/sap-erp-org-setup-the-cif/

Problems with CIF

Setting up the models is straightforward. However, troubleshooting the CIF is a serious issue that can consume many hours of troubleshooting. Really, at this late date, the CIF should be far better, and many of the error simply require experience and can not be troubleshot through logical means. I am very disappointed in SAP development for not improving this when there are so many easy ways to improve the system. If SAP would simply outsource its middleware to someone like Informatica everything could be so much more simple.

Basic Advice

To start off its important to have the comprehensive CIF transactions. Strangely, as it would not appear as if we have to bring over plants and materials into SCM each time, although it appears we do have to. We seem to get more errors in the CIF when we try to just bring the transactional objects (POs in this case) over without the associated master data.

This was an introduction to the CIF. For more on the CIF see other posts that show use using the CIF to bring data between the systems.

http://www.scmfocus.com/sapplanning/category/cif/

Shaun Snapp

Shaun Snapp is a long time supply chain planning software consultant, author & as well as the Managing Editor at SCM Focus. He focuses on both SAP APO as well as best of breed applications for demand, supply and production planning.

Previous post:

Next post: