Suspend and resume workflow runs

Suspend and resume workflow executions automatically.

Action

Wait for Callback
You can pause a workflow execution until an inbound event occurs.

Wait time

Wait time defines the number of days the system waits for the inbound events to occur, with a maximum limit of 25 days. The inbound event must occur within the specified wait time. If it does not, the workflow remains suspended and cannot resume. If the event occurs after the specified wait time, the system rejects the workflow resume request and marks the workflow execution as failed.

You can customize the wait time through the Execution settings link or the Workflow settings page.

Webhook URL

You can trigger the event by sending an HTTP request containing a webhook URL that includes a user-defined correlation ID or the workflow’s execution_id.

Example: https://demo.example.com/runflow/resume/a0/test

The webhook URL consists of three parts.

Base URL: https://demo.example.com/runflow/resume

Action ID: a0

Execution or Correlation ID: test

Correlation ID

You can set a custom correlation ID when you configure the Wait for Callback action. The system appends this correlation ID to the execution URL, which you can use to resume the workflow.

To set a correlation ID, follow the steps.

  1. Add the Wait for Callback action to your workflow and double-click the action icon to open it.
  2. Enter an alphanumeric correlation ID in the Correlation ID field and click Next. The Correlation ID is appended to the webhook URL displayed in the Webhook URL with correlation ID field. You can use this URL in an HTTP request to resume the workflow execution.
  3. Click Done.

Reusing correlation ID: You can set the same correlation ID for multiple Wait for Callback actions in the same workflow. Since the action ID for each Wait for Callback action differs, the system generates unique webhook URLs for same correlation IDs.

Note:
  • The correlation ID must remain unique across workflows to avoid workflow failures. If two workflows use the same correlation ID at the same position, the first workflow suspends correctly, but the second fails with an error.
  • If a user sends a request to a wait for callback webhook URL with a correlation ID before the associated workflow is suspended, an error occurs.

    To send a request to a callback URL before the workflow is suspended, use the webhook URL with the execution ID instead.

Access

You can set the webhook URL access to public or private.

Public: Under public access, the webhook URL can be accessed over a public network.

Private: Under private access, the webhook URL cannot be accessed over a public network. Two types of URLs are supported under private access:

  • Internal URL - The internal webhook URL is accessible only from within your IBM® webMethods Integration network or by IBM webMethods Integration applications across tenants.

  • Private URL - The private webhook URL is accessible only from within your privately configured network. This URL cannot be accessed from within your IBM webMethods Integration network or by IBM webMethods Integration applications across tenants.

Execution ID

The system generates the execution_id under Metadata during workflow execution and adds it to the mapped action. The system does not generate execution_id during action testing. You can copy the webhook URL displayed under the Webhook URL with execution id field and use it in an HTTP request to resume the workflow.

Stop workflow
You can manually stop the workflow execution while it is in the suspended state. This prevents the workflow from staying suspended if the callback event does not occur. To do this, click the console panel icon on the canvas, and then click Stop workflow.
Note:
  • The URL used to trigger the inbound event is secured with x-instance-api-key. Therefore, you must include your x-instance-api-key when you send the HTTP request with the URL. For more information, see Authenticating API requests
  • The duration for which the workflow remains suspended is not included in the calculation of the total transaction count for the workflow execution.
  • While designing the workflow, you cannot add the Wait for callback action before the Return Data on sync webhook action or inside the Global error handler or Loop action. Attempting to do so results in an error.
  • When you call a Wait for Callback action, the system determines the execution path by reexecuting all conditionals such as Condition blocks and Switch actions.
  • Any action that is already executed in the previous run does not execute again unless it belongs to an Error Handler path or the Global Error Handler.
  • Because the conditionals are reexecuted to determine the correct path, the workflow visualization line displays from the workflow Start button.