Call Sub Workflow

  The Call Sub Workflow construct allows a workflow to invoke another workflow as a sub-process. This helps in reusing existing workflows, modularizing business logic, and maintaining a clean, structured workflow design.

Use Cases

• Breaking down complex workflows into smaller, manageable sub-workflows.
• Reusing existing workflows in multiple parent workflows.
• Executing independent workflow logic as part of a larger process.

Subworkflows are invoked in a controlled manner within the workflow framework, ensuring reliability through built-in retry mechanisms.

Subworkflow Invocation

Subworkflows are executed inside a Workflow, supporting synchronous or asynchronous execution based on configuration.

Invocation Process

• The workflow requests execution of a subworkflow.
• The subworkflow receives input parameters and processes them.
• Execution occurs synchronously or asynchronously based on the configuration.
• The subworkflow completes execution and returns the result.

Subworkflow Implementation

Each subworkflow must be implemented as an independent, reusable function that adheres to the framework’s execution model.

Key Implementation Aspects

• Receives input data and processes it.
• Performs a specific business operation.
• Executes synchronously or asynchronously as per configuration.
• Returns an output after execution.

Retry Mechanism

To handle transient failures, sub workflows should include retry logic. The workflow framework supports automatic retries based on predefined policies, ensuring resilience.

Retry Logic Flow:

• If a sub workflow fails, it triggers the retry mechanism.
• The framework checks the retry policy.
• A retry attempt is scheduled based on configured intervals and backoff strategies.
• The sub workflow retries until either success or the max retry attempts is reached.
• If max attempts are exceeded, the sub workflow is marked as failed.

Subworkflow Execution Flow

• A workflow initiates a sub workflow.
• The sub workflow executes synchronously or asynchronously based on configuration.
• The result is returned to the workflow.
• The workflow continues workflow execution based on the sub workflow outcome.

Steps to Add a Sub Workflow Construct

 

Step 1: Drag & Drop the Construct

1. Open the Logic Flow Designer Canvas.
2. Drag and drop the Sub Workflow construct into the flow.

Deploy Identity Server

1. Double-click the construct to open its properties panel.
2. Configure the required properties:

Sub Workflow Properties

Property	Description	Comments
Label	Labels help developers quickly understand each step in the logic flow without examining the details of the construct.	It is recommended to provide a simple precise label that improves the logic flow readability.
Workflow Name*	Specifies the name of the sub workflow.	Must match the registered workflow name.
Workflow Version*	Defines the version of the sub workflow, which is dynamically updated based on the selected workflow name.	Required for versioning selection.
InstanceId*	Unique identifier for the sub workflow instance.	An Instance ID in a workflow is a unique identifier assigned to each execution of a workflow. It helps track, manage, and reference a specific workflow execution independently of others.
Input	Input parameters passed to the sub workflow.	Includes all necessary input values when the called workflow has inputs.
Execution Mode	Specifies execution as Sequential or Async.	Determines execution behavior.
Activity Handle*	Unique identifier required if execution mode is Async.	Required only for async execution. Activity Handle is used to track and manage asynchronous calls. Since asynchronous operations do not return responses immediately, the Activity Handle acts as a reference to monitor the execution and retrieve results when available. The response can be accessed later by explicitly awaiting the Activity Handle. e.g response = await CallApprovalWorkflowActivity
Output Mapping	Maps relevant data elements within the flow if Sequential mode is used.	This data type matches the output of the called workflow.
Enable Retry	Indicates if retry logic is enabled (YES/NO).	Helps handle transient failures.
RetryOptions	Configurable retry policies (attempts, delays).	Optimizes failure handling.
Comment	Specify whether to comment this construct or not. Either Yes or No.	If marked as Yes, the construct is treated as a commented expression and ignored in code generation.
Description	A brief explanation of the Sub Workflow purpose.	Helps users understand the Sub Workflow functionality.

Retry Options Sub-Properties

Property	Description	Comments
First Retry Interval	Initial delay before the first retry attempt.	Prevents immediate repeated failures.
Max Retry Interval	Maximum wait time between retries.	Ensures retries do not extend indefinitely.
Backoff Coefficient	Increases retry intervals exponentially after each attempt.	Reduces system overload.
Retry Timeout	Maximum time allowed for all retries.	Ensures timely resolution.
Max Number of Attempts	Limits retry attempts before marking failure.	Prevents excessive retry loops.
Exception Handler	Defines how exceptions should be managed.	Ensures proper error handling.

'Note: ' + ($args[0].Groups[1].Value -replace '\r?\n', ' ')