Have you already heard about the re-integration of the SAP IS in the ERP core? Do you know that the underlying technology to enable this large project is the Enhancement and Switch Framework? But how does the Enhancement and Switch Framework empower the SAP Industry solutions (ISs)? What are the benefits of this re-integration for the customer? These are the questions I will address and answer in this weblog. After having made your way through the first weblogs of this series (you find a list with links to all weblogs of this series at the bottom the SDN Wiki page on the Enhancement Framework) you have most of the concepts at hand to understand in principle how this so-called retrofit of the Industry Solutions into the ERP core works. Though you will not learn a lot of new complex concepts in this weblog, it still has become longer than I supposed. This is because there a quite some details to understand. The Switch Framework needs some levels to do its job. And in this weblog I explain you the basic structure of this framework.
Some weeks ago I unfortunately published this weblog without any of the figures that should have been included. For some reason I forgot the links and did not notice it. This time all the figures are in. So I hope you have more fun with this weblog now.
Let me start by sketching the situation before the re-integration, the so-called retrofit of the Industry Solutions into the ERP core: The SAP ISs were all developed in different add-on systems. Changes of the ERP core development objects were realized as modifications. Because of these changes of the ERP core the different ISs could not use the normal support packages of ERP, but had to install so-called Conflict Resolution Transports (CRT). In general this meant that the customer had to wait for these CRTs, because they were released later than the respective SPs. The customer of an IS was also dependant on the release strategy of its respective IS, and for some ISs the latest release was ERP 4.0. So the customer could not use the IS in the release of his choice, but was confined to the latest release that was available for his IS.
Since the retrofit of the IS in the ERP core all these things have changed now:
Due to the Enhancement and Switch Framework all ISs are developed in the latest SAP ERP system. So these ISs are available in time with every ERP release. Also the customer can now install the normal support packages of SAP ERP and need not wait for CRTs. This means, the customer can run its IS on the latest release of ERP and install all ERP SPs just as he would do in a pure ERP system without any IS. Of course, there are additional SPs for the ISs.
Where a customer formerly needed a new SAP ERP system and an Industry Solution based on older SAP ERP release he can now make do with one IS system on the latest release. For example, let us suppose the customer wants to run IS Oil & Gas, and he also needs some new features of ERP logistics that are only available in the latest release. Before he would have needed one old system for the IS Oil & Gas plus another system for the latest ERP release. Now he can just use the IS Oil & Gas on the latest ERP release. This means, the customer needs fewer systems in the landscape and thereby lowers his TCO.
Another advantage is the re-use of Business Functions of other Industry Solutions to some degree. For instance, you can use the Retail Business Function in the Industry Solution Gas and Oil. So to some extent IS specific functionality can be used by different ISs.
Despite of all these great advantages of the IS retrofit, this strategy still has some inherent limitations:
With the knowledge of the Switch and Enhancement Framework you have gained so far, you can probably guess what this re-integration of the ISs into the ERP core looks like. In a way, the code of all the different ISs is in one system, but only the code of the IS that is needed is switched on.
In a simplified case of just two ISs the situation looks like this:
The figure shows a system that contains the IS Oil & Gas and the IS Retail. If Oil & Gas is activated then the code specific to this IS is compiled and the code of IS Retail is not available at runtime. On the other hand, if we switch on IS Retail, its code is compiled. Just note that only one IS can be activated as I have told you. You cannot toggle between the different IS:
Based on your knowledge of the Switch- and Enhancement Framework you probably suspect that this figure here is a crude simplification. And you are right. I have simplified the whole thing to make the basic facts understood. Using what you have learned about switching in the last weblog I will show you some more layers to make out picture more realistic.
Of course, you cannot get the whole IS Oil & Gas add-on in one clump of code. What you have instead are additions and changes spread all over the application. An additional field in a structure, a broader interface, another select, an additional check, and above all a lot of changes in the user interface. So our IS looks more like this:
In addition to the enhancements, there are a lot of other types of objects that are switchable:
There is one group of objects that can be switched package wise that is by assigning the switch to the package:
Other objects can be switched by direct assignment of a switch to them:
So SAP adapts the classic Dynpro of an ERP application by assigning the respective UI elements to switches. This way an IS can have other labels, more fields and more buttons, for example, but, of course can also have less screen elements.
Let me just prevent some common misunderstanding. You may ask yourself what happens to classes, reports, and function modules that are in a package, which is assigned to a switch. What happens when the switch is switched off? Is then the whole class switched? No. This is definitely not the case. And there is a good reason why classes, reports, and function modules are not affected at all by the switch state if their package is assigned to a switch:
Only switchable objects can be controlled by switches. This may sound like a tautology, but it holds some useful information. Not all objects are switchable. Let me put it this way: Many objects depending on their type just do not care if their package is switched. For example, classes, function modules, and reports are not switchable. I have already compared a switch to a remote control. Of course, you can only control a TV set by means of a remote control, if the TV is built to respond to the remote control. The same is true in an analogous way for objects and switches. To really switch a particular object it takes at least two things:
Again the switches are organized by Business Functions. So the picture looks like this:
As you have learned in the last weblog, the activation state of the Business Function determines or remotely controls the state of the dependant switches and these switches, in turn, control whether the relevant elements are available at runtime. In general, each Business Function reflects a semantically coherent unit, which realizes some business processes. By the way, the Business Functions names in the figure are mere examples. They do not name any real Business Functions.
In general, an Industry Solution comprises of many Business Functions, and there is the need for another container to cover and control the different Business Functions of an Industry Solution. The container that holds all the functionality of the Business Functions belonging to one IS is the Business Function Set. So the improved picture looks like this:
So we have four levels:
These different levels are not made to confuse you, as somebody might suspect, but they all serve one well defined aim. They organize the huge bunch of objects to be switched, and the make sure that objects that semantically belong together are switched together automatically. We have the Business Functions and the Business Function Sets on the business level and the switches and the switchable objects on the technical level. Moreover, we have not only the additions and changes of one IS in the system, but those of all SAP ISs.
Due to the layered structure of the framework you only need to care about the business level when you choose and activate an IS in the system. Compare it to somebody first choosing a Portuguese restaurant and than ordering a five course menu there. The gourmet cares about the restaurant and the boeuf a la portugaise, but not about the different ingredients of a particular course. He does not want to be bothered by all these things that must happen behind the scene so that he can get the meal he orders. (By the way, there are more different dishes in a restaurant than there are Business Functions in an Industry solution, but every analogy has some limit, and so has this one.)
But let us now translate the analogy:
1. Because there are many different Industry Solutions in a system, you first have to make up your mind which IS you need. Remember, you can activate only one IS in a system. So you activate or switch on the Industry Solution you want:
2. Next you decide which Business Function you want to activate. You are guided by the tools in a way that you can only switch on the relevant subset of the Business Functions in the system:
The transaction to activate or switch on Business Function Sets and Business Functions is the SFW5. Let us have a look at what the activities just described look like in this tool:
After activating all the elements belonging to the relevant Business Functions are switched on in sync. So you see how the Switch Framework hides a lot of complexity from you and how it enables you to switch on a strictly semantic or business level.
Now it is time to tackle a topic I have mentioned at the beginning of the weblog, but not really addressed so far. I have told you there that thanks to the retrofit of the ISs into the ERP core, you can to some extent reuse Business Functions from one IS while you have selected another IS. In fact, this is no violation of the rule that you can only switch on one IS. This fact stays true, and it is a basic fact about the ISs.
But how then is this reuse of Business Functions possible? It is because of a fact I have not mentioned so far: A Business Function can be assigned to exactly one or to many Business Function Sets, and there are Business Functions that can be used irrespective of any IS. These are the former Enterprise Add-ons. The next figure shows in which way Business Functions can be assigned to ISs:
In the grey row you see the Business Function Oil & Gas 1, which belongs to the Industry Solution Oil & Gas, and the BF Retail 1, which belongs to the Industry Solution, you guess it, yes it is the IS Retail. They uniquely belong to one IS. The Business Function General Retail can be switched on in both the IS Oil & Gas and IS Retail. Quite in contrast, the Business Function Generic Trade is available for all IS and also for the pure ERP, that is a system in which you have not activated any Industry Solution.
In general, you have Industry Business Functions that can be used in one particular industry and Enterprise Business Functions that are compatible with all IS plus the pure ERP without any Industry Solution activated. So the EnterpriseBusiness Functions are, in a way, like the classic Enterprise Extensions. What I have shown in the middle row, is a possibility that is not realized so often.
For you, it is only important to understand how a Business Function can be reused by several ISs or even be available in the pure ERP in which no IS is activated. As a user of the transaction SFW5, the Switch Framework transaction to change the Business Function status, you need not care about all this. The tool does it all for you. After selecting an IS you see only the Business Functions that are available for you. So there is no risk to switch on Business Functions not meant for your IS.
In the figure showing the Switch Framework transaction SFW5 you see two nodes named Enterprise Business Functions and Enterprise Extensions. For the time being, these nodes contain different types of Business Functions. But I will not explain this in any detail, because this distinction will disappear in the future. What does not change is the simple fact that the tool shows you all and only the Business Functions you can choose depending on the IS you have activated.
Before resuming the basic facts about IS and about how they are technically realized I will show you a figure of the entities on the different levels:
At the top there is the Business Function Set that corresponds to an Industry Solution. A Business Function Set comprises of many Business Functions. Because a Business Function can be assigned to different Business Function Sets the relation between them is n to m. In the same way, a Business Function can be assigned to many switches, and a switch can be assigned to many Business Functions. This reflects the fact different Business Functions may need to switch the same object. The switches control some objects (like enhancements) package-wise and other objects like screen elements, menu entries, and IMG nodes by direct assignment. A switch can control many objects and packages. On the other hand, an object or a package is uniquely assigned to a switch. And this uniqueness has a clear reason: It is the switch of an object that indicates if it is switched on or off. So there can be only one switch for an object.
So what have we learned about the retrofit of the SAP Industry Solutions? Let me first recapitulate the benefits. There are two major advantages of this strategy:
How is this retrofit technically realized? All changes and additions, all additional code, and all UI changes are encapsulated by switches. All enhancements of the Enhancement Framework and many other object types are switchable. Some objects like the enhancements are switchable by assignment of the switch to the package, other objects like Dynpro screen elements have a switch directly assigned to them. In fact, the switches themselves are only the technical units. They are controlled by Business Functions. It is these units that the user switches in the switch transaction SFW5. And there is still another unit to manage the Business Functions that belong to one IS: This large bracket is the Business Function Set.
It is important to understand the motivation for the different layers. So let me address this matter once again. Both from a technical and a user perspective it is important to switch larger units and not the different technical switches. Obviously there is the need to keep the switch states of a large numbers of switchable objects in sync: A particular new functionality that comes with an IS is probably spread over many changes and additions. Some way or other it must be assured that either all or none of these changes and additions are active. Most typically are situations in which it would be no use to have a new additional field in a structure, if it is not filled from the database like its sibling fields, if the interface of the relevant method it belongs to is not suitably adapted, and if the new field is not shown in the UI. And this is only a minute example. In the real world the functionality of an IS is to a large degree interrelated. So from a technical perspective it must be guaranteed that either all switches of one larger unit are on or off.
The other reason is that the user wants to switch large units that make a semantic difference. An administrator does not care about a switchable enhancement of a class method. This simply is a level he does not want to be concerned with. There is the need for levels that answer to business needs. This is what the Business Functions and Business Function Sets are fore from a business perspective.
So this is why Switch Framework has some built-in mechanism to keep a lot of switch states in sync, to make sure that the users switch on a business level and need not care about implementation details. First, there is the simple fact that many objects are switched package wise. Then, you have an additional level on which the actual switching is done: The Business Function. As you can already tell by its name, a Business Function covers a semantic unit, a unit that contains some interrelated business logic.
An Industry Solution comprises of many Business Functions. Therefore the technical counterpart of an IS is the Business Function Set. You can activate or switch on only one IS in a system. This is reflected by the way the relevant Switch transaction, the SFW5 organizes the switching: First, you activate the IS you need. After this is done you see exactly the Business Functions belonging to this IS and those compatible with it. Among these Business Functions you can activate the ones you are interested in.