Triggering or Resuming a Looply Workflow from SAP
Last updated
Last updated
You can trigger a Looply Workflow (your Workflow must start with an Event Trigger step - see the for more information) from SAP by calling the following method:
/LOOPLY/CORE=>TRIGGER_WF
The method has the following parameters:
IM_LOOPLY_WF
CHAR36
IM_LOOPLY_WF_VERSION
INT1
IM_RECIPIENT
CHAR241
IM_SCENARIO
CHAR2
IM_SCENARIO_ID
CHAR32
IM_SCENARIO_VERSION
CHAR4
IM_STEP
NUMC3
IM_PROCESS_ID
CHAR36
IM_DATA
STRING
IM_UTIL_DATA
STRING
IM_TEST
FLAG
EX_SUBRC
SYSUBRC
EX_MESS
BAPIRET2
EX_EXECUTION_ID
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_STEP: If you want to trigger multiple Looply workflows for the same scenario (the same Varo form type or SAP workflow for example) you can use this (optional) parameter to distinguish between them.
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.
Looply Workflows which are at an "Awaiting Response" status can be resumed from SAP by calling the following method:
/LOOPLY/CORE=>RESUME_WF
The method has the following parameters:
IM_PROCESS_ID
CHAR36
IM_DATA
STRING
IM_UTIL_DATA
STRING
IM_MESS
STRING
IM_ACTION
STRING
IM_SCENARIO
CHAR2
IM_SCENARIO_ID
CHAR32
IM_SCENARIO_VERSION
CHAR4
IM_STEP
NUMC3
EX_SUBRC
SYSUBRC
EX_MESS
BAPIRET2
IM_PROCESS_ID: The process id of the workflow you wish to resume.
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_MESS: Often we may want to send a message to the end user when a workflow is resumed. This can easily be accomplished by using this parameter (of course messages can also be included in the IM_DATA or IM_UTIL_DATA strings).
IM_ACTION: Workflows can be resumed in a number of ways for different reasons. We might for example want to resume a workflow when a request is approved, rejected, deleted etc. This parameter can provide an easy way to distinguish between the different "resume scenarios".
IM_SCENARIO: Optional parameter used by the method for logging purposes. (see screenshot above for typical values)
IM_SCENARIO_ID: Optional parameter which can be used for logging purposes. Typical values include your Varo form type or SAP workflow id.
IM_SCENARIO_VERSION: Optional parameter used by the method for logging purposes. 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.
EX_SUBRC: Return subrc code indicating whether the call to Looply worked or not.
EX_MESS: Bapiret2 parameter containing success or error message.
Instead of passing hard-coded values into the above parameters, it is good practise to maintain and read the Looply Process Determination table (/LOOPLY/ACTIVITY). This will also help the system to keep more accurate logs of your Looply activity. The table can be maintained via the following IMG transaction: SPRO->General Application Functions->Looply->Process Determination. Here, based on your Scenario, Scenario Id, Scenario Version and Step values you can determine which Looply workflow to trigger (or which SAP function module to call in an Inbound or Workflow Outbound Scenario)
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 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 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 page for more information). Typical values include your Varo form version or SAP workflow version.
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 . 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).
