Integration tips
If you're looking for guidance on integration, you need to read this article.
Overview
When it comes to integrating a more or less complex component into an existing system, several questions immediately arise regarding how to do it better. Workflow Engine is well-suited for integration into both existing and new projects. In fact, when Workflow Engine was initially designed, it was envisioned as a library specifically tailored for existing solutions.
In this article, we will discuss some of the most common methods for integrating a Workflow Engine. It's important to note that there is no one-size-fits-all solution. What works best for your application may not be the best solution for someone else's. So, it's essential to consider your specific needs and goals when choosing an integration method.
Workflow Engine components
Workflow Engine consists of several components that can be integrated into your application. The main components are:
- Workflow Engine (nuget packages) - the core of the Workflow Engine, responsible for executing processes.
- Workflow Designer (npm packages) - a tool for creating process schemas.
- Workflow Engine Database - stores process schemas, processes, timers, process parameters, and everything needed to process processes.
Example of a simple architecture
Backend picture
Database picture
Database
The Workflow Engine stores process schemas, the processes themselves, and everything needed to process processes in a database. Workflow Engine supports the following databases: Microsoft SQL Server, Azure SQL, Azure SQL Managed Instance, PostgreSQL, MongoDB, Azure Cosmos DB, MySQL, Oracle, SQLite. A description of the objects used for the Microsoft SQL Server database can be found here.
The first decision to make is which database to use for storage. We recommend choosing the database you are most familiar with. If you don't use a cloud solution, you will need a specialist to act as a DBA (database administrator).
For .NET solutions, a large number of companies use Microsoft SQL Server. While this solution has some drawbacks, it's a robust and widely used database.
We do not recommend the use of SQLite in industrial solutions.
The next decision you need to make is whether to use an existing database or deploy a new one. If you are doing a new project, then deploying a new database is probably the right decision. If, however, you are integrating Workflow Engine into an existing project, then the answer is not so simple.
For example, if your application does not yet have a system in place to manage workflows, then it is probably easier to use the existing application database, since you already have backup-restore processes set up for that database. If you already have a process management system in place, and you are considering replacing it with Workflow Engine, you will need to decide if you want to keep everything in one database or if you would prefer to split it up. One option for migration is to create a new database for the new processes and gradually transfer them over to Workflow Engine while keeping the old system running until it can be fully disabled.
If you have difficulties with the choice, we recommend using one database for both the application and Workflow Engine. The simpler, the better.
Database updates
Workflow Engine supports automatic updates of used database objects. When you update the Workflow Engine version, you can run scripts automatically, or run them manually. There is no need to run migration scripts every time the application is launched. You just need to do this once, when updating Workflow Engine version.
Workflow Designer
Workflow Designer is not an essential component for the execution of processes. You can create process schemas in one application and execute them in another, and that's perfectly fine. In fact, all you really need from Designer is an XML file with the process schema, which you can then upload to Workflow Engine. Furthermore, you can create XML workflow schemas without using Designer at all, simply by using code.
In addition, you can choose from several different types of Designers. For example, you can customize and simplify the functionality of Designer, and allow your users to design process schemas with a limited number of activities. At the same time, you may have another, fully functional Designer that is available only to system administrators.
Based on the above, choose whether you need to connect Designer to the application that executes the processes or not.
In a simple case, connect a Designer with built-in Activities to your application without any modifications. If necessary, restrict access to Designer.
Security
Workflow Engine does not have its own security system, instead Workflow Engine uses your security system. You only need to connect your security modules to Workflow Engine.
If you need Active Directory integration, this plugin might come in handy.
Actions
There are two types of actions: actions in the schema and actions in the code of your application. The main difference between them is that actions in the schema are versioned with the schema.
You should use actions in the schema when you want to version and forward the action code along with the schema, or when you want to share the schema with someone else without sharing the application code. Actions in the schema go through a compilation process that takes memory and CPU time.
In most cases, it is better to keep the action code in the application and version it along with the application releases. This will allow you to easily update the action code without having to update the entire schema with each change.
Parameters
If you need to store large amounts of data in parameters, it is worth considering using external parameters.
Single-Server or Multi-Server mode
In most cases, you will only need to use the Single-Server mode.
The Multi-Server mode is needed if your application is running in a cluster and stopping it is critical. Multi-Server allows Workflow Engine to run in a cluster, which means you can update your application without stopping (by updating the cluster nodes one after another). Also, Multi-Server allows you to distribute the load between application instances.
Multi-tenancy
Workflow Engine supports multitenancy. If you require this feature, you are likely already familiar with application architecture.
HTTP API
The current version of Workflow Engine does not have a built-in HTTP API (we are working on an implementation).
Adding an HTTP API is pretty easy, you can take a look at our tutorials series.