Introduction to SAP APO CIF

ByPrimary Researcher

Executive Summary

  • The CIF or core interface moves master data and transactional data between APO and ECC.
  • The CIF is a high overhead item with queues and error management.
  • The CIF allows the creation of integration models that can be saved as CIF variants that can save CIF settings.

Introduction

In this article, you’ll get a high-level overview of the entire SAP APO CIF.

SAP SCM is basically designed to perform planning and develop recommendations for executing transactions such as creating purchase orders, stock transport orders, and sales orders; it doesn’t execute these transactions. So, SAP SCM needs to send recommendations to the execution system, most often SAP ERP, and receive status information and master data from SAP ERP. Although other integration methods have become more prominent in the newer releases of SAP SCM applications, the main interface system between SAP ERP and SAP SCM is the Core Interface (CIF). CIF connects SAP ERP to SAP SCM and is delivered as an SAP ERP plug-in. It allows a connection to be made between multiple SAP ERP systems and SAP SCM systems, at least in principle. However, in practice, the most common connection is between one SAP ERP system and one SAP SCM system. CIF is within the category of software called middleware. If you’re not familiar with it, it allows two software applications to exchange data regardless of the system on which they are being run. In this way, CIF has more in common with SAP NetWeaver Process Integration (SAP NetWeaver PI) (formerly known as SAP NetWeaver XI) than with any of the other SAP SCM applications. But we’ll discuss CIF in this book because it focuses specifically on SAP ERP to SAP SCM integration.

We explained previously why the SAP Cloud Platform is specifically designed to perform both cloud washing and HANA washing in previous articles. But this is only one of the uses of the SAP Cloud Platform to SAP. However, something else that is misleading about the HANA Cloud Platform is that it is not a PaaS, nor is it a platform, as SAP frequently claims. You will learn how SAP poses as being PaaS while being just a data center. You will also learn how SAP locks in customers with both its cloud and its ABAP code.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

The Technology of CIF

Behind CIF CIF is a combination of remote function calls (RFCs) with a user interface that allows for their setup and configuration. The user interface also allows the setup and running of integration models, which are selections of data to be moved between the systems. CIF also has several tools for queue and error management.

While middleware often refers to software that can connect multiple software applications, CIF is a highly specialized solution that, as we mentioned, focuses on SAP ERP to SAP SCM integration. SAP SCM can be used without SAP ERP, but it’s extremely uncommon. One of the main advantages of this for SAP ERP clients is that much of the data required to use SAP SCM is already set up in any live system of SAP that has SD and MM configured. CIF has a structured way to bring this master data and transaction data over to SAP SCM and bring planning results back to SAP ERP. However, don’t think that it’s prepackaged because getting CIF to work, or even monitoring it, is a lot of work. But it does offer some important functionality that makes it worth the effort.

Basic Functionality and Concepts of CIF

CIF transfers both master data and transactional data back and forth between SAP ERP and SAP SCM. A few examples of standard data types for master and transaction data are shown in Table 9.1.

From just this small sampling, you can probably see that generally speaking, master data tends to flow from SAP ERP to SAP SCM, while transactional data tends to flow from SAP SCM to SAP ERP (Figure 9.1). SAP SCM has more simplified master data than SAP ERP, which is typical for planning systems versus execution systems. SAP SCM has more simplified master data than SAP ERP, which is typical for planning systems versus execution systems.

Other definable characteristics also apply to the data that is exchanged. Comparatively, the data that flows from SAP ERP to SAP SCM is:

  • ››More numerous because many more types of data are necessary to populate SAP SCM than data sent from SAP SCM to SAP ERP.
  • ››Less aggregated because planning systems such as SAP SCM are more aggregated than transactional systems such as SAP ERP.
  • ››Greater in volume because much more data in terms of records flows into SAP SCM than back to SAP ERP.

