Beim Einrichten der 1-Stufigen Genehmigung von Urlaub mit dem Standard Workflow 21500001 bin ich in folgenden Fehler gelaufen in der Inbox nach Drücken des Genehmigungsbuttons.
Merkwürdigerweise wurde der Urlaubsantrag erfolgreich genehmigt und trotzdem gab es eine Fehlermeldung. Nach kurzem debuggen war auch klar warum. Der Antrag wurde erst erfolgreich genehmigt und dann wurde das gleiche Coding nochmal durchlaufen und führte zu einer Kollisionsmeldung.
Daraufhin habe ich mir den BAdI /IWWRK/BADI_WF_BEFORE_UPD_IB angeschaut. Dort konnte ich zwei Implementierungen zum Thema Leave Approval finden und in beiden war der Workflow 21500001 als Filterkriterium eingetragen. Das erklärte, warum die Genehmigungslogik zweimal durchlaufen wurde.
Daraufhin habe ich nach einem Hinweis gesucht und folgenden gefunden: 2658528. Der beschreibt zwar eine andere Fehlermeldung, aber die Lösung war genau die Aussage, die ich gesucht habe.
Die Implementierung HRMSS_LEAVE_APPROVAL musste also deaktiviert werden. Ich habe das über die SE19 gemacht, auch wenn das bedeutete, dass ich nun als letzter Änderer eines SAP-Objekts drin stehe. Anscheinend geht es auch über den Funktionsbaustein ENH_BADI_IMG_ACTIVITY_TOGGLE wie hier beschrieben.
It took me some time to figure out, how I can provide a label for an action parameter.
I try to separate all my translations in label.cds file. This means, the annotations are not placed where the entities or actions are defined. If you have the action definition and the label annotations in one file, you could simply do the following for an action:
trip-service.cds
entity Trip as projection on db.Trip
actions {
action approval();
action rejection(reason: String @title: '{i18n>reason});
};
But if you separate both, you need to access somehow the defined action to add the annotation. Following a short snippet, how it works. The important part is, that you have to write a complete new annotation block for your actions.
trip-service.cds without label
service tripService @(requires: 'authenticated-user') {
entity Trip as projection on db.Trip
actions {
action approval();
action rejection(reason: String);
};
}
label.cds
using my.namespace as db from '../db/index';
using tripService from '../srv/trip-service';
annotate db.Trip with @title: '{i18n>trips}' {
description @title : '{i18n>description}';
status @title : '{i18n>status}';
// etc.
}
// solution
annotate tripService .Trip actions {
rejection(reason @titlel: '{i18n>reason}' )
}
You can use the SAP_WAPI_CREATE_WORKLIST function module to display all workitems that are currently in a user’s inbox. This is very useful, as you cannot use the “on behalf of” function in MyInbox.
When dealing with standard HCM Fiori Applications, it can be handy to provide custom error messages when adding additional checks. This can easily be done using the message container.
DATA(lo_message_container) = mo_context->get_message_container( ).
lo_message_container->add_messages_from_bapi( it_bapi_messages = VALUE #( ( type = 'E' message = 'This is a custom error.' ) )
iv_determine_leading_msg = /iwbep/if_message_container=>gcs_leading_msg_search_option-last
iv_add_to_response_header = abap_true ).
RAISE EXCEPTION NEW /iwbep/cx_mgw_busi_exception( ).
In the SAP Fiori Apps Reference Library, you have to select the target system on which the app is to be installed. You can choose between different major releases and also between different FPS’s.
These feature packs are smaller, targeted updates delivered between major releases of S/4HANA. To check if a Feature Pack is installed on your system, go to
System → Status → Button Product version → Tab Installed Product versions → Column SP / FTP Stack
Customizing SPRO → Personnel Management → Employee Self-Service (Web Dynpro ABAP) → Service-Specific Settings → Working Time → My Overtime Requests.
Adjusting the Fiori UI
If you want to hide fields in the Fiori frontend, or you want to adjust some labels, you can simply do this via Customizing: My Overtime Requests → Layout of the Web Application → Define Field Selection
Multi-Level Approval for Time Data Requests (HRPT_B_TMD_MULTI_APPROVERS)
The BAdI is called when opening the My Overtime Request App and a second time when clicking on the New Button to create a new OVT request. It’s not triggered when sending the request, what I initially expected. To reuse the code from the sample class,
* "Determine approver level
* DATA(cust_key_request_fields) = VALUE cl_hrpt_ovt_const=>ovt_cust_key_request_fields( pernr = iv_pernr
* ktart = iv_subtype
* date = is_request_period-start_date ).
* TRY.
* DATA(approval_settings) = cl_hrpt_ovt_cust_factory=>get_customizing_reader( )->get_approval_settings( REF #( cust_key_request_fields ) ).
* CATCH cx_hrpt_tmd.
* RETURN.
* ENDTRY.
* IF approval_settings-use_multiple_approver = abap_false.
* RETURN.
* ENDIF.
....
* "If no last approvers exist, use line manager, HR BP and HR Admin by default
* CALL FUNCTION 'BAPI_GET_LINE_MANAGER'
* EXPORTING
* im_objid = iv_pernr
* IMPORTING
* es_approver = line_manager
* ev_has_manager = approver_exists.
* IF approver_exists = abap_true.
* last_seqnr = last_seqnr + 1.
* line_manager-seqnr = last_seqnr.
* APPEND line_manager TO rt_approver_tab.
* IF lines( rt_approver_tab ) >= approval_settings-approver_level.
* RETURN.
* ENDIF.
* ENDIF.
you have to set the amount of approval steps in the customizing.
Also, a Filter must be set for the BAdI:
Custom Workflow
If you want to replace the default Workflow WS02400057 (PT_OVTREQ) with a custom one, you must adjust the customizing (as described here for the standard WF), and you’ll need to create a new BAdI Implementation for /IWWRK/ES_WF_WI_BEFORE_UPD_IB analog HCMFAB_MYOTQ_APPROVAL_INBOX to get the Approve and Rejects Buttons working by providing the Workflow-ID and decision Step-ID.
Extensibility
Although it should be possible to extend both Fiori Apps via Adaptation Projects, I was unable to do so. Either it’s a problem with the new adaption editor, which got new released while writing the blog, or it is a problem with the apps itself. Whatever I tried, I was always running in issues.
Therefore, I did it the “classic” way and created an Extension Project and used the provided Extension Points. For the Approval App, I was unable to preview the application directly in BAS, perhaps because it is only an Inbox integration and does not run standalone. I therefore always had to deploy, to test my changes.
