This weblog of the series on the Enhancement- and Switch-Framework explains how you switch enhancements and what the point of switching is. You will both understand how useful switching is and how it is realized in the Switch Framework. (You find a list with links to all weblogs of this series at the bottom the SDN Wiki page on the Enhancement Framework)
You may be surprised that up to now I have presented a lot of information about enhancements, but have not told you anything about switching in this weblog series on the Enhancement- and Switch Framework. But there is a good reason for this. Though the two frameworks cooperate closely, enhancing and switching are nevertheless different things. In principle, all enhancements are switchable. But an enhancement can only be switched, if you attach a switch to it. To put it this way: Enhancements are switch-ready. Once you attach a switch to an enhancement, the state of the switch controls the enhancement. Without a switch an enhancement cannot be controlled by the Switch Framework. It is unconditionally compiled with the development unit it enhances. Once you attach a switch to it, you can switch it.
Why to Switch?
But what is switching good for? Imagine, you develop different add-ons of the same application, and in the end, each add-on should run exclusively in one system. With the Enhancement- and Switch-Framework you can develop the different add-ons in the same system using the enhancement technology. You need only to make sure that the code of each add-on is encapsulated by switches. Then you transport the application and all the add-on code to the different systems. Switch on the add-on needed in each system, and that´s it.
In this weblog I will show you in a very simple example how such a scenario works. I just enrich our little sample application from the last weblogs by adding a requirement for switches. You probably remember that we had a Web Dynpro view with a table and we enhanced the table by an additional column and added an detail table plus a button as other enhancements.
The Use Case
Let us now suppose our little enhancement project should be developed in a way that fits the needs of two different users: So the corporate airline IT should adapt it in a way that
Alpha Airlines , a normal airline, can use all enhancements and
the low cost airline Pay Less Airlines can use the additional table and the button, but does not get the additional column.
What has to be done, to achieve this? All we have to do is to assign a switch to the package that holds the table enhancement that is the additional column:
All enhancements are switched by a switch assigned to their package. A switch assigned to a package switches all and only the switchable elements in this package. Because all enhancements are switchable, they are affected by the switch assigned to their package. In the figure, the little switch on the right of the column is just intended to show this relation: The state of the (big) switch assigned to the package controls the state of the elements of the package, but only of those elements that are switchable.
Now that we have our switch at the package we transport all objects to the productive system of both airlines:
Both systems import the same transport. What makes the difference at runtime is the switch state of the package of the table enhancement. So let us have a look at what happens at runtime when we change the switch state. By the way, a switch is always switched off after it has been imported, unless you transport the switch state. In our example the we do not transport the switch state.
Switching an Object
So what do we want? Alpha Airlines needs all enhancements. So we switch on our package. In contrast, Pay Less Airlines does not need the column in the enhancement, so we just leave the switch as it is after the import. So the switch of this package in the production system of the low cost airline is off.
In the system on the left hand side the enhancement is switched on, and the additional column is visible at runtime, while in the productive system of the airline Pay Less, the switch is OFF, so this column is not compiled and not there at runtime. There is no need to worry that a lot of elements that are switched off may slow down the performance of a system. An element that is switched off is not compiled, and so does not have any impact at all at runtime.
Switching Many Objects in Sync
Off course, our first attempt to switch was still simplified. As you have seen you need some other enhancement and appends to populate the table column with some data. And they also have to be switched in in sync.
How is this done? The Switch Framework provides a simple solution to the problem of how to sync the different enhancements and appends we need. It is built in the very structure of this framework.
The units you switch are larger units that technically and semantically belong together, the smaller units just indicate if something is on or off. You know already that Enhancements and also DDIC appends are switched by a switch assigned to their package. So the switch state you see in the tools of the respective objects is just a view of the respective package switch:
Once a package is switched of all switchable objects within this package are switched again.
Looking at the example again, you easily realize that we still want to switch larger units than packages. What use would it be to switch on the Web Dynpro enhancements while the backend enhancements and appends are still switched off? Obviously this we want to avoid this, and the best thing would be if we had not to take care of this manually. Again, with problems like this, you can rely on the Switch Framework to do this job for you.
In order to keep larger units in sync you need a still more comprehensive unit that you can actually switch: The Business Function.
Switches and Business Functions
And this is the way it works: You switch on or off a Business Function and all the packages assigned to this Business Function get switched on or off. This is the way to keep the switch states of a many related objects in sync. So we have different levels of objects (in reality there are even more than I show here, because I try to keep things simple here):
Enhancements inherit the switch state from the switch of the package they belong to.
A simple switch cannot be switched itself. In a way, it is just the technical switch. Its state is determined or remotely controlled by the Business Function the switch belongs to.
It is the Business Function that you can really switch or activate. This is what the hand symbol in the figure is for.
This way of syncing many switches is enforced by the tools of the Switch Framework. You can only switch or activate a Business Function. The state of the (technical) switches is determined by the Business Function they are assigned to:
This figure shows the Business Function, which is activated or switched on. Let us now deactivate it again, and look what the consequence of this is.
Deactivating a Business Function
It happens the way I have just told you: The state of the dependant (technical) switches changes to off, and so all the enhancements and appends are switched off.
What does this mean at runtime?
After you have deactivated or switched off a Business Function, at runtime almost all objects that are switched off behave as if they were not there. Why do I say "almost"? It is because a DDIC object that was once switched on is not affected at all if you switch it off again.
On the one hand, this means, you should be careful with DDIC appends, on the other hand, you understand why most Business Function of SAP can only be switched on and not be deactivated or switched off. It is because of the DDIC appends that cannot be undone. Let me explain this second thought in some more depth: When you deactivate a Business Function you expect the application to be in the same state as before the activation of the Business Function. But once DDIC objects are involved and part of the Business Function the state before the activation of the Business Function cannot be re-established. Why? Because the activation of the DDIC objects cannot be undone. It is due to this situation that the Switch Framework provides an attribute for each Business Function. Using this attribute a developer can determine whether a Business Function is reversible or not. You can only deactivate reversible Business Functions.
Warning: Up to now the Business Functions that are part of the ERP Enhancement Packages (you will learn what these Enhancement Packages are in one of the next weblogs) cannot be deactivated, once they are activated. This means: Be careful when switching a Business Function that is part of an Enhancement Package: You cannot deactivate it after you have switched it on. Still you are free to create your own Business Functions that are reversible.
From a semantic point of view, switching off the Business Function in our example does its job. The DDIC appends do no harm because the relevant enhancements in the program that refer to these appends are switched off and not compiled. It suffices to keep in mind: At runtime all objects that are switched off are not compiled, except for the DDIC objects.
You have now learned the basic facts about the Switch Framework and about how it interacts with the Enhancement Framework:
All enhancements are switchable in principle.
You must assign a switch to the package of the relevant enhancements to make them really switchable.
In general you want to switch larger units as a whole. This is why you can only switch Business Functions with the Switch Framework. The simple (technical) switches are, to put it this way, remotely controlled or dependant on the Business Function. If the Business Function is switched on, all dependant switches are switched on and vice versa.
Now you have acquired all the concepts you need to understand how SAP develops all the different Industry Solutions in one system, and develops all of them on one set of DVDs. In the next weblog how this is realized with the Enhancement- and Switch-Framework in principle, and you will also get to know the big advantages this so-called retrofit of the Industry Solutions into the ERP core means for customers.