This is true of all planning systems versus execution systems. Because of these factors, in addition to the master data going from SAP ERP to SAP SCM, the complexity tends to be on the SAP ERP to SAP SCM side of the interface. There are CIF configuration transactions in both SAP ERP and SAP SCM, so it’s no surprise that most configuration is performed on the SAP ERP side. Master Data As we mentioned, master data flows from SAP ERP to SAP SCM, while transactional data flows in both directions. In addition to master data, which originates in SAP ERP, there is master data maintained in SAP SCM with no counterpart in SAP ERP. This data must be set up manually within SAP SCM. This includes but isn’t limited to the following:

  • ››Many fields on the product location master
  • ››SAP SCM specific resources. So, the master data in SAP ERP should be viewed as a “starter kit” for SAP SCM. CIFing over all of the master data available from SAP ERP is only the beginning.

As for the master data that comes across to SAP SCM, many terminology changes can be confusing. Table 9.2 shows a few examples of what objects are called in SAP ERP and what they become in SAP SCM.

Making the two systems work together properly takes a fine level of detail because there are numerous examples of how SAP ERP does things differently than SAP SCM.

Simple things like differences in numbering systems can be confusing; for example, SAP ERP uses 4 digits, and SAP SCM uses those same four digits preceded by a number of zeros. So a vendor master number in SAP ERP that is 2222 is 0000002222 in SAP SCM. Adding leading zeros is standard in CIF for some reason.

Other areas related to your SAP SCM master data are data volumes and data sequences.

Master Data Volume and Sequence

While transaction data volumes stay relatively stable, master data volumes work differently. When you first bring up SAP SCM, there’s an initial transfer of master data into SAP SCM to populate the model, and then subsequent transfers are used to modify the existing master data. The changes are often small because a company doesn’t frequently add large numbers of new products or new locations to its supply chain network.

Setting up the systems for transferring net changes from master data is performed by setting up change pointers. Transferring just the net change greatly cuts down on volumes. Change pointers are activated in SAP ERP, and SAP has a documented list of objects that allow change pointers.

Master Data Sequence Master data has an organization and a sequence in which it’s loaded because much of the master data depends on other master data being in place first. SAP recommends organizing master data in the order listed here. This list is useful for implementation; however, it’s also useful for simply understanding the different categories of master data:

  • ››ATP Customizing and product allocation customizing
  • ››Plants
  • ››Characteristics and classes
  • ››Material masters, and characteristics and classifications
  • ››MRP area
  • ››Planning product
  • ››Availability check
  • ››Product allocation
  • ››Customers and suppliers
  • ››Work centers
  • ››Production process models (PPMs)
  • ››Scheduling agreement, and contract and purchasing info records

Transactional Data

The following types of transactional data are also commonly transferred between SAP ERP and SAP SCM:

  • ››Purchase orders
  • ››Purchase requisitions
  • ››Sales orders
  • ››Planned orders
  • ››Planned independent requirements
  • ››Reservations
  • ›Stock

Essentially, the state of the supply chain (its on-hand balances, requirements, etc.) is transferred to SAP SCM from SAP ERP. SAP SCM then takes this snapshot and performs processing and communicates planned orders back to SAP ERP. But SAP SCM can’t actually change the supply chain’s real state; it can only make recommendations for changes. However, SAP ERP may or may not execute depending on many factors. For instance, SAP SCM may place a purchase order that can’t be fulfilled by the suppliers. And although SAP SCM is modeling reality, it’s still not the actual reality, so there will always be differences between the plan and the actual transactions that result from it. The supply chain state communicated to SAP SCM, followed by recommendations flowing from SAP SCM to SAP ERP, is the natural arrangement between the execution and planning systems.

Integration Models

Models are a method of selecting different sets of master data and transaction data segmented for export. This is where the data objects that are to be selected for transfer are defined. Integration models are created and then activated. They can be as small as the master data necessary to plan for a single product location, and different integration models can be set up for many different purposes. Integration models are subsets of the overall data available (Figure 9.2).

An integration model includes a subsection of the SAP SCM planned product location grouping and, of course, all of the master and transactional data to support it. Not all product-location combinations are planned; however, only critical, long lead time, supply constrained, or expensive products need to be planned (Figure 9.3).

