Article

Industry Solutions Are Now Integrated into the SAP ERP Core: How the Switch and Enhancement Framework Makes It Possible

by Thomas Weiss | SAPinsider

October 1, 2008

Get an inside look at how the Switch and Enhancement Framework enables the integration of SAP industry solutions into the core ERP system.

Companies seeking system adaptability — often a crucial competitive differentiator — profit from SAP's Switch and Enhancement Framework even if they do not use it in their own development. In my last Under Development column,1 I delved into the exciting technology of the Enhancement Framework, and explained how it empowers customers who adapt SAP objects in their own development projects and why enhancements have a great advantage over classic modification technology. In this column, I will focus on the Switch Framework and how it empowers the integration of SAP industry solutions (ISs) into the core ERP system.2

With the release of SAP ERP 6.0, all ISs are now developed in the latest ERP system and delivered on one set of DVDs. This integration results in several benefits for customers:

You can now install the IS you like based on the latest SAP ERP release — you need not wait for conflict resolution transports (CRTs).3 This means that you can run your IS on the latest ERP release
and install all SAP ERP support packages just as you would in a pure ERP system (without any IS).4

You can use the latest SAP ERP technology in your IS — some new logistics features in the IS Oil and Gas, for example — whereas before you needed two systems: one for the IS and another system running the latest version of SAP ERP.

To some extent, you can reuse functionality of one IS in another IS. For example, you can use some retail functionality in the IS Oil and Gas.

For any SAP customer upgrading to SAP ERP 6.0, already using the new release, or planning an upgrade, it's important to understand what the Switch Framework is, how it works, and how it enables these benefits.

Due to the power of the Switch and Enhancement Framework, all SAP industry solutions are, with
the release of SAP ERP 6.0, developed and delivered in the same system. This brings important benefits for customers.

Switching: An Overview

A switch controls the visibility of development objects at runtime. Using switchable development objects, you can develop different add-on functionality for one application in the same system. You can then transport the application — plus all the code and objects for the different add-ons — to different
systems and switch on just the add-on you want.

In a nutshell, this is the way the integration of SAP industry solutions into the SAP ERP core system works. Switches encapsulate all the additional functionality and changes that are required by the different ISs — everything that is added to or that substitutes part of the core objects. It is only when you switch on an IS that the additional functionality becomes active.

The Switch Framework: Key Concepts and Questions

In this article, you will learn the answers to these important concepts:

What is the Switch Framework? How does it work?

What does it mean to switch a development object?

How do you switch objects?

Why and how would you synchronize the switch states of many objects?

What is the relationship between the Switch Framework and the Enhancement Framework?

Business Functions

Business functions ensure that you can switch
objects on a semantic level and that you need
not worry about multiple technical switches. A business function contains many switches and is the
unit you can activate. Once you activate a business function, all dependent switches are also
activated. All business functions belonging to
one industry solution are bundled in a business
function set.

Switches and Enhancements

With this basic understanding of switches and business functions, we can now investigate some key
questions. How do enhancements relate to the Switch Framework? Are all enhancements switchable? If so, how do you switch them? Why would you do this? And what would be the result?

In simple terms, enhancements are packed in their own "boxes." At runtime, they are processed in the appropriate position — that is, at the position where they enhance the original code. But what happens to the code within this enhancement box once it's
activated in a system? Is it always processed? Or could you decide whether it should be processed or not, thereby allowing you to develop and store
different flavors of an application in one system?
This is precisely what the Switch Framework is for.

Suppose you want to enhance a table control in a Web Dynpro ABAP view so that you can transport the application in one system — where it runs with an additional column — into another system where the UI table does not need the additional column (see the "Important Note" sidebar).

Important Note: One Enhancement Necessitates Others

This article takes a simplified look at enhancements and ISs. In practice, however, one enhancement nearly always necessitates other enhancements.

For example, if you attach an enhancement that adds a column for a table control, you'll still need some other entities to make that column display data (and this is surely what you want). Accordingly, you will need an additional attribute in the Web Dynpro context that stores the new data to be shown. You will also need enhancements in the method that gets the data from the application layer, in the method that retrieves the data from the database, in the relevant interfaces, and in the dictionary and database objects (note that these two object types are still enhanced using the classic append technology).

It is relatively easy to understand what a switch does from a technical perspective: All enhancements are designed to be switch ready. Developers just need to attach a switch to an enhancement and wire up the switch in the proper way. If an enhancement is not switched on, then it is not compiled; at runtime, the program will behave as if the enhancement was not there. This way, objects that are not switched on won't slow down an application in any way (see
sidebar).

