Send One E-mail Notification with GeoEvent

866
6
10-18-2019 11:15 AM

Send One E-mail Notification with GeoEvent

When working with GeoEvent you may want to send a notification when a particular event occurs.  For example, when there is a flood warning for a county.  In this scenario you can be polling a feed of Flood Warnings.  When it intersects a geofence, i.e. a county boundary, an e-mail notification should be sent.  However, if you're polling the flood warning feed every 2 minutes, you don't want to send an e-mail every 2 minutes.  You want to only send one when the event first occurs.  This document will walk you through how to do just that.

1.  I will set up my Input to poll a service from a Live Weather feed.  There are a lot of free Live Weather feeds you can access as mentioned here.  I configured a Data Store in GeoEvent to connect to the following URL:  https://services9.arcgis.com/RHVPKKiFTONKtxq3/arcgis

2.  I created an Input to Poll an ArcGIS Server for Features from this Live Weather Feed every 2 minutes.  I set a query to only return Flood Warnings.

3.  When configuring the Input I chose to create a GeoEvent Definition called Flood Warning GeoEvent Def.  I will next tag the Uid field as the TRACK_ID:

4.  Next I will set up a Send an Email output.

I'm calling fields from the service I am polling by using the sytnax ${fieldname}.  For example, I'm calling the following fields:

  • ${Start}
  • ${End_}
  • ${Summary}
  • ${Link}

5.  I have an Input and an Output, so now I will need the link the two by creating a GeoEvent Service.  The first Processor I will add to this is the Incident Detector:

Note:  GeoEvents sent into Incident Detector must have a GeoEvent Definition containing a TRACK_ID.

  • Incident Name:  can be set to anything
  • Opening Condition:  in this example the opening condition is set to create an incident if the incoming geometry intersects a particular geofence (Jefferson County in Wisconsin)
  • Closing Conditionthe incident will be ended once the closing condition is met.  The closing condition is when the incoming geometry no longer intersects the geofence
  • Severity:  set to either Notification, Warning, or Urgent
  • Incident Type: 
    • Point-In-Time incidents have no closing condition. They are considered instantaneous and are closed immediately after they are generated and have no incident duration.
    • Cumulative incidents have both an opening and a closing condition. The time between the incident's generation and its expiry, or closing, is the incident's duration. Cumulative incidents are monitored and updated by GeoEvent Server as additional event data is received.  This is required in this example.
  • Geometry Type:  Incident Detector is typically configured to associate a point geometry with incidents it creates to model an incident as having occurred at a specific location at a specific time. However, multipoint and polyline are also supported geometry types for incidents created by the processor.
  • Expiry Time:  when the expiry time is met, the incident is closed/ended, even if the closing condition is not met.  In the above example I set this to a large value (4 days) so that the incident is not closed.  If this was set to 5 minutes, another e-mail notification would be sent after 5 minutes even though the closing condition was not met

6.  When the initial opening condition is met, the event switches from it's incoming GeoEvent Definition (i.e. Flood Warning GeoEvent Def) to the incident GeoEvent Definition:

The only information retained from the initial GeoEvent Definition is the field tagged with TRACK_ID.  Since the event is now using the incident GeoEvent Definition, status is a field that will be populated with the value Started when the opening condition is first met.  When the event is received again, the status will be Ongoing.  When the closing condition, or the expiry time is exceeded, the status will be Ended.

7.  A filter is set up to only process the event if the status = Started:

This is the key part to only send one notification.  The next time the Flood Warning feed is polled, and it's still intersecting the county, the status is now Ongoing so it will not send another e-mail.

