Attribute Rules - Exclude from Application Evaluation

[HusseinNasser2]

Attribute rules are scripts authored in Arcade and added to classes in the geodatabase to enforce constraints, calculate fields, query or edit classes in the same geodatabase. Many properties can be set while authoring attribute rules, the name of rule, subtypes the rule applies to, when to trigger the rule and yes Exclude from Application Evaluation. This option has raised many questions in the community so I thought I'd write a blog discussing the purpose of this property and when one should use it.

Attribute Rule Execution
Attribute rules are stored in the class, so wherever the geodatabase go, the rule goes with it. The rule always executes in the backend geodatabase datastore, whether you initiated the edit from Pro, Collector or Javascript API. Some applications are capable of understanding and executing the rule locally BEFORE the edit request is sent to the backend geodatabase datastore to be executed again.

Application vs Backend

It is important to differentiate between the application and the backend geodatabase workspace. ArcGIS Pro is an application and feature service, file or mobile geodatabase, enterprise geodatabase are the backend geodatabase workspace.

So if I add my filegdb class to Pro and edited the class, Pro can perform the edit locally before "sending" the edit request to the filegdb workspace. This concept is applied to any workspace, services, enterprise geodatabase, mobile geodatbase and file geodatabase.

You can see this behavior in Pro's attribute pane window while the Auto Apply option is turned off. Here is an example where we have an attribute rule that adds field a to field b and store the value in field c. The rule has allowed for application evaluation.

 

Exclude from Application Evaluation
When unchecked, "Exclude from Application Evaluation" property tells the application that its "safe" to execute this rule locally before sending the edit request to the backend. So you get the behavior like the attribute pane in place execution without the need to persist your edit to the backend to see the rules effects. Smart applications can look at this property and decide to leverage local attribute rule execution if it supports it. As for the time writing this blog, ArcGIS Pro is the only application that is capable of executing attribute rules locally.

Here is the same rule from before but with Exclude from Application Evaluation turned on. Noticed that local edits in the pane does not trigger the attribute rule until applying the edit to the workspace.

Constraint rules benefit the most from having the application execute the rule locally. If the application executes the constraint rule locally and finds that the rule is violated, an applyEdits request is never sent to the server since we know the request is going to fail there too. This saves on network bandwidth in certain case. Note that the constraint rule is always re-executed on the server side.

Another benefit of allowing the application to execute the rule locally is offloading heavy attribute rule compute to the application (when applicable) and only send the final result to the backend. The attribute rule has to be written in such a way to allow for the server to skip computation that has been already performed in the client. This way the server consumes less resources and editing throughput improves.

When to Exclude my Rule from Application Evaluation?

There are use cases where you want to exclude a rule from application evaluation here are a few.

Application doesn't support certain Arcade functionality
Even if the application is capable of executing attribute rules locally, not all Arcade functionalities are applicable for local execution. Examples are the attribute rules DML ability to edit other features, and working with sequences NextSequenceValue. Attribute rules that use these functionalities must be excluded from client evaluation.

Application doesn't have access to tables behind service

The application can sometimes have access to only a subset of classes of the backend geodatabase. Lets say a geodatabase has 3 classes class1,class2, class3. A feature service is published from this geodatabase but only class1 and class2 are included as layers. This means an application consuming the feature service only has direct access to class1 and class2 and NOT class3. If there is an attribute rule on class1 that was allowed to be executed locally (exclude from application evaluation was turned off) and that rule is querying class3, that rule will fail because the application wouldn't find class3 in its local workspace. You might have seen this error before "Arcade Error: Table not found"  followed by a guid, that error becomes clear once you understand what really is happening. For such cases you need to exclude the rule from local execution, sending the edit to the backend server will eventually execute on the server geodatabase workspace which has access to all classes.

Final thoughts
If we go back to when we first designed this, I would definitely pick another name for this property. Maybe Allow Application Evaluation?

[JohannesLindner]

Thank you for this great explanation!

This is a parameter that always confused me, but ArcGIS always told me when to check that box, so I didn't research it.

The attribute rule has to be written in such a way to allow for the server to skip computation that has been already performed in the client.

Sure, if I calculated a+b locally to improve throughput on the server, it would be senseless to have the server do it again. But how do you write such a rule? I don't see a way to tell the server that your example rule was already executed.

In my opinion, that should be part of the communication between client and server. When applying the edit, the client should tell the server it already did the job, so the server doesn't even have to start the execution to perform some checks built into the rule to see if it already executed.

[HusseinNasser2]

Hey Johannes,

In most cases you can tell if the rule has been executed if a value has been set to a certain field. In our example if $feature.c has changed that indicates that the client has already performed and persisted the value to c and is now sending us the value of c along side a and b.

We released a global $originalFeature that would allow you to compare the original value of the field compared to the new value that is about to get set. So subsequent edits to a and b will produce new c values and you can compare if $feature.c is not equal $originalFeature.c then it means the client has already performed the calculation.

Of course this isn't straight-forward to implement and there are other gotchas as well to be discussed like making sure the client doesn't just mock with the value of c directly by making the field read only or hidden.

The compute in our example here is obviously trivial but the logic is applicable to complex Arcade expressions in a similar fashion

[vpelleritoCritigen]

Thanks for this helpful illustration.

"If we go back to when we first designed this, I would definitely pick another name for this property. Maybe Allow Application Evaluation?"

My thought exactly!

Thanks,

Vince

[BrianBulla]

Hi,

Does this have any effect on sharing layers to AGOL?  For example, if I have a rule on a related inspection table, that updates the parent feature whenever an insert or update happens, would the rule automatically trigger when sharing the data to AGOL?

I am finding that when creating a hosted feature service in AGOL, that the attributein my parent feature class is getting updated, and this is the only explanation I can think of.

See the last few posts on this thread if you want more background:

https://community.esri.com/t5/arcgis-pro-questions/symbolizing-unique-values-with-wildcards/m-p/1273...

[solidsnake]

Hi

i have a probleme with attribute rule that execute twice in a feature service.

when i create record in arcgis pro through geodatabase evrything work perfectly for each record i create the ID increment by +1, but when i edit the data through  feature service in Arcgis Pro or with the Edit widget in web app builder its like the attribute rule is executing twice (URB00002, URB00004, URB00006....) +2 for each new record.

i checked Exclude from Application Evaluation but it always fire twice

i tried to put max instance = 1 but it didn't work

the arcade code of the attribute rule in the feature service is the same as the geodatabase, the only difference is the name of the table: in database its  "oncf.dgf.urb_projet" and in feature service its "L2oncf_dgf_urb_projet"

capture of attribute rule in geodatabase

capture of attribute rule in feature service

i use ArcGis enterprise 10.7.1 and arcgis pro 3.0.1

is there a way i can fix this probleme

thanks for you help

[SamSzotkowski]

@solidsnake I had not exactly the same, but a similar issue where attribute rules were creating 2 empty features every time a calculation or constraint rule returned an error.  I submitted a bug report and Esri said that got fixed in Pro 3.1.  So not quite the same thing, but sounds very similar so maybe yours got fixed with that update.

"Updates have been made to the following defect which you are associated with:
BUG-000155457 - The append tool surpasses Attribute rules (both constrain and calculation), adding two empty/null records to the target table per record that violates the rule."

[SayedAamirHussain]

Thank you so much @HusseinNasser2  for explanation, it really helped a lot.