Workflow and approval flow

Approval flow is a simple application of workflows. The approval flow is characterized by a document corresponding to an approval flow template. In the approval flow, only the status of the document is processed. For example, the document data is used in the approval flow, for example, where the document variables need to be referenced in the conditions. The approval flow does not involve processing between multiple documents, so the approval flow is relatively simple. Most workflows in the industry only implement approval flows, such as collaborative work and approval of some documents in ERP. The workflow is now in the initial stage.

If you need to make a real multi-document workflow, that is, the business flow. For example, from a purchase application, a purchase order, a receipt to a purchase invoice, a complete procurement process can be customized. Furthermore, the procurement can be connected with the inventory, production, or sales modules, which is more complete. At the same time, if these processes can be customized, such as standard processes, different enterprises can customize the processes that meet the needs of their own enterprises, which is more perfect. In this process, I think we need to solve two complicated problems.

1. Architecture ing between entities.
In BizTalk, source schema and target Schema are mapped through XSLT. An instance of the source architecture (XML) can be referenced or generated as an instance of the target architecture (New XML ). This is a better solution. Of course, you can define a simple ing table.Code. This work should be difficult.

2. Multi-to-many relationship between entity instances.
For example, if the invoice is received, you can open N invoices for one receipt, or one invoice for N receipts. Therefore, there is a many-to-many relationship between document instances. The processing of such a relationship is relatively simple for the traditional functional process and can be achieved through multiple references. The relationship between document instances is maintained in the two document data. However, it becomes tricky to use workflows to deal with such problems. The first problem is whether to introduce a process instance for processing. If there is no process instance, what is the difference between this and the traditional function-based applications? It is simply to display the process in a graphical way, this is just a shell. If introduced, the second problem will occur. What are the constraints between document instances? If the constraints are met, only one-to-one relationship can be processed. For example, if one bill is received, one invoice must correspond to each other, so that the entire process can flow. If there are no constraints, what are the conditions for selecting the order when entering the invoice? From the business point of view, it should be the previous order of all process instances that comply with this process template. If the invoice associated with another process instance is selected, the process instance will be suspended. Therefore, the process instance is merged. Note that it is not the activity of the Process Template but the process instance. The processing here is the key to the business workflow.

After several days of consideration, I did not want to fully understand it. I wrote it down for future reference. I hope that I have discussed it.