GeoEvent Processor - Make outputs aware of coded value domains

733
4
05-29-2015 07:03 AM
Status: Open
TimothyMichael
Occasional Contributor II

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.

4 Comments
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