93. Notes/domino-based Document Workflow System (v)

Determined that the process engine contains the following features:

• Verify the required fields.
• Modify the permissions of the process document, including the relevant reader domain, author domain, access control section.
• Add an action record.
• Modify the configured business fields.
• Send an email notifying the relevant handler.

The model will then be modeled. This process has different forms and terminology when developing in different paradigm languages. In a procedural language such as C, there are design data structures and top-down function hierarchies. When using an object-oriented approach, it is necessary to design a class diagram. In our notes environment, basically the "interface-oriented" development, to determine the need for several forms and views, design, and then write the necessary event processing code, an application is embryonic. Thanks to the nature of the document-type library, the form can be adjusted at any time, and the corresponding document is saved or the program is modified in batches to update it.

But at the moment we're going to develop a common process system that needs to be more thoughtful in the design phase to be well-architected, easy to understand, maintain, and expand. In fact, regardless of the language and paradigm, the overall direction of the design is consistent. That is to break up a big problem into a few small problems, each of which is solved with a part of the current language. The components of these programs can be divided into data structures and logical two classes. In C, the custom data structure is represented by the struct and the Union, and the logic is implemented by the functions classified by the source file. In Java, data structures and logic are merged into classes. As for our notes, such a clear and rigorous design is too little. This is largely due to the fact that notes itself has evolved from a user-oriented software rather than a development platform, and has also played a dual role so far. In order to emphasize rapid development, data design, interface design, business logic development are mixed into the form design.

Jumping out of our accustomed practice, starting with the design of the interface, as in other languages, first consider the system's back-end logic. Notes documents can act as both a record in a database and an object in a program in two roles, which is equivalent to a record in a relational database and used as an object in an object-oriented language. Therefore, our modeling approach is closer to the object-oriented class design. With a few previous articles on the requirements and design of a process system, we can envision the following types of objects:

Workflow: Each workflow instance holds information such as the name of the workflow, the current node, and is responsible for handling the operations of each node of the process.

Business object with workflow: Here is the purchase order.

The configuration object for a workflow: The actual difference between the different workflow instances and the operations of each node is read from the configuration data.

Further analysis, these objects need to be persisted in the process operation, that is, when the process runs, the object needs to read the data from the database creation; When the operation is finished, the object's data is saved back to the database. In the notes environment, the object persistence vector is the document. Because workflow instances are closely related to business objects, and the permissions information that a workflow object records, such as the reader author of a business object, is only valid in notes for the document that corresponds to the business object, the data for the workflow and business objects are stored in the same document, which we call the process documentation later. The configuration object for the workflow corresponds to the configuration document. The usual notes workflow takes only one process configuration document, the process name, the current node, the next node, the user of the next node, and so on, all stored in a single document. This may seem simple, but it is unavoidable to repeat data, such as messages sent by each operation in some cases can be used in a common set of configurations, it is not necessary in each process configuration document is set once. More importantly, this type of process configuration document does not logically reflect the structure of the configuration data. For example, the user of a node in a workflow is logically determined by the node, regardless of which node jumps to it, but it is set up by the "Next node user", which points to multiple operations on the same next node, where the same value must be set, error-prone, and misleading. It is also determined by the node rather than the operation, as well as the Access Control section, with only one process configuration document causing them to be redundant in the same multiple operations document as the next node. So we use three types of process configuration objects, which correspond to workflows, nodes, and operations, respectively. Naturally they are also stored in three types of documents: The workflow configuration document, the node configuration document, and the action configuration document. We'll look at these three types of documents in more detail below.

93. Notes/domino-based Document Workflow System (v)