A record of the process of handling workflow issues in a project at a time

    Process processing has always been a focus of my project, and I wrote a blog about workflow before. However, I recently dealt with the problems encountered by my colleagues, and I feel it is necessary to record them again.
1. Review Workflow
    First, let’s review in vernacular what is workflow and why there are workflow products. Workflow is to first design a work processing specification, there are several positions, which position is sent to which position, this design is generally used and does not move. It can be regarded as a complex dictionary item, which can be recorded in a file, stored in XML in the database, or stored directly in a table, and is generally cached in the system when used.

    Why Workflow Products? Products are generally universal. In actual work, different positions are handled in completely different ways, and the input content is also different, but there are also similarities, that is, some flows and task assignments. Therefore, according to the principle of abstracting the public part, there is a workflow product. During the flow of an item, there are workflow instances in the workflow, and business instances in its own system; there are business assignments in the workflow, and business data in its own system. It means that the commonality and individuality are separated, of course, there are fields between them.
Second,
    the problem is solved, let's talk about the problem. Another colleague participated in this project, and I instructed his technology. It mainly deals with and branching and merging in a process. Three departments are drawn on the flow chart. In practice, the user can choose three, two of them, or one of course. This situation is a very common situation. I have done business processes that are more complicated than this, and they are all allocated and processed by the process I wrote. If there are a few, I will allocate several concurrent tasks. After each concurrent task is completed, the detection is Not everyone has completed it, and everyone can move on to the next post.

    What is the difficulty? Internal product for workflow, no source code. The process adapter is packaged outside, which can support jbpm and others. Outside is a set of business layers written by one person before, including a batch of business tables starting with W. The business table and the form system are integrated again. This business table is wrapped with a layer of business tables beginning with INF written by another person. The to-do tasks used on the page all use the INF table, and the page is quite complicated. After the flowchart drawn by the process tool is loaded into the system, the links and operation tables corresponding to the W series tables are generated, and a batch of post and activity operation tables corresponding to the INF are generated. Therefore, a specific business process is divided into three parts. The inner part is the workflow instance, the middle layer of business, and the outer layer of business. Each layer has about 5 tables, and such a system is too redundant.

   Colleagues spend the main time on changing the form, that is, modifying the function of the department to select the actual handler. I have seen the database design and analyzed the data, saying that this and task has already been generated, and the change here has no effect. The number of ands must be controlled before the and is generated. As an unconfirmed task, the most important thing is to get through the difficulties as quickly as possible. Don't waste time on details. For example, the project should first build the data model and basic structure, not decorate the room. There are several dictionary items in a recent project, and the public page has been processed, but the final customer has to process the page, but I say this is very simple, fill in the data first, and move forward with more important work.

Third, the processing process
    1. First of all, I think and branch, you can choose the branch is a very common function, maybe it is OK to configure it, after understanding this function is gone. The condition for decompilation to see and merge is the number in the process configuration.

    2. My initial suggestion is that when assigning and tasks, the user selects the department and marks it down. If the mark is not involved, the task is automatically completed by default. To-do tasks and completed tasks are filtered out according to their IDs. This should be the easiest, and the outermost business layer, with minimal changes. (The simple test allows one part of the task to be completed immediately after submitting the and task, but the submission from COPY involves forms and involves some design patterns, and the error will be put down first. After all, I am not the leader, just a suggestion)

   3. On the other hand, the technical director of another team that had participated before asked for help from the technical director. In the remote guidance, it said to try xor, and the request conditions on the test process connection can be filtered, and also said that and xor has been changed, There is no difference, the key is the conditions of the process connection. As long as there are conditions in the form, it will work. It seems that it has been changed too messily by different people. Everyone can't eat it, only try it. XOR is an exclusive process.
   
  4. Of course, it is an audit position. Only if you agree can you assign and tasks. If you don't agree, you can directly transfer to the end. Therefore, among the two branches of the audit, one of them has an and node first. The main test is whether the conditions on the connection line after and can be used to coordinate the real assigned tasks. Colleagues prepare to write conditions and rewrite the submission form to include conditions. I said that it is feasible to use the existing items in the form to verify whether it is feasible, just write a condition, and it is not feasible to change it for a long time. Time is spent on important validation feasibility. The branch on and really works, and only 2 of the 3 tasks are generated.

  5. The next step is the merging operation. It has been said that and merging is related to the number of configurations. What should I do? They can't do anything right now. I suggest to modify the original code, only to know that there is no original code, another technical team responsible for saying that this class can be copied and modified, and the loading will be optimized after modification. Oh yeah, why didn't I think of this. He said that they have been doing this all the time. It seems that I had too little communication in the project circle before, and technical communication is very important. If I were a manager in charge of multiple projects, I would definitely organize various project technicians to explain their projects, recent problems and gains. But we don't have this mechanism here. In the end, I only wrote and a few lines of code, and finally used the actual number of tasks as the condition of and merging, and the test passed.

6. Now that the technical difficulties have been overcome, let them continue to develop.

4. Reflection

    Recalling the first idea I put forward, I began to think that the easiest way to bypass the problem is to automatically submit unselected branch tasks. For identification only. Why didn't it work? After assigning the and task, call the submit task immediately, and it should only need to change about 10 lines of core code. Because I'm not specifically responsible and I don't think much about it. After all the problems were solved, I realized that the most fundamental problem is that to string together two submissions, it must be two different requests and different transactions. In fact, it should be very simple to simulate a user operation to make a submission.
    
    Everyone likes products, and a colleague in the group wants to make OA products, but the closer it gets to the end user, the more changes will be made. The initial product conditions have changed, and then patched and changed. Layers of packaging. People are changing, and the changes become more complex and unstable. I always think a thorough and clear prototype system, or a complete design idea is more helpful. You can customize and modify freely. If it was really good at making products, project companies like ours would have been eaten up by Niu B's companies.