what? What? Aren't there already so many BPMS systems? For example, JBPM, why do you need a process design pattern? How should I put it, it's uncomfortable to use. If the project process is standardized, that's fine. If it's a customized system with many special or abnormal needs, it's better to do it yourself. In fact, these workflow products, don't you think their cores are similar (in fact, the author has not studied too much, sweat~)? In fact, they are also in line with the process model I have summarized. Of course, I will remove some cumbersome things and add some personalized things. If you are going to be a product, you may decide the process requirements yourself, using BPMS, if you are going to be a project, the process and many other aspects are up to you. There is still a big difference between making a product and making a project. If you fully understand this model, you will be able to consider more comprehensively than the user when making requirements. Know what kind of requirements are in place, and you can choose how to do it. The design is more flexible and more flexible. Reliable, yet more compact system. For example, when the user talks about the return operation, he must ask clearly what the return means, whether it is to completely erase the following tasks, or to submit it as an ordinary task, but submit it to himself.
Insert a sentence: Sometimes the process will cooperate with the form system and design a lot of tables, and the method will be mentioned later.
1. Straight to the point: There are several key points in the core of the process model.
1, is the job definition. Including the position of the process, the role of the position, the operation of the post before and after, some branch conditions and other main content. So what else have I ever defined? Including the name of the form corresponding to the position. In addition to configuring the role, the position should also be configured to a person in the role or to the role? What is the name of the menu corresponding to the position? In addition, there is also whether the position is a main process position or a subsidiary position. It is also necessary to define the time limit for the operation of this position, how long the reminder is in advance, and whether to call the police if it is overtime. The post also defines everything else that may be related to the post. How, if you define it yourself, the content is very rich! In the longer term, you can define a post as a webservice, define the address information, and even define parameters. By the way, you can also start the data exchange task at the post. Anyway, everything you want to configure is recorded together, and you can use it yourself anyway.
2. Post operation. For the operation, the role of the operation should also be defined. Usually, the position and the operation role of the position are the same, but there are also differences. Do people who operate the roles of the next post submitted need to set filter conditions? There has been a position with senior management and ordinary management. Why not design as two characters? Later, the new leader of the customer asked for it.
Here, the common problems encountered: For there are only simple and small processes in the project, some people will think about not introducing workflow, it will make it big. Do you want a state machine? However, the state machine is the state and the change condition of the state from the name, and does not include the most important task scheduling, without this lack of flexibility. Some people use workflow products, and only define some things related to positions, including branch conditions, but they don't know where to define many other things related to positions. They are often written in configuration items, or dictionary items. Write a little in the constant, or write a little in the constant, or write it in the program at all. Therefore, after understanding the pattern, it is more reasonable to grasp the placement and naming of various things as a whole.
3. Task scheduling definition. Task scheduling should also be considered a part of the definition. It is closely related to the operation of the job definition and can be regarded as the result of the operation. It is separated here because of its importance and very connotation. There is a simple serial task A-->B, which is the task of one job producing the next job. There is also parallelism. A post generates many parallel tasks behind it, that is: A-->BBBBB-->A(C). These are the most basic, and there are sub-processes, that is, the main job task is suspended.
Then I have done a lot of more complex scheduling here. For example, A-->B--B--B-->A(C), unlike the former, B is done one by one, and some are described in language. For example, a parallel task is suddenly withdrawn, one is added, or the current task person is changed, and the user is unwilling to withdraw and reassign it. For example, task A can generate tasks that are defined in the process, but not status. The most common situation is that I have designed some [reading] positions. Many positions can generate tasks for this position, and even require a receipt, but it will never affect the process. the current state of. Anyway, it is really arbitrary. As long as the user has an idea, it can be temporarily added, destroyed, suspended conditions, changed personnel, forced to end other people's tasks in the manual background, etc. As long as the user thinks, it can be done. Of course, abnormal operations must be recorded, and the reason for changing the time of the person or something. In the longer term, the webservice mentioned above can be the tasks of multiple other applications, which can be submitted to multiple parallel ws applications, and at the same time generate tasks to be completed by several external applications in its own system for callback. When calling back, judge whether other tasks have been completed, and push the workflow forward when completed.
In most cases, task scheduling can be regarded as an operation rule. In fact, as long as the rule scheduling relationship is implemented, the relevant part can be done with interfaces or abstract classes. The task tables of all businesses in a general workflow product are together, so specific tasks are scheduled. But when you design it yourself, you can ask for leave in these tables, and reimbursement in those tables, but the operation relationship is general, and there are serial scheduling. Then the main table for leave and the main table for reimbursement can abstract business objects, which must contain ID, status and other fields. The leave task table and the reimbursement task table may also be different, which can be abstracted into a task object, which at least contains the business object ID, task start time, task role, and task completion person.
4. Task operation realization. The task operation is to complete the task by the specific person in the specific business after the task is scheduled. In the previous scheduling process, a new task has been generated by the previous operation according to the defined scheduling method. The new task may only be in the init state, the current person has opened the task is the todo state, and the current person has completed the task is the done state. Usually, the task completed by a person contains two aspects. On the one hand, it is to process the form, fill in comments, and possibly make settings, such as selecting the next operation and the people involved. Another aspect is to drive the workflow. Generally speaking, when using a product, promoting the workflow is an encapsulated process, and when saving the information of this position is handled by the user, of course, there is a place designed by the user. These two operations can be packaged into a service and a transaction. The way of implementation can be the introduction of AOP, the method of saving its own information to process the process, or the service of the workflow product can be introduced into its own service.
Instead of using workflow products, one position is one task, some fields are managed by process promotion, and some fields are filled in by this position. It can be regarded as a combination of two. Of course, the content filled in the post may be the main record information, and it must be written in the main table synchronously. Because the workflow product only focuses on task scheduling, it can't control or manage other filling content, and its tasks are not allowed to be touched by you. You can only use the provided interface to access the tasks. The advantage of combining two into one is that the content of the task is integrated into one record, and it is possible to deal with various situations, such as suddenly adding a task, modifying a task suddenly, shooting a task suddenly, and it is convenient for ordinary developers to understand and deal with these situations.
2. Database design, pages and classes
related to it Changes can be placed in memory. In addition, the process does not have to be recorded in the database, it can be XML, it can be a configuration file, or it can be any other way that can be expressed.
Job information table, operation information table, these two tables are almost enough. According to the actual situation, a table was also simplified, but the records of the table were very large at that time. You can also get a process information table, define the version, start, etc., which are generally available in the workflow, and sometimes can be simplified.
Job information table: basic such as job title, ID, process name. You can define any menu name, role name, specific person or role, form address, external WS address and any other information associated with the position.
Operation information table: operation name, ID, previous position, next position, role, button name or selection name and so on.
2. Tables related to process operation: Of course, there is a main table, such as the main record of leave information, and a task table. I usually have one table for one business, and not all of them are put together. Workflow is abstract integration, and I am decentralized governance. The task table mainly includes: task ID, master record ID, task role, task person, task status, task start time, task end time, and may also include task filling content. And possibly what choices were made. Since I separate the different tasks in a system, the basic task elements are designed to be the same. In this way, I can programmatically handle abstract tasks in task scheduling. It can be considered that the workflow product is to put the public fields of the task in an internal management table, and the content of other tasks is managed by the user, but I put it together, just schedule the abstract class to manage the public part, and the concrete implementation class records their different content. .
3. The design page at the time of definition. This is incomparable with the workflow products. The products are all visual flow charts, but I have always used a simple list page to deal with the process definition. Simple diagrams can be drawn when displaying the process. why? Because I define a lot of content, the scheduling is arbitrarily designed, there is no public way to draw, and it is not a big problem if it cannot be visualized. To meet the diverse needs of users, there is no energy and time to do this, and the cost will be high and not worth it.
4. The most important class is the scheduling class. The scheduling class only operates the task table related to the operation of the previous process. As I said before, it is necessary to program abstract classes, because scheduling is a rule. The scheduling class implements the rules for the completion of tasks and the creation of new tasks. For example, if a parallel processing task is submitted, the task of the current person is suspended, and a batch of parallel tasks is generated. When one of the parallel personnel completes his task, it is necessary to check whether the others have completed it. If not completed, only his own will be completed. When everyone else is done, the pending task is restarted.
3. Design of related common pages and common methods
1. Menu design: In many cases, users require menus to be divided according to positions, such as tasks being divided into receipt, review, processing, and replying. It just so happens that these menus are closely related to the post, so the content of the menu configuration can be integrated into the post, such as menu name, link, etc. If you didn't expect the post attribute at the beginning of the design, you can easily add the attribute to use.
2. Task list: The task table and the main table JOIN come out at once, and can display the task fields with their own characteristics.
3. Specific business page: Usually, all related tasks of a business should be taken out, and displayed in different positions of the form after classification and combination. For example, several audit tasks are displayed in the audit place, and the specific business page opened by the current task person, for example, is also Review, the color of the review area is special, and you can click to open an entry information page instead of filling in the main page. The main page is used to summarize a batch of tasks of the same position and display it. For example, when multiple people are reviewing, the review office shows Zhang San 7.1: Agree. Li 4th 7.2: Agree. New reviewers have this task, just click here to enter, enter the refresh content, and add Wang Wu 7.3: Agree.
The main page is mainly for viewing. After the person who has the task fills in the page, he returns to the main page and selects what the next operation is. If the task is configured to a person, he must further select the next person. It can then be submitted. Some people clutter things together in the design, there is no sense of hierarchy, and those who maintain it have to take medicine.
4. Examples and summary:
For example, there are reimbursement business and leave business in the system. The main tables are the following:
Process information table (sometimes saved, when there is no new process), job information table, operation information table (sometimes simple and saved), reimbursement master table, reimbursement task table, reimbursement log table (sometimes also saved Now, the task itself also shows the log), the main leave table, the leave task table, the leave log table (the same as above will also be omitted), the main ones are these.
I won't mention some other attachment tables, and specifically mention the form system that is sometimes used. This form is different from the reimbursement form. Because there are many, XSTL and XML are generally used to make the form. The definition of the form is in a field of the definition form, and the form filled in the actual business is also in a field of the business form. Forms are usually only filled out in a specific position, abstractly similar to attachments, and do not participate in process management and scheduling. At this time, you only need to process to the post to configure which forms to fill in this post.
class? There are mainly post information class, operation information class, reimbursement main table class and implement process main table interface, for example, the process will set its status. Reimburse the task class and implement the process task interface. For example, the process will select a scheduling method to process tasks according to user operations, complete some tasks, and generate some tasks. The leave master table class implements the process master table interface, and the leave task class implements the process task interface. It is also possible to inherit from abstract classes.
The task scheduling is to program the process main table interface and task interface. The implementation class of which business is passed in to actually operate that business. When doing other projects in the future, that part will be reused.
In general, it is to set a model, and the real business is to follow the model. Abstractly, the model is a class, and the business is an object. The rules in life are the model, and you act according to the rules and it is the business. Put the model things together, the business things together, and organize the things inside. You can’t put the things that should be defined everywhere or write them in the code, and you shouldn’t put the filling content related to a task. For simple processes, it is best to write a separate task scheduling class. Why do I generally not use workflow products? Because it includes a part of the definition and is not complete, and also includes a part of the business, which is incomplete, the scheduling algorithm is not complete, and some special statistical requirements are not easy to handle. On the contrary, some drawings, startups, and process versions are in my opinion. It's not particularly important, it doesn't matter, then it's better to do it yourself according to this idea, and it's not every project is done again, it can be said that if you do more, you will have a prototype system, and you can change it quickly.
If it is a standardized business, the workflow must be convenient. Otherwise, it is necessary to fully grasp the complex business and make good use of the workflow. In many cases, the project is quite chaotic!
Fifth, the design ideas of other similar systems
After grasping the overall design ideas of the workflow, the design of other similar systems is very simple and standardized. For example, tasks must have status, generation time, start time and end time, even if the user does not mention them, they should all be designed, and there may be rules applicable to them. Some design time only has one time, then some of the following functions are not easy to do, such as the generation time and start time, you can know whether the person is checking his own tasks in time. The start time and end time will know the processing time, and some end times are very important and should be recorded in the main table, such as the settlement time. But the task table cannot be omitted, and the task table is the source of this conclusion. It is also very important whether the task is assigned to a person or a role, and some systems go to the role at one time, and then to the person at one time. There must be fields in the design. Some people only design people. When submitting to the role, find out the role of everyone in the role, each person has a task, there is a lot of redundant data, and the newly configured role cannot see this task. The person who leaves this role also records that he has a to-do task.
It is important to realize the relationship between configuration, scheduling and business. . .
For example, when doing assessment, the rules of assessment are the definition part, and each assessor is a business. Distributing the assessment form is equivalent to generating a series of tasks for the assessment personnel, and there are assessment items in the tasks. That is, it is convenient for appraisers to find their own tasks, and they can also fill in and submit. When submitting, the organizational structure of the unit can be used as part of the submission rules, such as which superior a subordinate submits to. When the task component is relatively large, the task part can be separated from the assessment score. Some tasks are related to assessment points, and some tasks are written comments. With a big idea of control, the system will be neat and tidy.
For example, to do some construction project approval monitoring, you can define the approval of a type of project, and configure some pre-requirements. When a specific project is in progress, all approval tasks are generated in advance and are in the init state. Through manual or docking, the actual progress can be obtained, the status can be synchronized when the task is updated, and the prerequisite relationship can be verified. In practice, the approval is also divided into stages, and the stages are also designed as stage tasks, which are composed of the approval tasks, and the status is automatically updated according to the rules.
Even if it is a small notification and feedback, you can configure what type of notification to give feedback, and after the notification, you can remind the parties of the task of generating feedback in advance. And this rule can be put together in the process rules for unified management. In practice, some designs are to complete the current task without generating new tasks in advance, and tediously generate to-do tasks according to the completed tasks and rules.
With patterns and ideas, you can improve your needs analysis in advance, you can choose to use products or do it yourself, you can standardize the design and development of libraries, tables, and classes, and similar situations can be applied as much as possible. It turns out that other requirements put forward by users can be satisfy.
