topic Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa in Attribute Rules Questions

Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Tue, 08 Feb 2022 00:35:17 GMT

Using ArcGIS Enterprise 10.9.1 - Field Maps version 21.4.0. I am curious if we are able to create an attribute rule to transfer a value from a related table to the parent feature class upon record submission?

I currently have attribute rules in place that transfers a water meter’s brand, meter ID, and latest reading from the parent feature class to the related work history table when the record is created. This is successful. I would like to then use another attribute rule on the feature class to automatically update the new meter ID once the new value is typed into the related work history table.

Is this type of workflow supported - actively transferring data from the parent feature to its related table and vice versa? If so, is the attribute rule created in the same manner? Unfortunately I’m not having successful results returning values from the related table back to the parent feature class.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

HusseinNasser2 — Tue, 08 Feb 2022 00:42:24 GMT

That should be possible, you need to add an attribute rule to the related table. One thing to watch for is cyclic execution and infinite loops. (Parent updates child, child turns out updates parent, which turns out and update child and that goes on.) We detect and protect against such cases but you will need to write the rules such that it has a base condition to quit.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Tue, 08 Feb 2022 08:59:57 GMT

It is possible. But you dont define the rule on the feature class, you do it on the work history table.

// Attribute Rule on the work history table // Triggers: Update // Field: empty // do nothing if meter id did not change (so you don't send senseless update requests) if($originalfeature.MeterID == $feature.MeterID) { return null } // get the water meter var water_meter = First(FeatureSetByRelationshipName($feature, "RelationshipName")) if(water_meter == null) { return null } // Send a request to update the MeterID in the parent FC return { "edit": [ { "className": "WaterMeterFC", "updates": [ {"globalID": water_meter.GlobalID, "attributes": {"MeterID": $feature.MeterID}} ] } ] }

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Tue, 08 Feb 2022 13:56:44 GMT

Thank you @HusseinNasser2 and @JohannesLindner for the replies. I think my main issue comes from me placing the attribute rule on the parent feature class rather than the related work history table and there seemed to be some looping occurring. Can you guys please let me know if this is what I should be inputting as an attribute rule?

Where Old_MeterId is the field on the work history table that stores the original Meter ID from the feature class, New_MeterId is the field on the work history table that is used for input of the new Meter ID after it has been replaced, test.DBO.WaterMeterTOWorkHistory_TEST is the name of the relationship class being used, test.DBO.WaterMeterTEST is the name of the parent feature class, and Meter_ID is the Meter ID field on the parent feature class that is to be updated if a new Meter ID was inputted into the work history table.

// Attribute Rule on the work history table
// Triggers: Update
// Field: empty

// do nothing if meter id did not change (so you don't send senseless update requests)
if($originalfeature.Old_MeterId == $feature.New_MeterId) { return null }

// get the water meter
var water_meter = First(FeatureSetByRelationshipName($feature, "test.DBO.WaterMeterTOWorkHistory_TEST"))
if(water_meter == null) { return null }

// Send a request to update the MeterID in the parent FC
return {
"edit": [
{
"className": "test.DBO.WaterMeterTEST",
"updates": [
{"globalID": water_meter.GlobalID, "attributes": {"MeterID": $feature.Meter_ID}}
]
}
]
}

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Tue, 08 Feb 2022 14:02:55 GMT

What's your workflow here? Do you insert the work history record with Old_MeterID and New_MeterID or do you change New_MeterID after the record is already inserted?

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Tue, 08 Feb 2022 14:07:30 GMT

Both of the values are inserted at the same time. User input on the New_MeterId field in the work history table and a triggered insert/update immediate attribute rule on the Old_MeterId field to populate the value from the parent FC.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Tue, 08 Feb 2022 14:29:16 GMT

OK, then the rule should trigger on Insert.

// Attribute Rule on the work history table // Triggers: Insert // Field: empty // get the water meter var water_meter = First(FeatureSetByRelationshipName($feature, "test.DBO.WaterMeterTOWorkHistory_TEST")) if(water_meter == null) { return null } // construct the edit parameter, only fill it if meter got replaced var edit = [] if($feature.New_MeterID != water_meter.MeterID) { Push(edit, { "className": "test.DBO.WaterMeterTEST" "updates": [{"globalID": water_meter.GlobalID, "attributes": {"MeterID": $feature.MeterID}}] }) } // return return { "result": { "attributes": { "Old_MeterID": water_meter.MeterID, // you can also copy the other fields here: // "Brand": water_meter.Brand, // "LatestReading": water_meter.LatestReading, } }, "edit": edit }

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Tue, 08 Feb 2022 14:45:51 GMT

