When is an error not an error?

[Michael Pokraka]

Hi,
On the 4.6c system here there is no error:
 
         67080          46  Blahdiblah
<green> Michael Pokraka    Background work item created    18.03.2003 17:34:11
<green> Michael Pokraka    Execution started automatically 18.03.2003 17:34:11
<green> Workflow WF-BATCH  Work item processing complete   18.03.2003 17:34:18
<red>                 Message OL 808
 
This is a little worrying, but the existencecheck step as per Alon's
excellent suggestion has done it for this case.
Now to implement that in all steps where an object attribute in in any
binding...
Thanks again for all your input.
Cheers
Mike
 
On Wed, Mar 19, 2003 at 04:42:38AM +1100, Alon Raskin wrote:
> Well at least we all agree...
>
> As for the report, why not just create a report that finds all the WOrkflow
> which have a step which is in status ERROR but the Parent Work Item (the
> WOrkflow itself) is not in status ERROR.
>
> Wouldnt that find all the offending work items?
>
> Alon
>
> Quoting "Becker Stephan (extern)" <Stephan.Becker.ext at mchw.siemens.de>:
>
> > Hi again,
> >
> > I agree the case Mike describes should be reported to OSS and will most
> > probably be treated as a bug..
> >
> > The report I was hinting at below could comprise of a series of logical tests
> > that would quickly point to possible errors. I would probably base it on key
> > step numbers in the definition, and compare it with actuals. Eg you know
> > steps 1,5, and 7 must be worked through in quick succession because they're
> > all background, hence if not all of them are in the runtime version, chances
> > are there is an error. For most workflows, it should be relatively easy to
> > come up with a condition I should think, naove as I am ;-)
> >
> > Hth,
> > Stephan
> >
> > -----Original Message-----
> > From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> > Sent: Dienstag, 18. Mdrz 2003 18:11
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Re: When is an error not an error?
> >
> > Alon,
> > I'd love to hear that argument that this is NOT a bug!!! In our case
> > there is no task in error. The binding errors, task does not get
> > created, the last entries in the log are the completion of previous
> > trask, then this error, and nothing more.
> >
> > Anyway, this explains a lot, but has led me onto another problem....
> > watch for the next instalment on this list :-)
> >
> > Thanks for that, not sure if I can now rest easily knowing the
> > answers.....
> > Cheers
> > Mike
> >
> > On Wed, Mar 19, 2003 at 03:24:16AM +1100, Alon Raskin wrote:
> > > Hi Michael,
> > >
> > > I am with you on this. I think this is a nasty 'feature' and I also agree
> > that
> > > this is a bug with the Workflow sub-system. if the item has gone to error
> > then
> > > so should the Workflow. I took this up with SAP on the last project and
> > they
> > > refused to admit that this was a bug. I ended up going back and forth with
> > them
> > > on this for quite some time to no avail. It even got to the point where
> > myself
> > > (and another on site SAP Consultant) debugged the Workflow code.
> > >
> > > I think the error is caused if an attribute that you are accesssing does
> > not
> > > exist. The property you are accessing should be returning a
> > > EXIT_OBJECT_NOT_FOUND if the attribute does not exist.
> > >
> > > In your binding you have bound Object1.Object2.Key The expression errors
> > > (sometimes) because Object2 reurns a EXIT_OBJECT_NOT_FOUND which for some
> > > unknown reason errors the Task! (but not the WOrkflow).
> > >
> > > The way 'around' this is to do a 'EX' Condition (object Exists) on Object2
> > > before calling the method (which has the problem binding). If the EX
> > condition
> > > check fails then dont call the method.
> > >
> > > Regards,
> > >
> > > Alon Raskin
> > > www.desktopworkplace.com
> > >
> > >
> > > Quoting Michael Pokraka <workflow at quirky.me.uk>:
> > >
> > > > Hmm, problem is that there _is_ an exception (red light in the log), and
> > > > the error happens in the binding - i.e. before any method execution.
> > > > The error itself is arbitrary, what does worry me is that a  binding
> > > > error can cause a WF to simply come to a silent stop whilst remaining
> > 'in
> > > > process'....
> > > > Sure one can argue that the design needs to be robust enough to handle
> > > > it, but when you're working at a client who already has a whole bunch of
> > > > their own flows this is not always an option.
> > > >
> > > > By the way, what would a little report look for in this case?? Other
> > > > than deadlines or trawling through the logs I can't see much of a
> > > > concrete option.
> > > >
> > > > Thanks for the input,
> > > > Cheers
> > > > Mike
> > > >
> > > > On Tue, Mar 18, 2003 at 01:51:41PM +0100, Becker Stephan (extern) wrote:
> > > > > Hi Michael,
> > > > >
> > > > > Think about it what you will, but if a method does not return an
> > explicit
> > > > exception, the behaviour that you see is all you get..
> > > > >
> > > > > The only solution in my experience is explicit exception coding, plus
> > a
> > > > little report that finds abended workflows in production..