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)

Trigger Looply from SAP Workflow

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.