How To Define a New BADI Within the Enhancement Framework - Part 3 ofthe Series

This is part three of the weblog series on the New Enhancement Framework. You get to know some more facts as to what a BADI is and when to use it, and then, at last, we start with an example that shows you how to build the BADI with the respective tools in the ABAP Workbench and how the code to instantiate and call the BADI is integrated in the ABAP language.

In the last weblogs you have learnt about the basic structure of an enhancement, the different enhancement technologies within the framework and the containers for enhancement options and enhancement implementation elements. You need to know them in order not to lose your bearings within the Enhancement Framework when we now start building a BADI. If you have a mental map of the entities in the framework, you will find it really too easy to understand what is going on in the example. So I would recommend you should take your time to recapitulate theses basics, before proceeding to the practical part of this weblog.

Some Basics about the BADI

Many of you know perhaps the classic BADI. And there is some good news for them: The basic things about the BADI itself have not changed a lot, though there are some major improvements, such as a gigantic step forward in performance. What will be totally new for those familiar with the classic BADI is the way the new BADI is embedded in the container-structure of the Enhancement Framework.

For those not acquainted with the classic BADI, let me spend some words on what a BADI is and what it is for:

The BADI is an object-oriented enhancement option. The BADI defines an interface that can be implemented by BADI-implementations that are transport objects of their own. The new BADI is fully integrated into the Enhancement Framework. Within the Enhancement Framework a BADI is an enhancement option or an anchor point for an object plug-in.

A BADI is to put it this way a controlled explicit enhancement option. It is an explicit enhancement option, which means: BADIs are not provided by the framework, but they have to be defined explicitly by the developer. Why do I call it a controlled enhancement option. To understand what this means we have to go a bit deeper into the methodology of enhancing development objects. Why is it done, and who does it? What is the typical process of enhancing a development object like?

Providing and Implementing Enhancement Options - Two Different Roles

In this process there are two different roles: There is the so-called option-provider. He is the one who builds an enhancement option that is a hook where others can attach something to. And it is essential to have such a hook: Where there is no hook you cannot attach anything. This analogy means that you can only insert an enhancement implementation where there is an enhancement option. Of course, there are implicit enhancement options, that are, so to speak, for free and always available. But there are not implicit BADIs. If you need a BADI, somebody has to define it explicitly. Let us call this role the (enhancement) option provider. In general, the option provider is identical with the developer of a development object that should offer an explicit enhancement option. Let us call this object the basic development object. Typically, the developer of the basic development object could be somebody working in the SAP core who anticipates that the customer or an industry solution might want to add some code at a particular point. In this case he creates both the development object to be enhanced at a later stage and defines an enhancement option.

An enhancement option that has no implementation does not do a lot when processed; in fact, it has no effect at all. To make something happen at an enhancement option, you need to implement it. The developer who implements an enhancement option, or to put it in the analogy, attaches something to the hook, is called the implementer. He need not care about the details of an enhancement option, but just know how he implements it. But, of course, he should have a sound knowledge of the way enhancement options function. You might compare this to somebody who uses a service class. He does not need to know the inside of this class, but just its public methods or maybe even only the respective interface he is interested in. In the same way, the implementer only needs a limited knowledge as to how to define an enhancement option.

In the strict sense, many of you are probably only interested in implementing a BADI. They suppose that SAP provides the BADI and calls the respective BADI methods. All they want to know is what they have to take heed of when writing the BADI implementation. But it is quite useful to know a bit more about defining a BADI, and once you have understood what a powerful pattern a BADI is, you might also be tempted to write your own BADI definitions. Moreover, it would be a bit long-winded to write two different series of weblogs, one for the option provider and another one for the implementer, because there is a large overlap in the background knowledge. For all these reasons, I have decided to handle both topics in this one series. But still, I treat building the BADI in this weblog and providing an BADI implementation in the next one. And you should always keep in mind: Implementing and defining a BADI are two different roles. And the same is true for source code enhancements.

The BADI as a Controlled Enhancement Option

To fully grasp in which way a BADI is a controlled enhancement option, let us first have look at source code plug-ins in contrast. This enhancement technology is not controlled at all. This means: The option provider inserts an enhancement point in the code thereby giving the possibility to attach a source code plug-in. The implementer can insert any code whatsoever at this enhancement point. The option provider has no control at all on the code that is written, because generally it is implemented at a later stage of development. Moreover the code of the source code plug-in has access to all the variables that are visible within the modularization unit that is enhanced. So the option provider cannot prevent the implementer from changing the value of some variables that should not be touched at all. In fact he cannot bar the implementer from anything at all.

