Reference Workflows - Valid URI
I cannnot get any URI to a Reference Workflow to work. I tried using the "gcxfile:///" syntax, but I could not get it to vlaidate in the Workflow Designer. So I used a complete UNC path from the root of the server to the workflow and it validates in Workflow Designer, but fails at runtime.
Can someone explain how to use the Reference Workflow activity and the "gcxfile:///" URI if my workflow file is the root of my Site and not in a subfolder of the site? Or even how to get a hard-coded URI to work?
-
Hello Sean,
The gcxfile:/// syntax accesses the sites directory, then you can add the path into the site you are working on. UNC paths will work as well.
Once you add the name of the .xaml file you are going to reference, you need to configure arguments with In/Out Direction and set the value field to be the actual values to pass to the workflow you are referencing.
In the workflow that is being referenced, you will need to create arguments with matching names to the other workflow's arguments, also with In/Out direction.
Let me know if you need any more information.
Stefan0 -
What if the parent and referenced workflows don't take in or pass out any arguments?
If the string "gcxfile:/// " = my Sites directory, then the path for my workflow - in a particular site's root folder - should be "gcxfile:/// [site folder name]/workflow.xaml "
Or the UNC path should be:
"\\[servername]\d$\Program FIles (x86)\Latitude Geographics\Geocortex Essentials\[instance name]\REST Elements\Sites\[site name]\workflow.xaml"
Correct?
0 -
Hi Sean,
That is correct for both gcxfile and UNC path.If you are not planning on sending any inputs/outputs between the workflows, I would suggest using Invoke Workflow or Invoke Workflow Async.
Stefan
0 -
I need to use a Reference Workflow because the child workflows contain client and external activities.
I've used both of those paths as described. The "gcxfile:///" path won't validate in the Workflow Designer with an error stating the workflow can't load the xaml file. The UNC path validates in the designer, but fails at runtime with the same "unable to load" error.
I'm trying to run a workflow that offers the user a choice of other workflows to run. The "I Want To Menu" was getting kind of crowded, and I don't want to display the entire list of workflows for the site. Since I want to offer a selection of ways for the user to search for Review Cases (e.g. by Permit Number, by Address Buffer, by Case Name, etc.), I was trying to use a display form with buttons for each search type that would call a child workflow to do that kind of search. If this is a bad idea, let me know.
0 -
Hi Sean,
gcxfile:/// paths do work. The interesting thing here is how the Workflow Designer application finds the Sites directory in order to root this path. It finds the Sites directory relative to itself (Geocortex.Workflow.Designer.exe). By default this is "..\REST Elements\Sites". If you look at where Workflow Designer gets installed "C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\<Instance>\Workflow Designer" this makes sense because the Sites directory is here "C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\<Instance>\ REST Elements\Sites ".
If you have more than one Essentials instace installed make sure you are running the corresponding Workflow Designer instance. Or else you will be looking at a different Sites directory.
If you are using a standalone version of Workflow Designer you will need to explicitly set the path to the desired "Sites" directory with the "gcx.io.fileSystem.path" app setting in Geocortex.Workflow.Designer.exe.config.
--Ryan
0 -
Thank you for that brilliant explanation!
Once you internalize the information that Workflow Designer is instance specific , it all falls together. I now have shortcuts for each of my instances and all executes as expected.
I think the documentation for Workflow Desinger needs to - wait a minute. There isn't any documentation for Workflow Designer!
Maybe someone should write a book . . . Geocortex Workflows for Dummies. I smell a small financial loss here . . .
Thanks again for the great help!
0 -
I think I'm running into the same issues.
For the workflow path, I'm trying to use this:
System.Configuration.ConfigurationManager.AppSettings("EssentialsRestBaseDirectory") & "\Sites\Resources\Workflows\Modules\ShowZoom.xaml"
That translates to:
F:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\4_5_0\REST Elements\Sites\Resources\Workflows\Modules\ShowZoom.xaml
I'm running the workflow design from my desktop, where I don't have a F: drive, nor any of those Latitude Geographics folders. The only way I could get this to work is to enter the hardcoded path and ignore the error when compiling. When the workflow runs from the server, the F:\ path is valid and everything works seemlessly. The bug seems to be that the reference workflow activity to trying to validate itself in the design-time and doesn't accept varriables to define the path.0 -
BTW: This path works too: "gcxfile:///Resources/Workflows/Modules/ShowZoom.xaml". It's better than defining the full path from the drive letter and needing to define the named instance of the version I'm runnung this under (4_5_0).
I still get the error when I run the workflow designer software from my PC. As long as I ignore the error, it works fine on the web server.0 -
And now, I fixed the error I was getting with the workflow designer, running from my PC.
I altered the file Geocortex.Workflow.Designer.exe.config and changed the value for the gcxfile from "..\REST Elements\Sites" to the fileshare path we have to the server
\\<server>\Development\Geocortex Sites (file://\\<server>\Development\Geocortex Sites)
Now the workflow compiles from my PC without errors and it works from the web server too.0 -
Seems like many of you have figured this whole gcx thing out. This concept is quite new to me and I am wondering if I should investigate my solutions around this area or elsewhere.
I have a workflow which calls a python script which dynamically overwrites the Legend.rpx file. Of course, the python script, legend.rpx and workflow are all saved under sites\[site_name] folder. Everything works great in local environment but when accessing the site externally, things are not working. I suppose this has something to do with Mike said, e.g. invalid file path etc. I am tempted to use gcx in my workflow so it can work on different servers. Am I on the right track? If so, I am wondering if there is any special requirement to use "gcx:///". For example, in my workflow I replaced the file location for my python script from "C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\Default\REST Elements\Sites\MapGallery_Geology_smp\Resources\overwriteFiles.py" to "gcxfile:///MapGallery_Geology_smp/Resources/overwriteFiles.py". And later I would use VBscript to execute the python code. But for some reason, it runs the hard coded path not for the gcsfile:///. I am sure I missed something in my approach. Please let me know if anybody has any idea? Thanks a lot in advance!!!0 -
Hi Dori,
The special "gcxfile://" protocol is summarized in the workflow help, and only makes sense for the activities that use it (Read File, Read File Bytes, Invoke Workflow, Invoke Workflow Async, and Reference Workflow). It was intended to provide an agnostic protocol to load files regardless of their actual path on disk (for example, when loading configuration in a clustered environment)
For your purposes you may want to use a workflow argument to set the path to your python script.
However, you may want to consider an alternate method for changing your legend. Writing out a file that will be used later by another component may introduce problems when scaling up for many users. We would consider using a dataset transformer workflow, or preparing the Dataset that will be sent to the print template such that the Legend RPX would not need to change. That way, your template will work with any number of requests and we can avoid a ton of issues that can come up with two users print at the same time.
Regards,
-Malcolm0 -
This thread is still helpful for the latest GE and HTML5.
Things to note - The ReferenceWorkflow gets cached on the Parent being uploaded. So if you refresh the child, upload the parent too. I wish I understood why this happens.
Passing Arguments In/Out from Parent to Child and Child to Parent is pretty clean. I recommend putting some Alerts in for testing.
I code everything on a laptop outside our clients networks so that will never validate and like others I mentioned about changing the configuration of Geocortex.Workflow.Designer.exe.config I cannot do that for network security reason. BUT I make sure all staff put the Workflows for each client's system in the SITES/VirtualDirectory so that would look like {gcxfile:///VirtualDirectory/Workflows/Shared/LG_COUNTY.xaml}
Here is a simple display of how I used it in a Parent Workflow
_img_ alt="User-added image" src="https://latitudegeo--c.na53.content.force.com/servlet/rtaImage?eid=907f200000013u4&feoid=Body&refid=0EMf2000000xG39" _/_img_0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
12 Kommentare