Moving VC Models to the IPC

So you're thinking about moving to the IPC? Here's a guideline, maybe even the guideline you've been looking for, offering an overview of what the IPC is, what kind of system you need to run it, and how to prepare your VC models to move them into the IPC world. Marek Duda, Oct. 10, 2005

In this article we will give a short summary of what you need to do to feed your IPC with models of configurable materials which were created in your variant-configuration (VC) module of R/3.

By Marek Duda, Sybit GmbH

1- Introducing the IPC

The following chapters will help you to become familiar with the IPC itself.

1.1- What is the function of the IPC?

The IPC is mainly responsible for pricing and configuration tasks. It owns a JSP user interface to show configuration and pricing results in the user's web browser.

1.2- Where is the IPC used?

The IPC, once the pricing and configuration component of CRM, has evolved to a component of the SAP application platform. It is used in most business scenarios within SAP where product configuration and pricing are used (see figure fig.: 1.1 IPC in different business scenarios).

fig.:1.1- IPC in different business scenarios
Figure 1.1

1.3- What is inside the IPC?

The IPC is completely Java based. It uses standard technologies like XML to store valuated configurations. The configurator itself is a deterministic and not a procedural one. To add procedural behavior in your configuration you have to implement user-defined functions.

fig.:1.2- IPC architecture
Figure 1.2

The IPC is a client-server application which communicates using commands. Dependent on the scenario the IPC can be called by RFC or socket commands. For load balancing, a dispatcher can be used. The client application calls the dispatcher requesting an IPC server. After a server was assigned to the client, further commands are submitted from the client to the server directly. In CRM, which is a typical IPC scenario, the IPC is called by RFC commands to initialize a configuration. Once called, the JSP user interface is started in a browser. The JSP user interface itself communicates with the IPC using socket commands to set and get values etc.

Up to version CRM 4.0 the Mobile Sales scenario uses JavaBeans and a Swing user interface to access the IPC functionality directly. In this scenario there is no IPC dispatcher and IPC server involved. From CRM 5.0 on, Mobile Sales will access the IPC using commands and the JSP user interface, similar to the description above.

1.4 - What does the IPC need?

Like many Java programs, the IPC can be deployed on most operating systems which support Java. Features like the option to run it as a service and better support possibilities, means that many users install the IPC on a Windows host. The IPC supports Microsoft SQL Server 2000 on Windows and Oracle 8.1.7. on Unix systems as standalone databases (e.g. Internet Sales R/3 Edition scenario). Other JDBC-compliant databases may be used on a customer project basis.

In case there is no standalone database, like e.g. in a CRM scenario, the IPC fetches its data using the SAP Java Connector (JCo). By the way: introducing the Netweaver technology JCo will get redeemed.

Depending on the scenario, the complexity of your products and the amount of transactions, the hardware requirements for the IPC do vary. Fortunately the IPC has brilliant load balancing features like a dispatcher-server architecture where you can use multiple IPC servers on different hosts. For details regarding hardware requirements of your IPC installation please check

2- Steps to get your VC models working on IPC

Of course, you could start creating new models of your configurable materials in the Java Product Modeling Environment, which is usually shipped with your IPC. But assuming that you already have existing VC models, we will show you some typical steps to make them run on the IPC.

2.1- Packaging your VC models for moving to IPC

All data belonging to a configurable product handled by the IPC is stored within a data structure called a knowledgebase. It contains Bill of Materials (BOMs), dependencies, characteristics, classes, variant tables, documents and so on.

For creating a knowledgebase in the R/3 system, you need a knowledgebase object and a runtime version.

Knowledgebase objects hold one or more profiles which are used to link materials or classes to a corresponding knowledgebase.

Runtime versions, as it is suggested by their name, are used for versioning. They are identified by the corresponding knowledgebase object and an assigned version name, whereas you will have to specify a plant and a BOM application to create them.

