Is there a way to control variable scope in workflow?
Does the result/output of the "Crate Value" activity get global (as in app-level) scope , and if so, is there a way to control this?
We've got an app that has several workflows in it. Two of them interact with the same feature service, but different sets layers within it. Both workflows are configured to get the feature service URL plus a comma-separated list of layer IDs from workflow parameters.
The latter is converted to an array using a"Create Value" activity and the expression =$getWorkflowInputs1.inputs["layerids"].split(','). This is used downstream to iterate over all configured feature layers for reading/writing.
The problem is that even though both workflows are configured to operate on different layer IDs it appears that the ID array only ever contains the IDs of the layers configured for the first workflow that is run within a browser session.
A workaround is to give the "Create Value" activity different IDs (they were the same in both workflows initially as the activity was copied from one to the other), but this raises a question about which other activities may behave the same way?
Can anyone shed some light on this for me?
Thank you,
Jan
-
Hi Jan,
There is no way to control the scope of an activity. It is expected to be available anywhere within the current workflow after it has been created. For example, if you had a Container which contained a Create Value activity, you would be able to use that value anywhere in the workflow - even outside of the Container.
It should not be possible for a workflow to access a value that was created in a different workflow, though. If you think that's what you are seeing, it would certainly be a bug.
0 -
Hi Ken,
Thank you for your reply. What you are saying about a variable being accessible anywhere in a workflow makes perfect sense and is what I'd expect, however, I do seem to be seeing what you mention at the end of your message.
A variable in workflow B uses the value stored against a variable of the same name in workflow A, if workflow A was run first.
If I then re-load the WAB app and run workflow B first, workflow A will have the same value for the variable, so whichever workflow is run first seems to set the variable.
I was wondering whether this may be due to browser caching, but in that case I would expect the value to be the same across browser sessions. As mentioned I was able to fix this behaviour by assigning a unique ID to the activity in both workflows, but I'm now wondering whether I need to do this for other activities as well.
I'll do more testing next week and post my results.
Thanks,
Jan
0 -
Hi Jan,
Did you find out any more about this?
0 -
Hi Ken,
Thanks for following up on this. It had slipped off my radar but I've just run a quick test now, and the behaviour I am observing is what I would expect, so Workflow is actually working fine!
Quick description of the test:
- built a brand new WAB app and added three workflows to it:
- Workflow 1: add activity sequence: "Get Workflow Inputs", "Create Value", "Log", "Alert". Add to WAB app and configure a 'numbers' parameter with value "1,2,3", then use =$getWorkflowInputs1.inputs["numbers"].split(',') to create an array in the "Create Value" activity.
- Workflow 2: copy/paste all activities from workflow 1 into a new workflow, then save as workflow 2; configure WAB 'numbers' parameter to be "7,8,9"
- Workflow 3: save workflow 2 as workflow 3, configure in WAB with 'numbers' parameter value "4,5,6"
- Export & deploy to web server
The "Create Value" activity's ID property has a value of 'value1' in all three workflows. When I run each workflow in the app I only ever get the numbers configured for it, both in the log as well as the alert. I'm not sure what happened in the workflows from my original post, but maybe I just got confused. Variables have workflow scope, not app scope, and that's great!
Cheers,
Jan
0 -
Hi Jan,
Thanks for the update. I'm glad to hear it's working after all. I was keen to double-check as this would be an important thing to fix otherwise!
0
Please sign in to leave a comment.
Comments
5 comments