Summarizing GeoEvents into one single email notification

401
1
05-23-2018 12:56 PM
KonradHughes
New Contributor II

I wanted to know if the out-of-the-box output connector Send An Email has the ability to do this.

For example, at the moment I have NOAA's observed river gauge layer monitored by my Geoevent Service.  Every 24 hours, the service will search for any gauges at minor stage or higher within my state.  I already have an output connector that sends these geoevents to a feature service, so I can observe my service working the way it's supposed to.  However, it's my understanding that geoevents are not cached.  If I want Geoevent to create one email containing all of the resulting gauges that the geoevent service identified, along with their names, locations, and attributes, I would need a way to cache the geoevents and send them all at once.  

The second problem would be to format the email body to contain fields from all of the geoevents.  I haven't reached this step yet, but having seen the email outputs already it doesn't appear to have the ability to differentiate between the fields belong to different geoevents.  Has anyone had any success with this concept?

0 Kudos
1 Reply
JohnEvans6
New Contributor III

Hi Konrad,

The short answer I found was no, not out of the box.

I completed a very similar project to yours and had the same problem of needing a single email that contained multiple geoevent incidents/triggers based on attributes. The easiest way for me was to use the TCP output connector. I then built a small listener in node to parse the data and send out emails. I couldn't figure out how to aggregate things directly within the GEP itself.

If I have a point that is found to be inside of a specific type of NWS Watch and Warning, I'll start tracking an incident via incident tracker. After a couple of additional processes (including data re-enrichment from the original input point feature service), I output a TCP message that looks like this:

Incident-Object-Repopulation,4edfb20f-80d7-4830-96bc-debdaf4342e5,Cumulative,Started,2018-08-23T03:28:16.723-04:00,ITO Airport,"Areal Flood Advisory/4041400,Flash Flood Watch/4038467,Flash Flood Watch/4039727,Hurricane Watch/4037484,Hurricane Warning/4041407,Flash Flood Watch/4041532,Hurricane Warning/4039274,Areal Flood Advisory/4040721,Areal Flood Advisory/4041585,Flash Flood Warning/4041621,Areal Flood Advisory/4040656,Hurricane Warning/4039807,Hurricane Warning/4040471",HILO INTL,Hilo,HI
Incident-Object-Repopulation,700ae764-81e4-4eb6-9054-79633b98e2d1,Cumulative,Started,2018-08-23T03:28:16.781-04:00,ITO Combined Tower/Approach,"Areal Flood Advisory/4041400,Flash Flood Watch/4038467,Flash Flood Watch/4039727,Hurricane Watch/4037484,Hurricane Warning/4041407,Flash Flood Watch/4041532,Hurricane Warning/4039274,Areal Flood Advisory/4040721,Areal Flood Advisory/4041585,Flash Flood Warning/4041621,Areal Flood Advisory/4040656,Hurricane Warning/4039807,Hurricane Warning/4040471",Hilo Tower,Hilo,HI

My code game is kind of weak, but the node server listens on the same port as the output connector, parses out the data whenever it gets any, and builds an email. Doing it this way solves problem 2.  I had the freedom to do things like format the message, group messages based on Warning Type, and add a map link that takes a field from the message as a URL parameter. This allows the user to open up to that specific object on a shared arcgis portal map.

0 Kudos