What This Article Covers
- Integration Models
- Creation of Initial System Settings for Data Transfer
- ERP Side of the CIF
- The APO Side of the CIF
- Inbound vs. Outbound Queues
- Important CIF Transactions in ECC
- CIF Errors
- Importance of the Variant to the CFM1 Transaction
- CIF Transactions in APO
- CIF Errors
- The CIF Cockpit
- CIF Postprocessing
- The CIF Queue Manager
- APO back to ECC
- The Calendar Setup
- The Real Story Behind the CIF
- Why the CIF is so Problematic
- The Importance of the CIF Administrator
- Other Brightwork CIF Articles
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. AAPO 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 individual 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) the 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 organization 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 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 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 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.
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 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.
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, 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 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.
Just double-click the numbers.
- CFM5: Filter Objects in 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 can not 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 for 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 into 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 are 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 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 just 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 upon 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 to 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.
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.
Other Brightwork CIF Articles
- Change Pointers: CIF has a series of change pointers that are described in this link.
- NonSAP Integration: The BApi Explorer for managing non-SAP integration is listed under the CIF as well at this link.
- 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 at this link.