Geoevent 10.9.1 Date field type error

831
2
Jump to solution
11-29-2021 11:04 PM
WalterSimonazzi_VicPol
New Contributor III

Hi community,

I set up the geoevent definition below in geoevent 10.9.1 that is used for the input and output of a geoevent service.

Input:  (Receive JSON on a REST Endpoint)

Output:  (Send Features to a Stream Service)

WalterSimonazzi_VicPol_0-1638254580807.jpeg

And set up a streams service that stream the location of our front line members. All working fine as shown in the map below.WalterSimonazzi_VicPol_1-1638254612557.jpeg

However, when I check the Geoevent logs, I see the error below:

Inappropriate type for attribute 'unit-activitydatetime'. This attribute should be of type esriFieldTypeDate. com.esri.arcgis.discovery.stream.ValidationException: Inappropriate type for attribute 'unit-activitydatetime'. This attribute should be of type esriFieldTypeDate. at com.esri.arcgis.discovery.stream.StreamService.validate(StreamService.java:813) ~[!/:?] at com.esri.arcgis.discovery.stream.StreamService.publish(StreamService.java:257) ~[!/:?] at com.esri.arcgis.discovery.stream.StreamService.send(StreamService.java:939) [!/:?] at com.esri.ges.transport.streamService.StreamServiceOutboundTransport.receive(StreamServiceOutboundTransport.java:502) [!/:?] at com.esri.ges.manager.stream.internal.OutboundTransportProxy.receive(OutboundTransportProxy.java:34) [!/:?] at com.esri.ges.manager.stream.internal.OutboundStreamImpl.receive(OutboundStreamImpl.java:178) [!/:?] at com.esri.ges.adapter.OutboundAdapterBase.receive(OutboundAdapterBase.java:36) [!/:?] at com.esri.ges.adapter.json.FeatureJsonOutboundAdapter.flushQueue(FeatureJsonOutboundAdapter.java:98) [!/:?] at com.esri.ges.adapter.json.FeatureJsonOutboundAdapter.run(FeatureJsonOutboundAdapter.java:75) [!/:?] at java.lang.Thread.run(Unknown Source) [?:?]

WalterSimonazzi_VicPol_2-1638254708818.jpeg

I tried to change it in the definition file however the only option available is “Date”, there is not a filetype esriFieldTypeDate that I can choose from. Can you advice please?

Regards,

@RJSunderman 

 

 

1 Solution

Accepted Solutions
RJSunderman
Esri Regular Contributor

Hello Walter --

The short answer, I think, is that GeoEvent Server displays Java data types in its pick list:

RJSunderman_0-1639680996776.png

When you configure a GeoEvent Definition you choose a data type for an event record attribute from one of the available types above.

The esriFieldTypeXXX date types come into play when looking at an ArcGIS Enterprise hosted feature layer or feature service which stores feature records in an enterprise geodatabase. The .NET API help topic lists the supported data types for feature record attributes.

Several of these GeoEvent Server does not support (like esriFieldTypeBlob). Others, like esriFieldTypeInteger, are compatible with a GeoEvent Definition specifying the ‘Java’ data type Integer. It can get a little tricky trying to keep the differences between the 64-bit Java data types used by GeoEvent Server and the 32-bit data types used by other parts of the ArcGIS Enterprise straight. Luckily, date/time values are always compatible when using a ‘Java’ type Date and ArcGIS Enterprise esriFieldTypeDate data type.

So long as the event records you route to a Send Features to a Stream Service output (for example) have date/time values mapped as Date then the outbound adapter should be able to construct a data record formatted as Esri Feature JSON representing the date/time as an epoch long integer value (a 13-digit integer representing milliseconds since the Unix Epoch). That is what you should see in the ArcGIS REST Services Directory when subscribing to a stream service to see feature records the service broadcasts. It is also what you see when querying a feature service “at REST” using the query endpoint exposed by the feature service. What you see when looking at a pop-up in a web mapping application is up to the web application -- it probably is going to represent the epoch value it gets from the database as a more human readable string, and might even do you the favor of shifting the value from UTC to the local time of your client/server machine.

I’m not familiar with the GeoEvent Server component logger StreamService-IRIS-delete captured in your screenshot. I would want to take a look at how the event processing upstream from the Send Features to a Stream Service output has been configured. I’m just guessing, but maybe by the time the event record reaches the output the data type for unit-activitydatetime has changed?  Maybe it is a String or a Long integer value rather than a Date?

The product team does rely on Esri Tech Support to work through these type of issues with customers, so I would encourage you to open an incident with Esri Tech Support so that an analyst can be assigned to investigate the issue and assist with reproducibility (if necessary). If you think it necessary you can request a GeoEvent Server specialist be assigned when you open an incident with Esri Technical Support.

Hope this information helps --
RJ

View solution in original post

2 Replies
RJSunderman
Esri Regular Contributor

Hello Walter --

The short answer, I think, is that GeoEvent Server displays Java data types in its pick list:

RJSunderman_0-1639680996776.png

When you configure a GeoEvent Definition you choose a data type for an event record attribute from one of the available types above.

The esriFieldTypeXXX date types come into play when looking at an ArcGIS Enterprise hosted feature layer or feature service which stores feature records in an enterprise geodatabase. The .NET API help topic lists the supported data types for feature record attributes.

Several of these GeoEvent Server does not support (like esriFieldTypeBlob). Others, like esriFieldTypeInteger, are compatible with a GeoEvent Definition specifying the ‘Java’ data type Integer. It can get a little tricky trying to keep the differences between the 64-bit Java data types used by GeoEvent Server and the 32-bit data types used by other parts of the ArcGIS Enterprise straight. Luckily, date/time values are always compatible when using a ‘Java’ type Date and ArcGIS Enterprise esriFieldTypeDate data type.

So long as the event records you route to a Send Features to a Stream Service output (for example) have date/time values mapped as Date then the outbound adapter should be able to construct a data record formatted as Esri Feature JSON representing the date/time as an epoch long integer value (a 13-digit integer representing milliseconds since the Unix Epoch). That is what you should see in the ArcGIS REST Services Directory when subscribing to a stream service to see feature records the service broadcasts. It is also what you see when querying a feature service “at REST” using the query endpoint exposed by the feature service. What you see when looking at a pop-up in a web mapping application is up to the web application -- it probably is going to represent the epoch value it gets from the database as a more human readable string, and might even do you the favor of shifting the value from UTC to the local time of your client/server machine.

I’m not familiar with the GeoEvent Server component logger StreamService-IRIS-delete captured in your screenshot. I would want to take a look at how the event processing upstream from the Send Features to a Stream Service output has been configured. I’m just guessing, but maybe by the time the event record reaches the output the data type for unit-activitydatetime has changed?  Maybe it is a String or a Long integer value rather than a Date?

The product team does rely on Esri Tech Support to work through these type of issues with customers, so I would encourage you to open an incident with Esri Tech Support so that an analyst can be assigned to investigate the issue and assist with reproducibility (if necessary). If you think it necessary you can request a GeoEvent Server specialist be assigned when you open an incident with Esri Technical Support.

Hope this information helps --
RJ

WalterSimonazzi_VicPol
New Contributor III

Hi RJ,

Thanks for such a detailed answer. 

0 Kudos