In GeoEvent Processor 10.3 does the "Update a Feature" output create new features if a match to the Unique Feature Identifier Field does not exist?

[JayFlorey]

In GeoEvent Processor 10.3 does the "Update a Feature" output create new features if a match to the Unique Feature Identifier Field does not exist?

[RJSunderman · Accepted solution]

Hello Jay -

My apologies that this reply is coming to you so late - hopefully it is still useful.

Yes, the 'Update a Feature' output should default to add a new feature to a target feature class if an existing feature cannot be found whose 'Unique Feature Identifier Field' matches the received event's TRACK_ID.

The process at the 10.3 / 10.3.1 product releases goes something like this:

• An event whose GeoEvent Definition has a field tagged TRACK_ID arrives at an 'Update a Feature' output
• The output checks an internal cache to see if it has an OID (row identifier) mapped for the event's TRACK_ID
  • If so, the output attempts to use that OID to update the specific feature
  • If it doesn't have an OID, it queries the feature layer to try and discover which feature should be updated

If GeoEvent queries for the OID needed to update a feature and discovers that no feature exists in the feature class whose 'Unique Feature Identifier Field' value matches the current event's TRACK_ID ... then it will assume that a new feature needs to be created. Basically we're making requests on three different endpoints of the targeted feature service:

• .../arcgis/rest/services/service-name/FeatureServer/layer-index/query
• .../arcgis/rest/services/service-name/FeatureServer/layer-index/addFeatures
• .../arcgis/rest/services/service-name/FeatureServer/layer-index/updateFeatures

You can request GeoEvent log the REST requests it is making by turning DEBUG logging on for the Feature Service outbound transport:

com.esri.ges.transport.featureService.FeatureServiceOutboundTransport

This will enable you to see the actual JSON included with each REST request and follow the transactions GeoEvent is making with your feature service. You might find additional information in my blog 'Debugging the Add a Feature / Update a Feature Output Connectors' helpful.

Best Regards -

RJ

[JayFlorey]

Hi RJ,

Thank you very much for the reply and the link to the debugging site. I'm not sure why the create was failing, but I have since implemented a GeoEvent Service pointing to a different feature class that did successfully create new features in the class. I will go back and take another look at the failing feature service to see if there is a setup issue. These feature classes are versioned, and the feature service is pointing to a child version. On a related question, why does the Update a Feature output leave large gaps in the OBJECTID sequence when it creates new features? In a class where the highest existing OBJECTID was less than 10, the GeoEventProcessor created features started with OBJECTID 810.

Cheers,

Jay

[RJSunderman]

Hello Jay -

These feature classes are versioned, and the feature service is pointing to a child version.

Don't do that.  The add / update feature capability being performed by GeoEvent has never supported versioned geodatabases.

[RJSunderman]

Hey Jay -

On a related question, why does the Update a Feature output leave large gaps in the OBJECTID sequence when it creates new features? In a class where the highest existing OBJECTID was less than 10, the GeoEventProcessor created features started with OBJECTID 810.

Many times, when using the 'Add Features' or 'Update Features' capabilities on a feature service, I have observed that one set of edits will use OBJECTIDs 1, 2, 3, 4 ... and see a second set of edits jump to begin using OBJECTIDs 401, 402, 403, ...

This is actually by design, and has nothing to do with the GeoEvent Extension. My understanding is that this is an attempt by ArcGIS Server to avoid conflicts when multiple contributors (or multiple web applications) are making edits to a feature class through a feature service's REST endpoints. By detecting, somehow, that a second editor is making edits, that second editor will be assigned a block of IDs (401, 402, 403, ...) so that features they add and update will not interfere with likely requests a previous editor is making to add and update features.

You can easily see this if you add a feature service's layer to a web map, begin editing, then in a different window POST an Esri Feature JSON record to the feature layer's 'Add Features' endpoint, then return to the web map and continue adding/editing features.

This is the primary reason why we introduced date/time support when polling a feature service for incremental updates. We had assumed (wrongly) that if a GeoEvent input were to cache the last (largest) OBJECTID retrieved we would be safe in querying for OBJECTIDs greater than our largest observed value. What we found was that we would often miss features that the first contributor had created; once we began querying in the 401, 402, 403, ... range we would never pick up features created in the 5, 6, 7, 8 ... range of OBJECTIDs.

- RJ