Is it possible to populate a field in a feature class from related table from within Field Maps?

2337
6
11-01-2021 04:31 PM
BrianOevermann
Occasional Contributor III

Using ArcGIS Enterprise 10.8.1. We have a feature class containing point features that effectively are the inventory of that particular facility (water meters, if it matters). That inventory layer contains fields such as the meter register ID and serial number, among others.

I'm setting up a related table for some specific maintenance activities such as replacing the meter with a brand new one, which will require updating the inventory fields accordingly. I plan to use the Smart Forms capability within Field Maps to guide the user through entering all of the required fields for a particular activity into the related table. For some of the activities, the user will need to populate a field in the related table with the new meter register ID (as one example). I would like that value to automatically update the feature class field upon submitting the related table edits.

Is there a way to set up an attribute rule or something similar that will update a field in a feature class with a value from the related table?

I'm open to any possible solutions. What I don't want is for the user to need to jump from one form to another (related table form over to the feature class form) to populate values or duplicate the population of a value (double entry and double the chance for user error).

Thanks for any ideas you might have!

0 Kudos
6 Replies
LongDinh
Occasional Contributor II

Hi @BrianOevermann ,

Have you tried setting up your service's feature layers with Attribute Rules. You can may be able to utilise ARCADE and obtain the related records via Data Functions, specifically the FeatureSetByRelationshipName which returns the related records for a given feature.

From there, you can apply conditions and assign the value according to your intended business logic.

 

Tags (1)
BrianOevermann
Occasional Contributor III

@LongDinh, thank you for the pointers to the potential Arcade functions. My disconnect is whether submitting edits to the relationship table's form can trigger an attribute rule to update fields in the feature class itself. If that is possible (and I haven't seen an example) then my questions are: Do you create the attribute rule on the related table or on the feature class? If on the feature class, how does the immediate calculation rule get triggered (i.e. how does it know that an edit is being made in the related table that affects the attribute rule in the feature class)? Is it polling the related table looking for changes?

0 Kudos
LongDinh
Occasional Contributor II

@BrianOevermann I haven't done too much tinkering in Field Maps to provide an example, however, given that data access is through Feature Service REST urls, data transactions are handled by the Feature Layer's associated Enterprise or File Geodatabase connection.

Do you create the attribute rule on the related table or on the feature class?

You create the attribute rule for the feature/table being edited. Be aware that you can create an infinite loop of triggers e.g changes in the parent table triggers its own attribute rules which alter the child table following a trigger from the child table altering the parent table. 

If on the feature class, how does the immediate calculation rule get triggered (i.e. how does it know that an edit is being made in the related table that affects the attribute rule in the feature class)? Is it polling the related table looking for changes?

It's not polling. The related table is just another table in the database. It is only called a related table as it has an association by a key attribute to another table. It is taking advantage of the database engine which manages your records.

ESRI's SDE schema implements attribute rules slightly differently than your traditional database triggers. This is from my own investigation of the SDE schema, but I believe the triggers are stored as an xml description for the table in the database and is executed by a set of SDE schema functions following certain database transactions. 

For example, your Feature Service REST url has a  /ApplyEdits method which sends a message to your database to make a set of edits and if there is an attribute rule, the rule is also executed. Should any part of the edit fails, the transaction is rejected and an error should is thrown back.

 

0 Kudos
BrianOevermann
Occasional Contributor III

Thank you @LongDinh. This is helpful. I've duplicated our data into a sandbox enterprise gdb that I maintain for testing purposes so that I can demo what the user says they want. So I already have a test bed ready for trying to implement my desired attribute rules.

My users think that this request only requires creating a smart form with conditional logic in Field Maps. And that is basically the case on the surface. They simply have no idea what needs to happen administratively behind the scenes to keep everything in sync so they don't need to do any double entry of the data.

Thanks again for sharing your knowledge!

LongDinh
Occasional Contributor II

@BrianOevermann creating conditional logic in Field Maps forms is also an option, however, it is difficult maintain data quality/integrity and scale the use of the underlying service across multiple applications. 

For example, should another application like a Portal Web Maps or a ArcGIS Pro make edits on the feature service url, then the conditional logic from Field Maps is not applied as it is a self contained application. 

Applying attribute rules ensures any data entry from any application using the Feature Service adheres to the rules of editing the dataset.

0 Kudos
BrianOevermann
Occasional Contributor III

@LongDinh, I probably should have been a bit more clear regarding the conditional logic in Field Maps. The use case for the related table will be field-only, so the conditional logic in the form will not be undermined by outside editing. But your point is well taken!

For this particular situation, the conditional logic in the form will be to govern which fields are shown based on the type of service activity since not all of the fields in the related table apply to all of the service activities.

I intend to use the attribute rules to 'sync' certain values from the related table back into the inventory feature class fields.