What you will learn

In this lecture we will look into how to asynchronously execute a task at a specific calculated date and time. Or, in other words, schedule a task execution at runtime to run at a later date and time.

We explore two scenarios throughout the lecture. In the first scenario we just postpone a task execution to a later date and time. In the second scenario we add the possibility to interrupt and cancel a postponed task execution by user intervention.

Prerequisites

This lecture assumes that you are already familiar with asynchronous tasks execution in OutSystems using Timers and (Light) BPT processes. If not please check out the official training course on "Asynchronous Capabilities in OutSystems" first.

https://learn.outsystems.com/training/journeys/async-capabilities-649

How to schedule asynchronous Task execution at runtime

By utilizing a Business Process OutSystems allows you to postpone a task execution to a specific date and time in two ways

OutSystems Built-In

• Using an Automatic Activity with a set Start Date value. Setting a Start Date makes the Business Process Engine to wait until the Start Date is reached before executing the actions inside the Automatic Activity.
• Using a Wait Activity with a set Timeout value. Just like the Start Date value of an Automatic Activity the Timeout value makes the Business Process Engine to wait until the configured Timeout Date and Time is reached before it continues the process flow, but it gives you greater flexibility as it also allows to interrupt the waiting time before it reaches its Timeout value.

Business Process instances that wait for either a Start Date or Timeout value switch to suspended state and do not count towards concurrent active process instances per front-end server.

Using either an Automatic Activity Start Date or a Wait Activity will always spin up a full business process instance. Even if you only have a single Automatic Activity in your process flow and configured Light BPT execution on the module. Due to the impact off full process instances, the built-in way should only be used for low volumes of scheduled processing.

External Scheduling Service

For large volumes of scheduled processing you should consider using an external service like AWS EventBridge Rules.

With EventBridge Rules you can create scheduled events, either one-time or recurring, that trigger an exposed REST API once a schedule is met. 

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html

Both ways, OutSystems Built-In or leveraging an external scheduling service do not provide second-level precision. The finest resolution you can get is between 3 seconds and up to the minute.

Scenario 1

Consider the given situation. Your application enables a user to transfer a sum of money to another user. This transaction should remain in a pending state for a duration of 15 minutes, after which it should automatically change to a confirmed state. A money transfer transaction can be initiated at any time, and it must be confirmed precisely 15 minutes post the creation of the transaction.

Scenario 2

In this scenario, we build upon our first scenario by giving users the option to cancel a pending transaction before it reaches its confirmation deadline. Should a user abort a transaction prior to this deadline, the transaction status should change to a canceled state, preventing any further processing.