Single workitem for multiple IDOC errors?

[Michael Pokraka]

Hi Stephan,
Good thinking, thanks. I was trying to avoid wait events and deadlines,
but it may well have to be. The scary part is that these are apparently
batches of millions of idocs. Must mull over perfomrmance impacts of so
many wait steps if things go wrong during one of those runs...
 
To Paul's question: In a test system, SWWL is a nice little report to get
rid of any unwanted WI's. Not recommended for productive use though.
You mention ORDRSP, a lot of IDOC tasks include terminating events. Thus
if you can reprocess them via BD87 or similar, the WI's should
automatically all terminate.
 
Cheers
Mike
 
Becker, Stephan wrote:
> How about this logic: The workflow starts and as the first steps looks
> around whether another one of its kind is active. If yes, the workflow =
in
> question raises an event that all these other workflows are waiting for
> and
> that cause the other workflows to end or not send a message, whatever y=
ou
> want; of course do not end the workflow raising the event (check the
> instance and do not end the workflow if the event is raised by the same
> workflow instance that receives it).
> Once the workflow that is left is past the initial event, immediately s=
et
> the wait event again to the one that was there before, in case there ar=
e
> more workflows coming afterwards. That second event needs to be in a fo=
rk
> with one branch necessary to complete the fork, hence if another workfl=
ow
> triggers the "end" event afterwards, the other workflow will take the
> lead.
> In the second branch of said fork you have a dummy step with a deadline
> that
> will be active for as long as you set fit (eg the time it usually takes=
 to
> get all those idocs of one batch processed), and once that deadline is
> expired, the remaining lead workflow will send the error message.
> As the icing on the cake, you could transfer some data about the workfl=
ows
> that end themselves through the wait event, through yet another raise/w=
ait
> event that goes from the ending to the leading workflow, and you could
> collect that data in the leading workflow, then you even have an audit
> trail.
> This just off the top of my head without having tried it, anyone see wh=
y
> this wouldn't work?
> Greetings,
> Stephan
>
> -----Mensaje original-----
> De: Michael Pokraka [mailto:workflow at quirky.me.uk]
> Enviado el: 09 December 2003 18:38
> Para: SAP-WUG at MITVMA.MIT.EDU
> Asunto: Single workitem for multiple IDOC errors?
>
> Hi,
> I have a potential scenario where we want to prevent repetitive IDOC er=
ror
> work
> items. Client wants to know when an IDOC fails, but doesn't need 2000
> workitems
> to tell them that a batch of 2000 IDOCs failed for the same reason.
>
> Is there a 'neat' way anyone has implemeted to handle this sort of
> requirement?
> It does of course raise the question of reliability/traceability of WF =
for
> IDOC
> error handling, but that's a seperate discussion for the time being. So
> far
> looking at things such as a check function which looks for similar
> instances
> within n seconds, a workflow which interrogates inboxes, using a task t=
o
> log
> stuff into a table and generate WI's from there, ...  but thought I'd j=
ust
> see
> if anyone has any previous experience.
>
> Any input appreciated,
> Cheers
> Mike
>
>