'Detached' task processing

[Mark Pyc]

Mmmm hardcoding!

There is always the option of copying the standard tasks (for historical 
reasons) before changing the SAP standard tasks to call a method that does 
what you want. Obviously has to keep the same signature, but I have used the 
technique before in a 3.whatever system for document scanning.

Don't know enough (and luckily for me no one is paying me to know) about 
your problem to know if it's useful, but worth a mention maybe.

From: Michael Pokraka <workflow at quirky.me.uk>
Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Subject: RE: 'Detached' task processing
Date: Tue, 25 Jan 2005 04:18:49 -0800 (PST)

Hi Mark,
Yes, a method to kick off a task is exactly right - just pass on the 
container
table and we're a-OK. So simple I should have thought of it myself, but the
caffeine is only just starting to approach normal operating levels.

The finer trickeries involve two factors: One is to check whether existing
instances of a workflow are active - one would need to exclude certain tasks
because they don't count, and the more ugly part involves SAP code that 
looks
for specific task numbers and statuses (yes, hardcoded, umpteen OSS notes
listed at the top of most ABAP's... need I say more).
I need to fudge the flows to make them look complete and possibly fire off a
few dummy SAP tasks and complete them programatically (yes, this REALLY is
Ugly!).

Thanks
Mike

--- Mark Pyc <markpyc at hotmail.com> wrote:

 > Is it really necessary that the main WF complete ASAP? If you only need 
to
 > have the flow continue then obviously the notification items can be 
hanging
 > off in a parallel branch and the main WF logic will continue. The only 
issue
 > is that the whole WF won't complete until all notification items have 
been
 > opened and completed.
 >
 > If you really need them as mini-WFs so the main flow can complete, I 
would
 > have thought a method that programmatically starts the task rather than
 > event based linkage would be easier. Less to define and largely you could
 > just pass the inbound method container straight to the FM triggering the 
new
 > task. May just need to fudge the move of the main object (self) into
 > _WI_Object_ID.
 >
 > Even with multiple tasks the creation of a little config Z-table and
 > suitabley dynamic code should mean you only need the one method to handle
 > any and all of the tasks.
 >
 > Any more info to indicate the trickeries of the problem?
 >
 > From: Michael Pokraka <workflow at quirky.me.uk>
 > Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
 > To: SAP Workflow User Group <sap-wug at mit.edu>
 > Subject: 'Detached' task processing
 > Date: Tue, 25 Jan 2005 02:03:58 -0800 (PST)
 >
 > Hi all,
 > I think the answer is a 'no go' but... I would like to execute a task and
 > have
 > the workflow continue before the task is complete.
 >
 > The simple answer - raise a custom event & trigger the task seperately. 
Can
 > be
 > done, except there are a few different tasks with lots of container info
 > (HR)
 > and it's going to get a bit messy. Just wondering if there is another way 
or
 > interesting design ideas to kick off a bunch of flows/task and pass over
 > lots
 > of container stuff and have the calling flow continue. (In other words an
 > asynchronous start).
 >
 > For what it's worth - these are a bunch of notifications that should by 
all
 > rights be sent as emails (which means the flow would resume/complete once
 > sent), but have to be workitems instead.
 >
 > Cheers
 > Mike
 >
 > _______________________________________________
 > 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
 >
 >

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug