SAP Workflow Integration
Set-up
In order to integrate Looply with SAP workflow, you must first create a standard task: In transaction PFTC select "Standard task" as the Task type and click on the Create button:
Enter an Abbreviation, Name and Work item text. Select "ABAP Class" from the Object Category dropdown and enter "/LOOPLY/WF_OUT" as the Object Type and "TRIGGER" or "RESUME" depending on whether you wish your standard task to trigger or to resume a Looply workflow. (You may of course create both a Trigger and a Resume task). Select the Background processing checkbox and click Save. Click on Yes in the pop-up to transfer missing elements from the object method. Next, select the Background processing checkbox and Save. Make a note of the number assigned to your standard task:
The task only needs to be created once. It can then be used any number of times in different (or in the same) workflow(s).
Triggering a Looply workflow from a SAP workflow
In transaction swdd, add a new activity to your workflow, and enter the number of your newly created task to the Task field, preceded by TS (for example TS90000004) and press Enter. Dismiss the "Define Container Elements and Binding" pop-up as this will create unwanted fields in your container and instead perform the binding manually. You may bind data from your workflow (or pass in static-hardcoded values) to the following fields:
| Parameter Name | Type | ABAP Type | Description |
|---|---|---|---|
IM_WFD_ID | Import | SWD_WFD_ID | Use to pass in the workflow id. This will then be used to read the "Process Determination" configuration for a matching Scenario Id to determine which Looply workflow to trigger. |
IM_WF_VERSION | Import | SWD_VERSIO | You may have multiple versions of the same SAP workflow and wish to trigger a different Looply workflow depending on the SAP workflow version. Use this field in order to achieve this. Please note that using the field is optional but it's value must match the value in the "Process Determination" configuration |
IM_STEP | Import | /LOOPLY/STEP | You may wish to trigger different Looply workflows at different points of the same SAP workflow. Use this field in order to achieve this. Please note that using the field is optional but it's value must match the value in the "Process Determination" configuration |
IM_WORKITEMID | Import | SWW_WIID | Can be used to pass in the workitem id. This can then be used to get data from the workflow container using function SAP_WAPI_READ_CONTAINER |
IM_REC_UNAME | Import | SWF_STRING | Not actually passed to Looply. Used in here in case you want to get data for a certain SAP user |
IM_REC_EMAIL | Import | SWF_STRING | Can be used to send a card to a certain user (of course you can bind the recipient to any field in the data you like on the Looply side) |
IM_DATA | Import | SWF_STRING | Can be used to pass in any (string) data from the workflow container |
IM_PROCESS_ID_T | Import | /LOOPLY/PROCESS_ID_T | Table of process ids of the Looply workflows that will be triggered (see below for more details) |
IM_IGNORE_ERRORS | Import | FLAG | If this flag is not set, any potential errors that occur while triggering Looply will raise an exception and stop the workflow execution. Setting this flag will ignore errors so that the workflow execution continues to the next step |
EX_DATA | Export | SWF_STRING | Use to pass back any (string) data to the Workflow container |
EX_PROCESS_ID_T | Changing | /LOOPLY/PROCESS_ID_T | Table of process ids of the Looply workflows that have been triggered (see below for more details). You may want to pass this to the workflow container so that you know which Looply workflows to resume at a later stage |
As part of the standard task to trigger Looply, core method /LOOPLY/WF_OUT=>TRIGGER will be triggered. The method will read the "Process Determination" configuration based on the values of IM_WFD_ID, IM_WF_VERSION and IM_STEP passed in above to determine which Looply workflow to trigger and a Z-function which will be called to get the data to be passed in to the workflow. You can create such a function by copying sample function /LOOPLY/SAMPLE_WF_TRIGGER. Based on the binding done in the workflow step above, the following parameters will be available in the function:
| Parameter Name | Type | ABAP Type | Description |
|---|---|---|---|
IM_WORKITEMID | Import | SWW_WIID | Passed in from binding parameter |
IM_DATA | Import | SWF_STRING | Passed in from binding parameter |
EX_CONT_DATA | Export | SWF_STRING | Passed back to binding parameter EX_DATA |
EX_SUBRC | Export | SYSUBRC | Assuming parameter IM_IGNORE_ERRRORS of the standard task has not been set to X via the binding, setting a subrc != 0, will cause an exception to be raised |
EX_MESS | Export | BAPIRET2 | When the exception is raised you can use this parameter to insert a certain message in the workflow log |
CH_LOOPLY_DATA | Changing | /LOOPLY/TRIGGER_DATA_T | (see below) |
Table CH_LOOPLY_DATA can be pre-filled by the SAP workflow via the binding with one row for every row in the process id table IM_PROCESS_ID_T. If IM_PROCESS_ID_T is not bound to anything or left blank, CH_LOOPLY_DATA will still be pre-filled with a row (with a blank process id) assuming binding parameters IM_RECIPIENT_EMAIL or RECIPIENT_UNAME are not blank. The table can be edited inside the Z-function, after which, one Looply workflow will be triggered for each row of the table with the relevant data. The table contains the following fields:
| Field Name | ABAP Type | Description |
|---|---|---|
PROCESS_ID | /LOOPLY/PROCESS_ID | The process id of the Looply workflow that will get triggered. Note that you can only have one active workflow per process id |
RECIPIENT_EMAIL | AD_SMTPADR | Can be used to send a card to a certain user (of course you can bind the recipient to any field in the data you like on the Looply side) |
RECIPIENT_UNAME | STRING | Not actually passed to Looply. Used in here in case you want to get data for a certain SAP user in your function |
DATA | STRING | Data string we pass to Looply. You can use method /ui2/cl_json=>serialize to convert an internal table to a json string if needed |
UTIL_DATA | STRING | Second data string in case you'd like to pass a second/separate string to Looply |
Please note that filling in any of the above fields is optional. You can if you wish trigger a Looply workflow without passing in any data and without a process id (Looply will automatically assign a process id in this case)
Resuming a Looply workflow from a SAP workflow
You may also wish to resume a Looply workflow from your SAP workflow - you may have sent out a request for approval that should now be escalated, edited, or deleted for example. The mechanism for doing so is very similar to the mechanism for triggering a workflow. You must first add an activity to your workflow which points to a task that calls method /LOOPLY/WF_OUT=> RESUME (instead of /LOOPLY/WF_OUT=> TRIGGER). The fields available for binding will be slightly different in this case:
| Parameter Name | Type | ABAP Type | Description |
|---|---|---|---|
IM_WFD_ID | Import | SWD_WFD_ID | Use to pass in the workflow id. This will then be used to read the "Process Determination" configuration for a matching Scenario Id to determine which Looply workflow to trigger. |
IM_WF_VERSION | Import | SWD_VERSIO | Use to determine the SAP workflow version. Please note that using the field is optional but it's value must match the value in the "Process Determination" configuration |
IM_STEP | Import | /LOOPLY/STEP | You may wish to include different "Resume Looply Workflow" steps workflows at different points of the same SAP workflow. Use this field in order to achieve this. Please note that using the field is optional but it's value must match the value in the "Process Determination" configuration |
IM_WORKITEMID | Import | SWW_WIID | Can be used to pass in the workitem id. This can then be used to get data from the workflow container using function SAP_WAPI_READ_CONTAINER |
IM_REC_UNAME | Import | SWF_STRING | Not actually passed to Looply. Used in here in case you want to get data for a certain SAP user |
IM_DATA | Import | SWF_STRING | Can be used to pass in any (string) data from the workflow container |
IM_PROCESS_ID_T | Import | /LOOPLY/PROCESS_ID_T | Table of process ids of the Looply workflows that will be resumed (see below for more details) |
IM_IGNORE_ERRORS | Import | FLAG | If this flag is not set, any potential errors that occur while triggering Looply will raise an exception and stop the workflow execution. Setting this flag will ignore errors so that the workflow execution continues to the next step |
EX_DATA | Export | SWF_STRING | Use to pass back any (string) data to the Workflow container |
EX_PROCESS_ID_T | Changing | /LOOPLY/PROCESS_ID_T | Table of process ids of the Looply workflows that have been resumed (see below for more details). You may want to pass this to the workflow container so that you know which Looply workflows to resume at a later stage |
As part of the standard task, core method /LOOPLY/WF_OUT=>RESUME will be triggered. The method will read the "Process Determination" configuration based on the values of IM_WFD_ID, IM_WF_VERSION and IM_STEP passed in above to determine a Z-function which will be called to determine which workflows to resume, as well as the data to pass to the Looply workflow. You can create such a function by copying sample function /LOOPLY/SAMPLE_WF_RESUME. Based on the binding done in the workflow step above, the following parameters will be available in the function:
| Parameter Name | Type | ABAP Type | Description |
|---|---|---|---|
IM_WORKITEMID | Import | SWW_WIID | Passed in from binding parameter |
IM_DATA | Import | SWF_STRING | Passed in from binding parameter |
EX_CONT_DATA | Export | SWF_STRING | Passed back to binding parameter EX_DATA |
EX_SUBRC | Export | SYSUBRC | Assuming parameter IM_IGNORE_ERRRORS of the standard task has not been set to X via the binding, setting a subrc != 0, will cause an exception to be raised |
EX_MESS | Export | BAPIRET2 | When the exception is raised you can use this parameter to insert a certain message in the workflow log |
CH_LOOPLY_DATA | Changing | /LOOPLY/RESUME_DATA_T | (see below) |
Table CH_LOOPLY_DATA can be pre-filled by the SAP workflow via the binding with one row for every row in the process id table IM_PROCESS_ID_T. If IM_PROCESS_ID_T is not bound to anything or left blank, CH_LOOPLY_DATA will still be pre-filled with a row (with a blank process id) assuming binding parameters IM_RECIPIENT_EMAIL or RECIPIENT_UNAME are not blank. The table can be edited inside the Z-function, after which, the table will contain a row for each Looply workflow to be resumed. The table contains the following fields:
| Field Name | ABAP Type | Description |
|---|---|---|
PROCESS_ID | /LOOPLY/PROCESS_ID | The process id of the Looply workflow that will be resumed |
RECIPIENT_UNAME | STRING | Not actually passed to Looply. Used in here in case you want to get data for a certain SAP user in your function |
DATA | STRING | Data string we pass to Looply. You can use method /ui2/cl_json=>serialize to convert an internal table to a json string if needed |
UTIL_DATA | STRING | Second data string in case you'd like to pass a second/separate string to Looply |
ACTION | STRING | Can be used to pass a certain action to Looply (ie Approve, Reject, Cancel) so that you can get to it easily without having to parse DATA or UTIL_DATA |
MESSAGE | STRING | Can be used to pass a (string) message to Looply |
Filling in any of the above fields is optional and depends on what data you wish to pass to your Looply workflow. If field PROCESS_ID is not filled with the process_id of a Looply workflow at a wait state however, the workflow will not be resumed. This is not treated as an error by the framework as there may be cases in your SAP workflow where it is not possible to determine whether a Looply workflow has already been resumed or not.
Last updated