With BADIs, things are completely different. The option provider has a firm grip on what the implementer does insofar as he defines the interface and confines the implementer to the class that implements the BADI. In detail this means: A BADI defines the methods with their signature, that is, which parameters the respective method imports, exports, changes or returns. The BADI implementer has to implement these methods defined in the BADI interface. We could put it this way: With a BADI the option provider defines what has to be done, but leaves it to the implementer how he implements the BADI. Moreover, the BADI implementer cannot fiddle with the basic program. It is assured that a BADI implementation can only change the parameters handed over to BADI. The implementation of a method has a context of its own and the variables of the development object using the BADI are not even visible from inside the BADI implementation.

BADI Commands in ABAP

There are two ABAP commands for the new BADI. GET BADI hugo returns a handle to all active instances of the implementations of the respective BADI. For example hugo might refer to five active BADI implementations.

You call a BADI method with the command: CALL BADI hugo->method. If a method of the BADI is called, all active implementations are selected. So this amounts to a loop with the different method calls in it.

When to Use a BADI?

As a potential option provider you should use a BADI if you already know that a particular procedure should be executed at a particular position in your program, but you want leave it to somebody else to specify the specific content of that procedure. This is typically the case if the details of the procedure vary among different potential implementers or are so specific that the developer of basic development object does not know them or want to give the possibility to add different implementations at a later stage.

So the developer of the basic development object just writes something like saying: subtract your fees and return the result. He does not care about what the different fees are and if there is a complex formula, percentages calculation or just a simple subtraction. To do this the option provider writes a BADI which contains a method:

subtract_fees CHANGING costs.

This way, a BADI can be used quite well to understand what enhancements are for from a semantic point of view. This is because the way BADIs work is pretty much like our common sense concept of enhancing something. Usually we do not think: Just add any enhancement, but add something as a means to a particular end. You can decide yourself how you want to accomplish the end, but the end is defined. This is one analogy to explain a BADI.

You might compare the usage of BADIs also to the process when some company delivers the same car body to different manufactures of multi-purpose vehicles. They all build their specific vehicle on the same car body. The producer of the car body leaves the technical details to the different manufacturer, but of course it prescribes that the car suspension has to be build in here and the engine there. In this way, the engine has to be in a particular place and has to have particular properties, but all the other details are up to the manufacturer of the multipurpose vehicle.

This process can be compared to the process of multilevel software development I have already sketched: The program logic of a SAP core program needs some value at a certain point, but the developer of this program does not know how to calculate this value. So he inserts a method call that should provide this value, but leaves the actual implementation, that is the calculation to the developer of the next development level. In terms of this framework, the developer inserts an enhancement option that is a BADI, providing the respective method in its interface, and also a call of a BADI method.

Multiple and Single Use BADIs

Concerning the programming model, there are two different BADI types: Single- and multiple use BADIs. They have a completely different semantics.

The use case with the calculation I have sketched above is a typical example of a single use BADI. The basic program needs the result of a calculation. You leave the implementation details of the calculation to subsequent levels of development, for example the developers for the particular countries. The business logic requires a result of the calculation, and it must be exactly one result. The next steps in the program need this result, so you need at least one BADI implementation. And there is no way to process many return values, so you need exactly one result. If you have a single use BADI, the system takes care that there is exactly one active implementation. This way the call of the method of a single use BADI functions like a method call.

Multiple use BADIs are quite different in this respect. Such a BADI is suitable for activities, that might be done or not and that might even be consecutively done in different ways in different implementations when a program is executed. Imagine you build a BADI additional_output that might convert data for different additional output devices such as a Blackberry, handy, etc… Many different active implementations can coexist in the program simultaneously, but there might also be no active implementation. So the call of a method of a multiple use BADI is in a way like sending a message: You do not know and do not care how many services react to the message. It corresponds to a publish and subscribe mechanism.

Building Our First BADI

The Use Case

And now let us have a look at an example in detail. Imagine that the developer of the basic program needs the VAT of different book entries. These entries should be passed to a method that calculates and returns the VAT. As this developer does not know what the VAT in a specific country is, he defines a BADI BADI_vat with the method get_vat. This method should return the VAT for a particular value that is passed to the method get_vat.

Building the Enhancement Spot

The first thing you need when creating a BADI is a container for the BADI. Up to now we have no container, so we have to create a (simple) enhancement spot. This is the container in which we develop our BADI.

We go to the ABAP workbench and navigate there to our local objects. We select:

