Overview

This section contains details on the recommended architecture to use when deploying WorkflowGen for Docker. The following schema illustrates all of the components in action:

As shown, all runtime components are inside one or more Docker hosts. You can use as many web application containers as you want for higher availability and better performance, but you can only have one instance of each WorkflowGen Windows Service. You also don't have to use the database container; if you want, you can externalize the database to a cloud provider such as Azure SQL or your own on-premise SQL Server.

As usual, you can configure the SMTP service that you want to use with WorkflowGen's container. There is no special setup needed for this.

All persistent data is externalized. The licenses used for WorkflowGen, the application data (App_Data), and the workflow applications (wfapps) are all persisted into a distinct shared space (wfgdata in the diagram). For example, this could be a file share, an Azure Files file share or Azure Disk disk, or any other service that is capable of acting as directory on a Docker host.

As well, in this diagram, the database files are in a Docker volume. This volume should be a disk, such as a local disk on the Docker host whose backups you can control, or something like an Azure Disk disk so that you can take snapshots. In the case of the database, it's important to have a disk to maintain good performance. For optimal results, you should externalize the database. See the SQL Server Hosting Options page for more details.

WorkflowGen services

This section describes each of the WorkflowGen container's runtime environments. Keep in mind that all environments are packaged in a single image.

Web applications

When you run the container's web applications, the following components are running:

• User Portal

• Administration Module

• All APIs:

  • GraphQL

  • SOAP

  • SCIM v2

  • Webhooks

  • OpenID Connect authentication

• ASP.NET web forms

• Workflow applications (.NET assemblies)

These are all of the components that you need to make every web service and graphical interface work.

Windows Services

When you run the container's Windows Services, the following components are running:

• Directory synchronization service

• Engine service

File storage

These are shared spaces between the containers where data that should be persistent and that can't be in the database are located. A shared space for WorkflowGen licenses is required because a license can't be stored directly into an image. Instead, it's retrieved at runtime from the container and placed at the correct location inside the container.

The WorkflowGen App_Data folder should be shared between the containers. It contains the following pieces of information that WorkflowGen needs to work properly:

• Design time process files

• Runtime process files

• Log files

• Workflow application temporary files

• Customized User Portal menus

• Process templates

• Mail templates

The wfapps IIS web application is also shared among the containers because the web forms contained at this location are ASP.NET files generated at design time; this is why they're considered as storage. The App_Data and wfapps folders are grouped in the same shared space called wfgdata.

Database container and storage

In this architecture, the WorkflowGen database is containerized and its data is stored in a shared space, preferably backed by a high performance disk as well. You can add other containerized databases as read replicas with their own shared space for their data. For more details about the database container or database management with containers, see the SQL Server Hosting Options section.

SMTP service

WorkflowGen relies on an SMTP gateway to send email notifications. A SMTP server or service with a low network latency and a high availability is recommended.