8.  I configured the e-mail output to use fields from the Input Flood Warning feed.  Since the event is now using the incident GeoEvent Definition I will have to join the information back from the initial GeoEvent Definition to retrieve these attributes.  To do this I will add a Field Enricher (Feature Service) processor:

  • ArcGIS Server Connection:  the connection where the Input is coming from
  • Folder:  the folder the service resides in
  • Service:  the Flood Warning service
  • Layer:  the layer we're polling
  • Feature Layer Join Field:  this will be the field tagged as the TRACK_ID in the Flood Warning GeoEvent Def
  • Target Fields:  I will be joining New Fields as they do not exist in the incident GeoEvent Definition
  • Enrichment Fields:  which fields I want to join (these are the fields I used in the e-mail output)
  • New GeoEvent Definition Name:  a new GeoEvent Definition is created when creating New Fields
  • GeoEvent Join Field:  this will be the incident GeoEvent Definition and will use the trackId field as this field contains the information from the field tagged with TRACK_ID (in this example I tagged the Uid field)

9.  Here is the final look of the GeoEvent Service:

When a Flood Warning event intersect Jefferson County, it will send one e-mail notification with details associated with that Flood Warning.  Ex:

Comments

Hi Jake

thanks for the comprehensive explanation on how to setup this notification service.

I have a quick question concerning the setting used in the Input service, specifically the "Get Incremental Updates" option, where in your example this is set to "No".

Can you please explain the rationale behind using Yes vs No and the use cases where either option is preferrable ?

In my example, I have a fixed network of stations (so if I understand correctly Track_ID would be associated with the StationID ?) that can record a flooding status and whose attributes change over time according to the status. A new timestamp is used to register the status change for a given station and stored in a LastUpdated field.

So given this scenario, I was planning on using Get Incremental updates set to "Yes" to trigger only changes in the status of the flooding for a station.

any comment or suggestion would be highly appreciated,

thanks

massimo

Hey Massimo Dragan‌, you logic is correct.  You will want to set the Get Incremental Updates to Yes.  Ideally, this is what I would set in the above example.  Since I'm polling a service, I could set this to the OBJECTID.  I then wouldn't have to worry about using the Incident Detector and Field Enricher to send the notification.  I would just receive one event when a new flood warning occurred. 

The above scenario in this document would be more relevant, for example, if you had an AVL feed and you wanted a notification if a vehicle left a county boundary.  In that example, there would be no OBJECTID, and the timestamp would be irrelevant since it's consistently changing. 

thanks for the immediate response Jake, much appreciated

so, I had actually setup a first version with the following:

- poll the flooding service with Get Incremental Updates set to Yes - this assumes that if LastUpadates changes, the site will fetch these features

- filter that service with the query, to only focus on actual flood events

- use the Intersector processor to apply a geofence (as that may change overtime and we can't filter the stations in a static way)

- send the output of the Intersector to email notification and in parallel to a feature service with the same schema of the inbound service, in order to webmap on AGOL the stations that are "currently" flooded AND within the "current" geofence

would you see disadvantages in this approach versus the Incident Detector ?

thanks if you have the time to review this additional note,

have a great day

Massimo

Massimo Dragan I have a question about the following:

use the Intersector processor to apply a geofence (as that may change overtime and we can't filter the stations in a static way)

The Intersector will be used to generate a geometry representing the intersection between a geofence and an event record’s geometry.  I don't believe you'll need to use this processor.  You can simply use a Filter and check if the event Intersects the geofence.  If the geofence is something that is not static, you can use the GeoFence Synchronization Rules and specify a dynamic geofence.

Nice example. I was able to use this example with some of my data. The field enricher piece is a little convoluted, since it would be nice to point to the geoevent def in the email output. Are Incident Detector and Field Enricher required in order to add feature service attribute values to the email body? 

I am just trying to email users when a new record has been created in a feature service, and provide some attribute information in the email. 

Thanks.

Will Hughes

I am just trying to email users when a new record has been created in a feature service, and provide some attribute information in the email. 

For your input, check on the option Get Incremental Updates and then specify either an ObjectID or Timestamp for the Method to Identify Incremental Updates:

You then won't have to add the Incident Detector and Field Enricher.

Version history
Revision #:
1 of 1
Last update:
‎10-18-2019 11:15 AM
Updated by:
 
Contributors