Create->Enhancement->Enhancement-Spot

from the context menu of the local objects folder.

This is what the dialog window looks like:

We enter a name for the enhancement spot and some short text. To name a composite enhancement spot is voluntary. We are content with our enhancement spot and need no higher level container for the example. In real life programming, you probably should take advantage of the structure the composite enhancement spots offer you and always work with these complex containers.

The BADI Itself

Next we create a BADI within the new enhancement spot. We select the CREATE icon on the left:

In the dialog window that appears we enter the BADI name z_BADI_calc_vat plus a short description and confirm. Now we have a BADI in the list of our enhancement spot. We deselect the property "multiple use", because for our calculation we need a single use BADI:

The BADI Interface

More important is the fact that up now we do not have much of BADI. We need an interface. In fact, it is the interface where you define the methods that determine what use you can make of your BADI. Understood this way, the interface makes up the identity of a BADI to a large extent. After clicking the arrow in front of the BADI name and after doubleclicking Interface in the tree below we can input the name of the interface. You can either choose the name of an interface that already exists or create a new one. There are no restrictions on the name of the interface enforced by the framework. But, of course, you should conform to the normal rules for choosing speaking names in a systematic manner.

Selecting the Change icon leads you to the class builder, where you can create the methods you need for your BADI in the same way that you are used to if you are familiar with the class builder. We just type in the name of the method get_vat and enter the parameters we need.

A BADI interface has to implement the interface if_BADI_interface. But if we create a BADI interface in the way just shown this marker interface is already integrated in the BADI interface. Probably you know how to work with the class builder, but still I have inserted the following two screenshots to show you: Defining a BADI interface is just normal ABAP Objects programming and as simple as could be for anyone familiar with the Class Builder. We define one BADI method.

Next we determine the parameters of the method.

We save and activate the interface and the spot.

So let us now take a breath and consider what we have created so far:

We have created an enhancement spot and a BADI with an interface. The interface has one method so far.

Of course, just building a BADI does not suffice. It does not do anything. You need a BADI instance, and this instance must be called somewhere in the code. This is the definition part of a BADI. But as a BADI only defines an interface, you need a class that implements this interface. Remember: A BADI definition is the option to insert an object plug-in that does a job at runtime. You still need an object that is plugged in to get something done.

BADI Commands in ABAP

So it is time to write some ABAP code to use the BADI. We need a variable that can refer to the BADI and some variables which are given as actual parameters to the BADI method. Next we create a handle for that BADI and call the BADI method get_vat. The respective commands are GET BADI and CALL BADI.

If we run the program it dumps. Considering what I have told you before about the single use BADI, this is no wonder. It is mandatory, that there is exactly one active implementation for a single use BADI. Our BADI is a single use BADI. One way to handle this is to catch the respective exception cx_BADI_not_implemented.

Using and Creating a Fallback Class

The other way is the better solution, namely to use a fallback class. A fallback class for a BADI is used if there is no active BADI implementation. This means: The GET BADI command returns a handle to an instance of the fallback class and the respective CALL BADI calls the methods of the fallback class instance. As soon as there is an active BADI implementation, the fallback class is not used any longer at runtime. So using a fallback class serves two functions at once:

• The program runs with a single use BADI without raising an exception.


• It is guaranteed that the fallback class is not used any more as soon as a BADI implementation is supplied. So a fallback class is only selected conditionally. This is important, because the BADI provider does usually not know the details of some process. This is why a BADI is used.

We select the checkbox the bottom with the text: Call fallback class if no implementation is executed and insert a name for the class.

Clicking the change icon leads us to the class builder. Again the tools do a great job for you: The respective method of the BADI interface is already defined. We only have to implement it:

I skip this, because it is no news to anybody familiar with the Class Builder. Of course, we have to save and activate the class. Then we navigate back to the enhancement spot and activate it.

Running the program again leads to result:

percentage: 20 VAT: 10.

And this is the end of this weblog. Now, you know how to build an enhancement spot and a BADI including the BADI interface and a fallback class plus the ABAP commands to use the new BADI. In the next weblog you learn how to create a BADI implementation inside the respective container, that is the (simple) enhancement implementation and how to select among the different BADI implementations using the addition FILTER to the GET BADI command

The new Enhancement Framework Part 2 - What Else You Need to KnowBefore Building an Enhancement

This weblog is part two of a series on the new Enhancement Framework. Together with the knowledge from my last weblog it gives you the background information you need to understand what you are doing when you define and implement an enhancement within the new Enhancement Framework. At the end of this weblog we should have prepared the ground for building our first enhancement definition.

