In the xpdl specification, a manual activity has the following features: A Multi-instance Activity Task (assigned an Activity Task Based on the participants specified in the activity, which is called a work item ), work Item Allocation Policy (all participants are allocated and Radom is randomly selected for allocation. Of course, there are more resource modes, because it is not implemented by demo ), the strategy for completing activities (completed only after all work items are completed and any work items are completed) and the Execution Mode for work items (parallel and serial ).
At the beginning, my description is a closed combination activity. The attributes exposed by the entire combination activity are: participants (a set, and you can define the organizational model interface by yourself, users, positions, user groups, organizations, etc.), assignment policies, completion policies, execution modes, and warning rules.
Let's take a look at the functions of each activity in a combination:
1. The findparticipant activity is passed into the participant list and allocation policy. After different processing of the policy (dynamic participants must be obtained from the context), final participants are returned.
2. The approvalreplicator activity is the replicatoractivity, which is the key to implementing multiple instances of the active task. The calculated participant list is used as the initdata of the replicatoractivity. The number of participants in the list determines the number of times the entire replicatoractivity block is executed, each time a separate thread is initiated (by observing the ID of activityexecutioncontext is different from that of the parent activity, we know that the context of the asynchronous thread is managed by ourselves ), the initial data of each thread is a specific participant. Set the executiontype attribute of replicatoractivity based on whether the work item execution mode is parallel or serial. The four events of replicatoractivity are very useful. We will not repeat them here for the purpose of initial data and support policy implementation. The WF designer seems to have poor support for attributes of the ilist type, and I am writing them in implementation. Code This type of parameter should be a bug.
3. singleapproval is a component activity. Because replicatemeditials can only contain one activity, you must seal it.
4. createworkitem creates a work item in the database based on the participants in the thread. The concept of work item is not in WF. It is estimated that WF is not designed for manual activities. We designed it as business data, which can be separated from the database provided by WF by default on Database deployment.
5. lintenforapproval + waitcomplete are used together to implement the process and wait for the user to complete the work item. The key point to note here is the use of correlationtoken, which aims to clearly distinguish the source from the host Program The thread to which the event to be sent. This design of WF is consistent with that of BizTalk. You need an activity to create correlationtoken (createworkitem in this example). The subsequent activities (waitcomplete in this example) are marked as the correlationtoken follow. The owneractivityname setting of correlationtoken is also critical. In this multi-threaded scenario, setting this attribute to singleapproval is a bad thing, so that the correlationtoken of each thread cannot be distinguished, the trick here is to set it to/parent, which is specified as the parent activity at runtime, And the WF engine supports it. Another point to mention is that the correlationparameter feature must be added to the user interface referenced by this activity using correlationtoken. This is available in this lab and will not be repeated.
6. The usersolve activity is based on the execution of the work item completed by the user (the host program passes the user execution result in the event parameter ).
7. delayactivity generates a waiting time based on the incoming warning information. defasolsolve completes the action specified in the warning information.
8. The completion policy is not mentioned yet. This is implemented through the untilcondition of replicatemeditition. As long as the result of this condition is true, the entire replicatemeditition ends, however, if other unfinished threads are discarded, the execution of this conditional calculation is triggered when each thread ends. The remaining policy rules are not difficult to implement. You can heap code based on different scenarios.
The main points of the above combined activities to achieve manual activities are:
1. process the replicatoractivity activity.
2. Combination of listen activity + handlerexternalevent activity and correlationtoken settings
After the demo is completed, I think this implementation is too cool. I really want to use code to directly write a humanactivity. The above two key points are implemented using code:
1. replicatoractivity. We use code to issue several threads based on the list of participants.
2. The listen activity + handlerexternalevent activity can be completed by using the WF Message Queue + bookmarks. If you have any questions, please refer to my previous blog. Correlationtoken. Let's write code to figure out how to do this. Haha!