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

[tbearb]

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.

[HusseinNasser2]

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.

[JohannesLindner]

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}}
      ]
    }
  ]
}

[tbearb]

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}}
]
}
]
}

[JohannesLindner]

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?

[tbearb]

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.

[JohannesLindner]

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
}

[tbearb]

@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

[tbearb]

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
}

 

[JohannesLindner]

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.