In my last weblog, you have learn t about the basic structure underlying the Enhancement Framework: It is an enhancement option and the respective enhancement implementation element. The option can be compared to a hook, while the enhancement is like a board attached to the hook. What makes modification-free enhancements possible is the fact that an enhancement option can be developed in one system and implementations in one or many other subsequent systems. Once the control flow reaches the enhancement option the respective implementation is processed though the implementations and the enhancement options are different transport objects.

The Enhancement Framework imposes a useful, complex structure of containers on the different enhancement options and enhancement implementation elements. In this weblog I want to introduce the different enhancement options and explain both the structure of the containers and motivation behind it. It is important to understand right from the beginning why this structure is very useful for you. Only if you understand the benefits of this structure, you will be able to take maximal advantage of it. Moreover the compliance to this structure is enforced by the tools. This means as soon as you build your first enhancement you have to find your way within this structure. So I have decided to explain another piece of theory before really showing you how to build a new BADI in the next weblog.

The Different Enhancement Technologies

Let me start by giving a sketch of the different enhancement technologies that are part of the Enhancement Framework. There are different kinds of technologies that provide enhancement options:

• Class Enhancements: You can add additional methods, optional parameters, pre- and post-methods to existing methods.


• Function group enhancements: You can enhance the interface of a function module by additional parameters using function group enhancements.


• Source code enhancements: Enhancement points are positions in the source code where you can attach source code plug-ins that enhance the source code at these positions. While a source code plug-in at an enhancement point is processed in addition to the original code, the code of a so-called Enhancement Section is substituted by the respective source code plug-in.


• The BADI is an object-oriented enhancement option. The BADI defines an interface that can be implemented by classes that are transport objects of their own. The new BADI is fully integrated into the Enhancement Framework. Within the Enhancement Framework a BADI is an enhancement option or an anchor point for an object plug-in.

Implicit and Explicit Enhancements

There is one major distinction among the enhancement technologies: The implicit enhancement options are provided by the framework without any effort on the developer's part. This means: The enhancement definition is for free, while, of course, the implementation has to be inserted. Implicit enhancements comprise class enhancements, function group enhancements and predefined enhancement points at particular predefined positions such as the end of a report, a function module, an include or a structure and the beginning and the end of a method. If there is a need for more or other enhancement options than those provided by the framework, you can use so-called explicit enhancement options: They have to be inserted explicitly by the developer. There are two types of explicit enhancement options: BADIs and explicit enhancement points or sections, where you can insert source code plug-ins.

The Nature of Developing Enhancements or Why to Group Enhancements

Enhancements are sociable beings. They hardly ever come alone, in particular when you write your programs according to sound modularization principles. Imagine, you introduce an additional variable as an enhancement. Probably you will work with this variable, transport it to all the different procedures that need the new variable for doing their job and maybe show its value in the user interface. That means, you have to enhance the interface of all these procedures, call these procedures using the new variable and also have to enhance the respective interface. These considerations corroborate the fact that you will probably have a large number of enhancements once you start using this technology.

If you have a large number of things, you need some organizing. This is a reason why it is a good idea to group enhancements. Just imagine the mess on your hard disk if you could not sort the files stored there in folders. The same is true for enhancements.  Moreover, in general you enhance your code for a semantic reason. That is, you want achieve some aim or other by your enhancements. For example, you add an additional variable because maybe you want to calculate an additional tax value. This project necessitates other enhancements. A good way to keep an overview is to keep all the enhancement options belonging to one project together. So it would be great to have a technology that enables you to group and organize your enhancements.

Of course, the reasons for grouping enhancements apply in equal measure to the definition and the implementation of enhancements. If you remember the structure of the enhancements you have probably realized that so far we have talked only about the definition side. The enhancement option is a hook where you can attach an enhancement. Within the terminology of the enhancement framework the enhancement that you attach to an enhancement option is called the enhancement implementation element. So BADI implementations, source code plug-ins or function group enhancements are different types of enhancement implementation elements.

As a matter of fact, enhancement options and their implementations should not be grouped together as they usually belong to different stages of development. Looking a typical scenario you will easily understand this: The global IT department of a company develops a program with enhancement options that are implemented later by the different local subsidiaries. To group these enhancement implementations together with the enhancement options would undermine the basic idea of the enhancement framework, namely to make room for code that is processed at runtime at a particular position of a compilation unit, while it does in fact not belong to this compilation unit. Furthermore, developing these implementations is another project than creating the implementation. And the grouping should group enhancements that belong to different projects separately.

