Restarting tasks that don't exist

[Michael Pokraka]

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