ABAP Objects: Custom SAP ERP HCM Class Library - E...

bjorn-henrik_zink · ‎12-07-2009

In this blog, I will provide utility class coding examples from the custom SAP ERP HCM class library. According to Wikipedia (Dec 6, 2009), "a utility class is a class that defines a set of methods that perform common, often re-used functions. Most utility classes define these common methods under static scope."

This is number 3 in a series of blogs on ABAP Objects in the context of a Custom SAP ERP HCM Class Library:

Class ZCL_UTIL

Lets start by having a closer look at the general utillity class, ZCL_UTIL. It is part of a package called ZAPI_UTIL.

The class contains methods that are static and public. They can be called without instantiating class ZCL_UTIL.

As the static and public methods represent common, often re-used functions they are candidates for functional methods in business workflow. For more information on functional methods, please read Joycelyn Darts excellent series of blogs about ABAP OO and Workflow (Using functional methods in workflows and tasks) and/or read relevant chapters in the new "Practical Workflow for SAP" book (Public SAP Mentor Webinar: Practical Workflow for SAP Book Release Celebration). In short, the utility class methods are business workflow enabled by adding the BI_PERSISTENT and BI_OBJECT interfaces. So now you probably think this is complicated? It is not. You need no business workflow knowledge. All you need to do is to active the interface methods. No additional coding required. Now your utility class methods have been business workflow enabled!

Method CHECK_MANAGER

In the previous blog ABAP Objects: Custom SAP ERP HCM Class Library - Example 1 - Class Instances, the CHECK_MANAGER method is called when instantiating a manager object of type ZCL_HR_MGR. The signature of the method is simple and contains an otype, objid, and date parameters.

Method CHECK_MANAGER calls the standard function module RH_STRUC_GET in order to determine whether or not a given user or person is a manager.

METHOD check_manager.
*
* References
DATA lo_message_list TYPE REF TO if_reca_message_list.
*
* Tables
DATA lt_result_tab TYPE TABLE OF swhactor.
*
* Create message handler
lo_message_list = cf_reca_message_list=>create( ).

CALL FUNCTION 'RH_STRUC_GET'
    EXPORTING
      act_otype      = iv_otype
      act_objid      = iv_objid
      act_wegid      = 'SAP_MANG'
      act_begda      = iv_begda
      act_endda      = iv_endda
      act_tdepth     = 0
    TABLES
      result_tab     = lt_result_tab
    EXCEPTIONS
      no_plvar_found = 1
      no_entry_found = 2
      OTHERS         = 3.
.
IF sy-subrc <> 0.
*
* Add message manager does not exist.
    lo_message_list->add( id_msgty = 'I'
                          id_msgid = zcl_util=>co_message_class
                          id_msgno = '012'
                          id_msgv1 = iv_objid ).

RAISE EXCEPTION TYPE zcx_messages EXPORTING messages = lo_message_list.
ENDIF.
ENDMETHOD.

If no exception is thrown, then the user or person is a manager.

Calling CHECK_MANAGER from classes

The following coding example is taken from CONSTRUCTOR of the ZCL_HR_MGR object.

METHOD constructor.
*
* Variables
DATA lv_objid TYPE string.

CALL METHOD super->constructor
    EXPORTING
      iv_otype   = iv_otype
      iv_objid   = iv_objid
      iv_plvar   = iv_plvar
      iv_begda   = iv_begda
      iv_endda   = iv_endda
      iv_keydate = iv_keydate.

lv_objid = iv_objid.

CALL METHOD zcl_util=>check_manager
    EXPORTING
      iv_otype            = iv_otype
      iv_objid            = lv_objid
      iv_begda            = iv_keydate
      iv_endda            = iv_keydate.
ENDMETHOD.

Exceptions thrown in method CHECK_MANAGER is not handled in the CONSTRUCTOR, but is merely passed on to the caller of the ZCL_HR_MGR object. More information, regarding the exception concept is provided in the next blog in this series.

Calling CHECK_MANAGER from Business Workflow

As mentioned above, adding the BI_PERSISTENT and BI_OBJECT interfaces to the utility class, makes it possible to reuse the functionality in business workflows. The following images shows an example of how to use utility methods in business workflow.

Create a new task and add CHECK_MANAGER method to it.

In the workflow builder you create an “Activity” step and assign the created task.

On the Outcomes tab of the activity you find the exception defined in the CHECK_MANAGER method. Activate the outcome General Exception Class by clicking on the Act./Inact. button.

A new branch when the exception is raised has been created. You can now create steps for handling exceptions.

Please be aware that often the utility class methods are wrapped especially for business workflow handling. Instead of calling method CHECK_MANAGER directly from the workflow task, a wrapper method CHECK_MANAGER_WF is created to handle exceptions in a more business workflow friendly way. For example, it could simply return a boolean parameter to indicate whether or not the object is a manager.

The next blog in this series will provide exception class coding examples.