GeoEvent Field Name Inconsistencies

306
2
Jump to solution
02-22-2024 12:47 PM
BenClark
Occasional Contributor

Okay, folks, I've been pulling my hair out over this one all afternoon: Our GeoEvent deployment receives data from our Geotab AVL system, which comes along with a handful of its own definitions that can't be edited and I need information from two of them to be fed through to a feature service hosted in our Portal. "No big deal!", I think, as I know there's an Event Joiner processor that I can use to combine the two definitions. That works great, except for when I go to publish the necessary Update Feature output. I'm able to publish the feature service just fine, but where I run into trouble is when I go to assign the Unique Feature Identifier Field via dropdown in the output configuration page the available fields all have their names truncated. Not only does this make it extremely difficult for me to choose what I think is the correct field, but GeoEvent doesn't recognize them either, and I get error log entries about how the field I've chosen as the unique identifier can't be found. This is the show stopper.

I've also tried adding in a Field Mapper processor after the Event Joiner processor in order to write to a definition that has shorter field names that don't get lobbed off in the output configuration window, but then I get error messages about the Track ID getting dropped and nothing but null values past the Field Mapper (but with good data going into it).

I'm stumped. Anyone have any insight? I've added a few images showing what's going on.

0 Kudos
1 Solution

Accepted Solutions
GregoryChristakos
Esri Contributor

@BenClark - There might be a defect here that's worth investigating on our end, but in the meanwhile I have a couple of thoughts/things you could try as a workaround.

1. Before using the event joiner, consider shortening the field names in your source definitions so that the resulting joined definition ultimately has shorter fields too. You might even want to go so far as to shorten the definition name feeding into the event joiner since these names are also prepended in the event joiners definition field names. This entire suggestion would potentially mean using a field mapper before the event joiner since the geotab fields associated with your input definitions are fixed. This means geotab input (i.e. the fixed definition) -> field mapper (where you've defined shorter field names and a shorter definition name instead of using the fixed geotab definition) -> event joiner -> *optional* field mapper (to redefine/shorten the joined field names once more) -> output feature layer.

2. Should the above be a no go, you might want to try truncating the resulting fields even further by removing "geotab_exceptionevent___" as a prefix with your current configuration. This means geotab input -> event joiner -> field mapper (where you reduce the field names even further) -> output. This might alleviate the drop down problem you mentioned before if I recall correctly.

3. The event joiner strips away any tags (such as the TRACK_ID tag). This goes hand in hand with all the suggestions here but make sure you assign the TRACK_ID tag again in the target definition you're specifying in the field mapper processor (after the event joiner). I assume you've done this already, but its worth double checking.

View solution in original post

2 Replies
GregoryChristakos
Esri Contributor

@BenClark - There might be a defect here that's worth investigating on our end, but in the meanwhile I have a couple of thoughts/things you could try as a workaround.

1. Before using the event joiner, consider shortening the field names in your source definitions so that the resulting joined definition ultimately has shorter fields too. You might even want to go so far as to shorten the definition name feeding into the event joiner since these names are also prepended in the event joiners definition field names. This entire suggestion would potentially mean using a field mapper before the event joiner since the geotab fields associated with your input definitions are fixed. This means geotab input (i.e. the fixed definition) -> field mapper (where you've defined shorter field names and a shorter definition name instead of using the fixed geotab definition) -> event joiner -> *optional* field mapper (to redefine/shorten the joined field names once more) -> output feature layer.

2. Should the above be a no go, you might want to try truncating the resulting fields even further by removing "geotab_exceptionevent___" as a prefix with your current configuration. This means geotab input -> event joiner -> field mapper (where you reduce the field names even further) -> output. This might alleviate the drop down problem you mentioned before if I recall correctly.

3. The event joiner strips away any tags (such as the TRACK_ID tag). This goes hand in hand with all the suggestions here but make sure you assign the TRACK_ID tag again in the target definition you're specifying in the field mapper processor (after the event joiner). I assume you've done this already, but its worth double checking.

BenClark
Occasional Contributor

Thank you very much for your time and assistance, Gregory. Option number one above worked like a charm! Two field mappers to effectively truncate the field names of the two otherwise immutable Geotab definitions upstream of the Event Joiner behaved exactly as I expected it to. Working beautifully now. 🙂

Edit: Oops! In case anyone else comes across this post I also wanted to mention that I added a third Field Mapper after the Event Joiner in order to reestablish the Track ID and Geometry fields. As Gregory points out above, those tags are scrubbed by the Event Joiner processor and using the third Field Mapper allowed me to create a final definition with the proper tags in place. If you don't do this you'll still get what looks like good tabular data, but the geometry won't actually update.