Looply Academy
  • Getting Started
    • What is Looply?
    • Deployment Models
  • System Requirements
  • SAP Integration: ABAP Add-on & Access
  • Security & Identity - What IT Teams Need to Know
  • Authenticating Teams User Actions to Enterprise Systems
  • Signing Up & Onboarding Your Team
  • Looply Implementation Plan
  • Looply Integration Demos
  • Integrations
    • Microsoft Integration
    • SAP Integration
      • Installing the ABAP Looply Add-On
        • Gateway Service Setup - Single System
        • Gateway Service Setup - Hub scenario
      • Triggering or Resuming a Looply Workflow from SAP
      • Triggering SAP code from Looply
      • SAP Workflow Integration
      • Varo/Stelo Integration
      • SSL & IP address
      • SSO Authentication
  • App Management
    • Building Apps
    • Deploying apps to Teams App catalog
      • Looply Dashboard
      • Manual Installation
    • Installing Looply Apps
    • Uninstall/Update Looply Apps
    • Teams Admin center
  • Adaptive Cards
    • Building Adaptive Cards
      • Container Elements
      • Content Elements
      • Input Elements
      • Actions
    • Data Binding
    • Conditional Rendering
    • AI Assistant
    • Inline Functions
  • Workflows
    • Building Workflows
    • Triggering Workflows
    • Environment Variables & Profiles
    • Versioning Workflows
    • Using HTTP Requests
    • Using Functions
    • Using Conditionals
    • Using Branch Conditionals
    • Using Advanced Conditionals
    • Using Integrations
      • Adaptive Card Actions
      • SAP Requests
    • Using Redirects
    • Using Override Payload
    • Terminating Workflows
  • Data Vault
    • Variable Datastores
  • Monitoring & Logs
    • Monitoring Workflows
    • Error Notifications
  • API REFERENCE
    • Developer API Overview
    • Workflow API
    • Adaptive Card API
  • Team Management
    • Managing Organisations
    • Team Roles and Permissions
  • Resources
    • JavaScript Libraries
  • Tutorials
    • Creating MS Teams Apps
    • Designing Workflows
    • Building Adaptive Cards
    • Adaptive Cards with AI
    • Examining Workflow Executions
  • Support
    • Changelog
    • Contacting Support
Powered by GitBook
On this page
  • Triggering a Looply Workflow
  • Resuming a Looply Workflow
  • Process Determination Configuration
  1. Integrations
  2. SAP Integration

Triggering or Resuming a Looply Workflow from SAP

PreviousGateway Service Setup - Hub scenarioNextTriggering SAP code from Looply

Last updated 9 months ago

Triggering a Looply Workflow

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:

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_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.

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)

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).

Triggering Workflows page
https://api.looply.io/v2/workflows/triggerworkflow/<looply workflow id>/<looply workflow version>?test=true
Triggering SAP code from Looply
Triggering SAP code from Looply
Triggering SAP code from Looply
resume a workflow