Regelmäßig bekomme ich die Anfrage, wie unbearbeitete Inbox Items (offene Dialog Workitems) ermittelt und weitergeleitet werden können. Das kann zum Beispiel erforderlich sein, wenn eine Führungskraft ein Unternehmen verlässt und vorher nicht alle Workitems in der Inbox abgearbeitet hat. Diese sollen daher dann meistens der neuen Führungskraft zugewiesen werden. Es gibt verschiedene Wege diese Workitems zu ermitteln und weiterzuleiten.
Mit dem Fuba SAP_WAPI_CREATE_WORKLIST kann man sich den Inbox-Content zu einem User anzeigen lassen (siehe hier), meist scheitert das aber an den Berechtigungen auf der Produktion. Ist aber ein praktisches Mittel, um sich einen schnellen Überblick über die Inbox eines Users zu machen.
Geht es z.B. speziell nur um Abwesenheitsantrage, könnte man in der PTARQ schauen. Mit dem Report “Belege anzeigen” kann man dann auf die Führungskraft filtern, dazu einfach den Radiobutton “Nächsten Bearbeiter” auswählen und die Personalnummer der Führungskraft eingeben. Hier gibt es einen direkten Absprung in das Workflow-Log und man kann sich die Workitem ID des Dialogschritts über Springen → Technische Workitem-Anzeige holen, um damit in der SWIA weiterleiten zu können.
Ich nutze für diese Aufgabe aber vorwiegend die SWI5. Typ US auswählen + die User ID und weiter unten auf “Zu erledigende Workitems” stellen. Optional noch auf einen speziellen Aufgabentyp filtern.
Als Ergebnis erhält man eine Liste mit Aufgaben IDs und zugehörigen Workitem IDs. Und da es direkt die Workitem ID des Dialogschritts ist, kann man damit direkt in der SWIA selektieren und das Workitem weiterleiten.
I recently had the situation, that after a standalone Gateway System got patched, a custom app in the My Inbox app did not load anymore, when clicking on a workitem. When opening the network tab in the dev tools, you could see three requests send over and over again. It called the manifest.json, a batch request to the OData Service and some i18n.properties calls. You could also see the app files in the sources tab, which means that app had already loaded correctly but could not be displayed because it kept restarting for some reason.
Since everything worked before the system patch and the custom app wasn’t changed, it must have been related to an updated My Inbox app or to the new UI5 version, which affected the custom app.
This “repeatedly loading” was exactly my problem! And since the Gateway got patched, I guess a new My Inbox version came with it. When checking the manifest.json in the custom app, there was no async property at all. After adding "async": true to the mainfest.json, the custom app started to load successful again. Nice!
There are many reasons why a workflow task might not appear in the Inbox app. One reason I always forget to check is quite simple.
Check whether a scenario is configured!
Simply open the Tile configuration and check the Parameter field. If there is a scenario, it would be something like scenarioId=EHS_HS_HAZMAT instead of allItems=true.
If a scenario is in use, you can find more about it in the customizing here:
In a scenario, a restriction to certain workflow tasks can be configured.
Kürzlich hatte ich die Situation, dass eine Führungskraft einen Abwesenheitsantrag in der Inbox hatte für eine Abwesenheitsart, die eigentlich nicht genehmigungspflichtig ist. Es hätte also gar kein Genehmigungsworkflow gestartet werden dürfen. Merkwürdigerweise war die beantragte Abwesenheit auch bereits im Infotyp verbucht. Auch konnte man den Antrag in der Inbox weder Ablehnen noch Genehmigen, beides lief auf ein Fehler.
Wie kam es also zu dieser Situation?
Der Mitarbeiter hatte einen Antrag mit einer genehmigungspflichtigen Abwesenheitsart gestellt, wie z.B. Urlaub.
Bevor der Genehmiger diesen Antrag bearbeitet hat, wurde der Antrag vom Antragsteller jedoch nochmal abgeändert. Dies ist über das Stift-Symbol möglich. Dabei wurde dann eine nicht genehmigungspflichtige Abwesenheitsart gewählt, wie z.B. Abbau Überzeit.
In diesem Fall wird der Antrag ohne Genehmigungsprozess durchlaufen und die Abwesenheit wird kurz darauf direkt in den Infotyp geschrieben durch den Verbucherreport.
Jedoch gab es ja bereits einen laufenden Workflow mit einem Workitem in der Inbox des Genehmigers und dieser wurde nicht beendet. Stattdessen wurde in dem Workitem sogar die beantragte Abwesenheitsart aktualisiert, obwohl für diese Abwesenheitsart ja gar keine Genehmigung erforderlich ist und sogar bereits in den Infotyp geschrieben war.
Auch in der Antragsdatenbank spiegelt sich das Problem wider. Der Antrag stand dort im Status ‘POSTED‘ und der Workflow-Status auf ‘STARTED‘.
Ich habe das Szenario dann mit einer Zweiten, nicht genehmigungspflichtigen Abwesenheitsart getestet, also Urlaub erfasst und vor Genehmigung die Abwesenheitsart geändert. Hier wurde jedoch der laufende Workflow korrekterweise beendet.
Als ich beide Abwesenheitsarten in der V_T554S_WEB verglichen habe, ist mir aufgefallen, dass bei der problembehafteten Abwesenheitsart ein Workflow gecustomized war, obwohl diese ja nicht genehmigungspflichtig ist. Der Workflow wurde jedoch nur verwendet, um eine Info-Mail zu versenden.
Die Workflow Checkbox ließ sich leider nicht deaktivieren (vermutlich weil es schon Anträge zu der Abwesenheitsart gibt). Aber es scheint, als führt dieses Workflowcustomizing dann zu Inkonsistenzen, wenn in einem laufenden Antrag von einer genehmigungspflichtigen Abwesenheitsart zu einer nichtgenehmigungspflichtigen gewechselt wird.
Dieser Post nur als Erinnerung, falls ich nochmal in so eine Situation laufe. Vielleicht habe ich dann die Chance, es zu verifizieren.
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.
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.
If you want to use the decision note / action comment of a Workitem in a mail step, you have to write a method to read the comment and then pass it to the mail step. To do this, I always create a method in my Workflow helper class called READ_DECISION_NOTE with the following parameters:
For the importing parameter, you must store the Workitem ID of your Decision Step in you Workflow Container, by creating a Container Element like DecisionWIID of type SWW_WIID and fill it with the Workitem ID of your decision step. Then use it later for calling your method READ_DECISION_NOTE.
Regarding the exporting parameter; If you want to send a mail via class cl_cbs you’re a fine reading the comment as string. But if you want to use the default workflow mail step, and you are expecting comments with more than >255 characters, you will need the comment as SOLI_TAB.
If you take a look at the decision Workitem, you will properly find the Attribute ACTION_COMMENTS, which is of type SWC_VALUE and is of type char with length 255. But this is only the case, if the entered text has less than < 255 characters.
If the user entered a text with more than 255 characters, the text is split and there are more elements named with ACTION_COMMENTS_1, ACTION_COMMENTS_2 etc. (Note 3017539)
There is the function module SAP_WAPI_READ_CONTAINER to read Workitems. As input for the function module, you need the Workitem ID from the decision step. You will then find the ACTION_COMMENTS in the simple_container table.
DATA: return_code TYPE sy-subrc,
simple_container TYPE TABLE OF swr_cont,
message_lines TYPE TABLE OF swr_messag,
message_struct TYPE TABLE OF swr_mstruc,
subcontainer_bor_objects TYPE TABLE OF swr_cont,
subcontainer_all_objects TYPE TABLE OF swr_cont,
object_content TYPE TABLE OF solisti1.
" Read the work item container from the work item ID
CALL FUNCTION 'SAP_WAPI_READ_CONTAINER'
EXPORTING
workitem_id = iv_wiid
IMPORTING
return_code = return_code
TABLES
simple_container = simple_container
message_lines = message_lines
message_struct = message_struct
subcontainer_bor_objects = subcontainer_bor_objects
subcontainer_all_objects = subcontainer_all_objects.
TRY.
DATA(text) = simple_container[ element = 'ACTION_COMMENTS' ]-value.
CATCH cx_sy_itab_line_not_found.
" Check for ACTION_COMMENTS_1 etc.
" or follow the approach below
ENDTRY.
The comment is also added as SOFM-Object (SAP-Office-Document) to the Workitem. Just check the table subcontainer_all_objects, which is also returned by the previous function module, for attribute _ATTACH_COMMENT_OBJECTS (or _ATTACH_OBJECTS or DECISION_NOTE or _DECISION_COMMENT). With function module SO_DOCUMENT_READ_API1 you can then get the actual comment.
" Read the _ATTACH_COMMENT_OBJECTS element
" There can be more than one comment, just take the last one
LOOP AT subcontainer_all_objects INTO DATA(comment_object) WHERE element = '_ATTACH_COMMENT_OBJECTS'.
ENDLOOP.
CHECK comment_object-value IS NOT INITIAL.
" Read the SOFM Document
CALL FUNCTION 'SO_DOCUMENT_READ_API1'
EXPORTING
document_id = CONV so_entryid( comment_object-value )
TABLES
object_content = object_content
EXCEPTIONS
OTHERS = 1.
et_decision_note = object_content.
* Or create a single string
* LOOP AT object_content INTO DATA(lv_soli).
* CONCATENATE text lv_soli-line INTO text.
* ENDLOOP.
This SOLI_TAB can be passed to a default mail step and will keep line breaks etc.
Update 02.06.2026: A shorter approach can be the following.
Go to /n/ui2/fpld_cust and define a second target for your App, i.e. approve.
The approve target needs the “emdedIntoDetails” parameter:
SWFVISU:
Add the new target for your WF Task. Here you have access to all attributes of your Workitem-Container. Pass all your mandatory fields you’ve defined in your oData Entity.
If your missing some parameters, just add them in your Workitem Task and pass the values directly into it right from your Workflow Container. This looks much better.
Manifest:
Add a route to navigate via Inbox. The pattern has to match your inbox url.
onInit: function () {
// Model used to manipulate control states. The chosen values make sure,
// detail page is busy indication immediately so there is no break in
// between the busy indication for loading the view's meta data
var oViewModel = new JSONModel({
busy: false,
delay: 0
});
this.getRouter().getRoute("object").attachPatternMatched(this._onObjectMatched, this);
//My Inbox Integration
this.getRouter().getRoute("wfobject").attachPatternMatched(this._onWFObjectMatched, this);
this.setModel(oViewModel, "detailView");
this.getOwnerComponent().getModel().metadataLoaded().then(this._onMetadataLoaded.bind(this));
},
_onWFObjectMatched: function (oEvent) {
this.getModel("appView").setProperty("/layout", "MidColumnFullScreen");
var compData = this.getOwnerComponent().getComponentData();
if (compData && compData.startupParameters && compData.startupParameters.PERNR && Array.isArray(compData.startupParameters.PERNR) &&
compData.startupParameters.PERNR[0]) {
var sPernr = compData.startupParameters.PERNR[0];
var sDatum = compData.startupParameters.DATUM[0];
var sInfty = compData.startupParameters.INFTY[0];
this.byId("detailPage").addStyleClass("myInboxPage");
this.getModel().metadataLoaded().then(function () {
var sObjectPath = this.getModel().createKey("/DataSet", {
Pernr: sPernr,
Datum: sDatum,
Infty: sInfty
});
this._bindView(sObjectPath);
}.bind(this));
}
},
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.
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.
*---------------------------------------------------------------------------------*
TRY.
"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 ) ).
ENDLOOP.
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.
RETURN.
ENDTRY.
"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 ) ).
COMMIT WORK.
ENDMETHOD.
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.
