This Blog is the first part of a series of BLOGs to cover best practices in development of Business classes in Object Oriented ABAP. This topic will be covered in detail at SAPTechEd Phoenix in the following session:
Best Practices in Development of Business Classes Using Object-Oriented ABAP in SAP NetWeaver 7.0
The other parts of this series will be published AFTER the SAPTechEds, so if you are attending SAPTechEd in Phoenix and are interested in this topic, we strongly encourage you to attend our session. We'll be able to go over it in detail.
- PART 1: What are Business Classes and why do we need them?
- PART 2: Naming convention and Class structure (Attributes and methods);
- PART 3: Instantiation;
- PART 4: Inheritance;
- PART 5: Database Access;
- PART 6: Exceptions (Exception Classes);
- PART 7: Model Classes
- PART 8: Others (Package Hierarchy, performance optimization);
- PART 9: Community content and collaboration;
It is important to outline that we assume that you already understand the importance and advantages of programming in Object Oriented methodology. If that is not the case, I strongly suggest you read the following articles from Horst Keller and Gerd Kluger:
What are Business Classes?
Business classes are Object Oriented ABAP Classes that represent business objects. Examples of these objects are the following:
- Purchase order;
- Sales Order;
- Delivery;
- Shipment;
- Customer;
- Contract;
- Material;
- User;
- IDOC;
- Etc, etc.
They are largely based on SAP content, but not restricted only to it. You can have classes for your own objects;
They are a level of abstraction between internal SAP programs and tables and business requirements. And that is a very important point that we'll cover later in this BLOG.
Written in Object Oriented ABAP, they provide many advantages. It makes much easier to interact with them.
Why do we need Business Classes?
There are many advantages in using a centralized set of Business classes but they all can be grouped together, since they all support reduction of development cost. Here is why:
- Simpler code;
- Simpler maintenance = lower support costs;
- Business content abstraction;
- MVC Support
- The importance of programming standards
Having a centralized repository of Business classes is the most effective way to promote code reusability. This is often overlooked or difficult to implement.
The idea is to have the code written ONCE, WELL and REUSED. I can't stress that enough.
I really enjoyed listening to the podcast from Ed and Thomas (Enterprise Geeks - Sapphire or Bust). A lot was covered there, but at one point they made a point that even though ABAP has evolved to a serious modern programming language, development is very often still done in silos, using procedural techniques. That is the reality of today's ABAP custom developments. This is a situation that doesn't promote reusability, so often you see the same business requirement coded in many different places. That is a nightmare since it costs more to implement (reinvent the wheel), but more yet to maintain it...
Simpler code;
I love Italian cuisine. Spaghetti is great, but not in code. Spaghetti code and Frankenstein programs are everywhere. Do they work? in most cases yes, but they cost more than they should.
The structure of a report should be built in a way that is simple to read. There is a distinction that needs to be made. Complex programming should not mean difficult to read. In my experience I can tell the quality of a program design by how simple it is to understand it.
KISS (Keep It Simple Stupid)
We've put together an illustration of this.
Where do I start? Which objects are involved and for what purpose?
Well, that is simpler. Knowing the availability of a business class (or the possibility of creating one) we know that we'll need to deal with the class PURCHASE_ORDER and execute the methods RELEASE and CREATE_DELIVERY.
Releasing a purchase order is a functionality that once coded, could be reused in many different places (Custom transaction, Workflow, BAPIs or RFC, etc)
Simpler maintenance = lower support costs;
Simpler code makes not only designing but supporting it simpler too.
How well a program is documented? Most of the times it is either well documented but outdated (never revised since go-live) or not documented enough.
I am in no way implying that code doesn't need to be documented. I am just saying that the program would be less dependent on its documentation and that no one could complain about.
Business content abstraction
We are dealing with business content here. At one point in the design process someone will have to make the link between hard development objects and business content.
Having a layer of abstraction to establish this connection makes the communication much easier between the gathering (Functional task) and design (technical task).
I often talk about how much technical knowledge the functional teams should have and how much functional/business knowledge the developers should have to be really competitive in the market today. But the reality is that most often there is a hole in the middle of these 2 groups and they don't even speak the same language. That is where this abstraction layer comes to help.
MVC Support
Again, Ed and Thomas mentioned that the best way to leverage future SAP functionality is to program in a way so that we expose custom functions as webservices. There can then be used both anywhere, making the transition to Webdynpro ABAP easier. This is also referred to as the implementation of the MVC programming standards.
I love the expression from Horst Keller at SAPTechEd 2007: "Separation of concerns..." That means to separate business logic from presentation logic. What "concerns" business logic should be put separated from the screen processing logic (presentation logic).
Investment today in developing centralized reusable business classes pays itself later when ABAP Webdynpro adoption becomes more generalized (you can't run away from this wave. It will hit someday...)
The importance of programming standards
Many classes are to be built and to be used by many different developers. In some cases this would be implemented even for different customers. It is imperative then that good standards are established and followed. What is the point of having a group of business classes if they all look and behave differently?
We all know how many different ways exist to accomplish something. This is even truer in development. That doesn't mean that there is only one "good" way exist. But since we all need to adopt one standard, we might as well put good effort to define it.
That is where the SAP community comes. This I am writing today is something I started in the community quite a few years ago. I even presented a similar session at SAPTechEd Community day Vegas 2008. Also, and more importantly, a lot of collaboration happened within the SAP community. A few developers got involved, some SAP Mentors even.
What we propose is what we consider a very good starting point. We even provide some implementation options depending on how complex you want to go. It will be always a question of establishing the balance between complexity (by using more advanced concepts and embracing further Object Orientation) and simplicity (by making the concepts easier to "digest", after all , we want it adopted by all developers, right?)
5 Comments
