Main Architecture Description

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.

Getting Started

SQL Server Hosting Options

Last modified 2yr ago

Copy link

On this page

Overview

WorkflowGen services

Web applications

Windows Services

File storage

Database container and storage

SMTP service