Introduction to Building Workflow Driven .NET Applications with Elsa 2
By: Sipke Schoorstra
Tags: Elsa, Workflow, Aspnetcore

The Activities

Let’s go over each activity used in the various workflows.

Get Document

A custom activity that has a single input property called DocumentId .

The document ID is used to retrieve the document record from the database. This document contains the file name of the uploaded file and is used to load the physical file into memory as a Stream .

Both the document and the file stream are then made available as the output of the activity.

Subsequent activities can then use this output. For example, the Send Email activity can be configured to send the file as an attachment.

Archive Document

A custom activity that has a single input property called Document of type Document . Notice that this is different when compared to the Get Document activity, which only needs a document ID. Therefore, these activities work together: first we load a document, and then we have activities that do something with this document.

We could have designed this activity to also accept just a document ID and have the activity load the document, but the reason we’re doing it differently here is to demonstrate that we can have activities provide any type of output such as complex objects and process them in a variety of ways.

Zip File

A custom activity that compresses an input stream into an output stream.

Update Blockchain

A custom activity that pretends it will store a file signature on some blockchain. The real purpose of this activity is to demonstrate how one might implement an activity that starts a background task using Hangfire while the workflow is suspended and then resuming the workflow once the job completed.

Send Email

An activity provided by the Elsa.Activities.Email package that can send email messages.

Fork

An activity provided by Elsa.Core that splits workflow execution in multiple branches. Each of these branches will execute one after another. A fork is typically used when you want to do work in parallel and/or if you want to wait for (one of) multiple triggers simultaneously. A common example is that of a race condition between waiting for user input within a specified amount of time and waiting for a timeout event.

Join

An activity that joins workflow execution back into a single branch. It is used in combination with the Fork activity and can have one of two modes:

Wait All

Wait Any

The Wait All mode will cause the Join activity to wait for all inbound branches to enter the Join activity. When there are no blocking activities in any of the branches, the Join activity will simply continue execution. But if there are any number of branches blocked, the activity will continue only once each blocking activity is resumed. This mode is useful for scenarios where you for example need to wait for all parties to sign a document before continuing.

This is in contrast to the Wait Any mode, which will cause the Join activity to continue as soon as any one inbound branch enters. This mode is useful for scenarios where there’s a user action to be taken within a given amount of time, a race condition modeled using for example the Timer activity and the Signal Received activity.

The Leave Request and Identity Verification both demonstrate the use of the Fork and Join activity using the Wait Any mode.

Any blocking activities between the Fork and Join activities will be cleared. This means that as soon as the Join activity continues execution, any trigger like timers and signals will no longer be handled.

Signal Received

An activity acting as a workflow trigger. When encountered, the activity will suspend the workflow until a certain signal is received. When the correct signal is received, the workflow is resumed.

A common use case is waiting for some user input to be received, as we will see.

Write Line

A simple activity provided by the Elsa.Activities.Console package. This activity takes a single string input and writes it to standard out (typically the console).

This activity is often used for testing out certain pathways in a workflow or as a (temporary) stand-in while the “real” activity is being developed.