Attribute Rules and editing via Feature service with branch versioning

[FraserHand1]

Hi,

I have a feature class with calculation attribute rules set up. The rule works out an attribute based on an intersection with another feature class. The feature class is versioned (BV) and published as a web layer with feature access and version management. It is the only feature class in the service. I have a rule like this:

var fsOwnership = FeatureSetByName($datastore,"GIS.GISADMIN.Ownership",["propertyid"],true);
var fsOwnershipInts = Intersects(fsOwnership , Geometry($feature));
var ownership = First(fsOwnershipInts);
if(IsEmpty(ownership)){
return 999;
}else{
if(IsEmpty(ownership.propertyid)){
return 999;
}else{
return ownership.propertyid;
}
}

this rule is set for insert and update.

When editing via the feature service in ArcGIS Pro, the rule fires correctly on an insert - but DOESN'T on an update. On an update it does this:

so it can find it for an insert but not an update?

has anyone seen this? ArcGIS Enterprise 10.7.1 with SQL Server back end.

Thanks

Fraser

EDIT:

the help does say 

The map or feature service containing one or more layers from which to create a FeatureSet. Typically, this value is the $map or $datastore global.

which suggests it expects the layer to be in the FS. We can't do this as the other feature class isn't versioned and doesn't fit with the publishing strategy. And it also doesn't explain why it's working for the insert. trying $map doesn't work with ArcGIS Pro

Sorry - should have also mentioned worked as expected via direct db connection before branch versioning.

EDIT 2:

Gets stranger - when you look at the rules in pro via design from the database connection you see

var fsOwnership = FeatureSetByName($datastore,"GIS.GISADMIN.Ownership",["propertyid"],true);

or

var featureSet=FeatureSetByName($datastore,"GIS.GISADMIN.Resource", ["GlobalID","IsActive"], true);

if you add the feature service to the map and do design you see

var fsOwnership = FeatureSetByName($datastore,"{8CC3904F-4B31-4B74-98F4-9ECF13DE8F72}",["propertyid"],true);

and

var featureSet=FeatureSetByName($datastore,"L0Resource", ["GlobalID","IsActive"], true);

The first is the ID of the layer in the gdb items table. Don't know where it got the second from....

[ColinZwicker · Accepted solution]

Fraser,

When connected directly to your enterprise geodatabase, and viewing the attribute rule(s) in question can you please check the exclude_from_client_evaluation property (i think its listed in the details pane near the bottom in an expansion >> ). If this is not set, try setting it. 

From reading your description (the odd GUID in the rule, the differing behavior) this looks like a case where the smart client (Pro) cant find one of the tables in your rule (because its not in the service) and therefore cannot evaluate the script before sending the edits to the server. Having the rule only execute on the server, where the enterprise data store does know about your other table) should allow the execution to be success.

[FraserHand1]

Hi Colin - yes that did it - thanks. I completely missed that when we moved from direct db connections to feature services. I had previously read about that setting in the help as well. Thanks for the assist - much appreciated.

Fraser