Development Experience of workflow software in recent years

Recently, the Group has been discussing Microsoft WF related knowledge. Today, we also take this opportunity to talk about our recent workflow-related development work.

First, let's talk about the mood when we finally use WF. It is not a product for development and use, but a basic framework of workflow software. We want to learn WF, I think it is best to first understand the workflow and related knowledge, understand what the workflow is, what concepts it contains, and what is general. For example, process definition, process version, process node definition, process instance, node instance, and the relationship between the Process and the business. I think it would be better to learn from these questions, it is really a headache to simply read WF. I don't know what it is and how it is used after reading a book.

Our development project is implemented through the company's development platform. In terms of functions, we can also say that the workflow system should have the following functions: Custom forms and custom processes, as well as the throughout-the-process permissions, I don't want to talk about the forms and processes today, but I want to talk about permissions. What I achieved in my graduation work at that time has caused me a headache all day.

Recently, the tracked projects have been developed on and off for several years and are maintained and constantly changed. For an enterprise management system, permissions are a key component, and permission management is good or bad, it depends on whether the system is controllable. For some modules, the biggest change is not the business, but the permissions, which is ever-changing.

There are three types of system permissions: menu and module-level permissions, which indicate which menu permissions a role has or does not have. Such permissions are easy to understand and implement, but maintenance is quite troublesome. The second is to record permissions, that is, to filter the data list based on certain rules, and only display some records that can be viewed by the user. Of course, there are various rules, data fields can be controlled by department, by specific person, by project dynamic role information, and custom, grant field authorization to these roles within the accessible role scope. In the end, this role can view which fields and cannot view which fields. The third is atomic permissions, which mainly involves the accessibility of controls, buttons, text boxes, and so on in forms.

As mentioned above, permission control is implemented in our system. It is not that complicated, but in actual project applications, roles and personnel in the Department are constantly changing, the permission configurations for each list or menu are not the same, and the project development may not be fully considered. In the end, time makes it increasingly uncontrollable. In the end, the N-hand project was put into your own hands, and sometimes I had no idea how to organize it.

In a workflow, a form is generally transferred among nodes in the process, so its permissions are generally authorized by nodes.

A workflow is not equal to an approval flow. If a workflow involves a large number of business processes, it requires convenient interaction between the workflow and the business. Generally, the workflow interacts with data to process the business logic, this requires strong scalability.

I haven't written anything for a long time. It's a mess. So far, I have time to write it again.