Termination event is created before work item completion
Soady, Phil
phil.soady at sap.com
Fri Oct 21 08:48:17 EDT 2005
Ricks comments are valid. Look at the process control step differences
first. Select the appropriate one.
Another little Trick:
You can also add delayed start empty background task
after the event receive and before the process step.
ie If the WORKFLOW has logically shot itself.
WI x excutes a method. This method fires the terminating event
indirectly.
The WF is listening for this event incase someone does it externally /
manually.
The wait for event is valid in the WORKFLOW.
The method you terminate the workflow isnt. Or needs qualification or
controlled termination.
Becareful with the shotgun. Don't take your own head off. ;-)
I have added delayed start empty background steps to provide
a way to allow for a sequence of WIs to complete, before the fork
completes.
An even more elegant way is for the workflow to recognise
it has triggered the event indirectly by recording a WF container var .
TRICK 2.
container OP to record a value "No self destruct = 'X'.
call method...
event is fired
Parallel fork is triggered.
now the fork says CONDITION ? Self destruct ?
YES or no.
When NO, this parallel fork loops back to set the wait for event again.
This may sound heavy...
But I have found this a way of allow a workflow to complete but also not
miss events that should complete the WF.
In summary: To illustrate the 2 ideas in combined use
FORK
Loop MAIN BRANCH
CONTAINER OP (logic record expect own
event)
WAIT for EVT DO Method X
IF OWN event NEXT Method
nothing ...
RESEST Container var(optional on logic)
else Main Branch end
delayed start
empty step
COMPLETE WF/WI
endCondition
Endloop (until logic)
You should be able to find a valid scenario if you know which event is
fired by what action. And by noting when you want a particular workflow
branch to continue.
Happy Workflowing...
Phil Soady
Solution Architect
Business Technologies
SAP Australia
M +61 (0) 412 213 079
E phil.soady at sap.com
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Rick Sample
Sent: Friday,21 October 2005 2:20 AM
To: sap-wug at mit.edu
Subject: Re: Termination event is created before work item completion
Production is where we found our issues. Lessons learned!
>From what you described it sounds like simple race conditions.
You are telling the WF to terminate and that is exactly what it is
doing. Without
waiting for other forks, tasks, whatever to complete.
Just like with anything, you have multiple choices.
My choice is to develop so that the always "Completes". Not "Killed".
Reasons:
1.
If I need to add some step at a later time, I don't have to concern
myself
with this Terminate WF event issues.
2.
Depending on the WF, I may have a last step in the WF for various
reasons.
3.
Less confusing to end users that see their WF "Canceled" verses
"Completed".
Several reasons...
Rick
>>> solenkahraman at hotmail.com 10/20/2005 9:55:17 >>>
Rick,
Thanks for your reply.
We tested that workflow several times in our QA and development
environments
without any problems on the terminating event so that makes me think
this
could be production performance or something else.
I just tested again in QA and it is working fine.
Do you still think we could have some problems on the fork completion
or
this is a basis problem?
Thanks
>From: "Rick Sample" <Rick.Sample at graybar.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: sap-wug at mit.edu
>Subject: Re: Termination event is created before work item completion
>Date: Thu, 20 Oct 2005 08:05:03 -0500
>
>Also, if you need to wait a few seconds for other forks to complete
you
>can slow it
>down by creating a task with a obj-method that calls FM RZL_SLEEP at
>the end of fork.
>
>Example, wait for a send message(s) to complete. Of course you could
>create a terminating events
>on other tasks and make more robust, but this works fine for me.
>
>CALL FUNCTION 'RZL_SLEEP'
> EXPORTING
> SECONDS = 5
> EXCEPTIONS
> ARGUMENT_ERROR = 01
> OTHERS = 02.
>
>============
>Had this problem and worked around it.
>
>When you execute the Terminating event, it does not wait for other
>forks,
>processing blocks, etc. to complete. It just terminates.
>
>We create a separate fork(s) for events, let whatever needs to
process
>like
>send a messages, etc. and let the WF end.
>
>Rick
>
>
> >>> solenkahraman at hotmail.com 10/19/2005 14:54:46 >>>
>
>Hi,
>
>We are experiencing some problems with terminating events in our
>production
>environment. We didn't come across to those problem neither in dev
nor
>in QA
>environment.
>
>According to the workflow logs, work item execution is completed
after
>
>terminating event creation .That work item is awaiting for a
>terminating
>event but that terminatinf event has already been created before it
is
>
>completed so the result is it stays in user's inbox .
>
>Has anybody else had that problem before? The only solution I can
think
>of
>is to activate event queues for that work item but if anybody else
have
>a
>more robust solution , please advice.
>
>Thanks for your help.
>
>_________________________________________________________________
>MSN Messenger 7.5 is now out. Download it for FREE here.
>http://messenger.msn.co.uk
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
_________________________________________________________________
MSN Messenger 7.5 is now out. Download it for FREE here.
http://messenger.msn.co.uk
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list