The Create Integration Model transaction provides an appreciation for how many different types of data can be brought across with CIF. And as you can see in Figure 9.3, PPMs don’t exist in SAP ERP; however, they are included in CIF because they are created in SAP SCM from the combinations of routing, work centers, and bills of material in SAP ERP. The product locations that are to be included in SAP SCM planning are coded in the MRP Type field on the MRP 1 tab of the material master.

Tiny integration models are beneficial for testing because they can isolate specific data. The best method we know for CIF data testing is to start with small models and then increase them in size (fixing the error messages you receive along the way) until you build up to larger models with more data.

An important feature of integration models is CIF variants, which are instrumental in maintaining integration models.

CIF Variants

In CIF, variants are integration models that are saved and can be reopened and continually rerun. After using CIF for some time, we’ve concluded that variants should be created and saved for each integration model. The saved variants have to do with the options selected on the integration model selection screen. They won’t affect the combination of product location or the objects to be brought over. The integration model controls the data selections, but the variants control how this data will be brought. A variant can be changed over and over, which provides the necessary flexibility to the integration model and being a great time saver.

If variants aren’t saved, it can be difficult to bring up integration models after they are created because CIF lacks a transaction for integration model modification at the time of this writing. So if you want to change or copy a model (which is typical), you need to create a variant of the model.

Now let’s shift gears a bit and talk about models as a generalized concept in SAP SCM, not CIF integration models.

Models in SAP SCM

The generalized models in SAP SCM are particularly important for supply chain planning, although they are also used in execution systems. While SAP ERP represents one reality, SAP SCM is designed to perform scenario testing. The “virtual” nature of planning systems means that they can test and retest different planning strategies. Nothing is executed until the planned orders are exported to SAP ERP. SAP SCM has one “live” or active model and several simulation models, which are never exported to SAP ERP. If simulated results are tested and considered beneficial, the configuration changes are migrated to the active model in SAP SCM. This concept isn’t unique to SAP SCM because SAP ERP also has versions.

Models and Versions

This design allows SAP SCM to keep many different models in the same instance of SAP SCM. When CIF brings data into SAP SCM, it always brings it into the active model, identified as model 000, along with the active version, which is also given the number 000. Also, multiple versions can be created for a model, although only the combination of model 000 and version 000 are active. The following rules apply for the active version and active model: ››The active model can be copied over into other models. ››Simulation models can be created so that different scenarios can be tested. The results can be compared with the active model to see if there are improvements in key performance indicators. This is because inherent flexibility is built-in to SAP SCM for keeping different versions and models. This serves to enhance planning and provides the ability to perform testing and run scenarios.

CIF Tools

CIF has a variety of queue management and error management capabilities. CIF’s queue management is similar in principle to the queue on a printer. As with a printer queue, if earlier jobs or queues don’t complete successfully, they tie up the jobs that follow them. So, CIF errors are supposed to lead you to make adjustments to how you’re bringing the data over to fit the receiving system needs. CIF errors actually say more about the ability of the objects to be used after they get into SAP SCM than about whether CIF intends to bring over the objects. You can really only find out by activating the integration model. When the queue between SAP ERP and SAP SCM is clogged, CIF provides the functionality to remove queues that failed to go through (Figure 9.4).

CIF has both inbound and outbound queue monitoring transactions. The ability to delete queues using this transaction is essential because, just as with a printer queue, jobs get stuck and need to be cleared out before other jobs can be processed. This monitoring feature is important during testing because many errors are typically created. These errors often create a lot of effort for those troubleshooting the system. And because CIF isn’t particularly intuitive or transparent, time and project resources must be allocated seriously to this work. Configuring and testing CIF shouldn’t be an afterthought for your project because the vast majority of errors come during testing the system before go-live. Additionally, after the testing is complete, the queues must still be monitored to find errors and to ensure that the two systems are sending data to each other properly. SAP has a full list of CIF areas to check daily and weekly after SAP SCM is live.

CIF Versus BAPIs and Custom Integration Code

