ReferenceWorkflow and cacheing
Hello,
I'm developing a workflow that references other .xaml files in order to make it easier to maintain.
It works great however I'm seeing some unexpected behaviour when using the 'ReferenceWorkflow' activity during development.
If I edit the workflow that is being called (referenced), then re-run the tool in essentials, the changesI have made don't come though, i have to adjust the path in my referenceworkflow activity to make the changes appear. I assume some sort of cacheing is occuring?
Can i clear this cache so that the workflow always references the latest version? (during development?)
a side question: how does the 'gcxfile:' variable work when referencing workflows? i.e gcxfile:\\\my folder\myworkflow.xaml - where does essential get the relative path from?
Any support gratefully recieved.
Thanks,
Nick
-
Hello Nick,
I tried to reproduce the issue that you are seeing with ReferenceWorkflow but was unable to. Everytime I make changes to the referenced workflow, it runs successfully. What version of Essentials are you running?
The 'gcxfile:\\\' path references your sites directory by default. I believe this value is set in the Manager web.config file in the key: gcx.io.fileSystem.path
Thanks, Stefan
0 -
Stefan,
Thanks for the swift response and the info about the gcxfile - i can use this with more confidence now.
I'm developing the workflows in essentials 4.1.0
and running the site in a silverlight viewer at version 2.2 i think.
as an aside I renamed the child workflow in an attempt to force a refreash, which worked, but the interesting thing was that the parent workflow refused to load (and caused an exception) because it couldn't find the child workflow, even though it hadn't required it yet. i.e. the parent workflow loads all referenced workflows into memory as it is loading itself. This seems like a waste of memory to me!
Nick
0 -
Hi again Nick,
I tried to reproduce the issue in GE 4.1 but I wasn't seeing the same errors. You are correct about the Reference activity, it checks for the existence of the referenced workflow as it is being updated.Thanks, Stefan
0 -
We had this problem. You might need to refresh the essentials application pool in IIS to force a new instance of your workflow to be loaded. Essentials does seem to cache them otherwise.. 0 -
Hi:
Wondering if it is possible to revisit the use of the ReferenceWorkflow activity and memory caching by Essentials. We are experiencing a related issue. We have parent-child workflows and needed to modify both. At first we managed to coordinate parent with child but now an error is being thrown as a consequence even after restarting the IIS app pool and IIS site. Here is the error shown in an Alert box:
"There was a workflow error running activity: Exception has been thrown by the target of an invocation. Workflow 'ParentWorkflow' failed. Aborted exception: 'The calling thread cannot access this object because a different thread owns it'."
Any suggestions on how to resolve would be much appreciated.
Thanks,
Ralph0 -
Hi again:
To anyone who read my post, many thanks but it has been resolved. It turns out the error existed in the child workflow and related to an embedded Sequence...probably not the best practice. Nevertheless, simplifying the activity sequence in the child workflow made the difference. Suppose that the error thrown might be of interest to others, given that it mentions the parent workflow only and seems to refer to a memory/thread issue. Might want to look deeper in the workflow processing. If anyone can offer further clarification, that would be very useful.
Thanks again,
Ralph
Ralph0 -
Hi yet again:
Forgot to mention in previous post what was required to refresh the parent workflow when changes were made to the child workflow...here is what seemed to work ok:
1. point parent to dummy child path;
2. run parent workflow...deosn't work...that's ok;
3. modify child workflow and save;
4. go back to the parent workflow and point to the correct child path and save...
5. parent should now pick up the changes in the child workflow when the whole sequence is run again
The recycle and restart of the IIS App Pool didn't seem to work for use to clean up the memory cache referred to in earlier posts.
Thanks again,
Ralph0 -
Hi Stephan,
I have two things that feel are unproductive:
1. The referenced workflow being "compiled" into the <sads:DebugSymbol.Symbol> tag of the parent workflow. I'm not too woried about the space it takes, but mostly about the unproductiveness of such a referencing of a child workflow. Because all parent workflows needs to be re-saved after modification of a child workflow. This can become very combursome when there are multiple level of child workflow or when there are multiple parents to a child.
Is there a way to avoid that caching of a child workflow into the parent? If not, is that something that could be done in the future version of Geocortex Workflow Designer?
2. My second issue is the fact that the ReferenceWorkflow activity tries to load the referenced workflow and it can't it sends an error. I understand why you'd want to load the referenced workflow, but that makes the use of gcxfile:/// in the Uri to reference a workflow send out an error in the Designer. Yet it works fine when I call the workflow in my application.
Is there a way ignore that particular error in the workflow, simply to send a warning or something like that. Because that will create a lot of confusion for the developers when they'll always have the notice of error when they build workflows.
Thank you
Denis0 -
As a note, I would use the InvokeWorkflow command, but I can't because the esri.geometry.Geometry object is not serializable. Is it also more work to create and read dictionnaries instead of simply passing the variables in arguments. 0 -
I agree that the error thrown by the ReferenceWorkflow activity in the Designer is confusing. 0 -
I had this problem too. Denis gave the answer that works for me:
"Because all parent workflows needs to be re-saved after modification of a child workflow."0 -
Hey guys,
In lieu of the reference workflow activity, you can use the Run External Command activity. Just use the command "RunWorkflowById", and set the parameter to the ID of the workflow you've added to your site. When invoking a workflow in this way, you will not need to go back and re-save the workflow you are referencing.
Thanks,
Danny0 -
Daniel, if I use RunWorkflowByID I can send values to the child workflow but I need to get values back as well, which is handled very well by ReferenceWorkflow. If I use RunWorkfloByID, how do I get values back from the Child workflow when it is complete?
Saving the parent workflow after the child workflow is updated did not fix the problem of having a 'stale' child workflow. After updates to the child are made, the only way to get the parent to 'see' them is to save the child with a new name, then point the parent to the new child. This is a cumbersome and extremely frustrating workaround.0 -
Hi Tami,
You're correct that Danny's workaround doesn't have a good solution for sending values back to the parent workflow from the child. You could use SetExternalValue, but then you likely wouldn't have a good way to time the execution of the GetExternalValue activity. ReferenceWorkflow handles this better.
Saving the parent workflow after the child workflow is updated should update the 'stale' workflow in a ReferenceWorkflow activity. I tested on my end on the latest version in case something changed, and it seems to be working. If that isn't working on your end, I would recommend starting a support case so that we can investigate the issue.
Thanks,
Amanda0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
14 Kommentare