Latest Contributions by HusseinNasser2

‎06-30-2025

Reposting this article I authored back in 2021 for visibility as it is not easily searchable. In it I discuss the best practices of authoring and configuring attribute rules. Hopefully you found it useful. https://community.esri.com/t5/attribute-rules-blog/attribute-rule-authoring-and-configuration-tips/ba-p/1023745

‎05-16-2025

The error "The requested operation is unsupported by instance db" often indicates that the geodatabase the UN is loaded on is not upgraded where some stored procedures maybe required by the application and they are not there. That explains why you are getting it on both enable and applyEdits. Can you try running upgrade geodatabase from your current Pro? Before you do that, take a screenshot of the current geodatabase version, I want to know what geodatabase version you are on because it is been years since I saw this error. You can find out by logging in as sde user and go to the properties. Expand Geodatabase version, upgrade status. Then run upgrade geodatabase gp tool when you are ready. If it works after that, will do some work to improve the doc.

‎02-07-2025

What version of Pro are you using? We should have yelled with a message that the sequence doesn't exist

‎02-07-2025

My guess is you might need to account for empty geometries , line 26 points to this "paths": json["rings"], which essentially means it couldn't find the "rings" property in the geometry object you sent to the function. So either you are sending something else (which your code doesn't look like it) or one of your features have an empty geometry that was recently added that broke your script.. try updating this function with this function polygonToPolyline(p) { var json = Dictionary(Text(p)); if (!haskey(json, "rings")) return; if (!haskey(json, "spatialReference")) return; var polylineJSON = { "paths": json["rings"], "spatialReference": json["spatialReference"] }; return Polyline(polylineJSON) } Now this script may cause other downstream failures so you might want to handle the empty geometry across the rest of the script.

‎02-05-2025

Can you try installing fiddler and capture the applyEdits call? What does the response looks like? Pro should refresh the map with updated features on the backend, the applyEdits returns a payload called "ServiceEdits" which tells the client the updates that have been made to the server (this includes attribute rules ) Capture what the request parameters (there should be returnEdits or returnServiceEdits parameter) and in the response there should be the edited features payload

‎01-02-2025

I know this is an answered post but just adding this for additional info. I wrote up a post to explain why. Why FeatureSetByName doesn't work with variables https://community.esri.com/t5/attribute-rules-blog/why-featuresetbyname-doesn-t-work-with-variables/ba-p/1541572

‎10-14-2024

Looks like you figured it out, you just need to add " " on the globalid, otherwise the JSON is invalid. [{"isFilterBarrier":false, "globalId": "{D0C706FB-B4D1-4645-A1B1-24CF0B1DE7F4}" ,"percentAlong":0.5, "traceLocationType":"startingPoint"}] Now we need to figure why Trace widget isn't sending the globalid though, sounds like a bug

‎10-10-2024

This is now possible with Pro 3.4 (You can test it with the Beta 1) with Attribute Rules Triggering Fields In previous releases of Pro, updating any field on a class that has immediate attribute rules will always execute update-based attribute rules enabled on that class. With this new feature in 3.4 Beta 1, users can specify what fields would trigger a constraint or immediate calculation rule on update, this way updating fields that do not affect the execution of attribute rules won't trigger the rules, significantly improving editing performance. To solve this particular idea, one would remove all triggering fields (which is the default) from the rule and only keep the "Shape" as single triggering field. Updating any attribute won't execute the rule, only updating the geometry will.

‎09-23-2024

When writing attribute rules, we often tend to use the FeatureSetByName function to reference other tables or classes. However, you might have encountered this error before when using Arcade scripts with attribute rules that utilize this function. ERROR 160288: The name object is invalid. (3.3.3, 3.2.4, 3.17, 2.9.13) ERROR 161022: Attribute Rules FeatureSet functions require a literal text string for table names. (3.4+) This means you wrote an Arcade expression using FeatureSetByName and passed a variable to the class name parameter. Here is an example: var class_name = "test"; var feature_set = FeatureSetByName($datastore, class_name); This pattern is not supported, and the error message is intentional to protect against downstream errors, such as issues with publishing, copy and paste, exporting XML workspaces, and various other data transfer operations. To fix this, find all instances of FeatureSetByName and ensure you are passing a literal string, as shown below: var feature_set = FeatureSetByName($datastore, "test"); Why does FeatureSetByName require a literal string? In ArcGIS Pro 2.3, we added the ability in attribute rules to reference other tables and classes. This created a dependency tree: if class A has an attribute rule that references class B, copying class A should also bring class B with it; otherwise, the editing behavior will be broken in the new workspace. To support this, in Arcade, we statically analyze the script to determine this dependency and rely on literal strings to find the referenced classes. When using a variable in FeatureSetByName instead of a literal string, we would have to execute all Arcade expressions to find the value of the table, which would slow down the process of saving the rule. Moreover, execution alone is not enough to discover the table name — for example, having FeatureSetByName nested within a condition that might not be reachable during execution would still pose a problem. Therefore, always use a literal string when working with FeatureSetByName. Note that this is also applicable to FeatureSetByRelationShipClass

‎07-08-2024

