I am looking to develop a web application that utility customers will use. They will enter their location/postcode to search for coverage of something e.g. do I get water in this area or do I get signal here etc.
The data reloads every 15m to daily depending on the feed.
I am wondering if it possible to use GeoEvent output connectors to send an SMS/email to customers if there was expected maintenance coming up e.g. in the next 3 days and/or unexpected issues e.g. sorry this service has gone down, we expect to have it up and running again by X
What you are wanting to do could be done in GeoEvent, but there would ba a few things to watch out for:
1. Unless the service area is pretty small (like a small city) the number of geofences you are likely to encounter may grow too large for GeoEvent to keep them in memory.
2. Managing and using the large number of emails you are likely to encounter may become troublesome.
If I was to implement something like this (sorry i'm going to make a lot of assumptions here) I would shoot for a solution that looked like the following blog post:
I would use GeoEvent to keep track/update all the service areas, outages, etc writing them to Feature Class(es) in the RDBMS. I would then use SQL to do a spatial join all of those areas with the customers. In theory this would result in a table where each record had a cutomer's details and the outage details that is affecting them. You could then use GeoEvent to read in each of these records and send an email to each user with details about the outage/coverage. Once the email is sent, you will probably want to write a flag back out to the database indicating that customer and/or outage/coverage has already been contacted (that would then omit that record from the original view).
The downside to that approach is it may result in a very large 'slug' of events in GeoEvent. If each outage or coverage is affecting a very large number of customers, you might consider consolidating the records in the orginal view into a single record for each outage/coverage and concatenating the emails into a single field. Obviously this will run into field size limitations and pagination may be needed (like using cartographic partitions to create zones with no more than 100 customers).
Another option for implementing this would be to use the Customer points as the GeoFences (CUSTOMER/OBJECTID). As each new outage/coverage is updated through GeoEvent, you could GeoTag with the Customer GeoFences, use a Field Splitter to separate into individual events, a field enricher to get each customer's email address, then send each individual email.
This approach has a few limitations. First you are going to be limited to how many customer points you can load into memory (the maximum is somewhere around 70,000 points on a 20GB RAM machine). Second, using the Field Enricher will slow your GeoEvent Service down to approximately 10 events/second. If an outage results in a large amount of customers being affected, you may run into latency within GeoEvent and it may not be able to keep up. Assuming updates no faster than every 15 minutes, this threshold sits somewhere around 9,000 affected customers (15*60*10).