Let's now consider a detailed example of how
this works. Figure 1 shows how to switch enhancements by unit — that is, in a way that switches
meaningful semantic units. In this figure, you should note that:

The Web Dynpro component and the application logic are each located within
different packages.

You switch enhancements (and appends) by attaching a switch to the package.

The small switches shown at the enhancements just reflect the switch state of the switch attached to the package.

A business function can be comprised of many different switches; the state of the business function (whether it is switched on or not) determines the switch state of
these dependent switches.

The large horizontal traffic light with the hand icon reflects whether the business function is switched on or off.

Figure 1

Switching enhancements within a business function

Developers want to ensure that all enhancements and appends within each package are switched in sync — and that both packages are either switched on or off. You should avoid a situation in which the Web Dynpro enhancements are switched on and the application logic enhancements and appends are switched off. There are several reasons for this — because the Web Dynpro enhancements presuppose the enhancements in the other
package, for example.

It's also important to remember that if you activate a business function, then all dependent switches are switched on, and the only way to turn on a switch is to activate (switch on)
the business function it belongs to — developers cannot turn on dependent switches
individually. They must always activate the more comprehensive business function.

The Switch Framework's Different Layers Explained

The Switch Framework is organized in several levels (see figure below). The top layer of the Switch Framework is comprised of a business function set that corresponds to an industry solution, and a business function set is made up of many business functions. Because any one business function can be assigned to different business function sets, the relation between them is defined as n to m in the figure.

In the same way, a business function can be assigned to many switches, and a switch can be assigned to many business functions since different business functions may need to switch the same object.

Switches control some objects (like enhancements) by package and other objects (like screen elements, menu entries, and IMG nodes) by direct assignment. One switch can control many objects and packages. On the other hand, an object or a package is uniquely assigned to a switch. 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.

The different layers of and objects controlled by the Switch Framework

Before You Start Switching:
Important Considerations

Having learned the basics about switches and enhancements, you now know all the general concepts needed to understand the principles of integrating SAP industry solutions into the ERP core.

Despite all the advantages of the integration that I mentioned before — fewer systems in your landscape, no more waiting for CRTs, and some reuse of functionality from other ISs — there are also some inherent limitations to this approach (see Figure 2):

You can activate only one IS at a time. You cannot use two different ISs on one system — only the one you switch on.

You cannot switch off an IS; once you activate one IS in a system, you cannot undo it.

Figure 2

Activating an industry solution in SAP ERP

Figure 2 represents the state of affairs in an extremely simplified way. In reality, though, you
cannot get the whole IS Oil and Gas add-on, for
example, in one clump of code. Instead, additions and changes — such as an additional field in a structure, a broader interface, another select statement, an additional check, or changes to the user interface — are spread all over the application. So an IS often looks more like what you see in Figure 3.

Figure 3

Objects that are directly assigned to a switch, and objects that are switched by package

How the Framework's Layered Structure Hides the Technical Details from the Customer

Industry solutions are comprised of many business functions, thus another container is needed to cover and control them all. This container is the business function set. Figure 4 shows what this structure
looks like. So in the Switch Framework, we have four different levels:

On the lowest level, we have the objects, which can be switched either by package or by direct assignment to a switch.

On the next level are the switches.

These switches are assigned to or organized by business functions. In general, SAP delivers business functions in a deactivated state. It's up to the customer to activate the ones that are needed.

Business functions are large, semantically coherent parts of a business function set or industry solution. You can only switch on a business function if its industry solution is activated. Keep in mind that some functionality can only be switched at the business function level.

Figure 4

An example business function set and its elements

Due to the layered structure of the framework, you need only care about the business level when you want to activate an IS in the system.

Which Types of Objects Can Be Switched?

In addition to enhancements, many other types of objects are switchable. These objects, which are switched by package (that is, by assigning the switch to the package) include appends, includes for dictionary structures, fixed value appends to domains, secondary indexes, append search helps, and business configuration sets. Other objects can be switched by directly assigning a switch to them; these objects include screen elements, flow logic, menu entries and functions, IMG nodes, and customizations.

SAP adapts the classic Dynpro of an SAP ERP application by assigning its respective UI elements to switches. This way, an IS can have other labels — more fields and buttons, for example — but, of course, it may also have fewer screen elements. In this way, the Switch Framework makes for an easy adaptation of ERP standard UIs in the ISs.

I'd like to address a common misunderstanding. You may wonder what happens to classes, reports, and function modules that are in a package assigned to a switch when it is switched off. Is the whole class then switched off? No. Classes, reports, and function modules are not affected by the switch state if their package is assigned to a switch. Why? Because switches assigned to a package only control the switchable objects in this package — that is, objects of the types listed above.

