Termination event is created before work item completion

[Rick Sample]

>>You can also add delayed start empty background task
Yep. When you want / need to wait at least a minute. 
Yes, I do use it but sparingly. If other event handling like error
trapping, 
logging, etc, is required I prefer to throw event(s) to communicate to
WF 
and do some other tasks if needed. You never know how long some 
processes will actually take and "x" minutes may not work.

>>ie If the WORKFLOW has logically shot itself.
What it "sounded" like he was referring to in the original thread was
the 
'Terminate Workflow' function AND waiting for a terminating event 
in a task somewhere. Terminate Workflow fired first, for whatever 
logical reason, and the terminating event was never kicked. 
If I miss understood this, many apologizes.

Like I said, many choices in the world of event handling with WF. 
We have to take a lot into consideration when making these decisions
like 
Cost of design and development, complexity for support, etc. 
It clearly makes sense to just stick an empty task at the end of a
process 
and wait X minutes if that fork is just sending a bunch of messages
before the WF ends. 
No need to make a design more complicated than needed. 

Now, getting back to the original issue. 

>>
> According to the workflow logs, work item execution is 
> completed after terminating event creation .
Task is completed after the event. This sounds correct. 
The logs may be a tad misleading when dealing with events.

>>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.
What is the task doing? 
What is triggering the terminating event for the task? i.e. is a method
in the 
task triggering the term event, or is the term event triggering outside
of the task 
via a listener while the task is processing? 

Rick


>>> phil.soady at sap.com 10/21/2005 7:48 >>>
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.
>