Designing a Workflow Engine for nopCommerce CMS: Intro

Our company was developed CMS plugin to simplify process of creating new entities for nopCommerce. We are using this plugin extremely in our development process and it’s really good solution for creating new pages and templates for nopCommerce. Also we started to use it for implementing Business logic and noticed that a lot of processes were relatively similar:
Our company started thinking that, since we had so many similar processes like approvals and notifications, could we build a database-driven tool to manage all of them?
We realized that these processes were essentially finite-state machines which had a request Entity in a given State at any particular time, and which also defined how to travel from one state to another (Transitions) and what needed to happen in order to invoke that travel (Actions).
Upon further research, what we discovered was that these collections of Requests, States, Transitions, Actions, and so on had a name: they were Workflows.

What is a Workflow?

A Workflow is a series of decisions made by different people that determines what happens to a particular request that one of those people made, according to a defined and repeatable process. An example of this process is shown in this flowchart:

Example Steps in a Workflow

Let's illustrate that flow chart another way, by enumerating the steps:

1. Buyer submits a request that says "I need a product that would allow me to repair my car."
2. Buyer submits that request to Store Owner by using website, who checks that request correct and approves the request.
3. Store Owner’s approval creates notifications for vendors according to their subscriptions.
4. Vendor, who looks over the initial request and decides that they have some products which can be useful for buyer and he and his company can solve buyer issues. He create proposal for the request.
5. Vendor submit that proposal to Store Owner by using website, who checks that proposal request correct and approves the request.
6. Store Owner’s approval send notifications to buyer with orders to begin purchasing.
7. If Store Owner approves the proposal, it is marked initial request complete, and no more action can be taken against it.

Lots of Similarity

We had many different kinds of leads to develop similar workflows in our organization, and we wanted to determine if we could build a generic, database-driven service that could represent many (if not all) of these processes in one central place.
After reviewing several of the currently-existing workflows, our team discovered that they all had similar components:

• different types of entities that is reviewed, approved, or implemented by various people.
• A set of highly-variable data that was associated to each entity.
• A series of decisions (called a Workflow) that determine who was next going to review the Entity or action which should be implemented.
• A set of notifications that could go to various groups of people.
• A small number of people that were in charge of the Workflow itself.

Designing a Workflow Engine

In this series, we're going to walk through the model design of our Workflow app and show each part of the solution was implemented, and finally how they were all wired together. We're going to do this in seven parts (this post is Part 1):

• Part 1: Intro
• Part 2: The Workflow Model
• Part 3: States and Transitions
• Part 4: Actions
• Part 5: Activities
• Part 6: Security
• Part 7: The Process table and Shortcomings

This isn't the only design that can implement Workflows, and it has been simplified from our actual implemented design. But we believe that putting our design ideas down on paper (as it were) will help us understand our design better.