@JohannesLindnerI really appreciate the help! I will give this a go once our field crew signs off for the day.

You have a great day as well!

-Terry

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Tue, 08 Feb 2022 22:29:43 GMT

I am unfortunately still having negative results getting any value to update in the parent feature class. After adding the attribute rule / publishing, when I access the web map again I am now receiving an error when I attempt to create the related record (see attached). I also took a screenshot my settings used for the attribute rule in Pro.

Attribute rule applied:

var water_meter = First(FeatureSetByRelationshipName($feature, "test.DBO.WaterMeterTOWorkHistory_TEST"))
if(water_meter == null) { return null }
var edit = []
if($feature.New_MeterId != water_meter.Meter_ID) {
Push(edit, {
"className": "test.DBO.WaterMeterTEST",
"updates": [{"globalID": water_meter.GlobalID, "attributes": {"Meter_ID": $feature.New_MeterId}}]
})
}
return {
"result": {
"attributes": {
"Old_MeterId": water_meter.Meter_ID,
}
},
"edit": edit
}

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Wed, 09 Feb 2022 06:40:35 GMT

Oh yeah, "Exclude from application evaluation" has to be checked for rules that affect other tables.

Try inserting a record in Pro before publishing, that will give better error messages.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Wed, 09 Feb 2022 13:42:56 GMT

Good morning. I went ahead and made sure the "Exclude from application evaluation" box was checked but I am still unfortunately seeing the same results. Attached are the error messages I have received within Pro. Again, thank you for your help.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Thu, 10 Feb 2022 22:01:54 GMT

I haven't had much success with placing the attribute rule on the related table to update the feature class. Just out of pure curiosity, I placed an attribute rule on the parent feature class with the following settings / expression.

Field: Meter_ID

Trigger: Insert / Update

var WM = FeatureSetByName($datastore, 'waterutilities.DBO.WorkHistoryTEST');
var water_meter = First(FeatureSetByRelationshipName($feature, "waterutilities.DBO.WaterMeterTOWorkHistory_TEST"))
var globalid = $feature.globalid
var filterStatement = 'Related_Asset = @globalid'
var related_data = Filter(WM, filterStatement)
var cnt = Count(related_data);

var results = "";

if ((cnt > 0) && (water_meter.Issue == 'MR')) {
for (var row in related_data) {
var line = row.New_MeterId;
results +=line;
}
} else {
results = "No related record";
}
return results;

The new Meter_ID is placed in the field on the FC (from the related table) after the record is created, but is appending the Meter_ID to whatever was previously there with each new record that is added. So, Meter ID of 7777 then becomes 77778888 when a new related record is added and then becomes 777788889999 when another record is added. Rather than just 8888 or 9999. Any ideas why?

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Fri, 11 Feb 2022 11:18:46 GMT

The first error comes from me not testing the rule. When no relates asset is found, the rule should just return, not return null.

Second error: no idea.

I built a rudimentary structure:

Feature class:

Table:

Relationship class:

Attribute rule on the work table:

// Calculation Attribute Rule on WaterMeterWorkHistory // Triggers: Insert // Exclude from application evaluation // Copies old values from water meter t // get the water meter var water_meter = First(FeatureSetByRelationshipName($feature, "WaterMeterTOWorkHistory")) if(water_meter == null) { return } // get attributes from water_meter var old_attributes = { "Old_MeterID": water_meter.Meter_ID, "Old_Brand": water_meter.Brand, "Old_Reading": water_meter.Latest_Reading, } // map the attribute names from the work table to the feature class var update_attribute_map = [ ["New_MeterID", "Meter_ID"], ["New_Brand", "Brand"], ["New_Reading", "Latest_Reading"], ] // if the new attributes are filled in, add them to the edit request var updated_attributes = Dictionary() for(var i in update_attribute_map) { var work_att = update_attribute_map[i][0] var asset_att = update_attribute_map[i][1] var new_att = $feature[work_att] var old_att = water_meter[asset_att] if(!IsEmpty(new_att)) { updated_attributes[asset_att] = new_att } } var edit = [{"className": "WaterMeter", "updates": [{"globalID": water_meter.GlobalID, "attributes": updated_attributes}]}] // return return { "result": {"attributes": old_attributes}, // copy old attributes from water meter to work table "edit": edit // copy new attributes from work table to water meter }

