Homelab, Linux, JS & ABAP (~˘▾˘)~

[HR] TMW – Time-Manager-Workplace BAdI

Transaktion: PTMW

Badi Implementierung anlegen und Filter-Ausprägungen hinzufügen. Es muss für jede benötigte Filter-Ausprägung eine eigene BAdI Implementierung und Klasse angelegt werden.

Klasse anlegen und in der Interface Methode die Kundenlogik, wie in der Dokumentation empfohlen, in eine private Methode kapseln.

  METHOD if_ex_pt_blp_user~process_data.

    CHECK i_record IS BOUND.

    IF  i_record->data->category = cl_pt_tmw_tdm_const=>cat_infty
    AND i_record->data->type     = '2001'.

      "hier die erforderliche Logik rein, z.B. weitere Prüfungen
      process_it2001( EXPORTING i_record    = i_record            " Aktueller Satz
                                i_time_data = i_time_data         " Aktuelle Zeitdaten
                      IMPORTING e_messages  = e_messages          " Ausgabemeldungen für die Transaktion
                                e_time_data = e_time_data   ).    " Neue und geänderte Daten

      "An den konkreten Infotypsatz kommt man z.B. folgendermaßen:
      DATA(record_data) = CAST cl_pt_td_it2001( i_record->data ).
      DATA(p2001)       = record_data->if_pt_td_it2001~p2001.



[HR] Infotype – add PBO or PAI logic

There are many ways to add custom logic when processing an Infotype. Here are just a few:


ZXPADU01 – when an infotype is called
ZXPADU02 – when an action is performed on an infotype



  • HRPAD00INFTY (method IN_UPDATE) is called by the old infotype framework (PA30, SAP50UPR)
  • HRPAD00INFTYDB (method UPDATE_DB) is called in the decoupled infotype framework

BAdI: HRPAD00INFTY – Verbucher / Infotyp-Pflege

This image has an empty alt attribute; its file name is image-1.png
This image has an empty alt attribute; its file name is image-2.png

BAdI: HRPAD00INFTYDB – HR: Stammdaten, Infotype DB Update Logik

“The BAdI is called, after the decoupled infotype framework writes the infotype data to the database. This is done during method FLUSH.”
Note: The Infotypes 2000-2999 are not decoupled yet! More here and here.


[Fiori] Send notification mail if workitem is forwarded in MyInbox

Workitem function modules

If you forward a workitem manually from the MyInbox or via function module SAP_WAPI_FORWARD_WORKITEM, the function module SWW_WI_FORWARD will be called. There the SAP implemented a BAdI call of the BAdI WF_WI_FORWARD.


The BAdI provides a method to add additional checks, when forwarding a workitem. I will use it, to send notification mails.

BAdI Filter

Create your own BAdI implementation and add a task id as filter. In my case it’s the task TS21500003 of the leave request approval workflow.
Now your implementation will only be called, if this specific workitem is forwarded. Now we implement the method CHECK_BEFORE_FORWARD. The method has enough parameters to get all necessary information to enrich the mail text.


First the workitem container is read out of the context. There we get the _WI_OBJECT_ID element, which contains the request object reference. With this information we are able to get the current request object out of the workflow. I pass this into antother class where I already have a mail sending implementation.

  METHOD if_ex_wf_wi_workitem~check_before_forward.
* This BAdI implementation is used to send an info mail when a workitem is forwarded.


        "Get workitem container and requestId
        DATA(container) = im_workitem_context->get_wi_container( ).

        container->get_value_ref( EXPORTING name       = |_WI_OBJECT_ID|
                                  IMPORTING value_ref  = DATA(lr_req_id) ).

        ASSIGN lr_req_id->* TO FIELD-SYMBOL(<lpor>).

        "Get current request object
        DATA(lo_req) = NEW cl_pt_req_wf_attribs( )->bi_persistent~find_by_lpor( lpor = <lpor> ).

        "Send an info mail to each new agent (should be only one)
        LOOP AT im_table_new_agents INTO DATA(new_agent).
          zcl_hcm_leave_request_assist=>send_mail( io_req         = CAST cl_pt_req_wf_attribs( lo_req )
                                                   iv_tdname      = mc_mailtext
                                                   iv_pernr       = cl_hcmfab_employee_api=>get_instance( )->get_employeenumber_from_user( iv_user = new_agent-objid ) ).

      CATCH cx_hcmfab_common.
      CATCH cx_swf_cnt_elem_not_found.
      CATCH cx_swf_cnt_container.
        "In error case, do nothing. The workitem should still be forwarded.

    "Write Info to WF Log
    MESSAGE s001(00) WITH |Forward: Mail { mc_mailtext }| INTO DATA(lv_message).
    im_workitem_context->set_message_to_log( im_function = CONV #( lv_message )         "max char30
                                             im_message = VALUE #( msgid = sy-msgid
                                                                   msgty = sy-msgty
                                                                   msgno = sy-msgno
                                                                   msgv1 = sy-msgv1 ) ).

At the end I’m writing a little notification in the workflow log. The workitem context provides the method set_message_to_log for this. The log will look like this.

[Fiori] Leave Request Approval Steps with Custom Workflow

If you want to copy the standard workflow of the leave request approval process (WS12300111) and are adding another approval step (or you just want to add an escalation where you set the approve workitem to obsolete and create a new approval step for the next approver) you have to implement the following BAdI. In detail you only have to add the new step ID in the filter, else the approver will not see any approval or reject buttons in his inbox. See details here.


Default implementation: HCMFAB_LEAVE_APPROVAL_INBOX
Default Workflows and Step ID’s
Add your custom workflow and the custom approval step id in your own BAdI implementation

As second step you have to add the Workflow in the customizing. You’ll find further information here.

Add the Workflow with Approval StepId
Add the Approve and Reject Buttons