We now look at the design of the workflow system with a demonstration of the procurement workflow. This article discusses what features are included in a common workflow engine. Through demand analysis and grooming, we have obtained the following flowchart. It is shown that the process consists of a set of States, a set of users and processes that correspond to a state, and several actions that the current user can make.
The actions are then analyzed individually. First look at the IT department drafters after completing the purchase order submission. At this point the process system must do the following work:
- Verify the required fields.
- Generate purchase order number.
- Modify the purchase order status to waiting for IT Approval.
- Change the current processor of the process from the drafters to the IT Leader for approval, add the drafters to the reader domain, and set the Write permission for the Access Control section that holds the basic information for the purchase order to no one.
- Add an action record, which is when the drafter submits the purchase order from the draft, along with possible notes.
- Send an email notifying it leader to process the order.
It leader can choose to approve or dismiss the purchase order through a mail link or directly under the My work view of the procurement system. When approved, the process system will do the following actions:
- Modify the purchase order status to waiting for Finance verification.
- Put it leader into the reader domain and change the process current handler to a colleague of the finance department responsible for finance verification.
- Add operational records, that is, when it leader the purchase order from waiting for Finance verification status approval, and possible notes.
- Send a message to notify the current handler to process the order.
Let's pick up some of the other nodes ' operations. When the process is in the waiting for Finance confirmation state, the Finance department is responsible for Finance confirmation's employees when they choose to approve:
- If the purchase amount exceeds $500, modify the purchase order status to waiting for Final Review, otherwise change to inputting Payment information.
- The user who is responsible for the current state is credited to the reader domain, and the process currently handles the change to the corresponding status of the handler. If the next state is inputting Payment information, the Write permission for the Access Control section where the Payment information resides is set to the handler for that state.
- Add an action record.
- Send a message to notify the current handler to process the order.
When the process is in the inputting Payment information State, the drafters responsible for processing choose change Price:
- The system will pop up the Modify Price dialog box.
- Modify the purchase order status to waiting for IT Approval.
- The current handler of the process is changed from the drafters to the IT Leader responsible for approval, and the drafters are added to the reader domain.
- Add an action record.
- Send an email notifying it leader to process the order.
When the process is in the inputting Bank information state, the Finance Department staff responsible for processing is selected to close:
- Modify the purchase order status to closed.
- The current handler for the process is changed from [Nobody], which represents no one, and the current user is added to the reader domain, and the Write permission for all Access control sections is set to nobody.
- Add an action record.
- Send an email notifying the drafters that the order has been approved for completion.
- Automatically create an expense statement in the Finance Department's expense reimbursement process system and fill in the relevant information from the current purchase order.
As can be seen, the above node operations are quite similar, such as modifying the permissions of the purchase order, including the relevant reader domain, author domain, access control section, but the specific changes in each operation of the content is different. Therefore, rather than writing code for each operation, it is more desirable to write generic code to handle these
a similar action, and the specific data that is used for an action on each operation is provided by the configuration document. These generic codes form the so-called process engine. As for an operation that contains
Specific Actions, it is prepared on a temporary basis, based on the specific needs of each process.
Let's look at what the process engine contains:
Although the above operation instance, only the submission needs to check the required fields, but this function is also necessary in other node operations, and the requirements of the functional boundaries clear, easy to standardize, so included in our process engine. In addition, when a process document jumps from one state to another, it is sometimes necessary to modify the values of some business fields, including this functionality in the process engine and to write code for many of these simple and specific actions. The generation of serial numbers such as purchase order number, although in development is also very common, but this function is not limited to the process system, and the implementation of the serial number configuration documents it is also best to save separately, so although common configuration documents and code to generate serial numbers, but independent of the process system. In addition to the similar actions that can be clearly seen from the above operating examples, the final 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.
92. Notes/domino-based document Workflow system (iv)
