I have a request to have a destination rule that can have multiple detination users and then rotate the work items between the users as a new work items is created. So the first work item goes to a, second goes to b, third goes to c and so on. I have done this by using a database table where I insert the user and then check the next time if that user is in the table, if so I use the next user and so it goes on till I get to the 7th work item. Then I start to increment an id with each user but it get message. Is there maybe any better way of doing it.
Regards
Charl
Destination Rule
+1
+11- Nintex Employee
Hi Charl,
I hope some other members will also post their comments but what I would do, is:
Keep an external (db or file) index of work item number.
In the code behind your destination rule...
* Read the index
* Increment it by 1
* Assign to User(index)
* If index > StringTable("maxIndex"), index = 0
In this way, there's not a lot that can go wrong. The only problem that I see with it is hardcoding the users but there MUST be a way around that.
Regards,
Ockert
I hope some other members will also post their comments but what I would do, is:
Keep an external (db or file) index of work item number.
In the code behind your destination rule...
* Read the index
* Increment it by 1
* Assign to User(index)
* If index > StringTable("maxIndex"), index = 0
In this way, there's not a lot that can go wrong. The only problem that I see with it is hardcoding the users but there MUST be a way around that.
Regards,
Ockert
+4Hi Charl,
I had to pull out my old CS lecture notes on this one :wink: The algorthm you are looking for is called a "Round Robin" and there are a number of articles on the web describing the pros and cons of this algorthm. The last BPM software I worked with had such a construct as standard within it.
To implementation: you must take care of "blockage", i.e. a recipient not being available for some reason. You may also need to take dynamic recipient lists into account. This would point me towards using a AD group or user management component.
Using "out of office" and delegation routing components you should be able to overcome the "blockage" problem. Hell, if you do not care how overworked certain members of staff are or that you do not receive that million dollar payment this month due to someone being sick, you do not care about using these components :wink:
Given that your UM component always returns the static receipient list in the same order (you could always sort the list anyway) you only need to know the last recipient you sent to. The "count" attribute of the list indicates you are at the end of the list.
This solution would take care of Ockert's stumbling point of hard coding recipient lists as well.
When you have implemented all of this perfectly, you must provide me with the complete solution in source code packaged as custom activities and events for ease of use. :wink:
Hope this helps
Graham
I had to pull out my old CS lecture notes on this one :wink: The algorthm you are looking for is called a "Round Robin" and there are a number of articles on the web describing the pros and cons of this algorthm. The last BPM software I worked with had such a construct as standard within it.
To implementation: you must take care of "blockage", i.e. a recipient not being available for some reason. You may also need to take dynamic recipient lists into account. This would point me towards using a AD group or user management component.
Using "out of office" and delegation routing components you should be able to overcome the "blockage" problem. Hell, if you do not care how overworked certain members of staff are or that you do not receive that million dollar payment this month due to someone being sick, you do not care about using these components :wink:
Given that your UM component always returns the static receipient list in the same order (you could always sort the list anyway) you only need to know the last recipient you sent to. The "count" attribute of the list indicates you are at the end of the list.
This solution would take care of Ockert's stumbling point of hard coding recipient lists as well.
When you have implemented all of this perfectly, you must provide me with the complete solution in source code packaged as custom activities and events for ease of use. :wink:
Hope this helps
Graham
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.