Resetting Destination Users on an activity

  • 6 November 2008
  • 5 replies
  • 2 views
P
Badge +3

All,


Got a problem with some processes.


We use a look-up to a SmartObject to identify Destination Users (by role and country data). This is working very well for us, however we've run into a problem when users change - especially when we running Mail events or Escalation mail events. Scenario: a process is running, and 4 destination users are identified for an activity. They get the item in their worklist. Then one of the four people leaves, and their AD account is inactivated. A day later, the escalation email is triggered, but because not all the Destination users can be reconciled as active users in AD, the mail event errors, and nobody can progress the Process Instance.


What I'm looking for is a way of either a) triggering a reset of the Destination Users for the whole activity, or b) finding the list of Destination users for that Activity in the SQL Database and removing the now-departed user. I really don't want to delete the process instance and start them again, because these are pretty far down the chain, and I don't want to 'upset' the user community by making them re-work a great deal of stuff.


Any ideas?


Paul

5 replies

S
Badge +4

I presume when you say that you are doing a look-up that you are doing this in the process.  What you might want to try instead is creating a role in the workspace, adding that to the Destination Set instead of the Smart Object, then adding the Smart Object to the role.  You can then make the Role dynamic and set how often it refreshes (defaults to 10 minutes).


Hope that helps.

P
Badge +3

Yes, we are doing the look-up in the process, but we are referencing data held in two (sometimes three) smartobjects and also Process Level datafields, then looking up the user table held in a further SmartObject. I can see that this would be the best long-term solution, but given the number of Activity instances we have, and the number of reference points we use to determine the destination Users, the amount of work involced in applying this solution is currently prohibitive.


 Is there a way that I can look up the correct SQL table that would list the identified Destination Users for a  specific Activity Instance, and then update the table to remove the 'rogue user'? That would allow us to then retry the errored proccesses and it should go through...?

A
Badge +9

You could probably use the K2 Process Management to achieve this.

You can find process management under the view menu in Visual Studio. I have used this in the past to fix problems that have occurred - it allows you to open the code of a process that is in error, put in a fix, deploy the fixed code (the altered code would only be used for the current instance of the process), and then retry. You could probably add some code that replaced the user that has left from the list of email recipients with the new user's email address (or something similar??

Have a look at the following link for more info on process management
http://www.k2underground.com/blogs/howtok2/archive/2008/07/24/process-error-repair.aspx

P
Badge +3

Thanks for that one. It's useful to know, although still maybe a longer term fix and still sounds like it involves a considerable effort (I would need to make the update to cover somewhere in the region of 300 distinct activities.)


 However, do you know which table in SQL the destination users for specific activity instances are held in? That way, for these that are giving the issue now I can go in and remove the old user?

S
Badge +4

If you are not using DestanationQueues at all then I think might want to do is join between _Proc -> _WorkList -> _Actioners and then remove (or reassign/delegate as appropriate) any Activity Instances assigned to invalid users for that Process Instance.  You might be better off going through the API than directly to the database.  I suggest taking a look at SourceCode.WorkFlow.Client if you want to do that.


I'd be curious to hear if updating _WorkList directly works, though :-)

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings