Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at [email protected].
The structure of the Enhancement Framework
No matter if you create an enhancement point or a BAdI as an enhancement option provider, or if you implement an existing enhancement option (be it implicit or explicit), what you create must fit into the structure of the Enhancement Framework in a way that enables you to collect and organize the enhancement options and their counterparts on the implementation side. This means that the explicit enhancement options and all enhancement implementation elements (enhancements) have to be part of containers, which also serve as transport objects.
In this final part of the blog, I will explain what these containers are and how they are structured. At the end of it, you should know all you need about organizing enhancement options and enhancements.
Enhancement Framework Spots & Implementations
Option providers and implementers must assign all explicit enhancement options (i.e., BAdIs and source code plug-ins) and all enhancement implementation elements, respectively, to containers. Explicit enhancement options must be assigned to (simple) enhancement spots, enhancement implementation elements must be assigned to (simple) enhancement implementations, each of which can be grouped into composite enhancement spots or composite enhancement implementations, respectively. These containers not only serve to manage your enhancements and enhancement options and keep them organized, but also serve as transport objects. Lets define these a little further…
What do we mean by simple? Composite? Its easy, simple signifies that it is an individual enhancement spot or enhancement implementation as opposed to a composite, which is a grouping related enhancements spots or implementations.
(Simple) enhancement spots and (simple) implementation elements
You must create an explicit enhancement option within a (simple) enhancement spot. A (simple) enhancement spot can contain many enhancement options, while an enhancement option is uniquely assigned to one (simple) enhancement spot. So its a one to many relationship.
There are rules…A (simple) enhancement spot can only contain enhancement options of the same type; that is, a spot that contains enhancement options for source code plug-ins cannot also contain BAdIs.
You must create an enhancement implementation element within a (simple) enhancement implementation. A (simple) enhancement implementation can contain many enhancement implementation elements, while an enhancement implementation element is uniquely assigned to one (simple) enhancement implementation. As with (simple) enhancement spots, a (simple) enhancement implementation can only contain enhancement implementation elements of the same type. More rules…beyond this. a (simple) enhancement implementation containing source code plug-ins can contain only source code plug-ins enhancing one report or additional methods and additional attributes enhancing one class. Class enhancements in one enhancement implementation must belong to one class, function group enhancements to one function group, and Web Dynpro enhancements to one Web Dynpro component…etc…etc
Composite enhancement spots and composite enhancement implementations
Sometimes there is the need to put all enhancements of a particular project in a single traceable bucket. One of the main reasons for enhancement spots and enhancement implementations is to enable you to put entities semantically belonging together, (because they are all needed to solve the requirement together), in one basket. But, as I just described, (simple) enhancement spots and implementations can only contain options or elements of the same type. So what do you do when you need to put all of the enhancements of a particular project, which are bound to be of different types, in a single container? There is another type of container for this, enter Composites.
Similar to composite enhancement spots, composite enhancement implementations group related (simple) enhancement implementations, which can contain enhancement implementation elements of the same or different types. Like composite enhancement spots, composite enhancement implementations can only contain (simple) enhancement implementations directly, not enhancement implementation elements, but they can be nested.
Lets recap…and then see how this all fits together.
So there are four new transport objects in the new Enhancement Framework:
– (Simple) enhancement spots can contain explicit enhancement options of the same type (i.e., BAdIs).
– (Simple) enhancement implementations can contain enhancement implementation elements that are of the same type and implement enhancement options in the same development object.
– Composite enhancement spots can contain (simple) enhancement spots of the same or different type and other composite enhancement spots.
– Composite enhancement implementations can contain (simple) enhancement implementations of the same or different type and other composite enhancement spots.
How it all fits together..
Let’s now look at all these objects of the Enhancement Framework and the way they are assigned to each other, the picture below summarizes the relationships between all of these objects.
One enhancement spot can contain many enhancement options, while an enhancement option is uniquely assigned to a spot. The same applies in concept to the relation between simple enhancement implementations and the enhancement implementation elements.
So it follows then the simple containers on both the definition and implementation side can only contain elements of the same type: A spot that contains BAdIs cannot contain enhancement points/sections and vice versa.
The composite containers are not affected by this restriction. A composite enhancement spot can contain simple enhancement spots that in turn contain enhancement options of different types. One composite enhancement spot can contain many (simple) enhancement spots, while a (simple) enhancement spot uniquely belongs to a composite enhancement spot. Composite spots can be nested.
There are composite enhancement spots and composite enhancement implementations. And this makes perfect sense– All the stuff on the left hand side (the definition side) are hooks created by the enhancement option providers, while those on the right hand side (the implementation side) are used by the implementers. This is me and you.
Now that you have a solid understanding of the concepts behind the new Enhancement Framework, lets look at a final point for consideration and a best practice.
Consider: One enhancement usually will require other enhancements
You enhance a SAP development object to achieve some aim on the semantic level. Usually this aim cannot be reached by one enhancement only. For example, suppose you have enhanced a SELECT statement by an additional field. First, you need to enhance the structure that holds the result set. And most probably the new field should do something. So you probably have to enhance the interfaces of the relevant methods that work with the new data.
You probably also have to add some additional edits or validations because the additional data needs to be validated and/or derived. And after all you want to present some additional value in the user interface. That means you have to add an additional field to your user interface and to transport the new value there. In this way, enhancements are sociable — they hardly ever come alone.
So the very nature of enhancement development leads to a larger number of enhancements. And a larger number of objects need to be organized. In addition, there are the well-know reasons that require some structuring of every software project–Enhancement options may be created and implemented by a team, or even multiple teams, and be part of different projects. And you need to silo the enhancements in a way that mirrors the team and project structure.
So there are plenty of reasons why you will have many enhancements and why these many objects need some organization. This is why the Enhancement Framework not only provides containers but also enforces a container structure on the different objects. Containers enable you to organize your enhancements and explicit enhancement options according to type, project, content-related matters, and other sorting criteria, and these containers also serve as transport objects.
Best Practice: Several small enhancements are better than one large enhancement
If you keep your code small instead of, for example, replacing an entire program, the chance increases that they will create less work in an upgrade. Remember that one of the promises of enhancements is that they can survive an upgrade without requiring a lot of additional work.
The smaller a portion of code replaced by an enhancement is, the smaller is the possibility that the original code will be changed or deleted by SAP in an upgrade. So a number of small enhancements are less susceptible to changes of the enhanced object than one very large enhancement — there are less chances for dependencies that could cause problems after an upgrade.
Final thoughts..
The basic idea of the enhancement framework is to have a technology that serves the same aim and fulfills the same functions as modifications, without any of the drawbacks that are inherent to the very concept of a modification — a modification is part of the object it modifies, which means you have to reinsert modifications of SAP objects after every upgrade. In other words, modifications cause quite a bit of work. In contrast, enhancements are transportable objects in their own right that you develop within your own namespace. For this very reason, enhancements cause far less work during an upgrade.
This is a powerful technology and I cannot emphasize the importance of planning before you use the Enhancement Framework to adapt your SAP system.
To read part 1 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 1.
To read part 2 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 2.
To read part 3 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 3.
To read part 4 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 4.
