Workflows starting for deleted objects - nevermind

Dart, Jocelyn jocelyn.dart at sap.com
Mon May 19 15:11:10 EDT 2003


Hi Mike,=20
Glad you've solved your problem - the following is just for everyone's =
info...
 
For instance-independent methods, workflow DOESN'T need an object =
instance instantiated, however it does have
to recognise the object handle you are using as a valid object handle.  =
 
 
So you can "instantiate" your object with a dummy key - e.g. SPACE - to =
create the valid object handle and=20
then use your instance-independent object attribute/method.  Something =
to keep in mind for coding - and another
case where method SYSTEM.GENERICINSTANTIATE can come in handy.=20
 
Regards,
        Jocelyn Dart=20
Consultant (SRM, EBP, Workflow)
and co-author of the book
"Practical Workflow for SAP"=20
SAP Australia
email: jocelyn.dart at sap.com=20
phone: +61 412 390 267
fax:   +61 2 9935 4880
 
 
 
 
-----Original Message-----
From: Michael Pokraka [mailto:workflow at quirky.me.uk]
Sent: Tuesday, 20 May 2003 1:34 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Workflows starting for deleted objects - nevermind
 
 
Yup, but workflow still assumes that if an object has a key it must be =
instantiated - even for instance indep. methods. (At least that is what =
it looks like).=20
So it still fails.=20
 
On the other hand, I've been missing the obvious all along - a check in =
the start condition does the trick...  I do feel a bit silly now.=20
 
Thanks for the input though...=20
 
Cheers
Mike
 
On Mon, May 19, 2003 at 02:45:53PM +0200, Schmidinger, Heinz (Unaxis IT =
BZ) wrote:
> the create object handle is the problem, so I thought to use an own =
method
> instnceless defined which is not trying to create an object which is =
only
> giving back a paramter.
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Michael Pokraka [mailto:workflow at quirky.me.uk]
> Gesendet am: Montag, 19. Mai 2003 14:41
> An: SAP-WUG at MITVMA.MIT.EDU
> Betreff: Re: Workflows starting for deleted objects
>=20
> Ahh, but that is exactly what LIKP.EXISTENCECHECK doe. Or at least =
it's
> supposed to do.=20
> But... as far as I can figure, since it has a key, it must exist, =
therefore
> workflow instantiates the object (or at least it tries to) before =
executiong
> the method. In the trace it fails with 'Object handle for object =
cannot be
> created'.
>=20
> Thanks for the input,=20
> Cheers
> Mike
>=20
> On Mon, May 19, 2003 at 01:16:10PM +0200, Schmidinger, Heinz (Unaxis =
IT BZ)
> wrote:
> > Hi Mike,
> >=20
> > just an idee:
> >=20
> > cretae an own instanceless method just reading the table if row =
exists and
> > return a parameter (not)exits.
> >=20
> > regards
> >=20
> > Heinz
> >=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Michael Pokraka [mailto:workflow at quirky.me.uk]
> > Gesendet am: Montag, 19. Mai 2003 13:02
> > An: SAP-WUG at MITVMA.MIT.EDU
> > Betreff: Workflows starting for deleted objects
> >=20
> > Hi all,
> > Another question to ponder:
> >=20
> > Users often create deliveries and delete them straight afterwards =
(I'm too
> > scared to ask why - but I assume it's when they mess things up and =
want to
> > start again).
> > Now, we have workflows that start after a LIKP.CREATED event, using =
the
> > event queue. The Queue introduces a delay, and hence we have =
workflows
> which
> > fail straight away (object doesn't exist). Adding a task based on
> > LIKP.EXISTENCECHECK also fails, it appears to be that it falls over =
when
> > instantiating the object in order to check it's existence... =
(duh!).
> >=20
> > Any ideas would be welcome...
> > Thank
> > Mike
 


More information about the SAP-WUG mailing list