The Structure of the Containers for Enhancements

So it seems we need at least two containers: one for the enhancement options on the definition side and another one for the implementation side. Within the Enhancement Framework there are even more container types.

There are simple containers that can only contain enhancement options or enhancement implementation elements respectively. As a consequence these containers cannot be nested. Moreover, one basic container can only hold elements of one type: That is a simple container cannot, for example, hold BADIs and enhancement points at the same time. To make room for a nested structure there are composite containers that can hold basic containers and other composite containers. These composite containers can contain basic containers of different enhancement types. As these composite containers can be nested, you can build a structure that really fulfills the needs of your project. A simple structure looks like this:

 

It is important that you have a clear idea of this structure in mind because everything you do when creating an enhancement happens within this structure. This is due to the fact that the compliance to the rules is enforced by the framework. This means for you: Every enhancement element has to be part of an enhancement spot. When you create an enhancement from scratch you always have first to create the respective containers. You can compare this to creating a method. There is no such thing as a method on its own. A method is always part of a class. In the same way there is no stand-alone BADI. Every BADI is part of an enhancement spot and it is the spot that is the transport object. It is because of this fact that you cannot build a new BADI and just forget about the framework in the way you might be accustomed to from the classic BADI. It is also not possible to build the BADI first and take care later of how it fits in the structure of containers. When building a BADI you have to put the BADI within the relevant structure from the very beginning. But it is only mandatory to have simple containers. Composite enhancements spots and composite enhancement implementations are not enforced by the tools.

I mention this explicitly because, at first, it might be a bit astonishing for you when you want to create an enhancement point and you first have to create an enhancement spot. When this happens, you should keep in mind two things:

• Experience has shown that structure has to be imposed by tools. Otherwise when programming it is tempting to forget about the structure because it is time saving in the beginning. You see the real costs later when you get in trouble trying to keep an overview of all the different enhancements.


• You should be aware of the fact that you have only the containers after having created an enhancement spot and a simple enhancement implementation. You have prepared the ground for building enhancements, but that is all. Don't delude yourself into thinking that you have already an enhancement option or the respective implementation.

Previously, in my last weblog you have learnt the basic concept of an enhancement. In this weblog you have seen the different kinds of enhancement options, you understand the difference between implicit and explicit enhancement option and you know the structure where the enhancements fit in. In other words,   now you have everything you need at hand to build a BADI. And this is what I will show you in the next weblog. We will build a BADI and see all the pieces of theory at work that you have become acquainted with by now.

What the New Enhancement Framework Is For – Its Basic Structure andElements For Beginners - 1

Introduction

Has it ever occurred to you while looking at some complex technology, that you are lost as to what the technology is actually for? Have you ever had doubts as to whether the complex technology was created exclusively for the entertainment of the developers? I confess that this thought crossed my mind when I first faced the huge complexity of the new Enhancement Framework.

But after a second look I found that nothing could have been further from the truth. The "complexity" of this framework has a clear function, and the basic structure that serves to accomplish this function is actually pretty simple. In this weblog I want to explain what it is exactly that the new Enhancement Framework, packaged with NetWeaver 2004s, provides the software developer. The Enhancement Framework is about resolving an old conflict in software development: standard software solutions versus proprietary solutions. What the Enhancement Framework does is to combine the advantages of both the standard (easily maintainable) with the proprietary solutions (more flexible) while avoiding the drawbacks of both standard software (lack of flexibility) and customized software (upgrade issues).

At the core of this framework is a simple structure consisting of a hook or an enhancement option and an implementation element you can attach there. You may already understand that enhancements are preferable to modifications. To take full advantage of what enhancements over modifications offer, you will need the new Enhancement Framework. Its purpose: to offer you the ability to enhance the SAP standard software and to organize these enhancement options and their respective implementation elements as effectively as possible. Don't expect to learn about all the technical details of the Enhancement Framework in this particular weblog, though. This weblog will solely cover the basics of the framework. Once you have a clearer concept of the basics, you will see that the complex structures of the whole framework serve a lot of different functions and still not feel lost within these structures.

What SAP Does to Bridge the Gap between Standard Software and Proprietary Solutions?

Standard software can have many advantages over proprietary solutions in terms of cost, ease and effort. But standard software is much like off-the-rack clothing. It doesn't always fit perfectly. There will probably be some aspects in which standard software does not optimally meet the specific requirements of a process as it is realized in a particular customer company.

