Can an Attribute Rule Passively Perform an Update?

[ChristopherBowering]

I have a feature class related to Table 1 (for illustration purposes) then Table 1 is related to Table 2.  The relationship classes are both based on GlobalID to GUID...all datasets are in an SDE environment.  Each of the 3 datasets contains the identical field 'Assembly_ID'.  

I want the 'Assembly_ID' value to be updated in Table 2 when the feature class field is updated.  Currently, I have a functional attribute rule that will update the 'Assembly_ID' field in Table 1 when said field in the feature class is updated.  I have another functional rule that will update the 'Assembly_ID' field in Table 2 from said field in Table 1 when some other field is updated in Table 1.  I don't want to have to perform an edit/update in Table 1 for the value to pass thru to Table 2.  

Is there a way to pass the value directly from the feature class to Table 2 (I DO NOT want to create a relationship between the feature class and Table 2...that field is the only common field between the feature class and Table 2) OR have the value pass from Table 1 to Table 2, passively, without some trigger being activated in Table 1?

[MikeMillerGIS]

sure, you need to use FeatureSetByAssocation($feature) to get the table 1 feature, then use that feature again in FeatureSetByAssocation(ResultFeatureFromFirst) to get the second.  Then issue the DML to update that feature.

You can also just use featureSetByName and just build the pkey/fkey sql if you want too.  Same process

[ChristopherBowering]

Hi Mike - bear with me as I'm just reading about this function for the first time.  I also don't know what DML is or how to use it.

From the ESRI documentation I'm reviewing, I need to select an Association Type; would this be 'Content' in this case since I'm just dealing with a single value?  The examples I'm seeing almost exclusively return a count value as the result, as well.  I found this blog post but the example is wayyy more complicated than what I'm trying to do.

Would the attribute rule be set on the feature class since it's pushing the value all the way down to Table 2?

Thanks!

[MikeMillerGIS]

Sorry, not FeatureSetByAssociation(was working on a rule using that).  FeatureSetByRelationClass

Needs a lot more work, but something like this.

var table1FS = FeatureSetByRelationshipClass($feature, “pole_inspection”,  [“comments”], false);
var table2FS = FeatureSetByRelationshipClass(First(table1FS), “pole_history”,  ["globalid",“comments”], false);

return {
    'edit': [{
        'className': 'pole_history',
        'updates': [{
            'globalID': first(table2FS.globalid),
            'attributes': {
                'comments':  first(table2FS.comments)
            }
        }]
    }]
}

[ChristopherBowering]

No worries!  Your last response did the trick.  I combined how you created the variables with part of the attribute rule I was using within a single relationship class.  The following works as a two-step "jump" I guess I'll call it.

if ($originalfeature.Assembly_ID == $feature.Assembly_ID) {
    return
}

var table1FS = FeatureSetByRelationshipClass($feature, "OCGIS.DPW_TESTING_REL",  ["Assembly_ID"], false);
var table2FS = FeatureSetByRelationshipClass(First(table1FS), "OCGIS.DPW_TESTING_Secondary_Table_REL",  ["globalid","Assembly_ID"], false);

fields to update
var updates = []
for(var f in table2FS) {
    if(f.GlobalID == $feature.GlobalID) { continue }
    if(f.Assembly_ID == $feature.Assembly_ID) continue;
    var u  = {
        globalID: f.GlobalID,
        attributes: {
            "Assembly_ID": $feature.Assembly_ID
            }
        }
    Push(updates, u)
}

return {
    edit: [{
        className: "OCGIS.DPW_TESTING_Secondary_Tabe",
        updates: updates
        }]
}

Thanks for your help!

[ChristopherBowering]

@MikeMillerGIS I spoke a little bit too soon.  The script I included in my previous message does function how it should, however, only if an existing record is present in Table 2.  If there isn't one, I'm not even able to enter an Assembly ID value in the feature class to begin with.  I receive a "feature expected" error.  This is with the rule trigger being set to only "update" (I tried it with all triggers checked on as well).  Is there a way to make the rule only run if a corresponding record exists in Table 2?  Or, is there another way to account for this?

[MikeMillerGIS]

you just need to add some checks for first(fs) returning null

[ChristopherBowering]

@MikeMillerGIS I have tried a handful of  checks using examples I've come across but none have worked so far.  I might have to create 2 of them because neither a record for Table 1 nor Table 2 will exist when a new feature is created and this script is using Table 1 to get to Table 2.  Is there a specific example you could point me to that may work in this scenario?  Or something creative you can think of?

Also, something that I've never seen before, this particular script/rule (even the functional version that solely updates the Table 2 record) can't be published in my current Enterprise version (11.0).  I get an error (00396) saying "The dataset version is later than is supported by your server. Minimum version 11.2".  As soon as I delete the attribute rule, the message goes away and all datasets containing all other rules publish without issue.  Some of the other rules use very similar scripts...so I'm not sure what it is about this particular script that can't be supported in publishing until Enterprise 11.2.

[MikeMillerGIS]

You can check the min version and details on the rule in the Attribute Rule design view.  You can also look at the functions online

FeatureSetByRelationshipClass was new at 1.24

https://developers.arcgis.com/arcade/function-reference/featureset_functions/#featuresetbyrelationsh...

If you need to support older versions, you would need to move to https://developers.arcgis.com/arcade/function-reference/featureset_functions/#featuresetbyrelationsh...

or manually build the sql and use FeatureSetByName

Here is your code with some checks to handle empty stuff

if ($originalfeature.Assembly_ID == $feature.Assembly_ID) {
    return
}

var table1FS = FeatureSetByRelationshipClass($feature, "OCGIS.DPW_TESTING_REL",  ["Assembly_ID"], false);
var first_hop = First(table1FS)
if (IsEmpty(first_hop))
    {
        return
    }
var table2FS = FeatureSetByRelationshipClass(first_hop, "OCGIS.DPW_TESTING_Secondary_Table_REL",  ["globalid","Assembly_ID"], false);

var updates = []
for(var f in table2FS) {
    if(f.GlobalID == $feature.GlobalID) { continue }
    if(f.Assembly_ID == $feature.Assembly_ID) continue;
    var u  = {
        globalID: f.GlobalID,
        attributes: {
            "Assembly_ID": $feature.Assembly_ID
            }
        }
    Push(updates, u)
}
if (Count(updates) == 0 ){
    return
}
return {
    edit: [{
        className: "OCGIS.DPW_TESTING_Secondary_Tabe",
        updates: updates
        }]
}

[ChristopherBowering]

@MikeMillerGIS Thanks for the script adjustments, I'll give it a go!

I didn't know about that matrix; that's really interesting.  I guess I never paid much attention to the minimum release information in the design view.  I believe we're upgrading to 11.2 later this year.  Odd that the minimum release for that rule is showing 11.3 in Pro despite the error prompt saying minimum release was 11.2.  The matrix shows 'N/A' for v 1.24.