Scriptoria uses DWKit .NET-based workflow engine to implement long-lived workflows. We chose this for the following reasons:
Our back-end was going to be ASP.NET Core
We wanted to allow the service to be run by non-programmers. So we wanted:
a. no-code solution
b. graphical workflow creation
c. form engine
Originally, the licensing cost of DWKit started at $3K/yr and has increased to $15/yr.
Here are reasons for changing the workflow:
The license maintenance cost is too much.
The handing of the service over to non-programmers never happened and will probably never happen.
When we selected DWKit, we were not web developers and we were concerned with implementing the workflow forms. We are now more experienced web developers and it isn't a problem.
We are using Svelte+SvelteKit for other web-based projects and it would be easier to maintain Scriptoria with Svelte+SvelteKit instead of React.
Upgrading the version of the workflow engine is hard due to manual database migration for features we don't use.
The version of DotNet Core we are currently using is very old (2.1). Upgrading to newer versions is a time consuming process.
There are also dependent core libraries (for jsonapi) that have significant breaking changes for 2.1 to newer DotNet Core versions.
Even with the graphical workflow, we still had to add code for the events.
The workflows haven't changed and will only have minor changed (e.g. for auto rebuilds).
Hosting the workflow in the back-end causes problems with the back-end crashes or needs to be restarted.
The workflows can stall due to retry loops in the workflow stopping.
Plan:
We will be implementing the workflow forms in Svelte+SvelteKit.
We will be implementing the workflows in AWS Simple Workflow Service or AWS Step Functions
Scriptoria uses DWKit .NET-based workflow engine to implement long-lived workflows. We chose this for the following reasons:
Here are reasons for changing the workflow:
Plan: