Why I No Longer Recommend Using the CIF

What This Article Covers

• Why the CIF is greatly overrated in actual project use.
• The real story behind the CIF.
• Why the CIF is so problematic.
• The current SAP position on the CIF.

Background

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

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. In my opinion, the CIF is the least reliable and most poorly designed middleware product I have worked. It combines a bad user interface with poor 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 be frequently manually cleared. The errors that are produced by the CIF can also be quite inaccurate. SAP consultants that think the CIF is a decent tool, often have never been exposed to “real” middleware.

I am surprised myself how badly CIF performs at companies, because as a person who has worked in SAP integration off and on since 1998 and has connected 5 planning systems to SAP, I know that planning system to ERP adapters are not very difficult to create. So when you are discussing the limitations of really 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 actually beneficial.

Why Is the CIF so Problematic?

One reason is simply quality. The CIF has always been a poorly developed product. I directly question the integration knowledge of the developers of the CIF and suspect they lacked experience in adapter development or were unduly influenced by the product managers that wanted too much put into the interface.

One of the major problems, which should have been caught early on by SAP development, is that SAP made the integration system overly complex. This means that there is a large amount of logic in the CIF that in most cases is 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. This issue is explained in the post.

Since this article I have worked on two more clients, both with continual 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.

The Current SAP Position on the CIF

SAP knows it has a maintenance problem with the CIF, and is proposing to customers that there is a new transaction which can be used to show records that did not go through with better transparency, however, I think this is missing the point. The CIF is so flawed it needs to be replaced with something else. If I were setting up an APO project, there is no way I would include the CIF in the solution.

How to Create a CIF Replacement

So if I would not use the CIF, what would I recommend. An adapter can be written with the following components:

1. Standard SQL for extracting and importing the data to the system that is to be connected to SAP
2. UNIX Awk scripts for transforming the data into the right format for import or extact
3. ABAP coding for extracting or importing the data into SAP

Conclusion

The companies that purchased APO were told this integration harness would be solid, and have been mislead. After years of working with the CIF, I have concluded that it is a disabler for projects, and should no longer be implemented. Companies that are evaluating APO need to choose it because they really think the applications or modules within the system (DP, SNP, PP/DS, etc.) are the best fit for their needs. The argument that APO in integrated to SAP ERP is no longer a valid reason because the CIF is not of sufficient quality to be part of any solution.

For new implementations, no value is added from using the CIF. For existing APO accounts, the decision is more complicated. For companies that find the repetitive CIF issues manageable, it might be better to simply leave the CIF in and deal with it. However, there are a number of companies that need to remove the CIF and custom code a solution. It must be understood that the CIF will consume part of a resource as long as APO is running. It can never be expected to simply run all by itself without long-term hand holding.

Share