ABAP Objects: Creating a Custom SAP ERP HCM Class Library
For the past decade the advantages of ABAP Objects has been described time and again. If you are still skeptical to ABAP Objects, then please read “Not Yet Using ABAP Objects? Eight Reasons Why Every ABAP Developer Should Give It a Second Look” before you read the reminder of this blog. Although the advantages of ABAP Objects are evident, many ABAP developers still neglect to write object-oriented (OO) programs. One reason for this could be a lack of hands-on examples of how to get started with ABAP Objects programming. In this article, a class library skeleton for OO programming within the area of SAP ERP Human Capital Management (HCM) will be introduced. To benefit from this blog you should be well acquainted with both ABAP Objects and HCM.
This is the first blog in a series of blogs on ABAP Objects in the context of a Custom SAP ERP HCM Class Library:
- ABAP Objects: Creating a Custom SAP ERP HCM Class Library
- ABAP Objects: Custom SAP ERP HCM Class Library – Example 1 – Class Instances
- ABAP Objects: Custom SAP ERP HCM Class Library – Example 2 – Utility Classes
- ABAP Objects: Custom SAP ERP HCM Class Library – Example 3 – Exceptions
There is no need for a custom class library if you have no custom HCM code. A first step is therefore to analyze your need for a class library. One starting point is to create a where-used list from table PA0001? Did you get an alarming large number of custom procedural programs containing select statements to table PA0001? Many redundant select statements? Same problem with table HRP1001? Guess what – you are not the only one facing this problem!
It is my experience that select statements in custom programs following a procedural paradigm are very common. The select statements have often been copied-and-pasted from one program to another. Needless to say that this is an error prone approach that requires unnecessary maintenance.
A frequently used approach is to centralize and reuse the select statements by simply wrapping them into class methods. Often it is sufficient to have one custom HCM class that contains various methods. In my opinion, however, this type of programming strongly resembles writing function modules and can barely be considered as OO programming. Therefore, I would like to propose a class library that can be used for your custom HCM programming.
2. Class Library
During the past years as an ABAP architect within the area of HCM, I have tried to find a nice design for my ABAP Objects coding. The following class library is not a theoretical concept and is used for concrete tasks at SAP customers. Keep in mind that the class library is an ongoing effort for improvement and is by no means final. Do not hesitate to comment this blog if you have improvements that you would like to share with the rest of us. A class diagram representation of the library is presented below.
The business layer class diagram from a transaction SE80 perspective.
It is not possible to go into details with all the classes here. In the following sections selected examples of the class library are presented.
3. Attributes Example
Attributes of class ZCL_HR are common to all subclasses.
Superclass attributes are inherited and must not be declared again in subclasses. The developer can focus on attributes that are specific for the subclass. For example, class ZCL_HR_EMP contains attributes such as person and user.
4. Method Example
Now lets have a look at a method example of how to use the class library. Remember, the class library is merely a skeleton that should be extended to suit your needs.
Creating a where-used list from table HRP1001 reveals several select statements with relationship 012. This relationship indicates a managing position of an organizational unit. Usually a 012 relationship select statement is part of a context for resolving the person who holds the managing position of an organizational unit. In other words, get manager functionality. The starting point for getting a manager often differs. Sometimes you have the personnel number of an employee, an organizational unit, a position, and so on. Consequently, the get manager functionality is used in many subclasses of class ZCL_HR. By adding a GET_MANAGER method to class ZIF_HR it is guaranteed that the signature is the same for all classes using the interface.
The GET_MANAGER method returns an object collection of type CL_OBJECT_COLLECTION. Using an object collection provides flexibility to the signature. Presumably the collectin contains objects of type ZCL_HR_MGR.
Interface methods contains no coding. The coding is implemented in the classes ZCL_HR_EMP, ZCL_HR_ORG_UNIT, and ZCL_HR_POSITION. Each class contains object specific logic. Go to class ZCL_HR_EMP and implement the inherited method GET_MANAGER.
I have successfully applied the class library in various HCM scenarios. Among others it has proven very valuable in Self-Service (XSS), Performance Management, Travel Management, ALE/IDoc scenarios, Workflows, and many more. In my opinion, centralized OO development leads to improved quality and lower costs:
- Consistent business rules. It seems obvious to have consistent business rules before any coding can be done. However, experience has taught me that this is not always the case. Sometimes development specifications made in a hurry lead to irregularities in the business rules. Centralizing the coding will force business rules to be more consistent.
- Onboarding cost reduction. Bundling custom functionality into a class library makes it easier and quicker for new employees to start coding.
- Authorization checks implemented centrally will keep developers from forgetting adding them.
- Maintenance costs decrease because problems can be fixed centrally and thereby avoid repeating changes in various places. Fewer issues through enhanced robustness achieved through reuse of code.
- Division of labor. Experienced ABAP developershandle design questions and beginners implement simple code within predefined methods. SQL experts focus on optimizing wrapped select statements.
- Faster development and more stable applications through reuse of code.
- Better performance. Despite the technical overhead of OO programming, I think that performance can be improved by optimizing the code of the class library. Often programmers have little time to consider performance aspects. By reusing functionality from a class library performance optimization is given.
Finally, it seems that all SAP applications are in a transition to OO programming. Prepare yourself for the future by coding OO today!