On the other hand, proprietary software is usually better suited to meet your specific requirements. Unfortunately having a non-standard solution also means a lot of drawbacks. Surely, your company prefers to concentrate on the things it does best, be it building cars, selling food or whatever other core business and competences it has. So it isn't really a very attractive option to resolve standard solution limitations by maintenance and further development of a proprietary IT solution.

Of course, it would be great to have the best of both approaches: to have all the advantages of a standardized software solution while having the flexibility of a highly customized solution. One way to accomplish this (at least to a certain extent) is to have a standard solution that can be adapted to the individual needs of your company. SAP has gone quite a long way in this direction.

Since SAP exposes and delivers the source code of all ABAP-based solutions, a customer theoretically could directly modify SAP coding. But, of course, this should happen only in a controlled way. It would do no good to change the source code in a totally ungoverned way. For this reason SAP offered so far two different technological approaches to enable the customer to adapt SAP source code:

• Modifications are changes of a SAP development object. These are supported and tracked by the Modification Assistant.


• Enhancements, on the other hand, do not change the SAP development object, but rather add something to it or enhance it. Up to now, there were so-called User Exits and Customer Exits where you could put in additional source code. Since release 4.6 there were also BADIs (Business Add-Ins). A BADI specifies an object-oriented interface that can be implemented by a customer.

The new Enhancement Framework, packaged with NetWeaver 2004s, is intended to unify these two approaches: the modifications and the classic enhancement technology. Up to now it integrates all the new enhancement technologies such as the new BAdI, source code plug-ins, class enhancements, and function group enhancements. The framework brings with it flexibility so that you have the freedom to adapt a solution to your own needs while keeping all the advantages of a standard solution.

Simply stated, the new Enhancement Framework is an evolution of classic enhancement technologies. The concept of enhancing a development object has some important advantages over modifying it. SAP has decided to optimize the enhancement technology in such a way that you can now use enhancements in many of the situations where you formally needed to modify the source code.

The Limits of Modifications and Why Enhancements Are More Powerful

Modification has limits almost inherent in this very concept. You face these limits when upgrading or transporting a modified object. Imagine you have a modified program in your system and your system is upgraded. What happens to your modifications? First, your modifications are gone, although you can re-insert them using the Modification Assistant. But reinsertion means a lot of work for you. You have to go through your whole program and look at all the modifications to see where they fit in the upgraded version of your program. Taking into account the fact that you often have many modified programs spread over one or many solutions, modifications generate a lot of work after an upgrade. Further limitations surface when you consider different modifications of the same development object from parallel or subsequent development systems. All of these problems stem from the fact that modifications are technically a part of the source code unit they modify. And one source unit exists only once in a system. After an upgrade, a modified development object is first substituted by the unmodified one that comes with the upgrade. In order to keep the modifications, you have to reinstate them in the new object.

Though the transaction SPAU offers you good support for this task, it is not at all a trivial task. If relevant parts of a development object have changed, you need expert knowledge of this object to reinsert the modifications. The administrator who runs the upgrade is most probably not able to merge the modifications properly. Instead of using your systems at once after the upgrade you need some developers with expert knowledge of the relevant solutions to attend to the modifications. So you pay for the high flexibility modifications offer with a lot of additional work during upgrades.

When you have many modifications you surely want to organize them in some way. Unfortunately, as they technically belong to the program they enhance, there is no possibility to group modifications. You cannot even organize them at all in a structure of their own. Changes to a development object should, of course, be documented. Modifications can have no documentation attached to them in the system. It is also not possible to track who modified which parts of a development object.

Obviously all the limits of modifications originate from the fact that they are part of the object they modify. In contrast to modifications, enhancements are objects in their own right. If you enhance SAP code these enhancements are in your namespace, not in that of SAP. They are your objects.

Most of the advantages the Enhancement Framework offers are based on the fact that enhancements are objects in their own right. You can organize enhancements in a structure of their own and document them in the system. You can transport them in units of their own. As far as upgrades and transports are concerned, you can transport enhancements from different systems into one system and keep all these enhancements, plus the ones that exist in your target system. No enhancement gets lost.

This is the basic conceptual advantage that enhancements have over modifications. A major advantage of the new Enhancement Framework is that it unifies all the new enhancement technologies in one framework. It is this framework that realizes the advantages that are possible because enhancements are objects in their own right: The enhancement framework enables management of different types of enhancements from different systems. They survive an upgrade without a lot of additional work. You can organize them in a structure of their own and document all the enhancements in the system.

Why and When to Change SAP Software

