Advise and question about adding container elements for monit oring purposes

Soady, Phil phil.soady at sap.com
Tue Jul 29 15:46:23 EDT 2003


Thanks for the update.
I see your reason now.
I like Mike's idea Encapsulating special tasks for analysis in a subworkflow with 1 step
 
Did you try WIS as an answer to the task analysis ?
 
It might be worth raising a development request for the SWI5 analysis shortfall.
 
Regards
 
Phil Soady
Senior Consultant
Business Technologies
SAP Australia
* : 0412 213 079
* : phil.soady at sap.com
 
 
 
 
 
-----Original Message-----
From: Michael Pokraka [mailto:workflow at quirky.me.uk]
Sent: Tuesday, July 29, 2003 11:54 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Advise and question about adding container elements for monit oring purposes
 
 
I agree with both responses: Generic tasks should be the aim, I normally try to stick to that as far as possible. When it becomes unfeasible (for reasons similar to Fred's I then create a second copy of the task. I wouldn't go as far as including a WS... number in the task though. There are often a few tricks for working around some of the issues mentioned though, I've used subworkflows, 'text' container elements (i.e. 'hardcoding' something in the binding from WF->Task). Cheers Mike
 
On Tue, Jul 29, 2003 at 03:30:32PM +0200, Kouw, FA - SPLTX wrote:
> Phil,
>
> Mainly because of the following:
>
>    * re-using tasks in different workflows makes it more difficult to monitor running instances (f.i. when using 'SWI5 - Workload analysis' the task number and task description are shown. If the task is re-used in different workflows it is difficult to see for which workflow templates a user has work items in his/her inbox;
>    * when changing a task it's only necessary to know the impact on one workflow template instead of the impact on more than one workflow template (on the other hand this could mean that multiple similar tasks need to be changed....);
>    * re-using tasks would mean that the task definition has to be
> generic (valid for all workflow templates in which it is used). That
> means that the task description must not contain workflow template
> specific information (which is often the case).
>
> Hope this makes sence to you, otherwise I maybe need to 're-name' the
> tasks in case a workflow needs to be changed. I appreciate any advise!
>
> Regards,
>
> Fred
>
> "Soady, Phil" wrote:
>
> > Hi Fred
> > Out of interest Why didn't you want someone to re-use the tasks ?
> > Which problems are these?
> >
> > Re-use of tasks is one of the goals, so im interested why someone
> > deliberately tries to avoid re-use.
> >
> > Regards
> >
> > Phil Soady
> > Senior Consultant
> > Business Technologies
> > SAP Australia
> > * : 0412 213 079
> > * : phil.soady at sap.com
> >
> > -----Original Message-----
> > From: Kouw, FA - SPLTX [mailto:fa.kouw at td.klm.com]
> > Sent: Tuesday, July 29, 2003 10:21 PM
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Re: Advise and question about adding container elements for
> > monitoring purposes
> >
> > Thanks Mike !
> >
> > I was referring to note 125400, but didn't understand the impact of
> > changing the container. Now (I think) I do. I'll add the container
> > element and add the binding from the triggering event to that
> > container element.
> >
> > In my case copying my workflow also means copying the tasks (and
> > replacing the tasks and (re)defining the bindings), because I
> > created tempate specific tasks (included the template ID, the last 3
> > numbers in the task abbreviation). I've done this to be sure that
> > tasks are not re-used, in order to prevent problems that can occur
> > when using tasks in different workflows. Maybe this was not a very
> > smart thing to do...(?)
> >
> > Regards,
> >
> > Fred
> >
 


More information about the SAP-WUG mailing list