Designing a Workflow Engine for nopCommerce CMS Part 7: The Process table and Shortcomings

This is Part 7 of a seven-part series describing how to implement Workflow Engine for nopCommerce CMS. Click here for Part 1

All of the infrastructure we've built so far has lead to this moment. At long last, we can build the final piece of our schema: the Process table.

Process

This table stores current StateId and some statistic information which is updated by Actions.

The Table

Let's look at the schema of the Process table:

What did we accomplish in this series?

We're trying to design a generic engine for nopCommerce CMS, one that can be used for many disparate processes, and as such the complexity of this design reflects the complexity of the requirements.

Shortcomings of This Design

There are a few shortcomings of this design:

• Currently, there's no way to say "Stay in this state for X days; after X days, move to another state." We cannot cause Entities to move along in the Workflow due to time elapsed.

• We don't currently have a way to designate that a specific individual needs to perform an Action or receive an Activity.

• It is possible that a request will need multiple things to happen before it can continue in the workflow, and we didn’t allow it by implementing the relationship between Transition and Action as many-to-one

That said, most of these shortcomings are fairly easy to implement; we actually did solve a few of them for our company's workflow engine.

Remember: this is only a models and some tables for nopCommerce CMS. The design doesn't account for how this service would actually be implemented in code.

Whew! That was a lot of steps! But what we ended up with was a generic, extensible, reusable workflow engine for nopCommerce CMS that can handle a huge variety of processes.

Thanks for reading! If you found this series helpful (or just need to yell at us for something We did incorrectly) let us know in the comments.