- CIF is the integration component between APO and SAP ERP. We cover how to create integration models in the CIF, understanding outbound and inbound queues, how to interpret CIF errors and the CIF Queue Manager.
- There is much to learn about the CIF regarding the real story, and the importance of the CIF administrator.
Introduction: Understanding the CIF
The CIF is the integration between APO and ECC. You will learn how the CIF is configured and used.
What is the CIF?
The CIF integrates SAP ERP and APO. The CIF (or core interface) is the standard method by which you move data between APO and ECC. The systems are “loosely coupled.” That is that master data, and transaction data must be transferred between the systems periodically and in only a few situations (such as GATP) is immediate interaction necessary. APO becomes increasingly transactionally oriented 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 effective solution to 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.
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 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 your 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.
Here you can see the CIF is the central integrating component for all the APO modules.
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. Companies are live for years and have the CIF as a continual maintenance item. For years SAP used the Core Interface (CIF) which is an adapter between SAP ERP and APO to convince companies that they were offering a truly integrated solution and that businesses should never use best of breed applications that were better than APO’s modules because they were not “integrated to SAP.” However, as a person who moves between different SAP accounts, often attempting to improve APO implementations, I can say unequivocally that the CIF has been a nothing like what was advertised by SAP sales or by large consulting companies.
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. It is going to be painful, but let’s get on with it.
I found a nice slide on the CIF from SlideShare, so we thought we would start there.
One of the advantages of using A is that you can “CIF” or send over data from SAP ERP where it is often maintained as the system of record (although that can change per implementation). CIF always requires configuration and often some enhancements, however, it is the standard integration harness between APO and SAP ERP. The integration includes:
From SAP ERP to APO Master Data
- Material Master
- BOM / PPM / iPPE
- Schedule Agreement
- Planned Orders
- Production Orders
- Purchase orders
From APO to SAP ERP Transactional Data
- Purchase Order Req
- Stock Transfer Order Req
- Production Order
- Planned Order
- ATP Request
There is also a major organizing principle the integration models that should be followed. SAP recommends the following:
- ATP customizing and product allocation customizing
- Characteristics and Classes
- Material Masters and Characteristics and Classes
- MRP Areas, Material Masters for MRP Areas, Characteristics, and Classes
- Planning Product
- Availability Check
- Product Allocation
- Customer and Suppliers
- Work Centers
- 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.
Often much of the following paragraphs have been set up 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 APO side and on the ECC side. We will address the ECC configuration first.
ERP Side of the CIF
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
After the RFC destination has been created, we assign it to application cases.
Go to this path…
ECC SPRO – SAP Customizing Implementation Guide – Integration with Other MySAP Components – Advanced Planning and Optimization – Assign RFC Destination to Different Application Cases
The APO Side of the CIF
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
Then the logical names assigned then to physical clients.
Go to 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
Next is setting up RFC destinations…..
As a planning application and APO box can be integrated into 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.
Go to 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 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.
However, the complexity comes with assigning the BSG to a logical system. We get there by following the path below.
Go to 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
However, a logical system can only be assigned to one BSG, as you can see from the error below.
Go to 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 resides in SAP ERP, and not in APO)
- CFM1 – Create the model
- CFM2 – Activate the model
- CFM4 – Display the model
- CFM5 – Search for the model
- CFM6 – Change the model
- CFM7 – Delete the model
Now I will post the screenshots 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.
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 used in SAP. Essentially variants are different integration models. Which of course is confusing.
- CFM2: Activate or deactivate integration model
- CFM3: Activate integration model
During activation, a consistency check can be performed for the model.
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 say more about the ability of the objects to be used once they get into APO than about whether CIF intends to bring over the objects. You can find out by activating the model. See below.
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, 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 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, 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 save a single variant per integration model simply.
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
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.
Double-Click the numbers.
- CFM5: Filter Objects in the integration model
- CFM6: Change integration model
CIF Transactions in APO
All of the qRFC transactions are centralized here in the APO directory structure. They are primarily error checking and monitoring in nature:
- RZ20 – CCMS – Commonly the admin will lock you out of this. The area that is of great interest is called error handling.
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 possible error messages cannot be directly returned to the application.
- Communication errors – this includes network problems, non-existant RFC destination
- 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 critical because just like a printer queue, once you have one wrong 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 selects Display Selection
Application logs for error processing. Go to this path…
Logistics – Central Functions – Supply Chain Planning Interface – Core Interface Advanced Planner and Optimizer – Monitoring – Application Log
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 donut 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 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 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.
The CIF 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.
APO back to ECC
The CIF usage typically starts off with configuring CFM1 in ECC. This makes sense as the initial master data, and even transaction data transfer is from ECC to SCM. SAP calls ECC the dominant master data system. Not that master data cannot be created in APO, and not that APO does not have master data that does not exist in ECC (it does) only that it is primarily configured in ECC. After planning is complete, there has to be a way to get the results from APO back to ECC.
Thus it becomes necessary to configure the second leg – or back to the mother ship. For this to occur, first, it is necessary to configure SCM SPRO.
Go to this path…
APO SPRO – Integration with SAP Components – Integration Via Core Interface – Basic Settings for Data Transfer – Publication – Maintain Distribution Definition
This is a clumsy transaction. It asks for me to enter the types of objects we want to be able to come over to each location. It also gives a strange error when we first insert our object and logical system.
The Calendar Setup
Underestimated and possibly overlooked, the calendars need to be synced between ECC and SCM. This way both systems use the same assumptions. We need to goto RSA1, select the source system and transfer global settings.
Then select factory calendar
There are many different calendars to transfer. There is a production calendar, a shipping calendar, etc…. These different calendars are associated with different locations. Here you can see the calendar options at our Vendor in San Diego.
Here you can see we are on the production calendar.
Here we assign this calendar to this location.
There is a lot more to the calendars and a lot more to how the systems are synched, and we will build out this article as time passes.
The Real Story Behind the CIF
In addition to consuming significant resources during implementations, 4 to 5 years after go-live the CIF is still consuming support time. I have considerable experience in middleware and interface development over the years seeing solutions such as SeeBeyond, Informatica in addition to building custom adapters between SAP ECC and planning systems. It combines a bad user interface with reduced error checking, and with a degree of complexity which makes it very easy for a small irregularity in either system (SAP ERP or APO) to upset the apple cart. The CIF has errors that require troubleshooting, and the queues must frequently be manually cleared. The errors that are produced by the CIF can also be entirely inaccurate. SAP consultants that think the CIF is a decent tool, often have never been exposed to “real” middleware.
I am surprised myself how the CIF performs at companies because as a person who has worked in SAP integration off and on since 1998 and has connected five planning systems to SAP, I know that planning system to ERP adapters is not very complicated to create.
So when you are discussing the limitations of actually existing SAP to SAP integration, realize that this is supported by a large number of client experiences. For almost a decade I accepted the official SAP position that CIF needs to be part of the APO implementation. It is only recently that I have begun to question if this is beneficial.
Why Is the CIF so Problematic?
One of the biggest problems, which should have been caught early on by SAP development, is that SAP made the integration system overly complicated. This means that there is a significant amount of logic in the CIF that in most cases are not desired or needed by the client. I extensively documented one issue related to sales order integration recently in this post. The decision to include this level of detail in the field that was pulled for consumption logic was never going to be a good trade-off and should have been recognized as a long-term maintenance item during the initial CIF development.
Since this article, I have worked on two more clients, both with persistent problems with the CIF. I understand that it is sacrilegious to say things that oppose SAP sales and product management, but one would have to be blind not to see the pattern.
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 cannot 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 outsource its middleware to someone like Informatica, everything could be so much more simple. It’s difficult to buy things like the new SAP integration products when things like the CIF sit with little improvement year to year.
Anyone who works on SAP APO projects knows that the CIF is extremely unappealing to work with, has a poor and confusing user interface and constitutes a long-term maintenance problem for clients. The problem that you say distributed to other parts of APO and ERP is also related to the CIF itself. However, I would ask you to review the 99% value that you quoted. The CIF has far more than 1% of the blame for its maintenance woes.
SAP has designed a solution with the CIF that has so many options for how data will be represented in APO that it creates significant problems, and makes for a fragile interface. At the heart of it, I don’t trust SAP development to make the right decisions with integration products, because they have proven themselves to be not very good at it. I can point to SAP XI/PI as another integration product that SAP has had major issues with. The problem is that companies are not buying the CIF or XI/PI because it competes well with companies that do integration well, but because the products come with the SAP brand. There are simply a lot of things that SAP does not do well. Integration, data management, document management (i.e., Solution Manager).
If you rely on products that could not survive outside the SAP universe, you end up disabling your company’s abilities to accomplish its goals. This must be differentiated from IT’s or a consulting company’s goals. As long as their budgets are increasing, even if poor functioning products are provided to the business, IT and consulting companies are usually pretty happy. However, I am proposing to broaden the analysis of what is “good.”
A qRFC is not fundamental to any design, many interfaces have no qRFC and run much better than the CIF. In fact, RFCs are known as slower than direct table connections. (of course, this is impossible in SAP) The problem many SAP consultants have is they consider SAP an innovator in every area. SAP is not a respected company in integration. The only integration business they have is integrating into their products. I should not have to do much more than bring up the work “IDoc” to illustrate this point. Look at Informatica’s products sometimes to see what a real integration vendor looks like.
When the CIF Administrator is Necessary
The CIF Administrator must be available before go-live to support all of the troubleshooting that proceeds go-live. They will then need to support the APO applications post-go-live.
The Skills Set and Behavior of the CIF Administrator
The CIF Administrator is primarily a technical role. They must be technical enough to fix problems in the CIF, but for more fundamental issues, they must be able to communicate with functional resources. This is because many problems that crop up in the CIF are often related to problems in the functional module. While technical, they must also be able to communicate out to the broader business community when there are issues. One common complaint at other SAP APO clients is that the business community can feel left in the dark when there are problems. This should not be the case. The CIF Administrator needs to be ahead of the planners and challenges should not be discovered in planning books that the CIF Administrator does not catch beforehand. There will be problems with the CIF and challenges with APO in general post-go-live.
However, the interpretation of these inevitable problems is quite different when they are discovered and communicated by the CIF Administrator versus being discovered by the planners. When planners are told which parts of the product location database are having a problem, and the steps and timeline that are part of the solution, the planners can adjust and not waste time. They can work on other things and return to APO when it is functioning properly. Simply the knowledge that the CIF Administrator is on top of the problem increases confidence in the system.
Regarding communicating both general APO and specific CIF problems, it is important that the CIF Administrator talks to the planners in business terms that mean something to them. Comments to the effect that.
Inbound queues are now up to 250,000 records, causing data inconsistencies…
Is not translating the technical problem into a business language. The planners will want to know when the system has the correct output for the products they are responsible for. I have seen a variety of emails sent from CIF Administrators to the business, some getting into detail on the CIF, and showing screenshots of the CIF queues. I have also seen it debated as for whether a report should be sent out every week, which communicates the state of the system and the CIF to the business.
Generally what I have seen work best is for the assumption to be that the system is working properly unless the business receives an email outlining a problem with the CIF. When an email is sent, it should outline not the problem, but the implications of the problem. One example might be.
APO is having some issues will prevent the following product groups (A, B, C) from displaying proper values. We are currently working on the problem and as soon as we know more we will send out a new email.
While the role is titled “CIF Administrator,” the individual who fills the role must be able to work in all of the transactions, both in APO and ERP, to troubleshoot problems, though they may first appear in the CIF. Because the role of the CIF Administrator is a support function, the individual filling the role should have a support background. A support resource is a very different resource than, for instance, an SAP implementation resource, or a SAP training resource.
The CIF Administrator is a role that is required for companies that are serious about having a successful APO implementation. The more APO modules a company implements, the more effort is needed on the part of the CIF Administrator. Implementing a single module does not make the role of a CIF Administrator a full-time role, but few companies that implement APO are satisfied with implementing just one module.
The CIF Administrator must be technical, but if they are supported in their communication by another resource, they must be able to explain to the business when there are problems, and they must find the problems before they do, and also communicate when the problems will be rectified. SAP has a hard time communicating the huge support needs of the CIF because they are tied to their sales message that the CIF is a great middleware product that is easy to use.
The “ease of integration” is part of SAP’s master strategy to keep companies afraid of using other applications, even though in many cases writing a custom integration product would be superior to the performance and stability of the CIF. Therefore, they are not a reliable source of information on the staffing requirements for the CIF, even though it is their product.
Issue of Integration
One of the most frustrating things about getting EWM or any SCM component up is the work required to get ECC working properly. As EWM is transactionally focused (rather than planning oriented), it has a high degree of traffic moving between ECC and SCM. SCM has only a few things that it wants from ECC. Yet it requires all types of setup that the SCM consultant is not interested in getting into, and often there is CIF consultant on staff (most projects to not see the CIF as requiring a separate consultant but expect the knowledge to come with a functional consultant).
If you are on a project then you can ask a fellow ECC consultant to do this, however, if you are not or if you can’t get their time, you will have to do it yourself. We tried to create POs using the Purchasing Org and Company Code that we did not create. We ran into problems because of the of the validity period of the company. You can see this below. Notice how a number of the Company Code’s validity periods are in the past.
Company Code (Hijacking)
This in SPRO is where you create the Company Code.
We tried creating our company code but ran into problems, so instead, we decided to use an existing company code. (which is 3000)
Next, we want to assign a plant to this company code.
This is where you assign the Plant to the Company Code. By choosing an existing company code, we don’t have to worry about assigning the company code to the purchasing organization.
However, we do want to assign the purchasing org to the plant.
Sales Org Assignment
We used an existing company code as the company code we tried to create ourselves we had problems getting to work properly. We want just to get things working from a supply chain perspective, and we are not concerned about financial postings.
Next we want to assign the Sales Org to the Plant. You can find this by searching.
However, even after doing this, we still were not able to extend a material to our new plant. It did not bring up plant SNA5 as an option. However, when it finally did, we were not able to extend the material because it did not have an MRP Controller assigned to the plant.
For some reason, we forgot to document this step last time for the first four plants that we created.
Next, we go through entering various fields into the material master, and we get an error on the Scheduling Key, and we find that it is not assigned to the material.
Then to this.
MRP Areas and Transfer
Next, we create storage locations Enterprise Structure – Definition – Materials Management – Maintain Storage Location.
Now when we goto MRP Areas.
SPRO – Materials Management – Consumptive Based Planning – Master Data – MRP Areas – Define MRP Areas
We can see that the storage location creation essentially creates an MRP Area for us.
We want to assign these MRP Areas to the correct material and plant combination. To do this, we go into (MM02), to the MRP 1 tab and select the MRP Area button towards the bottom of the screen.
Now we will fill in the next screen.
Now we will want to transfer the MRP Area to SCM with CIF.
Strangely, while this is documented (to use storage locations as proxies for MRP Areas), this did not work when we put in into practice. However, if we add the MRP Areas in the screen below, then they do show up in the integration model.
You can see them in the integration model.
After we check the CIF model that only transfers MRP areas (as recommended by SAP)
Just because you create an integration model, does not mean that you only have to type in the integration model and change it. In fact, it is necessary to save integrations models as variants to bring them up in the future and modify them. You do this by selecting the save button after you have configured your integration model.
Without doing this, we do not know if it is possible to alter the integration model after first creating it. There is no CFM* transaction for modification. It is transaction CFM1 with variant.
When you get back into the CFM1 transaction it necessary to select Goto the menu and then choose your variant.
Here you can see there is a log of changed integration models when you go into transaction CFM2.
Unfortunately, we got the same errors.
However, we have gotten errors before, and the CIF still went through. The way we check is to go to the Location Master in SCM and type in the MRP Area.
After all those errors it the storage location came across fine!!The big lesson from this is to take the CIF errors with a grain of salt. Also, notice the location type is 1007.
So it is a 1007 location inside of a 1002 location (distribution center plant).
Customer Creation and Transfer
Next, we will want to create a customer. It is very important that the customer is picked up as a 1010 type (VMI) as that is the only location that will be modeled in SCM. Later we will test this to see if it was the case.
Now after filling in a few fields, our customer is created. This next part is very important, so we wanted to quote directly from SAP documentation.
“As of release 4.0 of SCM the maintenance of the sales area shifted from the customer location to the CIF. You assign the sales area to your sold to and delivering plant.” – SCM215
It is located here:
Integration with Other mySAP.com Components – Advanced Planning and Optimization – Application Specific Settings and Enhancements – Settings and Enhancements for Sales Orders – Settings for Vendor Managed Inventory VMI – Assign Sales Orders and Order Type to Ordering Party/Plant
While this functionality has been moved to the CIF, interestingly another portion does not move through the CIF – that is the sales transactions.
“Similar to that of the plant, stock movements will be modeled via stock transport requests in SNP and PP/DS. When it is time to deploy and ship, SAP SCM can instruct SAP ECC to convert stock transports to sales orders. This functionality is the reason for the addition of the VMI tab.” – SCM215
Now we will want to create an integration model to move the customer over to SCM and see if it is picked up as a location type 1010. Underneath Material Independent Objects, we find the selection of Customers. We want to CIF our one customer over.
We will activate and run the model with (CFM2) and not bother looking at the error log as the CIF error log always seems to have some problem. Now we can see the customer has been created.
Supplier/Vendor Creation and Transfer
The supplier is just another location (type 1020) Let’s start by creating our Supplier.
Now we will transfer to CFM2 by typing /nCFM2.
However, we keep getting an error on the address of the Vendor. This error is critical as it prevents the activation of the integration model. We do have the address field filled in, so the actual problem is not apparent to us. What we did learn is that we had left over errors and a blocked message queue even after we changed vendors we received the old error.
So we goto the qRFC Monitor and delete the queue.
To start off, it is important to have the comprehensive CIF transactions. Strangely, as it would not appear as if we have to bring over plants and materials into APO each time, although it seems 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.
Brightwork MRP & S&OP Explorer
Improving Your Supply Planning, MRP & S&OP Software
SAP ECC and SNP cannot be run effectively for MRP and supply planning without help from another application.
Brightwork Research & Analysis offers the following supply planning tuning software, which is free to use in the beginning. See by clicking the image below: