Restarting tasks that don't exist

[Michael Pokraka]

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