WaterMeter:

WaterMeterWorkHistory:

WaterMeter after these changes:

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Fri, 11 Feb 2022 11:23:47 GMT

It's because of this line: results +=line

What your code does is: go through ALL related work records and concatenate their New_MeterIDs. You need some way to check only the LATEST work record.

You shouldn't need the filter, as the FeatureSetByRelationshipName function returns only the related work records.

Note that, while this is absolutely a legit way of copying the new Meter_ID to the feature class, this won't happen automatically. You have to update the WaterMeter after you added a new WaterMeterWorkHistory record.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Fri, 11 Feb 2022 14:50:55 GMT

Hi, @JohannesLindner I really appreciate all the help you have given me thus far! I am admittedly new to arcade expressions / attribute rules so your assistance is really helpful. I hate to be nuisance, but for whatever reason it keeps telling me the fields in the first index [0] cannot be found for the $feature work history table. Everything appears to be set up correctly. From what I can tell, the fields are able to be found in the second index [1] water_meter FC.

Field "New_MeterId" cannot be found

Work History table fields

Water Meter FC fields

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

JohannesLindner — Mon, 21 Feb 2022 07:57:02 GMT

Hey! Busy week, sorry for ghosting you...

Sadly, I can't really help you here. The fields seem to be fine.

My only suggestion would be to rebuild the two tables in a test gdb and try it again, mabe there's some interference from other rules (or something else, idk).

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Fri, 11 Mar 2022 17:26:36 GMT

Hi @JohannesLindner I just wanted to reach back out to you as a follow up and say that I finally have the expression working for me! Posted below is what ended up working for me where I had to specifically call out the field I wanted to use for the update. I then just applied the expression to individual fields when I set up the rule. I want to thank you for all your help and getting me on the correct path, it is really appreciated!

// Calculation Attribute Rule on WaterMeterWorkHistory table // Triggers: Insert, Update // Execution: Exclude from application evaluation // Field: New_MeterId

var water_meter = First(FeatureSetByRelationshipName($feature, "WaterMeterTOWorkHistory")) if($originalfeature.New_MeterId == $feature.New_MeterId) { return null } // get attributes from water_meter var old_attributes = { "Meter_ID": water_meter.Meter_ID } // map the attribute names from the work table to the feature class var update_attribute_map = [ ["New_MeterId", "Meter_ID"] ] // if the new attributes are filled in, add them to the edit request var updated_attributes = Dictionary() for(var i in update_attribute_map) { var work_att = update_attribute_map[i][0] var asset_att = update_attribute_map[i][1] var new_att = $feature.New_MeterId var old_att = water_meter[asset_att] if(!IsEmpty(new_att)) { updated_attributes[asset_att] = new_att } } var edit = [{"className": "WaterMeter", "updates": [{"globalID": water_meter.GlobalID, "attributes": updated_attributes}]}] return { "edit": edit }

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

dommybo123 — Tue, 05 Jul 2022 23:18:15 GMT

This is awesome and it worked for me! However, I'm unable to get it to work with ArcGIS Online nor Field Maps. Any suggestions?

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Terry_Bearb — Wed, 06 Jul 2022 13:52:13 GMT

That's great, glad to hear you were able to use this as well! I have it currently working in Field Maps. What is the error you're receiving?

If it is working as it should in ArcGIS Pro, but in Field Maps you receive an "Arcade expression is invalid" error when you attempt to edit, it could be the version of Field Maps that is causing the issue. Ever since the 22.2.0 version was released, there have been issues when attribute rules are implemented. The temporary work around at least for that error was to make sure you checked "Exclude from Application Evaluation" for all the attribute rules in Pro and then re-publish the service.

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

dommybo123 — Wed, 06 Jul 2022 16:10:27 GMT

That's really interesting. I'm actually not receiving any error message, it's simply that when I add a new related record on field maps, it's not autopopulating the respective attributes in the feature class like it does in ArcGIS Pro. I checked "Exclude from Application Evaluation" when I initially made the rule, so I don't believe that's the issue. And it's an online map, so I don't need to manually sync it. I have Field Maps version 22.3.0, and ArcGIS 2.9.3. In another thread, someone said that FeatureSetByRelationshipName has some bugs, but I don't know of any other ways to rewrite your code. Let me know if you have any other suggestions. I appreciate the help and I'm glad it's working for you!