There are some of us who come from a K2.net 2003 background and we tend to bring the concepts of K2.net 2003 destination rules and Destination Queues along with us when we use K2 blackpearl. I was no exception to this.
However, while having a discussion with some of the labs guys on a feature request, I discovered my understanding of how slots and the various destination rule options work was totally wrong!
Yes, K2 blackpearl and K2.net 2003 destination rules work quite differently.
Take this example:
I have a client activity where I want to do a voting scenario. I want to route it to a pool of 5 users. I want my item to be approved when 2 of them approve it or 1 of them rejects it.
Now in K2.net 2003, you would set 5 users into your destination rules and set 2 slots in your activity. Now, when this activity instance is created; in the worklist table, you would see that 5 records in the worklist table will get created (i.e. one for each user). As soon as the first two users action on their workitems, the other 3 workitems in the other 3 user's worklist will get expired. Now, that isn't too efficient if the number of users increases in the destination pool. e.g. a call center can have maybe a 100 operators serving workitems. Of course in K2.net 2003, there is a way to work around it by using the optimization for the destination queues. This allows you to create a single entry in the worklist table for a destination queue. So in the worklist table, you would see that the item is assigned to the queue name instead of the user name. The item will be assigned at the point where the first user picks up the workitem.
Now in K2 blackpearl, if you have the same scenario. This varies depending on which option is being used in the client event options.
Plan Just Once - This option instantiates only one activity instance regardless of the number of slots.
So it would look something like this.
ActivityInstanceDest 1
|____ Slot 1
|____ Slot 2
Note that as there is only one activity instance, any events in the activity will only fire once regardless of the number of slots.
So you will note that you cannot:
- Assign the destination user in the notification email.
- You cannot get the User and Action Result properties from the ActivityInstanceDest object.
The whole reason here is that events and succeeding rule in the activity instance will only fire once. So the results of the users are actually stored in the slots collection. However, what is interesting is that there is intelligence in the succeeding rule logic. If you have your succeeding rules to complete if 2 or more slots approve or at least one slot rejects. The succeeding rule will fire as soon as 2 of the slots have Action Result = Approve or 1 slot has Action Result = Reject. Note that for the "Plan Just Once" option, the succeeding rule will always fire the SetSucceedingRuleTrue handler in the code for the Succeeding Rule. The SetSucceedingRuleFalse handler will never fire.
Plan Per Destination - This option instantiates one activity instance per slot.
So it would look something like this.
ActivityInstanceDest 1
|____ Slot 1
ActivityInstanceDest 2
|____ Slot 2
Note in this case, any events in the activity will only fire based on the number of instances (in this case it is 2). Also there is a one to one relationship between the ActInstDest and SlotInstance objects.
So you will note that destination user in the notification email functions as expected and the the User and Action Result properties from the ActivityInstanceDest object are populated as well.
So in the same example above, if you have your succeeding rules to complete if 2 or more slots approve or at least one slot rejects. If the first user approves, the succeeding rule will fire the first time. However, as the succeeding rule condition has not been met, the SetSucceedingRuleFalse handler will fire first. Now if a second user either approves or rejects, the succeeding rule will fire again. This time the SetSucceedingRuleTrue handler will fire.
Last Thoughts
Now after digesting all this, you can probably see that there is a performance benefit in K2 blackpearl when dealing with large number of users. For a destination rule pointing to a hundred users while working on a activity with 2 slots. Only two slot records get created versus 100 worklist records in K2.net 2003. User resolve their worklist at runtime and slots are assigned to users in real-time as well. Isn't this great? :)