Triggering or Resuming a Looply Workflow from SAP
Triggering a Looply Workflow
You can trigger a Looply Workflow (your Workflow must start with an Event Trigger step - see the Triggering Workflows page for more information) from SAP by calling the following method:
/LOOPLY/CORE=>TRIGGER_WF
The method has the following parameters:
| Parameter Name | Type | Mandatory | ABAP Type |
|---|---|---|---|
IM_LOOPLY_WF | Import | CHAR36 | |
IM_LOOPLY_WF_VERSION | Import | INT1 | |
IM_RECIPIENT | Import | CHAR241 | |
IM_SCENARIO | Import | CHAR2 | |
IM_SCENARIO_ID | Import | CHAR32 | |
IM_SCENARIO_VERSION | Import | CHAR4 | |
IM_STEP | Import | NUMC3 | |
IM_PROCESS_ID | Import | CHAR36 | |
IM_DATA | Import | STRING | |
IM_UTIL_DATA | Import | STRING | |
IM_TEST | Import | FLAG | |
EX_SUBRC | Export | SYSUBRC | |
EX_MESS | Export | BAPIRET2 | |
EX_EXECUTION_ID | Export | CHAR36 |
IM_LOOPLY_WF: The ID of the Looply workflow you wish to trigger. To get the id you can click on the Event Trigger step in your Looply workflow and copy the Request URL. It will be of the following form:
IM_LOOPLY_WF_VERSION: The version of the Looply workflow you wish to trigger. If you leave this blank when making the call from SAP, the latest version of the workflow will be triggered.
IM_RECIPIENT: You can use this (optional) parameter to easily pass a recipient for a card to Looply. You can also leave this blank and pass recipients inside the data or util_data strings.
IM_SCENARIO: This (optional) parameter can be used for logging purposes or it can be passed back to SAP when making a POST request from Looply to determine which function module to run (see the Triggering SAP code from Looply page for more information). The /LOOPLY/CORE class contains a number of constants for typical scenario values.
IM_SCENARIO_ID: Optional parameter which can be used for logging purposes or it can be passed back to SAP when making a POST request from Looply to determine which function module to run (see the Triggering SAP code from Looply page for more information). Typical values include your Varo form type or SAP workflow id.
IM_SCENARIO_VERSION: Optional parameter which can be used for logging purposes or it can be passed back to SAP when making a POST request from Looply to determine which function module to run (see the Triggering SAP code from Looply page for more information). Typical values include your Varo form version or SAP workflow version.
IM_STEP: If you want to trigger multiple Looply workflows for the same scenario (the same Varo form type or SAP workflow) you can use this (optional) parameter to distinguish between them.
IM_PROCESS_ID: The process id of your Looply workflow. If you do not pass one in, Looply will assign one automatically. You need the process id if you wish to resume a workflow. Looply does not allow multiple "In progress" instances with the same process id (although you can trigger a workflow instance with the process id of a previous workflow instance which has completed) so the parameter must have a unique value. Typical values include your Varo form id or PO number. (Tip: include your system id in the process id to avoid clashes when workflows are triggered from different systems in your landscape).
IM_DATA: Data you wish to pass to your Looply worklow. This will typically be in JSON format. (Tip: you can convert your ABAP internal table or structure to a JSON string by use of method /ui2/cl_json=>serialize).
IM_UTIL_DATA: Second data string you may pass to the workflow.
IM_TEST: If you set this flag, a test request will be made to Looply. The data will become available in the Workflow Studio for binding, but the workflow will not actually be triggered.
EX_SUBRC: Return subrc code indicating whether the call to Looply worked or not.
EX_MESS: Bapiret2 parameter containing success or error message.
EX_EXECUTION_ID: Id retrieved from Looply for logging purposes.
Resuming a Looply Workflow
Last updated
