Restarting tasks that don't exist

[Dart, Jocelyn]

Just a suggestion - why not create a delegated subtype of USR01 - and redefine the existence check method to swap the object key to the wf administrator if the user id does not exist instead of throwing an exception.
Should work.
Suggest you also set up a virtual attribute to indicate if user-is-wf-administrator - you're bound to need to know sometime if you have a real user or just the administrator.
Jocelyn.
 
 
-----Original Message-----
From: Michael Pokraka
To: SAP-WUG at MITVMA.MIT.EDU
Sent: 22/07/2003 12:03 PM
Subject: Re: Restarting tasks that don't exist
 
Hi Jocelyn,
This is in a delegated subtype, and is actually something I put in place
for a few object types without realizing that they wouldn't be
restartable.
The idea is to use ZBUS9999.ZsomeUSR01.NAMEWITHLEADINGUS as an agent,
rather than create two attributes - 'user' and 'user object'. We also
make further use of the USR01 object for custom email setups - hence the
object is required anyway.
 
Perhaps I'm trying to get too generic here, the loop would be to make
sure an obbject is instantiated or to route to someone to pick an agent
and then retry with a new person. Though the real reason is to try to
work around corporate policy to delete users as they leave - no
forwarding, no substitution, no HR - making this a bigger problem than
it should be (in my humble opinion).
 
Thanks for the input,
Cheers
Mike
 
 
On Tue, Jul 22, 2003 at 08:34:30AM +0200, Dart, Jocelyn wrote:
> Ok Mike, but why don't you just redefine the relevant virtual
attribute in a delegated subtype instead of changing all your workflows?
It's got to be easier that adding loops everywhere.
> Jocelyn.
>
> -----Original Message-----
>> From: Michael Pokraka
> To: SAP-WUG at MITVMA.MIT.EDU
> Sent: 7/21/03 7:39 PM
> Subject: Re: Restarting tasks that don't exist
>
> Hi Sergey,
> Thanks for your input. I mostly agree, but it just seems a waste of
> effort to have to build big workarounds for what could be considered a
> design issue.
> For e.g. a virtual attribute used in a binding rather than an agent
can
> be changed, and the task does at least get started. The problem with
> this one is that it cannot be restarted - 'restart after error' just
> reevaluates the attribute, fails and doesn't create a task. No task =
no
> way of fixing attribute.
> This is on 4.6c by the way - I believe the agent determination works a
> little differently in later versions (including the option to
> re-determine agents), so perhaps this has already been addressed.
>
> Ah well, looks like we're stuck with changing all agent-object
> references and building loops all over the show... grrr. (annoyed
> because these are already quite convoluted flows, now getting messier
> and messier).
>
> Thanks again.
> Cheers
> Mike
>
>
> On Thu, Jul 17, 2003 at 03:53:28PM -0500, Breslavets, Sergey wrote:
> > seems like not much options: since you use virtual attribute to
> determine an
> > agent you either have to change it's logic or some input data to get
> alternative
> > result.
> > I use this method too, but check if the found agent exist in the
> system before
> > returning ACTOR_TAB, if not - forward Wi to admin.
> > Another option is to use Org Objects (e.g. return positions instead
of
> the
> > assigned users from the virtual attribute).
> >
> > As for existing instances, you can "restart them after error" after
> fixing the
> > attribute.
> >
> > Thanks,
> > Sergey
> >
> >
> >
> >
> > -----Original Message-----
> > From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> > Sent: Thursday, July 17, 2003 9:55 AM
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Restarting tasks that don't exist
> >
> >
> > Hi all,
> > Got a situation here: Taking full advantage of the whole
> object-oriented bit, we
> > direct a WI to ZBUSwhatever.ZCREATEDBYUSR01.NAMEWITHLEADINGUS, which
> works very
> > nicely, except when the user no longer exists.
> > In this case, the workflow ends in error, but with no step to
correct.
> This
> > means that there is no way to restart the workflow, bar recreating
the
> user in
> > the system.
> >
> > I know we can change things and build custom virtual attributes with
> validation,
> > but this seems like a lot of work to fix something which should not
> really
> > require fixing, as well as getting away from the whole
object-oriented
> > philosophy.
> > Also, this doesn't help the existing error items (which are quite
long
> > workflows, so creating new ones will upset some people.)
> >
> > Any thoughts on this?
> > Cheers
> > Mike