If you succeed in running the appropriate transactions and specifying all necessary inputs (CU31 "Create Knowledge-Base Object", CU34 "Create Runtime Version"), congratulations! Your configurable products are ready to get transferred via middleware, Conntrans, Dataloader to the final business scenario where the users can configure them.

If you haven't had success doing so, then please have a closer look at chapter "2.2 What you shouldn't forget making models for the IPC".

fig.:2.1- Creating and transferring Knowledgebases
Figure 2.1

2.2- What you shouldn't forget making models for the IPC

Because of "historical reasons" there are some differences in the way the VC and the IPC treat the product models. Therefore it is necessary in some cases to modify existing VC models in order to make them work in the IPC world.

There are many notes regarding this issue, but a good beginning is to check your VC configuration by taking a detailed look in the document "Comparison of SCE and R/3 Variant Configuration", also known as the "delta list". You can find it with the following link:

It describes many differences between VC and the IPC, and provides hints what to do, to make VC models run in the IPC. Some typical issues to be considered are:

  • The IPC requires normalized variant tables, duplicate entries in variant tables are not allowed.
    This means that in each table cell there has to be exact one value, unlike to VC where multiple values or no values at all are allowed too. It is not allowed to have identical rows in one variant table.
  • Explicit constraints are needed for handling class positions of BOMs in the IPC.
    This means unlike in VC you have to implement a constraint to pass values from a super position to identical characteristics of a sub position which would be done in VC automatically.
  • There can be just one kind of BOM and one plant for a material in a knowledgebase.
    During configuration in IPC, only the BOM explosion for the plant and BOM application which were specified during creation of the runtime version are possible.
  • Characteristic value names are always maintained in the characteristic itself. They can't be overwritten in classes.
    This means, if you have a characteristic "a" with values "a1" and "a2" which you use in a class, lets say class "c", and there you specify additional values like "ac3" or "ac4", the IPC won't be able to display their language dependent description.

2.3- Re-implementing user-defined functions for configuration

Unfortunately, all the special requests which were handled in VC by your user-defined functions are not a part of the knowledgebase used by the IPC. This means, you have to re-implement them in Java.

Some technical details on this: SAP provides with the IPC a Java interface which you have to implement: For each of your user-defined functions you have to create a class with the same name. Classes implementing your user-defined functions must be within the Java package "".

fig.:2.2- Re-implementing user-defined functions


If these classes are within the class path of your IPC then they should be found and used automatically during configuration. For implementing P-Functions (functions just have input and output parameters, P-Functions in contrast are capable of influencing the configuration directly) SAP provides the "scelib" class containing methods to match the functions of the function group CUPR.

2.4- Re-implementing your pricing-userexits

The IPC is shipped with a standard implementation for handling pricing. If you need more functionality then given and you have implemented customer specific requirements and formulas in your R/3, you have to re-implement them in your pricing-userexits in Java. You can specify in the administration tool of IPC which Java classes have to be used for handling pricing, taxes etc.

Again, some technical details: there is already a Java class which you can edit or which you could extend: userexits.PricingUserExits. It already has the according method blocks and the standard pricing implementation.

fig.:2.3- Re-implementing pricing-userexits
Figure 2.3

2.5- Summary

Basically, the transfer of VC models to the IPC environment is a straight forward process.

Of course, there are exceptions where modifications have to be done. But on the other side we can state from our configuration experience that in nearly all cases the given VC models can be used for the IPC.

If you start to model a configurable product in the VC, then you are well advised to consider the delta list beforehand. You will get VC-IPC compatible models from scratch.

In the future the IPC will become more and more a key component of different business scenarios. Therefore it is very important to take care of your configurable products being IPC compatible!

Marek can be reached at; Marek Duda
Sybit GmbH
Sankt-Johannis-Str. 5
78315 Radolfzell, Germany
Tel.: +49 (77 32) 95 08-144
Fax: +49 (77 32) 95 08-111
Sybit - a bit better