GeoEvent Processor - Make outputs aware of coded value domains

[TimothyMichael]

I am currently using GeoEvent processor to send an email when a feature (leak point) is created.  Certain fields in the source feature use coded values for drop-downs :

leak_type ( type: esriFieldTypeDouble , alias: leak_type , editable: true , nullable: true , Coded Values: [1: Leak] , [2: Break] , [3: Other] )

In the email output settings, I am using the GeoEvent field to show the value in the email (Leak Type: ${leak_type}).  The issue is that the Code value is sent in the email, rather than the Description, so the output looks like this:

Leak Type: 1.0
Pipe Condition: 5.0
...etc.

It would be great if the GeoEvent processor was 'domain-aware' and was able to send the Description for field values.  Or, provide an option to let the user choose to send the Code or Description.

[KenCarrier1]

It is kind of sad to see that almost 3 years later this functionality has not made it into the product yet. We are new to geoevent and we are enjoying much of the functionality although somewhat disappointed in the formatting of the email. We built some nice HTML code but then when we triggered an event we noticed only the code was being returned rather than the description of a field which is using a coded value domain. Hoping to help get this idea some attention and see this functionality in a future release.

[RJSunderman]

Ken -

GeoEvent Server really only has the information provided in an event record. When polling feature records from a feature class, through a feature service, GeoEvent is provided the coded values, not the descriptive strings. If the descriptive strings and their coded values are available via a REST request, so we could pull them out of the service's metadata properties, we might be able to offer some sort of switch on an inbound connector to replace the coded values with their descriptive strings ... but this may run into problems with data structures and data types with how the transport and adapter underneath an inbound connector work to pull data into GeoEvent Server.

I have a potential workaround you might try. You could establish the codedValue-to-descriptiveString mapping in a non-spatial table and publish that along with your feature service as a layer ... then configure a Field Enricher processor to use the coded value as the primary key for an attribute join and enrich each event record with the descriptive string for that event record's coded value attribute. If you have only a couple of coded values, this shouldn't be too bad to design into your GeoEvent Service. The only real headache would be having to maintain the coded values for the domain in both the geodatabase and in the look-up table being used by GeoEvent Server.

- RJ

[KenCarrier1]

RJ,

Thank you for the prompt response. In our case we are talking about 50-60 fields all of which have domains applied so I am not sure if the workaround would be feasible for this situation. We might give it a go but I agree the headache of having to maintain it in 2 places is making me think this might not work the way we would have hoped for. I think going forward if an option was provided to pull the code or the description if a domain is applied would be a nice feature. Although I do understand it is certainly easier to say that, than it is to build it on the backend of geoevent. Will keep my fingers crossed this makes it into a future release, thanks again RJ!

[RJSunderman]

Yeah, in your case, I would not try to design a GeoEvent Service with five or six dozen Field Enricher processors to convert the coded values to descriptive strings one at a time. The headache of trying to maintain that in a GeoEvent Service aside, you'll likely encounter performance and perhaps even product stability issues.

For this case, given 50 - 60 coded value domains, I think the better approach would be to develop a custom processor using the GeoEvent Server SDK. A custom processor could take in a single event with five or six dozen coded values and convert all of those numeric fields to equivalent descriptive string values. One event in, one event out, one processor. Much cleaner approach.

- RJ

[RJSunderman]

Update June 2023

There have been a couple of changes to GeoEvent Server which could be used to support coded value replacement as part of an event processing workflow. These changes will required that you have upgraded to at least the ArcGIS 10.9.1 release of GeoEvent Server though.

The first option, if you have only one or maybe two attribute fields which contain coded values, would be to use the new Choice element. You could use Choice to switch on the coded value in each field and fan-out to follow each choice with a separate Field Mapper processor to write a descriptive string or label for a coded value into an attribute field. If you allowed the input to adapt the coded values as String then you could have the Field Mapper replace the string value '1' with the more descriptive string 'Minor Leak', for example.

The drawback to this approach is that a coded value domain with a dozen (or more) discrete coded values would require a separate Field Calculator for each choice of coded value. The fan-out in your GeoEvent Service could become unwieldy, especially since you would also need a separate Choice element for each attribute field which contained a coded value.

This is hardly better, in my opinion, than using a Field Enricher if you have dozens of attribute fields each with their own coded values. The approach uses a lot of brute force, and isn't very elegant, but it is more readable (perhaps) than a second approach I can suggest.

The second approach would be to use a Field Mapper processor which, beginning with the 10.9.1 release, supports field name delimitation and expression evaluation.

Suppose you were receiving data like the following:

[
   { "code1": 1, "code2": 20, "code3": -3 },
   { "code1": 2, "code2": 30, "code3": -2 },
   { "code1": 3, "code2": 10, "code3": -1 }
]

The value { 1, 2, 3 } in the field code1  should be replaced with { 'Red', 'Green', 'Blue' }
The value { 10, 20, 30 } in the field code2 should be replaced with { 'Small', 'Medium', 'Large' }
The value { -1, -2, -3 } in the field code3 should be replaced with { 'Jack', 'Jill', 'Jane' }
etc.

An expression like the following could chain together a series of replaceAll( ) functions to handle the coded value replacement.

replaceAll(replaceAll(replaceAll(code1, '1', 'Red'), '2', 'Green'), '3', 'Blue')

The attribute value in the input field (code1 in this example) would have to be adapted as a String (rather than an Integer) so that the expression could overwrite one string value with another.

Nesting several replaceAll( ) functions together this way requires the input string to be iteratively evaluated (and re-evaluated) which isn't very efficient. The expression itself would also become unwieldy if, for example, there were dozens of coded values in the domain. The only real advantage to this second approach is that you could configure a single Field Mapper with several different string substitution expressions in each of several different mapping fields. Each field mapping expression would take data from one field, translate it, and write the translation out to a target field.

Configuring a Field Mapper with an array of string manipulation expressions might be better than having to configure a Field Enricher to handle the look-up of a descriptive string value and enrich the look-up value into an event record if only to avoid having to configure a separate Field Enricher for each attribute field containing a coded value you needed to translate (using a series of separate look-up tables).

You can read more about using expressions in Field Mapper in the blog @EricIronside has here:  GeoEvent 10.9: Using expressions in Field Mapper Processors