Latest Contributions by HusseinNasser2

‎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

‎05-02-2024

That is because attribute rules are triggered on updating any field. the target field you set on the attribute rule view is the field you want to set the value to, not the field you that you want triggering the rule. Updating any field will trigger the rule

‎05-02-2024

Unfortunately in complex recursive case like this where the child updates the parent and the parent updates the child we need more context in the attribute rule itself. Currently it is not possible to differentiate between an edit made as a side effect of attribute rule vs an edit that is made directly by the user. Adding that field allows us hint us to know is this edit done by the user or is it a result of a propagation from parent which will allow us to continue propagation vs to stop. The field can be added but hidden so users don't see it. Without this knowledge, parent updates child, which triggers the rule to update the parent which then triggers the rule again to update the child.

‎05-02-2024

Yeah there is a bug here, we are suppose to yell at you that you can't pass variables to FeatureSetByName, because we need the name to be static so we can resolve the table name to a registered geodatabase catalog id. Change your script wherever you have a featuresetbyname and pass in a literal string instead. for example FeatureSetByName($datastore, addresspoint_fc, ['*'], true), firstPoint); to , this and it should solve the problem FeatureSetByName($datastore, "AddressPoint", ['*'], true), firstPoint); Meanwhile we will fix the bug where it tells you the exact the error message instead of 9999 error. it shouldn't even let you save it to begin with.

Online Status	Offline
Date Last Visited	‎03-19-2026 06:14 AM

My Ideas

Latest Contributions by HusseinNasser2

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: Unable to Resolve "The evaluation of attribute rules is cyclic or exceeds maximum cascading level" Error Message

Re: Unable to Resolve "The evaluation of attribute rules is cyclic or exceeds maximum cascading level" Error Message

Re: Cannot save calculation rule after making any change to the expression

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

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

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

Split with Attribute Rules

Temporarily Disable Attribute Rules