Override workflows
Hello,
I have poste this already under the Workflow topic, but then thought it may be more applicable and visible here.
I am working on override workflows to edit and add features in Mobile.
Most of the functionality I want is there already, but I want to exclude some fields from editing and validate user inputs: just a few tweaks from the default behavior.
If I have a feature layer with dozens of fields, is it possible to do something like edit the default add/edit workflows or is there an activity that will detect data types from a feature layer query and initialize the form with field aliases, coded value domains, values, etc., instead of having to recreate the entire form?
Thanks!
-
Hi Alex,
Thank you for your question. The default add/edit functions simply listen to what attributes are configured to be editable in the web map's pop-up config. If you deselect the checkboxes for the attributes you want to omit, they should not show up during adding/editing (but viewing is still separate as per the 'Display' checkboxes):
That would be the lightest touch approach to hiding those fields. Otherwise, if you want to override the entire add/edit Workflows, unfortunately it is a wholesale replacement. You'd need to generate your own Workflow to configure it to show just the fields you want. Though at least this can be done on a per-layer basis in case you want to only apply that override for specific layers rather than needing to do it for all layers.
I hope that helps,
Phil MacIntyre
0 -
Thanks Phil, that helps clarify things and gives me a better estimate of the development time we will need to get collections of tools together for a mobile app.
0 -
You're very welcome, Alex. Please let us know if you have any other questions.
Have a great day,
Phil
0 -
There is no workflow json buried somewhere on my VertiGIS Studio server then? Even if I can't load it into the Designer, I think I could still benefit from seeing the mechanism of how it populates form elements and other pieces of functionality that I need to recreate.
0 -
For the default tools, they're embedded directly into our code. Let me chat with our team though and see if we can provide a way to expose that in some way, as I certainly agree having that would make for a great learning tool.
Phil
0 -
Neat, thanks Phil!
0 -
Hi, Can you explain how you pass the context to your workflow when using the override workflow to Edit features? How can you pass the element you've selected as an input argument to to workflow?
0 -
Hi Wouter,
Thank you for your question. For the override add/edit Workflows, because these are done on a per-layer basis, you can target the Workflow for that specific layer rather than making something more general, like you would for say a Feature Action Workflow. In which case you could just specify the layer via a Get Layer + Query combo, and then simply collect the data you want your users to be able to edit via a display form, then use the 'Set Feature Attribute' activity to update the feature in question.
If you want to make something more dynamic, you'll want to make use of the 'Get Workflow Inputs' activity, which will allow you to harvest context and work with that. In Mobile App Designer, under the feature action Workflow templates, we have a really good one that demonstrates this nicely, the 'Get Feature From Results' template. Nested in the load event of the 'source' Display Form, you'll see the correct syntax for accessing lots of the layer-specific properties, like so:
If you inspect the Get Workflow Inputs activity's outputs via the Workflow inspector tool in Go's log viewer, you'll be able to see the structure of the complete object. That should be able to guide you towards the properties you need.
Alex St. John My apologies for letting this thread go cold. I spoke with our team and it turns out that our out of the box tools make use of a mixture of code and Workflow to function as they are, and are complicated to the degree that teasing it apart won't be easy. That said, we've brainstormed a couple ideas about some shortcuts that would enable app authors to quickly generate an appropriate Workflow for the various overrides, and now have a work item in our backlog. I've linked this Communities post to that ticket, so when the work is done, we'll be sure to respond here.
Hope that helps,
Phil
0 -
Wouter D'hollander Note that I have found ambiguity in using context vs. context[0]
For example, in a Create Value activity to fetch the inputs, I use the Get App Info activity and a ternary operator to decide:
=($appInfo1.name == "VSM") ? $getWorkflowInputs1.inputs.context : $getWorkflowInputs1.inputs.context[0]
@... Maybe this has been resolved?
Also, thanks for the follow up on that! I'm glad it got some discussion and ideas going.
0 -
I think that's an expected difference. Web & Sandbox are both running on the Javascript/Typescript version of Workflow, whereas Mobile is based on .NET. The Workflow team has made efforts to try to make things as compatible between the two as possible (and has ongoing efforts to that end), but there are some fundamental differences between how the two coding languages structure objects and method calls. For example, one language might return a single object whereas the other may return an array. The Workflow inspector tool I mentioned above is very helpful for this in that it will let you view the types of objects being expected or returned, as well as their properties needed to work with them.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
10 Kommentare