At this point you might ask yourself: Why should I change an SAP software solution at all? You should change a SAP solution only if you have come to the conclusion that none of the possibilities of customizing meet your specific requirements. First try out everything that is possible by means of customizing. If you are still in need of adjustments of the standard you should consider enhancements as the means of your choice. As enhancements are objects of their own they are quite robust in an upgrade. They will cause you far less work than modifications. In addition to this advantage concerning the work necessary for an upgrade, the new Enhancement Framework offers you a variety of useful features to manage, organize and document your enhancements. Just as enhancements have advantages over modifications, not all enhancement technologies within the new framework are equally suitable if you want to write highly structured code that causes as little work as possible during update. But this will be explained in detail in another weblog in which you learn more about the details of the Enhancement Framework.

Understood in this way, the new Enhancement Framework isn't an open invitation to freely enhance your SAP solution in as many ways and means as are possible. The Enhancement framework can be compared to a powerful tool. Think of it like a high-end precision drill which will probably not tempt you to sprinkle holes all over your walls and furniture. It is merely a comfortable professional means by which you drill a hole whenever you absolutely need to drill a hole. It is this attitude that you should have towards the Enhancement Framework. With standard software there may be a necessity to adapt to your needs. Whenever there is a necessity, use enhancements within the new Enhancement Framework.

The Basic Idea of the Enhancement Framework: How Do Modification- Free Enhancements Work?

Before going into more detail, you should now understand the basic idea of the Enhancement Framework. It provides a modification-free enhancement technology, enhancing source code units without modifying them.

The basic mechanism is to offer so-called enhancement options in development objects. These enhancement options function like hooks where you can attach the enhancements. The hooks are part of the development objects which can be enhanced. When you assign an enhancement to a hook, at runtime the enhancement is processed when the control flow reaches the hook. In other words: At runtime the enhancement behaves as if it belonged to the development object it enhances, while the enhancement as a transport object does not belong to the enhanced object.

As this probably sounds a bit abstract let us have a look at a specific enhancement, the source code plug-in. At predefined positions in the source code (for example, in a report) you have a particular type of enhancement option, that is an enhancement point. At these points you can insert an enhancement that is called a source code plug-in. The respective plug-in is processed after the enhancement point is reached by the control flow. That is, the source code plug-in behaves at runtime as if it were part of the report while in fact it can belong to another package.

This is what a source-code plug in looks like:

 

Ignore the details of the source code enhancement for the moment. This particular example only serves to illustrate the point of how enhancements function: You have the anchor point or enhancement option, which is an enhancement point in our particular example. At this enhancement point which is in the orange marked line the enhancement element 1 (in grey colour) is inserted. The spot flights_display_b and the enhancement flights_display are units you should not be interested in at this point.

.

In some way you can compare the enhancement technology with a closet system where you can insert different elements at particular positions. You need not drill the wood in the side walls, but nevertheless you can attach boards and other elements where there are already hooks or holders at important positions. The boards and other elements such as drawer or CD-holder look as if they were integral parts of the closet system while in fact they are only attached to the walls by hooks or holders.

The holder in our analogy corresponds to the enhancement options. The different elements you can attach there such as boards, drawers, CD- elements etc. behave like the enhancements. You can not attach a board to the closet system everywhere you like, but rather only where a holder is prepared. In the same way you cannot enhance a development object anywhere, but only at predefined positions, which are called enhancement options.

So irrespective of all further refinements, superimposed containers and their respective connections, the basic structure of how an enhancement functions is as simple as could be:

• On the one hand, there are hooks or enhancement options where you can insert enhancement elements. Further on I will also speak of the definition side of the Enhancement Framework because it is there that the enhancement options are defined.


• On the other hand, there are the enhancement implementation elements that you can attach to a hook or an enhancement option.

The Complexity of the Enhancement Framework

Despite this simple structure the Enhancement Framework as a whole is pretty complex: You have different kind of enhancement technologies. At different kind of enhancement options you can attach different types of enhancement elements. The enhancement options are divided in two different classes: Implicit enhancement options which are provided by the framework and exist without any particular preparation by a developer. Explicit enhancement options have to be inserted explicitly in the source code. These explicit enhancement options must belong to a container.

On the implementation side all implementation elements, regardless of whether they enhance implicit or explicit enhancement options, belong to other containers. The containers on the definition side and those on the implementation side are assigned to each other with a particular cardinality.

All these different units form a complex structure despite the fact, that the basic concept of a single enhancement is so simple, as I have just shown you. But this structure is indispensable to accomplish all the aims the framework is made for. The Enhancement Framework is made to organize and manage a huge mass of enhancement options and implementations of different types. And it is mainly this aspect that requires the high complexity.

