Workflow-business data and process data (below)

I can't sleep, so I will continue to talk about the workflow.
In the morning, I wrote an article about the business data and process data in the workflow system. The two are interrelated and no one else can become a complete business process. What I want to say is that the two need mutual understanding, that is, process data requires business data for some operations, and business data requires process data to provide some information.
Whether a workflow system can flexibly and conveniently develop business functions is critical to the flexibility of business data processing capabilities. perhaps for a simple approval flow, for example, documents and applications do not involve too many business processes. Most of them are filled out by the applicant, and are routed to each node through the predefined process. node instances are the corresponding tasks, perform approval step by step and generate a final result. This is a simple process application. If it is more complex, such as computing business data in some task nodes and batch processing of business data according to conditions, after the process ends normally, data is imported into the database, information is archived, and message notifications are triggered after the interruption. Various business processes are linked to the flow process, and the process is only a set path, like a road, the specific fuel or other actions must be handled manually. For core business in the field, we need to organize them Code Because it is impossible for a process to process tasks in addition to other tasks, the process must be able to process data in various circumstances, that is, the business operation interface.
The key point here is the business operation interface, which key points should be supported in the process. Here, we can actually think of Microsoft's WF, which involves pre-and post-functions in the activity method. This is the interface provided for business processing. Likewise, we can also imagine that the process instance should be able to process the business during creation and results, and provide interfaces for prevention when the status of the process instance changes. For process node instances, the pre-function and post-function are more important. In node routing, each route should also involve the pre-and post-function. As you can see, process instances and node instances may process services when they change. This is where the business needs to be mounted, that is, the Open Location of interfaces.
As mentioned earlier, a workflow is not a simple approval flow. Approval is only a description of its entire process. It is more meaningful to drive the business in a specific production and operation process effectively, flexibly and conveniently, in particular, how to easily process complex business data is the focus of developing workflow systems.
For the association of process data and business data, when the business data is multiple tables, we usually associate the master table with the process instance, and the business sub-table is associated with the master table.
In general, when creating a business table, you will habitually add some fields, such as the creator and creation time. In addition, you also like to add a business status field, as mentioned earlier, it is different from the Process status, which may be consistent or inconsistent. It uses the process to drive changes in the business status, which sometimes facilitates query. Whether to add a process instance id to the business table depends on the actual situation. After all, the development modes vary.