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:

https://api.looply.io/v2/workflows/triggerworkflow/<looply workflow id>/<looply workflow version>?test=true

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 for example) 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

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:

Parameter Name	Type	Mandatory	ABAP Type
IM_PROCESS_ID	Import		CHAR36
IM_DATA	Import		STRING
IM_UTIL_DATA	Import		STRING
IM_MESS	Import		STRING
IM_ACTION	Import		STRING
IM_SCENARIO	Import		CHAR2
IM_SCENARIO_ID	Import		CHAR32
IM_SCENARIO_VERSION	Import		CHAR4
IM_STEP	Import		NUMC3
EX_SUBRC	Export		SYSUBRC
EX_MESS	Export		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.

Process Determination Configuration

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)