How to identify that an event occurred outside the workflow?

Thu Aug 22 19:24:55 EDT 2002

Thanks everyone for helping, there is so much to learn! Can't wait to get
my hands in THE Book (please make it available in Oz soon!!!)

I created an asynchronous method to ApproveInteractive and it worked fine.
I mean, although the user doesn't get the Confirm End Processing screen,
the workflow doesn't end 'abruptly'.

I am not sure if the users will like it though (a bit of good change
management should do?). In my previous workflow implementation the users
liked having the Confirm End Processing screen for two reasons: they could
add attachments and they were sure that they have executed the step. I will
leave as it is at the moment ie. asynch method and see how we go!

Thanks, cheers, have a great weekend!

Cristiana

==========
Jocelyn,

- on the async task with ... --- absolutely agreed. I just didn't know
there's also a background method to perform the approval.

- as of the coffee -- hope it was Ne.cafe :-)

Tomasz
(who's actually SAP, not Nestle)

=========
Hi Alon/Tomasz,
Honest, it's not that hard - an asynchronous task with a terminating
event is all that's needed.  That's why we have asynchronous tasks
with terminating events - to be used where we don't want to complete
the task until the system confirms the work has really been done, i.e.
updated the database.

We tend to drink the odd cup of coffee ourselves so we have thought of this
one before :-)
Regards,
        Jocelyn Dart
=============
Hi Cristiana,
No please don't do that - the wait-a-minute approach is not a reliable and
robust
solution and is therefore not suitable to a production environment.
Andrew's comments about using an asynchronous task with terminating
event instead of using confirm end of processing would be the correct
standard approach unless you have good business reasons for handling it
otherwise.

I'll see you in a few weeks.
Jocelyn
==========
Hi All,

The last comment that Andrew made is true in deed. If you still think
having a step in the WF canceling itself is ugly, instead of using
ApproveInteractive method, make the step a decision step. Once confirmed OK
to unlock, subsequent WF step performs a background unlock at an
appropriate time (eg. after all the notifications are sent).

Regards, Eva
=========
Hi Tomasz,

You are right. Its always the coffee that ruins your best Workflow
designs...:)

I like your way much better.

Regards,

Alon
========
But... if a user wants to grab some coffee before completing the task (it
takes 2 minutes on the average), this will not be safe either :-)

Normally a way to handle this could be passing some parameter into the
respective transaction that would only be set if the call occured via
workflow. Then in the code you'd have to raise the event only if the
parameter is empty. But this requires a change to the code, so it's
probably
not applicable in this case.

Another way of doing this is to:
1. Set a "lock" entry indicating the workflow is running for this object
instance. This could be done in some custom table early in the process.
2. Create another event (e.g. ABSENCE.ApprovedOutsideWF)
3. In the type coupling -- enter a receiver function module that will be
triggered upon ABSENCE.Approved and raise ABSENCE.ApprovedOutsideWF if the
lock is NOT set
4. In the workflow -- wait for ABSENCE.ApprovedOutsideWF instead of
ABSENCE.Approved
5. At the end of the flow -- clear the "lock" entry.

Still ugly, messy and far from perfect, but a bit safer. And it's 100% pure
workflow certified :-)

Tomasz
========
Hi Alon,

I tried your suggestion and it worked fine! However I don't know if the QA
reviewer for the project that I am working on (Jocelyn) will like that
idea!!

Thanks

Cristiana
===========
This is kind of ugly but could you put a 1 minute wait after the wait for
event step? That way it would ensure that the workflow gets a chance to
complete before the parallel step terminates it.

Alon Raskin
=========
Hi Christiana

Firstly if the ApproveInteractive method was asynchronous then it would
have
a terminating APPROVED event, in which case there would be no need for the
'confirm end processing'. This would be the best way of handling the
situation, but if the method has to be synchronous and you want to use the
'confirm end processing', what about putting in a process control step just
prior to it, and in that process control you cancel the other wait step for
the  APPROVED event. This way when the event happens you won't have to
worry
about your 'confirm end processing' being cancelled by the wait step. The
only problem then is if they don't actually approve it and it's done
outside
of workflow in the meantime, your wait step is dead and nothing happens.
Another way to look your present situation is that if the wait step picks
up
the APPROVED event and ends the workflow, why should the user need to
confirm end of processing? Maybe what you have is fine as it is.

Regards
Andrew Rankin
===========
Hi All,

I'm using 4.6c and implementing a workflow to Process Leave. Employees will
be applying for leave via ESS and workflow will be triggered.

The work item goes to the manager for approval but depending on the type of
leave the manager's approval will not unlock the record. Instead the record
will be sent to a central area where a few other checks will be done. I
created a task that will execute ABSENCE.ApproveInteractive ie. the user
will be taken to the screen and upon saving it the record will be ulocked
(this will generate event APPROVED). This task is also set up with
indicator for Confirm End Processing switched on.

I also have a Wait for event APPROVED step that will terminate the workflow
- this step was set up because someone might unlock the record via PA30,
outside the workflow...can you see the problem happening? Well, when the
user executes the work item and saves the record, the event APPROVED is
generated and terminates the workflow before the Confirm End Processing
screen happens...

How can I identify that an event has been generated outside the workflow?
If there is a way of doing it, I will be able to control if the Wait step
will terminate the workflow or not.

Any other ideas?

Much thanks and regards

Cristiana
_________________________________________________________________
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.