Add Attachments in offline workflow
Hi,
Curious about the Add Attachments activity. The objectid is one of the required input, but if we're doing offline workflows, then the globalid would be the relationship key. How does the workflow know that we are doing it offline and puts the globalid into the relationship key instead of the objectid?
We are running into issues where some attachments would show up as failed in the log, but it might still attach to the feature.
Thanks,
Aaron
-
Hi Aaron,
Thanks for your question. While you're offline, you can actually continue to use the OBJECTID property. To ensure that it works offline, you want to be sure to use the Get Layer or Get Table activities. For a very simple example, I crafted an offline-capable Workflow that will fire from a feature action for any layer that supports attachments:
The 'Get Workflow Inputs' activity gives you access to the context from which the Workflow is run, which will include details about your specific feature when run as a feature action. I can then dynamically harvest the Layer ID out and feed that into the Get Layer activity like so:
=$getWorkflowInputs1.inputs.context[0].source.layer.idI then simply use a display form with a file picker to collect the attachment, then use the Add Attachment activity to complete it on the other side. The layer value you can get from the Get Layer activity, the attachment will simply be the output of the file picker, and you can dynamically harvest the OBJECTID from the Get Workflow Inputs like so:
=$getWorkflowInputs1.inputs.context[0].attributes["OBJECTID"]
I've confirmed that this works with multiple layers, online and offline, in both custom and predefined map areas.
If you wanted to make it a little bit more robust, you could build some validation into your Workflow that checks the layer to see if it supports attachments, and then will branch accordingly (e.g., if it supports attachments, go down the path that exposes the file picker. If it doesn't support attachments, warn the user and exit the Workflow).
Hope that helps!
Phil
1 -
Hi Phil,
I think for a feature service to be taken offline the relationship is recommended to be in GlobalID. But an update that this is actually due to a back end server problem.
But i'm still curious how this activity uses the objectid to retrieve the globalid to attach objects.
Thanks!
Aaron
0 -
Hi Aaron,
I had a chat with one of our devs and from the sound of it, GlobalID isn't necessary. Working with the OBJECTID appears to be entirely valid throughout all of the various calls we make to the Runtime to query and work with services. Go knows if it's working online/offline based on the results of the call to the service (e.g., is it reaching a web map or is it referencing a locally stored map area or MMPK), but can work effectively with the OBJECTID in either case.
Bit out of left field, but what version of Go are you encountering the issues? We had a client with some specific security configurations around having anonymous authentication disabled in their host environment that was impacting their ability to add attachments to features, but this was resolved when we upgraded to the 100.15 version of Esri's Runtime, which we included in out 5.21 release. If you're using 5.21 or newer (5.23.1 is current), that should be a non-issue.
Cheers,
Phil
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
3 Kommentare