Basic Concepts of the Switch Framework 

The fundamental idea behind good solutions to problems is usually quite simple, and the Switch Framework is no exception, with its basic idea following quite simple logic: Previously, the Repository objects of a system were active in every client. With the Switch Framework you can use switches to control which Repository objects are active at runtime. Deactivated Repository objects are not compiled. At runtime, it is as if they did not even exist.

In our example, this means: The Repository objects of the basic component, which are changed in the add-ons, have to be switchable, just like all other parts of the code that are also included in the add-ons, be it additional code or replacement code for the basic component. If it is now possible to switch on either the unchanged basic component or one version each changed by the relevant add-on, you will have exactly what you need: You can develop and maintain the basic component and two different incompatible add-ons in one system. You can set the switches so that only the code of the desired version (basic component without add-on, basic component with add-on 1, or basic component with add-on 2) is compiled and thus available.

With the Switch Framework all SAP industry solutions can be lead back o one system, where they can be developed and maintained. And this is exactly what SAP does. This is a very real example of the usefulness of this framework. All industry solutions are delivered in one system in an inactive state. The customer then switches on one industry solution. Since the inactive Repository objects are not compiled, the performance of the individual industry solutions at runtime is the same as if the switched off Repository objects did not even exist. Therefore, the load is not increased.