Handling long running operations in WEBCON - task scheduler workaround

1

Hi,
I’m looking for the best approach to handle long-running operations (potentially taking several minutes) in WEBCON BPS.

Scenario:
Suppose we need to perform time-consuming Active Directory updates based on a list of items within a WEBCON BPS workflow instance. Given the current execution time limit of 120 seconds, this may not be sufficient.

Workaround Approach:
My current solution is to use a scheduled Windows Task (created via a PowerShell integration action in WEBCON), then transition the workflow to a system step (without assigned tasks) to passively wait for the scheduled task to complete. The scheduled task retrieves its parameters either from the command line (passed during job creation) or by connecting to the BPS database. It’s essential that the scheduled job issues a PATCH API call back to the originating workflow instance to continue the process flow. Although the solution might sound complex, it has been running reliably in a production environment.

Step-by-Step Overview:
Job Creation (Step 1):
The originating workflow executes a PowerShell action to create a scheduled task, configured to start with at least a 10-second delay and set for single execution only. This delay allows WEBCON to move to the next step before execution begins.
Passive Wait (Step 2):
The workflow transitions to a system-type step (no tasks assigned), effectively waiting for the scheduled task to run.
Execution (Step 3):
The scheduled task is triggered and performs the required long-running operations, which may take several minutes or more.
Callback (Step 4):
Upon completion, the task performs a PATCH API call to the originating workflow, allowing it to continue along the appropriate path depending on the design and context.
Cleanup:
The completed scheduled task should be deleted to keep the Task Scheduler clean and avoid clutter.
Timeout Handling (Step X):
To manage exceptions or unexpected failures, you can configure a timeout using a timer action on the waiting step, which redirects to an error-handling path if the job doesn't complete within a defined timeframe (e.g., 24 hours).
Refer to the attached diagram for a high-level concept of the solution.

Advantages:
Effectively bypasses the 120-second execution limit in WEBCON BPS.
Allows complex, long-running operations to be executed as a single unit, without needing to split them into smaller chunks or repeated timer/global actions.

Disadvantages:
Adds complexity to the solution, requiring basic OS-level administration skills from the WEBCON developer.
The developer must implement and handle the PATCH API logic in the scheduled job script.
Scheduled jobs must be explicitly cleaned up after execution to avoid polluting the Task Scheduler.

Open Question:
Do you have alternative approaches for handling long-running operations in WEBCON BPS?
I would love to see native support for this use case—perhaps in the form of a special asynchronous system step—so we could handle long tasks more gracefully within the platform itself.