You might ask yourself why you need the containers if you just want to create a single enhancement option and implement it. The answer is that you hardly ever need only one enhancement. As good software is usually divided in components, one change (for example an additional field in a structure) necessitates a lot of other changes. And in real life programming it is not just you, but your team and many other teams that create and so have to manage their enhancements options and implementations.

The framework not only offers you that structure to organize and manage your enhancement options and enhancements, but the compliance with the framework is enforced by the tools. By adhering to the rules you can be sure that you can fully take advantage of the framework and you will never face a situation in which you have lots of unorganized enhancements in your system.

Types of Work Processes

Even though the Work processes are unique at OS level SAP differentiated between the work processes based on the nature of work.
The processes are determined by the instance name DVEBMGS<Instance_No>
For Dialogue instances the work process will be denoted as D01, D02….

1. D – Dialogue


2. V – Update


3. E – Enqueue


4. B – Back ground


5. M – Message


6. G – Gateway


7. S – Spool

1. DIALOGUE ‘D’
It is only the process which communicates interactively with the users. There should be atleast 2 Dialogue work process per instance. Dialogue work process initiates Update, Background and Spool.

2. UPDATE ‘V’
It is used to update the transactions in the database. It is initiated by Dialogue process. There should be atleast 1 Update in the entire system. It is also recommended to have an update process for every 5 Dialogue.

3. ENQUEUE ‘E’
It is used to provide locks for the records that are going to be updated. It ensures consistency for updates. There will be only 1 Enqueue configured in the system during the installation. It is possible to have more than one enqueue provided they are installed or configured on the central instance.

4. BACKGROUND ‘B’
The tasks which are expensive or time consuming are scheduled to run in the background mode non-interactively. There should be atleast 2 background work process in the system

5. MESSAGE ‘M’
There should be only 1 message server in the entire R/3 system. It is used to manage all the dispatchers. It is used to load balance the requests to identify the least loaded dispatcher.
It is also used to provide locks to the request that are coming from Dialogue instances.

6. GATEWAY ‘G’
It is used to provide a means of communication with SAP and NON-SAP systems. There will be only 1 gateway for each instance.

7. SPOOL ‘S’
It is used to print the documents to a printer or output to a fax machine etc. There should be atleast 1 Spool process in the entire system. It is also possible to configure more spool process depending on the print/ spool volume.

Monitor SAP Systems

Monitoring SAP system is a must to make sure that everything is running as perfectly as possible. Any of these problems, which might suggest a small problem, might very soon creep up to be a big problem. So it is always recommended to monitor SAP systems everyday and it’s even better if you share these reports to the entire group of SAP technical members working in your project to make sure that they can identify something which was not identified by you or other team members.

Here is the list of things which should be monitored in SAP Systems frequently.

1. Check SAP Process Overview (SM51/SM50/SM66): Use these transactions to monitor work processes which are running for a long time. If you see any processes running in a Dialog mode for a longer time, then inform and find out from the users what they are trying to do.


2. Logged in users in AL08/SM04: This is used to check the no of users logged in the system, Make sure the users are evenly distributed across all instances, if you see a lot more users in one instance than the other, there is something wrong, check the load balancer settings or other options.


3. Spool Requests: Check the no of Spool requests created each day, there shouldn’t suddenly be a spike in the process unless there is a new process in place.


4. Lock Objects SM12: check this transaction for any locked objects. If there are any locks for more than a day, than that is a problem, find the user or the programmer to dig more further to see if this is really required.


5. Update requests on SM13: There should not be more than 10 updates at a given time.


6. System Logs SM21: Check the logs frequently for any abnormal trends, find corresponding system dumps (ST22) and contact the necessary developers or check OSS Notes.


7. Check Background Jobs: SM37 is used to check the background jobs. Check for any jobs running for a long time, check for past run time of the same jobs to see if there was a sudden increase in the duration.


8. SAP Buffers: User ST02 to check for the SAP Buffers, The “current use” should not be near the value of “in memory”.


9. Workload Analysis: Use ST03 is used to check the workload analysis of SAP Instance.


10. Operating System Monitor:  Use ST06, to check the Operating system status. Check the utilization of system resources, check the event logs. If CPU utilization is higher than 60%, find the programs and transactions and take corrective measures.


11. ST11 to display Developer traces.


12. St22 for ABAP dump analysis


13. St04 /ST02 for Database Analysis to monitor expensive Statements, monitor database performances.


14. WE02 for failed IDocs