Implementing variant functions in Java for IPC 5.0 (AP 7.00)

In this article we will give a short summary of the changes and what you need to do to implement your variant function with this new technology

By Marek Duda, Sybit GmbH

Implementing variant functions in Java for IPC 5.0 (AP 7.00)

First of all I have to highlight that SAP contributed to the CWG a presentation and created a really comprehensive note which covers most questions regarding this issue:

Therefore please take a look at note 870201 “Implementing variant functions in Java” if you want to start right away. There you will find information about the prerequisites you need, helpful recommendations and so on.

Unlike IPC 4.0 where a JDK 1.3.1 but not 1.4 (in former service packs) was required for implementing variant functions, you need for the IPC 5.0 a JDK 1.4 compatible compiler and a IDE (Integrated Development Environment), therefore a Sun J2SE 1.4.x JDK and Eclipse 3.x are suggested.
The API which is used for implementing Java variant functions, both functions and pfunctions, is the same as in IPC 4.0. To be able to use this API you have to download it using transaction cfg_user_exit_dev and to include it to the libraries of your IDE.

Typical steps after starting up your IDE are downloading the packages of the variant function API and including them to the project libraries of your IDE. Now you can start the actual work and implement variant functions. Ideally the compiled variant functions should be packed with their source code and a manifest in a jar-file which can be uploaded to your CRM using again the transaction cfg_user_exit_dev. This makes it easier to search errors, because another developer or someone from the support team can just download the variant functions, take a look at the code or start debugging to understand what’s going on.

If the variant functions need to be extended or exchanged, they can be downloaded from the CRM and included in the developer’s IDE. Of course, this isn’t necessary if the developer has the latest working versions of the variant functions, but this would be ensured by using the mentioned procedure.
When the jar-file with the changes is uploaded, the old one is overwritten. To get rid of your variant functions in your CRM, you have to upload an empty jar-file.

fig.: 1 Typical steps during development of variant functions
Figure 1

All these steps are described in detail in note 870201, so I will talk about some thoughts I had about the new technology, its advantages and the questions regarding the handling of variant function implementations in customer projects, which raised during our CWG 2006 european conference.

Regarding the implementation of the variant functions, we learned that the API hasn’t changed in the new release and therefore the same API is used in the IPC 5.0 as it was before. Merely we cannot cache data in the variables of our variant functions because of the VMC (Virtual Machine Container) concept which could be described as follows:
If a user starts a configuration the VMC assignes a VM to handle his request, during the session the VM serving the user can be exchanged with another. Each VM would have its own instance of the variant function and the previously saved data would not be available. Therefore, do not cache data in static, global variables of variant functions or in singleton data containers.

fig.: 2 Handling of user requests during a configuration session by different virtual machines
Figure 2

Most of the time during the SAP presentation on the CWG 2006 european conference was spent with a discussion about handling of the variant functions in customer projects.
What should be done if multiple developers implement variant functions simultaneously?
The easiest would be to split up the variant functions among the developers. Each developer would create his own jar file, for example function_developer1.jar. Additionally, each developer would use his own ABAP package and a corresponding transport. This would enable the developers to work more independent. The problem is that it isn’t obvious which variant functions are hold in which ABAP package.

There are many advantages of this new mechanism. You won’t delete your variant functions when updating your IPC for example, which often happened in prior releases. Moreover, the used mechanism matches very well the new IPC architecture when it comes up to load balancing etc.

A variant function developer uploads his implementation on a development system. Multiple virtual machines can use this implementation and it can be transfererred via a transport to a productive system. When a user configures a product he is served by one of many possible virtual machines. Load balancing is now done by dialog instances, which have their own VMCs but use the same data as the main instance of a system. It is no longer necessary to copy the variant functions and to maintain the classpath settings etc. on each IPC installation which was common in IPC 4.0 load balanced scenarios with multiple IPC Servers.

fig.: 3 Distribution of variant functions in a VMC based scenario
Figure 3

Your CRM could be the ideal backup place for your custom development, therefore, it is adequate that the variant functions are now stored inside the CRM system, using transaction cfg_user_exit_dev.
Unfortunately, due to the way of transaction cfg_user_exit_dev works, there are some risks doing that. Since a variant function can exist just in one version within IPC 5.0, testing new releases of a variant function always means overwriting the old ones. If a variant function would exist in multiple ABAP packages then you wouldn’t know which one is used. There is no mechanism for versioning available, which would allow to upload multiple versions of a variant function and control which one to choose.
Therefore, an additional source versioning system is recommended when multiple developers work over a longer period.

As a result, variant functions became as well as the IPC 5.0 itself more integrated into the backend system. The storing/uploading is quite comfortable for the productive mode of a system, but similar to the IPC itself it is more complex for developers during the development phase of the project.

Unfortunately, it is no longer possible for a developer, as it was in IPC 4.0 releases, to have a small, local IPC installation which could run against a CRM system. Usually, the CRM was maintained to delegate all IPC requests of the developer to his own IPC and he was able to test his code without influencing the other CRM operations.

fig.: 4 4 comparison of development system landscape in CRM 4.0 and CRM 5.0 scenarios
Figure 4

If a developer wants to have a simple test environment for his variant functions without the need of testing within a sales scenario, he seems better served having a local IPC 4.0 for this task. He doesn’t have the possibility to check his variant function in a integrated scenario and he doesn’t have all the features of the IPC 5.0. But as the API hasn’t changed, all tests regarding the pure product configuration are applicable.

Marek can be reached at; Marek Duda
Sybit GmbH
Sankt-Johannis-Str. 5
78315 Radolfzell, Germany
Tel.: +49 (77 32) 95 08-145
Fax: +49 (77 32) 95 08-111
mailto:marek.duda@sybit.de
http://www.sybit.de