Workflow-concept of no permission

The value of a workflow mainly refers to the transmission of information between various tasks, especially the initiation and completion of various processes. Considering this issue, it is obvious thatWorkflow does not have permissionsThe so-called permissions are only information control in service processing.

Seeing that you are wandering in the research of Workflow Organization and permissions, I feel that I have to say that I hope that some of my colleagues who are just getting started with the workflow will not take a detour. Chinese friends who know this are close to their own treasures. They are reluctant to teach and teach students, and their academic ethos is blocked. That's why I have to make a splash of money at a low level.

1. Landscape and Landscape

The so-called workflow permission Model in China generally refers to RBAC or the combination of tree structure and role.

According to the so-called RBAC standard, the original intention of the design is security administration. Note that these permission standards are generally followed by the AC (Access Control). This description shows the concept of the design. This model is generally used in the network operating system. Some articles on the Internet introduce this model into the workflow system, which is probably affected by the operating system.

There are also some articles that adopt the organizational structure that directly reflects the reality. This forms a saying that the organization model and permissions are combined. But what if the organizational structure is landscape-oriented? Generally, the concept of "position" or "role" is introduced according to the intuitive concept. I don't want to say much about this practice. The experts in system design will soon be able to draw a conclusion on this structure: the requirement for plagiarism is directly achieved without analysis.

2. Why is there no permission?

Workflow is a concept of active sending. Is a work task, the system needs to find a person, notify him to respond to work, isActive. The role-based or organizational structure is generallyPassiveThe concept is that someone can do one thing, while others cannot.

In this case, there is a very obvious difference: in a workflow, a person must do this, and the system will not distribute the work to others during the work process, it is impossible for others to "grab" (This "grab" is actually the access concept in RBAC) to work tasks without being assigned by the system. Therefore, the workflow has no permissions, but only the target of the distribution task.

3. A design for distributing tasks

Now it is clear that the issue of all permissions is just a problem of distribution tasks. The distribution task is just an instant action, so the distribution target can be very simple and completely independent from the workflow engine itself (if jbpm or osworkflow is used, this design should also be realized ). This is completely different from the permission system. Permissions must penetrate into every possible detail of the system, and it is difficult to completely separate them.

How can we find the target for distributing tasks? The answer to our practice is:Mesh Structure. The design of this mesh structure can be expressed as a set in mathematics. If Department 1 is a target for distribution, and distribution needs to find its subordinates through this department 1, we can say that its subordinates are associated with this department 1, recorded as department 1 = {Zhang San, Li Si, Wang Wu }. It is possible to find the Director of Department 1 in workflow distribution. What should I do? It can be recorded as manager = {Zhang San, Chen Liu, Ding Yi}. In this way, the department 1 department manager = {Zhang San} is set and the target is found.

How can we find the relationship between superiors and subordinates? Can be recorded as: Sales Department = {Telephone sales department, business outlets, network sales department}. In fact, if you are configuring these sets, it is mandatory that each department can only belong to one department (in mathematics, the intersection of any two departments is an empty set). This is the so-called tree structure. Looking for a higher-level department is actually looking for the set to which it belongs, and looking for a lower-level department is actually looking for an element in the set.

If there is no reference to a link in the workflow definition, you do not need to create a set. For example, although the network direct sales department has a relationship with the Sales Department, if the network direct sales department does not need to report the process in the actual business process, the sales department has not issued a command, therefore, the distribution target set does not need to reflect the relationship between the two.

If we look at the actual language from a metaphysical perspective, we can see that the departments in the organizational structure, the roles in performing operations, and jobs in tasks are actually collections. Without metaphysical abstract analysis, when the intersection of these different sets is not empty, many complicated and conflicting details will be introduced, at this level of the specific intuitive model, you must carefully repeat it to use it correctly (usually the Code with various conditions is filled with the screen of developers ). Therefore, we have seen some practical ways to describe the complexity of the system (that is, to vertically represent the organizational structure with a tree, and to horizontally use a role to represent the structure of access power ). It can be seen that this design can only be regarded as the product of the software analysis fault (whether it is a talent fault, a consciousness fault, or a fault caused by cost? This is another issue worth reflecting on ).

As for the code implementation in the collection method, it is relatively simple. I will not spread it here.

4. Summary

We can see that the delivery of workflow targets is highly abstract based on the set representation, and almost all delivery needs can be solved using the simplest concept. The role of software analysis and design shows its power. When we are a technical engineer, we must be careful not to be blinded by coding: intuitive models can only meet specific needs; only abstract logic or mathematical models can be analyzed, in order to make our code have 10 years or even stronger vitality.