Skip to Content

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:

  1. ABAP Objects: Creating a Custom SAP ERP HCM Class Library
  2. ABAP Objects: Custom SAP ERP HCM Class Library – Example 1 – Class Instances
  3. ABAP Objects: Custom SAP ERP HCM Class Library – Example 2 – Utility Classes
  4. ABAP Objects: Custom SAP ERP HCM Class Library – Example 3 – Exceptions

1. Analysis

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.


5. Outlook

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!

You must be Logged on to comment or reply to a post.
  • If we can use this concept,it's very useful!
    However,I have some question about implementation of this concept. How can we apply this concept with the other object types (Job, Cost center,...)? I think it really difficult to define super class for all object types in SAP and also its method because each object's characteristic is quite different.
    • Hi Pissanu,

      thanks for your comment.

      My real class library contains other object types, such as for example Cost Center. However, to get a better overview I did not include them in this blog. Perhaps you need to make some adjustments to the method signatures or even move some methods to subclasses in order to suit your needs.

      Inheritance is difficult to find and so far I am only using it for the P object (Person) branch. The idea of this blog is propose a skeleton to make it easier to find a suitable place to write your code. For example, you have some select statements to get the employees of an organizational unit. Based on the class library I would add a method GET_EMPLOYEES() to the class ZCL_HR_ORG_UNIT.

      If you have anything that you would like to discuss, do not hesitate to write a comment.  

      • ็Hi,
        The thing that I concern about the other object types is how we find general attribute and method for ZCL_HR class which all attribute and method will inherit to subclass. For example,ZCL_HR has GET_MANAGER() method but cost center,which is supposed to be subclass of ZCL_HR, don't have manager. Please share your idea to me in this case.
        Thanks 😀
        • Hi,

          for the cost center there is a responsible. Take a look at function module RH_GET_COST_CENTER_RESPONSIBLE. If that does not fit into the GET_MANAGER() concept then perhaps the GET_MANAGER should not be part of the ZCL_HR class. To ensure that the signature is the same for all GET_MANAGER methods an interface could be used. 

          • Hi again,

            just a short update. Yesterday, I extended the library for the ZCL_HR_COST_CENTER class. The new method name was GET_POSITIONS, which get the positions related to a cost center. The method returns a collection (CL_OBJECT_COLLECTION) of ZCL_HR_POSITIONS objects.

            Besides adding the method it made me realize that the GET_MANAGER method should perhaps return an collection in order to make it more dynamic and flexible.

        • Hi,

          Nice blog. More exaples and discussions about ABAP Object is great.

          Why is the cost center class supposed to be a subclass of ZCL_HR? I see no point in having a common superclass for all other classes. Some languages or libraries have that, e.g. the Java class java.lang.Object but the content of that class is quite techical.

          It makes sense to have a common superclass for person, org unit and position, since they share attributes and behavior, like having a manager, but a cost center does not belong there. If cost center has something in common with the other objects, perhaps a new class could be created that is the superclass of ZCL_HR and cost center.

          Only use inheritence for "is a" relationships. Don't use it to group classes together because they belong to the same project. That could be done by e.g. packages.

          • Hi Christoffer,

            thanks for your comment, I appreciate having a discussion around this topic.

            I see a point in having a common superclass as it avoids me reimplementing code like for example setting the plan version. However, I get your point for the cost center an perhaps it is better to not make it part of the inheritance and place it in a package to group the classes.

  • Hi this is a good practical example of how to used ABAP Object. I guess by reading these kind of blogs, it would be easier for us to related to the real paradigm of Object Oriented programming rather than read manuals.
  • i too have seen far less OO that i would expect, outside SAP coding, itself. i believe it is the old skool developers that have failed to lever the power of OO by learning the new concepts. it would be a milestone to see more OO, let alone a design with inheritance etc. before you know it, ABAP will be out and Java in (only kidding)
  • I surely hope you do not have many custom codes with select * from PA0001.  By-passing HR authorizations is not a good practice.  It would be wiser to use an SAP HR function module.

    But, I am detracting from the main topic of your blog.  Yes, I agree that I would like to see more OO ABAP outside of SAP.  It is definitely slow to be adopted by customers.

    • Hi Raja,

      thanks. I am planning to write two additional blogs related to this topic.

      The second blog will elaborate on the layered architecture. The business layer and utility layer are going to be enhanced with a process layer and a UI layer. An example from each layer will help clarify their purpose.

      The third blog is a deep dive into selected methods and will contain more coding examples.

  • Good work.  At State of Louisiana (USA), we have many custom ALV reports that do not use the PNP due to it's slowness and size. 

    While the reports have standard select-options, like PERNR, BEGDA, ENNDA, and WERKS, each report has other fields specific to the business need.  We usually report by all PERNRs in WERKS.  How would using the class benefit me?  

    • Hi Steven,

      from a design point of view, I would suggest you to create a subclass ZCL_HR_PERSONNEL_AREA of ZCL_HR. I believe the object type is 'IZ'. In class ZCL_HR_PERSONNEL_AREA add method GET_EMPLOYEES returning a collection of ZCL_HR_EMP objects. Class ZCL_HR_EMP should contain attributes with appropriate methods to suit the sum of your reporting needs.

      • ... and how would it benefit you?

        It is difficult to be specific here ...  however, to start with I guess it will help you reuse code in your reports. If one day you decide to use the functionality somewhere else than SAP GUI ALV, then you have a framework that can be easilly called from various places (Web Dynpro, Web Service, and so on). When new developers join your team you can ask them to have a look at your class library to start with ...

  • I do agree that any modern abaper should use OO programming but your example of relations between HR objects is not exactly the best example

    in order to get relations between HR objects you should use evaluation paths - this is the standard way to do it and it is pretty efficient

    your utility class is used mainly to get texts about objects, there you could have used a very good example of OO programming by using class CL_TEXT_IDENTIFIER which is able to return texts for a lot of fields

    all in all your post is useful but you should not go too far with OO for processing of PD while it can be very useful in PA (for example to check attributes of an employee against several infotypes)

    • Hi François,

      thanks for your comments. I fully agree that you should use the standard concept as far as you possibly can. The class library skeleton is thought to be a structured way to write the custom code you would have written anyway. Regarding the utility class - I repeat - use standard whereever possible. If CL_TEXT_IDENTIFIER suits your need, do not implement any custom code. However, if you have special needs for texts then it could be an idea to place that code in a utility class.

      I will keep your comments in mind in my future programming.

      • From my perspective, I do not see how the class library clashes with the evaluation path concept?

        I am curious how you did interpret the class library.

  • Very nice and practical blog. One comment I might add is to (potentially) consider the application of the strategy pattern as this class library continues to expand. This keeps the depth of your inheritance tree manageable over time. For example, underneath the ZCL_HR_PERSON branch, the subclasses start to get very specific. Here, is there a way to factor some of this specialization into a separate class? Of course, only intimate knowledge of the HR domain can tell you this, but the general rule is to "find what varies and encapsulate it". That way, your OO design remains flexible in the event that you need to deal with various other types of HR person-types.