GeoEvent 10.9.1 inappropriate type for attribute error on empty values

[Casper_Span]

I've upgraded our ArcGIS Enterprise with GeoEvent 10.7.1 to 10.9.1 and now I'm seeing some strange behavior. The error I'm getting closely resembles (https://community.esri.com/t5/arcgis-geoevent-server-questions/geoevent-10-9-1-date-field-type-error...) but I'm seeing some differences.

First of all, we have been running this setup since 10.3.1 without any real problems, the only changes we did this upgrade is changing the ArcGIS platform.

As soon as the upgrade was successful I started our own software that feeds GeoEvent through a REST input connector. The schema has a streamlayer with store latest as output.

I am seeing the following errors on various fields, for instance:

Inappropriate type for attribute 'Field4'. This attribute should be of type esriFieldTypeString. com.esri.arcgis.discovery.stream.ValidationException: Inappropriate type for attribute 'Field4'. This attribute should be of type esriFieldTypeString. 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) [?:?]

This was actually a bit of a legacy field that's been removed from our software, but not yet on the ArcGIS side. It will never be filled, but it's a nullable string field, so what should it matter? (or so I thought)

The event will cease being processed at this point, so we're missing data in our output now.

When I add a processor to the scheme that sets a value of "foo" into the field, the error magically disappears and the record will get posted on screen and database.

This is true for all kinds of fields. Integers, Dates, Strings. When the value of the field is null, we're getting that error, but using the field name and the actual field type.

But I'm also getting other kinds of variants where the log reports "Inappropriate type for attribute 'LifeTimeStatus'. This attribute should be of type esriFieldTypeSmallInteger.".

The field is a short on the definition and a smallint in the database side. I'm getting the inappropriate type when I post the number 1 to the field.

I'm at a loss here...

[Anonymous User · Accepted solution]

Hello @Casper_Span ,

I think you are on the right track comparing your issue to the other Esri Communith thread (https://community.esri.com/t5/arcgis-geoevent-server-questions/geoevent-10-9-1-date-field-type-error...). There was a defect logged against the following behavior at GeoEvent  Server 10.9.1:

BUG-000145944: Event records with one or more null values are no longer supported by the ArcGIS GeoEvent Server 10.9.1 stream service output.

This affects null values of any data type when the output connector is a stream service. I would wager this is the limitation you are encoutnering.

I hope this helps!

Best,

Calvin

[Casper_Span]

Hi Calvin,

I was digging some more yesterday and roughly came to this same conclusion. I didn't find that bug report yet, so thanks for giving me that reference.

Do you know if there is a workaround yet, besides filling in spaces for null values within our software responsible for sending the data?

Thanks!

[Anonymous User]

Happy to pass that defect number along.

As for a workaround, the only one available at the moment is as you described - make sure that no null values get passed on to the stream service. Field Calculator processors can be used to make this easier, by converting null integers to zero, or null strings to "null", and so on. Even though null values are acceptable forms of data in all types of ArcGIS Server services, for now we have to steer clear of them for the time being until a better solution comes around.

[MatejVrtich]

Hi,

can you please give an example of how to handle NULL values using a field calculator?

If I understand correctly, I need to conditionally process NULL values (if it is NULL, set the default value, otherwise use the original value), but I am not aware that Field Calculator supports conditional processing.

Thanks,

Matej

[Casper_Span]

Hi Matej,

I'm afraid it's not as easy as that. For some fields in my solution, just setting it hard coded to a single value sufficed, but for 80% of the fields I had to change my backend applications responsible to feed GeoEvent.

So, for instance in C# you can do:

Aanduiding = incident.Aanduiding ?? EMPTY_STRING,

where EMPTY_STRING is a constant of a single space.

But a simular solution can be built in any language.

In GeoEvent you can only fill in fixed values with a field mapper, as far as I know, arcade expressions aren't working.

[MatejVrtich]

Hi Casper and thank you for your reply.

I had in mind what @Anonymous User suggested: Field Calculator processors can be used to make this easier, by converting null integers to zero, or null strings to "null", and so on.

However, this can only be done conditionally (convert the value only if it is null, otherwise pass the value on) and there seems to be no way to do this in GeoEvent Service processing.

Unfortunately, I do not have the ability to change the backend providing the data as it is operated by a third party.

Regards,

Matej

[Casper_Span]

Matej,

Then I fear you have to resort to filters in that case. That will potentially reduce your performance.

Kind regards,

Casper