Input/Output variables for tasks not visible in the user interface

[yawlfoundation]

Hi,

I would like to be able to use a variable in a task as an input and output
variable which I do not show to the end user.

Motivating scenario: In the conf.example (see attached file) I have a list
(called Paper List) which I am building by gradually appending an element
to it (i.e. a Paper). The values of this element are retrieved from the
user during the execution of a task which may be executed several times
consecutively (i.e. during the SubmissionRegistration task a paper is
registered. This is repeated until a deadline expires). During an execution
of the task, from the user I only need to retrieve information for one
element of the List, i.e. the registration of a single paper (for this I
need one output viable). I also need to have the List as input and output
variable to the task, so I can append the new element to it. However, I do
not want to show the complete List to the user at that stage in the
process. Nor do I want to allow him/her to change it (i.e. because it is an
output variable, currently the user can potentially modify its values).

Cheers, Petia

Original issue reported on code.google.com by petia.wo...@gmail.com on 20 Nov 2008 at 10:59

Attachments:

• Conference-Example-Editor-v2.0-Example-v5.0.yawl

[yawlfoundation]

Yes, agree as another user. Note that you can stop the user modifying it by 
setting
the readOnly extended attribute to True. So perhaps the cleanest solution would 
be to
add a visibleToParticipant (or similar) extended attribute as well??

Original comment by monsieur...@gmail.com on 15 Oct 2009 at 4:37

[yawlfoundation]

Maybe there is a slightly wider discussion to have here. The reason why users 
need
this type of functionality is, as Petia says, typically to *update* net level
variables from task outputs (rather than replace their whole contents), 
something I
have found a relatively common requirement in data-driven projects (and 
something I
was going to raise here anyway if I hadn't seen this Enhancement).

This whole issue of using "Input & Output" type variables to be able to do this 
is
because net level variables aren't in scope for XQueries in the output parameter
mappings for a task decomposition. If they were (as they *are* for input 
parameter
mappings), this would be a more powerful solution.

If you had a net Net1 and a papersList var. (such as Petia discusses) then, for 
a
task decomposition AddPaper, then this would support an output parameter XQuery
something like:

{/Net1/papersList/*} <paper> {/AddPaper/newPaper/*} </paper>

However, I have no idea how this "restriction" relates to the underlying 
workflow
theory and/or the YAWL implementation. My initial (probably wrong) assumption 
is that
it's like it is because the task output exists as a standalone XML document on 
which
the XQuery acts, and the net variables exist as another. Thus, making this scope
visible *by default*, with the design as it stands, would mean copying the 
entire net
document into the task output one (with concomitant performance and storage
overheads). So it is left to the user to only "import" the variables they 
explicitly
need via "Input & Output" type variables (but this participant visibility issue 
then
remains).

In this context, I guess Petia's original requirement boils down to a special 
"Net
Passthrough" variable type (i.e. equivalent to Input & Output but invisible to 
the
participant). Maybe that's a better way to go than another extended attribute 
(so it
becomes native to the YAWL engine itself), but appreciate that there may be
theoretical or other reasons not to do this.

Original comment by monsieur...@gmail.com on 16 Oct 2009 at 10:49

[yawlfoundation]

Really sorry for the multiple posts, but just remembered something vital I'd 
missed
out. (You wouldn't think it was possible to miss something out in that length 
post,
would you? :-) )

This "net passthrough" process should also ensure that the required passthrough 
data
is not sent at all to custom services. I have precisely this issue at the 
moment: I
am calling custom services and using the task decomposition's XQueries to 
update a
net variable at the output stage. I currently have to declare it Input & 
Output, and
have my custom service copy the inputs across to the outputs before doing 
anything
else. It would be much nicer if the custom service never saw this passthrough 
data
which it isn't at all interested in (and similarly for the resource service when
doing the UI for human-performed tasks).

The whole solution also gives a performance gain compared to an "invisible 
Input &
Output type" equivalent solution...

Original comment by monsieur...@gmail.com on 16 Oct 2009 at 12:01

[yawlfoundation]

A workable solution to the initial issue is to use the 'hide' extended 
attribute on an I/O variable, making it accessible to xqueries but invisible to 
users.

The functionality described in comments 2 and 3 would involve a very large 
refactoring of both the engine and the editor, and at this stage the costs far 
outweigh the benefits (esp. since there is a workable solution to the issue). 
However, I'll leave this issue available as a possible future enhancement for a 
time when resources are available. 

Original comment by yawl.mic...@gmail.com on 28 Apr 2014 at 3:48

• Changed state: UnderObservation
• Added labels: Priority-Low
• Removed labels: Priority-Medium