Designing a Workflow Engine Database Part 7: Request Actions

_This is Part 7 of an eight-part series describing how to design a database for a Workflow Engine. _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 Request Actions table.

Request Actions

So we now have Actions that Users can perform to invoke Transitions. Obviously we can’t allow for any action to be performed against the Request; only the actions we need should be allowed.

The Table

Let’s look at the schema of the RequestActions table first, and then show how it would actually be used:

Those last two columns (IsActive and IsComplete) are very important to the actual execution of this table.

Here’s how we’re going to use this table.

1. When a Request enters a State, we get all outgoing Transitions from that state. For each Action in those Transitions, we add an entry in RequestAction, with each entry having IsActive = 1 and IsCompleted = 0.
2. A User may submit an Action at any time. Each submitted Action consists of an ActionType, a RequestID, and a UserID.
3. When an Action is submitted, we check the RequestActions for the specified Request. If the submitted Action matches one of the active RequestActions (where IsActive = 1), we set that entry’s IsActive = 0 and IsCompleted = 1.
4. After marking the submitted Action as completed, we check all Actions for that Transition in that Request. If all RequestActions are marked as Completed, then we disable all remaining actions (by setting IsActive = 0, e.g. all actions for Transitions that were not matched).

#workflow engine #database

What is GEEK

Buddha Community

Designing a Workflow Engine Database Part 7: Request Actions

_This is Part 7 of an eight-part series describing how to design a database for a Workflow Engine. _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 Request Actions table.

Request Actions

So we now have Actions that Users can perform to invoke Transitions. Obviously we can’t allow for any action to be performed against the Request; only the actions we need should be allowed.

The Table

Let’s look at the schema of the RequestActions table first, and then show how it would actually be used:

Those last two columns (IsActive and IsComplete) are very important to the actual execution of this table.

Here’s how we’re going to use this table.

1. When a Request enters a State, we get all outgoing Transitions from that state. For each Action in those Transitions, we add an entry in RequestAction, with each entry having IsActive = 1 and IsCompleted = 0.
2. A User may submit an Action at any time. Each submitted Action consists of an ActionType, a RequestID, and a UserID.
3. When an Action is submitted, we check the RequestActions for the specified Request. If the submitted Action matches one of the active RequestActions (where IsActive = 1), we set that entry’s IsActive = 0 and IsCompleted = 1.
4. After marking the submitted Action as completed, we check all Actions for that Transition in that Request. If all RequestActions are marked as Completed, then we disable all remaining actions (by setting IsActive = 0, e.g. all actions for Transitions that were not matched).

#workflow engine #database

Designing a Workflow Engine Database Part 5: Actions and Activities

_This is Part 5 of an eight-part series describing how to design a database for a Workflow Engine. _Click here for Part 1

Having already defined our Process Infrastructure, our Request structure, and our States and Transitions, we can now start to design tables for what a User can actually do to a Request in this engine. For that, we will be defining two terms:

• Actions: Things a user can perform on a Request.
• Activities: Things that result from a Request moving to a particular State or following a particular Transition.

Let’s start by creating Actions and Action Types.

Actions

Actions are things a user can perform upon a Request.

Say we’ve got a request to build a new grocery store, and that request includes the address of the development where it should be built. The person who is in charge of approving new store construction, John, takes a look at the request and decides that, yeah, it’s a good idea to build a store here. He submits an Approval to the Request, which can cause the Request to go to the next state. John has submitted an Action.

Since we don’t want to allow an infinite number of kinds of actions that can be performed, we are going to group Actions together via an ActionType table that looks like this:

Just like the StateType table, this table is independent of the Process and will be considered static. For our database, we’ll use the following Action Types:

Why are we using these action types?

• Approve: The actioner is suggesting that the request should move to the next state.
• Deny: The actioner is suggesting that the request should move to the previous state.
• Cancel: The actioner is suggesting that the request should move to the Cancelled state in the process.
• Restart: The actioner suggesting that the request be moved back to the Start state in the process.
• Resolve: The actioner is suggesting that the request be moved all the way to the Completed state.

The reason we say the person is “suggesting” that the request be moved is that we want to allow for a process to require multiple Actions to invoke a Transition. It is possible that a request will need multiple things to happen before it can continue in the process, and we want to allow for that scenario.

Now we need the table for the Actions themselves. Actions are unique to Processes, and each have an ActionType, so our table will look like this:

Our design for ActionTypes and Actions looks like this:

#workflow engine #database

Designing a Workflow Engine Database Part 3: Request Details and Data

_This is Part 3 of an eight-part series describing how to design a database for a Workflow Engine. _Click here for Part 1

We now have our basic Process information defined, so we can start tackling the tables and relationships for exactly what a Request is comprised of.