It’s important to understand that CIF is an infrastructure component and not a functionality component. Although no user will interact with CIF, they’ll quickly notice a problem if CIF is in error. CIF’s primary benefit is that it can kick off pre-built adapters that shuttle data between the two systems. Almost every SAP SCM implementation also implements CIF; however, CIF doesn’t necessarily cover every integration requirement between SAP ERP and SAP SCM. For some requirements, SAP has developed integration BAPIs (Business Application Programming Interfaces). This is a non-CIF interface that connects the systems for specific data needs. SAP also has BAPIs that connect SAP SCM to non-SAP ERP systems such as SAP NetWeaver BW. To bridge the gap between what is offered by SAP and what is required for the project, you may have to do some custom coding. Project managers shouldn’t assume that the combination of CIF and BAPIs will meet all their implementation needs. Next, we’ll discuss how the information flow is managed by CIF, and we’ll bring up the topic of the CIF queue.

Queues

With CIF, you have your choice of queue type. You can use either inbound or outbound queues. There are advantages and disadvantages to each. Inbound queues can handle a much larger data volume than outbound queues. With inbound queues, the receiving system controls the data transfer. However, outbound queues are often the preference for lower volume interfaces. The transfer between the two (inbound versus outbound) occurs in the CIF (see Figure 9.5).

Error Management

Error management is critical. The first reason is that this is one of the best ways to isolate the errors that invariably come up when breaking in new data transfers. A second reason for breaking up larger data sets into multiple integration models is to better control the volume flowing between the two systems. A mammoth number of errors can occur when attempting to integrate systems because a series of master data objects must come across to SAP SCM correctly. If even a few are missing or aren’t consistent with the model in SAP SCM, errors will result.

CIF Error Management Components

CIF has the following main error checking components (Table 9.3).

Not all of these monitoring tools are created equal. It may be a matter of taste, but many users find that the qRFC monitors and application logs (where CIF status can be evaluated) are more effective than the SAP SCM Queue Manager or the CIF Cockpit. In fact, some users don’t use these second tools at all, even though they are strongly showcased as important CIF tools in other sources.

Errors in Error

We found that CIF errors aren’t as reliable as we had originally thought in our own testing. Data sometimes comes across without actual incident, but a CIF error points to a nonexistent problem. Because we’ve encountered this issue many times, we found it useful to document the examples so they can be identified the next time we encountered these errors. One such error related to storage locations occurred after we received errors from transferring storage locations from SAP ERP to SAP SCM. But we checked to find that the storage locations had been created correctly in SAP ERP. In subsequent interface runs, we gave this particular error much less consideration.

You should now understand how the systems transfer data between one another, so let’s move on to discuss the broader integration requirements.

Complete Integration

SAP ERP and CIF must not only be integrated into that they send data between one another, but they must also be synchronized so that when the data arrives from the other system, it makes sense. So, it’s necessary, for instance, to synchronize the calendars used between the systems. You can see how to synchronize calendars in Figures 9.6 and 9.7 using the Transfer Global Settings options.

In this transaction, we are transferring the Factory Calendar settings from SAP ERP to SAP SCM. Both systems must plan off of the same calendar. When this calendar is changed for any reason in SAP ERP, transferring global settings must be repeated.

Real Time CIF

Real-Time CIF? While referred to as a “real-time system,” this description isn’t as useful as it originally appears.

This phrasing can make executives or business users think that CIF runs in real time continuously. Although this sounds good, very few interfaces between the execution and planning systems must be real time. Also, explaining to business users that, in most cases, real-time interfaces are counterproductive is an important part of many planning projects. In reality, as with most execution to planning system interfaces, most of the transfers occur in batch. One of the exceptions to this is the availability checks, which are sent to the GATP application.

Go to top

Conclusion

CIF is a complicated middleware solution that takes a good amount of effort to master. But any SAP SCM implementation will want to take advantage of its prebuilt adapters to speed the implementation. However, there is still a lot of work involved in getting SAP ERP and SAP SCM to interoperate. In terms of managing a CIF project, you can find consultants who mainly specialize in CIF, so it’s a good idea to bring in one of these CIF specialists in the initial stages of your implementation. Then you won’t necessarily need them after CIF has been brought up and thoroughly tested. But mastering CIF will really come down to experience and trial and error with or without a specialist. In the next chapter, we’ll look at the Service Parts Planning (SPP) packages.