Because the services is reading and caching the definitions of the geodatabase it acquires the shared lock. This blocks anyone from going to the database and update the definition which will result in the service having stale/outdated definitions which can cause problems. If you know that, hey I'm just changing an alias of a field or adding a comment to an attribute rule, yes it is updating the definition but it won't cause any harm, then yes it is safe to uncheck that option so the service won't acquire any locks. and Yes we refer to dedicated instances here because those cache the definitions. I'm not familiar very much with shared instances behavior but I would assume they destroy all cache after every request because you could open multiple workspaces on the same shared process and that will cause bloat in memory and perhaps bugs. For the maxCacheAge, you can add only add it in the admin api, right under the properties of the mapserver of your service. I think if the default is 300 (5 minutes), is it not there by default. thanks for bringing up the issue that it isn't in the doc For the feature dataset question I don't think we document that as its an implementation details so it won't be in the official doc, but perhaps mentioning it as part of best practices in general would be good idea. If you enabled debug logging , you should see a debug entry, something like this. Which tells you how long the broadcast took, and how many tables/classes and relationships were touched. So if you have a feature dataset with 100 classes, and you just published one of those classes as a service, all 100 will be opened when you edit that class. BeginBroadcastStopEditing;Broadcasting Stop editing accross: 1 Feature Datasets, 24 Tables, 17 Relationships Hope that helps

‎07-05-2024

Here is this year's attribute rules session, filled with new content and great questions from the audience! https://mediaspace.esri.com/media/t/1_r9zuohx4/325483122

‎06-18-2024

Can you try isempty function? ar fs = FeatureSetByName($datastore,'Parcels_OCPA_Web',["PARCEL"],FALSE); if (isempty(geometry($feature))) return; var interlayer = Intersects(fs, $feature); var cnt = Count(interlayer); var billing = $feature.MultiUserType if (TypeOf($feature) == null) { ParcelID = $feature.ParcelID } else if ((cnt > 0) && (billing != "D: Delete")) { var interpid = First(interlayer); return interpid.PARCEL; }

‎05-14-2024

The error essentially say you tried to update a feature that doesn't exist. So we need to debug to see what the rule is passing.. I see you are using 2.9.10, is it possible to move to 2.9.12? we included many fixes for attribute rules and relationships there plus we also included the ability to print the console output to the debug diagnostics in Pro. I included the updated rule with few changes.. Run the rule while ArcGIS Pro monitor is running (debug mode) (CTRL+ALT+M), and look for the console output , I added **** to make searching easy, see what output you get, this will tell us more. var globalId = $feature.globalid var lstatus = $feature.LSTATUS; var tableToUpdate = "EW"; var fs = FeatureSetByName($datastore, "EW", ["globalid"], false); var feats = Filter(fs,'CGUID = @globalId'); var editDict = {'className': tableToUpdate, 'updates': []}; var updateCount = 0; var updateList = []; for(var feat in feats) { var updateDict = {'GlobalID': feat.globalid, 'attributes': {"lstatus": lstatus}}; updateList[updateCount++] = updateDict } //if no matches simply return. if (updateCount == 0) $feature.comments; editDict[updates] = updateList; //print out console("******" + text(editDict)) return {'edit': editList};

‎05-07-2024

I think you might just ran into this issue https://community.esri.com/t5/attribute-rules-questions/cannot-save-calculation-rule-after-making-any/m-p/1418156#M1428

‎05-02-2024

Thanks Linda, You see rules often are downloaded to the client application (e.g. ArcGIS Pro) so when you make the edit the rule is executed in the application locally first (like Pro) then the modified row is sent to the backend (be it a service or geodatabase) where it will be executed again. so if this option is checked it means that this rule will execute on the backend and not locally in the application. So in the first case you will see the change immediately, while in the second case you will have to wait for the server/backend to finish processing your edit, built a service edits payload (things that has changed in the server) and return to the client application, the application then takes those changes and applies them locally to the display/caches where it will show up. So yes little delay but the delay is equal to the time of the actual edit. hope that helps There is a devsummit session I did where I go into that in details https://mediaspace.esri.com/media/t/1_gr7hrdjy

Online Status	Offline
Date Last Visited	3 weeks ago

My Ideas

Latest Contributions by HusseinNasser2

Attribute Rule Authoring and Configuration Tips and Best Practices

Re: enable utility network topology errors

Re: General Evaluation Error

Re: Address Data Management- "Arcade error: Field not found"

Re: Attribute rule evaluation on the backend does not seem to get synced back to the client (ArcGIS Pro) but appear once I force a restart of ArcGIS P

Re: Is it possible to pass dataset name from variable?

Re: Share named trace configuration in webmap - missing JSON parameter

Re: Attribute Rules: Update only on geometry change - Status changed to: In Product Plan

Why FeatureSetByName doesn't work with variables

Re: Attribute Rules - A Deep Dive - DevSummit 2024

Attribute Rules - A Deep Dive - DevSummit 2024

Re: How to skip over a record for update in AR that is null geometry when using Intersects

Re: A requested row object could not be located-Attribute rule for calculating and update value on relationshipclass.

Re: I am encountering an issue with saving an attribute rule in ArcGIS Pro

Re: Attribute Rules - Exclude from Application Evaluation

Re: Edit operation failed. Message: Cannot acquire...

Re: Attribute Rule [Constraint]: Combining GetUser...

Re: Attribute Rule [Constraint]: Combining GetUser...

Re: applyEdits in squence - FeatureService vs. Lay...

Split with Attribute Rules