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:
- 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
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!
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.
DATA lo_message_list TYPE REF TO if_reca_message_list.
DATA lt_result_tab TYPE TABLE OF swhactor.
* Create message handler
lo_message_list = cf_reca_message_list=>create( ).
CALL FUNCTION ‘RH_STRUC_GET’
act_otype = iv_otype
act_objid = iv_objid
act_wegid = ‘SAP_MANG’
act_begda = iv_begda
act_endda = iv_endda
act_tdepth = 0
result_tab = lt_result_tab
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.
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.
DATA lv_objid TYPE string.
CALL METHOD super->constructor
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
iv_otype = iv_otype
iv_objid = lv_objid
iv_begda = iv_keydate
iv_endda = iv_keydate.
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.