Activating an Industry Solution

Because there are many different ISs in a system, developers first have to decide which IS their company needs. Then, they can follow these steps:

Simply activate or switch on the industry solution you want (see Figure 5).

Next, decide which business functions within the set you want to activate and activate them (see Figure 6). The Switch Framework's tools will guide you so that you can only switch on the relevant subset of the business functions in the system (this will be explained in more detail later).

Figure 5

Switching on and activating a business function set; in this example, the business function set is also the industry solution

Figure 6

The different layers of the Switch Framework after activating two business functions (marked with check boxes) within a business function set; the orange boxes indicate the objects and the packages that are switched on

In the example, we have chosen Business Function Set 1 and then activated the Business Functions F1 and F2. This means that the dependent switches 1, 2, and 3 are also switched on. These switches control two packages (with all their switchable content, including enhancements of the Enhancement Framework, dictionary appends, and secondary indexes), some IMG nodes, and Element 1 of Screen 1. The transaction to activate or switch on business function sets and business functions is SFW5. Figure 7 shows us what the steps above look like in this tool. As you can see, the Switch Framework hides a lot of complexity and enables you to switch on ISs at a business level.

Figure 7

How to activate a business function set and the business functions it contains with transaction SFW5

Since all ISs are now developed in the latest ERP system and delivered on one set of DVDs, this means lower TCO for you as a customer; where you used to need two systems, you now only need one.

Reusing Business Functions in Different Industry Solutions

An important benefit of IS integration is that, to some extent, it allows you to reuse business functions from one IS while you have activated another IS. For example, as of SAP ERP enhancement package 3, those customers using IS Oil and Gas can also reuse the entire functionality of the IS Utilities. This enables customers to not only calculate the mineral oil tax and plan the storage and transport of oil and gas, but also handle mass billing for the end customer — all in one system.

You may be wondering how this is possible —
especially since I already mentioned that you can only switch on one IS within a system. However, since business functions can be assigned to one or many business function sets, the SFW5 transaction will present them as options that you can activate once you have activated any of these business function sets. Additionally, some business functions can be used irrespective of the IS — these are the former enterprise add-ons, which can, in principal, be
used in all ISs or in the pure SAP ERP system (see Figure 8).

Figure 8

How reusable business functions work

Summary and Outlook

The Switch Framework and its different layers make the integration of SAP industry solutions into the
SAP ERP 6.0 core possible. Since all ISs are now developed in the latest ERP system and delivered on one set of DVDs, this means lower TCO for you as a customer; where you used to need two systems,
you now only need one. What's more, you can reuse business functions from other ISs — at least to
some degree.

All changes and additions, all additional code, and all UI changes are encapsulated by switches. Objects that are switched off are not compiled, so you can be sure that any switched-off objects will have no impact on the running system.

My previous article covered the functionality of the Enhancement Framework, which allows developers to make modification-free adaptations to their SAP system. Here, I've explained the Switch Framework, which allows customers to activate the exact ISs and business functionality they need. In an upcoming column, I will explain how the Switch and Enhancement Framework empowers yet another important SAP development: the new enhancement package strategy of SAP ERP, which enables you to stay on one stable release and still get
new functionality.

Additional Resources

"A New and Improved Approach to SAP Industry Solutions — How the Switch and Enhancement Framework Now Consolidates SAP Industry Solutions with the ERP Core," an Under Development column by Karl Kessler (SAP Insider, July-September 2005, www.SAPinsideronline.com)

"Introducing the Enhancement Framework — a new way to enhance
SAP programs without having to modify them" by Thomas Weiss and Michael Acker (SAP Professional Journal, January/February 2008, www.SAPpro.com)

Thomas Weiss (thomas.weiss@sap.com) has a Ph.D. in analytic philosophy and worked as a professional writer before he joined the SAP NetWeaver Product Management Training team in 2001, where his responsibilities included the
e-learning strategy for ABAP. After becoming increasingly
more involved in writing ABAP material himself, he is now a member of the SAP NetWeaver Application Server Product Management team. The Switch and Enhancement Framework
has been one of Thomas's major interests for quite some time.

2 For more information on the Switch and Enhancement Framework and on the benefits of using industry solutions, see "A New and Improved Approach to SAP Industry Solutions," an Under Development column by Karl Kessler in the July-September 2005 issue of SAP Insider (www.SAPinsideronline.com). [back]

3 Conflict resolution transports (CRTs) resolve conflicts that can arise between support packages for SAP ERP and an SAP Industry Solution or another add-on component. [back]

4 Of course, there are additional support packages for the ISs. [back]