Parts of a Request

In our workflow engine, a Request has these basic parts:

• Basic Info: A title, a create date, a create user, and a current state ID.
• Data: A highly-variable set of data that pertains to an individual Request.
• Stakeholders: A set of Users that are to receive periodic updates about the Request.
• Files: Any physical files that relate to an individual Request.
• Notes: Any notes entered by Users pertaining to an individual Request.
• Request Actions: The Actions that can be performed at any given time upon a Request.

We will deal with Request Actions in Part 7 of this series. For now, let’s define what makes up a Request object, starting with the basic Request table.

Request Basics

Requests are unique to Processes; a Request may only exist in a single Process. A basic Request only needs one piece of information from the User (a title) and the rest of the Request’s basic information comes from how the Process is laid out. Our Request table will look like this:

• Title: The title of the request.
• CurrentStateID: The ID of the State the Request is currently in.

Request Data

Once we’ve got the Request basic info down, we still a way to store data that doesn’t fit in the Request table’s schema. It’s very likely that each Process will need to store different information about their Requests, so we need a table design that’s flexible enough to allow for many kinds of data. All we really know about each piece of data is that it will have a value, and we need a way to determine what the value represents. Hence, we design the table to be a set of name-value pairs, and our design will look like this:

With Request and RequestData defined, our complete design (including the tables from Part 2) looks like this:

We still need three additional tables to round out what comprises a Request. First up is Stakeholders.

#workflow engine #database

How to Make a Good Database Design?

How to make a good database design? Why we should create a good design database? Database design is an essential skill of a software engineer. In some interviews, the interviewer can ask you a few questions about it. As far as I know, we have some database principles. There are a lot of definitions about them and you can search on google for more details. Based on my experience, I’ll write it simply.

After reading this article, you will understand things:

• What is a good database design? Why we should create a good design database? How to make a good database design?
• Design process
• Define and use some rules
• Normalization Rules
• Integrity Rules
• Column Indexing
• Some notes and advice when we design a database

Database Design Overview

Firstly, What is database design?

“Database Design is the organization of data according to a database model. The designer determines what data must be stored and how the data elements interrelate.” Source: wikipedia.org

Database design is a part of the Design Process when we develop software. Before doing database design, we have to complete software architecture (N-tier layer, Microservice, …) at the high-level. Database design is a very important step at the low-level. Design Process often creates by Senior Software Engineer or Software Architect who has a lot of experience in the IT field.

Development Process. Source: Internet.

With a medium or big system, we usually choose and combine some databases to achieve our purpose. We need to support transactions and relationships: MySQL or PostgreSQL or SQL Server. We need to save flexible data: MongoDB(unstructured data). Support caching (Redis: key-value, sorted set, list, …), support full-text searching(Elastic Search, …), and so on.

Depends on your project, you should choose and combine some databases appropriately and wisely. There’s not the best database, only have database appropriately. We should take advantage of databases and know the limit/issues of them. In this article, I’ll only write about DBMS(Database Management System): MySQL. The reason is it’s complex more than NoSQL database such as MongoDB, Redis, and so on.

In some projects, the Senior Software Engineer or Solution Architect could request to make a Class Diagram and ERD (Entity Relationship Diagram). What the difference between the Class Diagram and ERD?

• The class diagrams are **used to represent the main object or building block**of the system. They are used to **_show the relationship of one class with another _**and also represent the attributes of the system.
• However, and ERD is more of a database in the form of tables. They don’t show individual relationships but relationship sets as well as sets of entities. They show the type of information that needs to be stored in the database.

In my opinion, we should make ERD and don’t create Class Diagrams unless we have some special reasons. This depends on your project.

#erd #database-design #good-database-design #design-db-process #database

Landscapes Website Design | Nature Landscapes Website Designer

Most landscapers think of their website as an online brochure. In reality of consumers have admitted to judging a company’s credibility based on their web design, making your website a virtual sales rep capable of generating massive amounts of leads and sales. If your website isn’t actively increasing leads and new landscaping contracts, it may be time for a redesign.

DataIT Solutions specializes in landscape website designing that are not only beautiful but also rank well in search engine results and convert your visitors into customers. We’ve specialized in the landscaping industry for over 10 years, and we look at your business from an owner’s perspective.

Why use our Landscapes for your landscape design?

• Superior experience
• Friendly personal service
• Choice of design layout
• Budget sensitive designs
• Impartial product choice and advice
• Planting and lighting designs

Want to talk about your website?
If you are a gardener or have a gardening company please do not hesitate to contact us for a quote.
Need help with your website? Get in touch

#nature landscapes website design #landscapes website design #website design #website designing #website designer #designer