Checkpoint
Store the state of your Process and dehydrate it.
In order to store the state of the Process, a Checkpoint shape can be used. It can be either used to pause and dehydrate the Process to continue it later, or simply act as a backup in case of errors or other reasons requiring a retry later.
What is Checkpoint?
Checkpoint shape is used to store the state of the Process into the Agent database and optionally pause the Process, causing the execution to halt until resumed. Resuming the Process causes the Agent to load the stored data of the Process and resume its execution as if nothing had happened in between.
If a Checkpoint shape is used but the Process execution is chosen to continue immediately, the state of the Process is still saved. This allows resuming and retrying the following execution path later on, if the Process is put to wait for a scheduled resume using Scheduled Resume shape. If an error occurs after a checkpoint, a Frends developer or IT Support personnel can also resume the Process manually from the Frends UI after the error is corrected.
Usage
Checkpoint shape can be used to store the state of the Process up to that point, and optionally to pause the execution, or allow immediate continuation of the Process. The shape can be placed anywhere within a Process between a Trigger and a Return or Throw shape, as long as there are no other branches in the Process execution that would bypass the shape.
That means that any parallel execution branches should merge back together before the Checkpoint shape, and branches from Exclusive and Inclusive Decisions should also merge back together before the Checkpoint. Alternatively, the branches should end in a Throw or Return shape to finish the Process execution before the Checkpoint is reached.
If the Checkpoint shape is used with HTTP or API Triggers, the Process should include an Intermediate Return shape before a Checkpoint shape, in order to have the Process return a response to a caller. Without Intermediate Return shape the Process would essentially always end in a timeout from the caller, if it would pause the execution for possibly extended periods of time.
Once added to your Process, you should define the Checkpoint shape's parameters for whether to continue the execution immediately and for how long is the Process state being stored in the Agent database. You can also assign a value to act as the Correlation ID for this specific Checkpoint, which is used with Signal Resume shape to remotely resume the Process from another Process.
Architecture
Instead of storing all of the Process data up to a Checkpoint shape, the shape stores only the necessary data for continuing the Process later on, into the Agent database. If some data from the Process before Checkpoint shape is not used after the Checkpoint shape, it will not be stored. While this lessens the data storage required, it will still consume some storage space for each paused Process Instance for the defined time to live or until the Process execution completes.
Correlation ID is used as the key to the stored state within the database, and when Signal Resume shape or other resume methods are used, Agent is responsible for querying the stored Process state with the provided Correlation ID and resuming the Process execution.
As the Process states are stored to a non-volatile data storage, it is possible for the Agent and/or the Frends Core to be unavailable without losing the data. It should be noted however that resuming the Process is not possible while the Agent is down. If the Agent database is reset or cleared, any stored data will be lost unless backed up, making resuming any existing Process Instances impossible.
Every time a Checkpoint shape is reached in a Process will mean that the Process's data is serialized as JSON, and once the Process resumes, the data is deserialized back to usable format for the Process. This serialization and deserialization cycle also occurs when the Checkpoint shape is set to continue execution immediately, and it can have significant performance impact if excessive number of Checkpoints are used in a Process.
Any paused Processes are resumed on the same Agent as where the execution started in. In case a High Availability configuration is in use, it is not possible to switch the executing Agent while resuming a Process.
Configuration
To set up a Checkpoint shape, add the shape to Process canvas and connect it as part of your Process. After that, you can configure the parameters for the shape.
The following configuration parameters are available for Checkpoint.
Display name
Shapes can be given a display name in Frends Processes to distinquish them from each other. Shape's display name has no technical purpose and is only for documentational and visual purposes only. For shapes returning a #result reference value, the display name can be used to specify which result is meant.
Display name is given to the shape by double-clicking it on the canvas or through its configuration parameters.
Correlation ID
String value to reference the dehydrated data by this Checkpoint shape. Other Processes can use this same value with Signal Resume shape to resume a Process from the Checkpoint, if it is paused.
Time to Live
Numerical field that specifies the storage time for the stored data. Value is specified in minutes.
If this time is exceeded while the Process is paused, the Process context will be discarded and the Process will be reported as failed, effectively immediately finishing the Process execution.
Continue Execution
Toggle switch to select whether the Process will dehydrate at this Checkpoint, pausing its execution until resumed later, or if the execution will continue after the Process state is stored.
Reference Values
Checkpoint shape provides a #result reference value, which contains its result values.
#result
#result reference value can be used to access earlier shape's return value. For Scope shapes, the value is specified using Return shape, while for Task's the #result is populated directly by the Task.
When Return shape is used to end Foreach or While shapes, the expression or HTTP content values in Return shape are available through #result reference value as an array of values for each iteration.
#result reference value by default references the last Task's or Scope shape's return value. Instead of unnamed #result reference, you can also use named #result reference value.
Named #result
Named #result reference value is used with square brackets, much like dictionary's or object's fields would be used, such as #result[Handle elements] or #result[HTTP Request]. This way it can be specified which shape's result you are using.
When using named #result reference value with Scope shapes and Return shapes, it should be noted that the #result reference value is named by the Scope shape and not by the Return shape, although the value is specified in the Return shape. Thus, when using the named #result value, such as #result[Handle elements], the Scope shape's name should be used.
#result.HydrationPoint (String)
Internal ID of the Checkpoint shape where the execution resumed from.
#result.CorrelationId (String)
Defined Correlation ID for the Checkpoint.
#result.TriggerId (String)
Internal ID of the Trigger that started the Process originally.
#result.Variables (JObject)
Object containing the stored values and their data types from the Process before the Checkpoint, that are used in the Process after the Checkpoint.
Only values that are actually used in the Process after the Checkpoint are stored and displayed here. Defined values from earlier in the Process that are not used later on will not be stored.
#result.OriginalProcessStartTimeUtc (String)
Timestamp when the Process originally was started, in format yyyy-MM-ddTHH:mm:ss.ffffff.
#result.Iteration (Int)
Current number of iterations done from the Checkpoint.
Last updated
Was this helpful?