What’s new in ArcGIS GeoEvent Server 10.9
ArcGIS GeoEvent Server 10.9 offers many new and exciting improvements in usability, expanded analytic capabilities, and stability enhancements. At a high-level, the user experience for designing and maintaining all of your real-time event processing workflows has been greatly simplified. In addition, several stability enhancements were made to increase event throughputs and uptime. Let’s explore each of these in some more detail.
To start, GeoEvent Server 10.9 provides a boost to your real-time event processing by improving the underlying event throughput for complex GeoEvent Services. This includes improvements to event handling, allowing event data to be routed and processed more efficiently, thereby, reducing system load and increasing event processing rates.
Next, on the user experience side, many quality and usability improvements have been made when designing GeoEvent Services as well as in GeoEvent Sampler. In the service designer, the workflows necessary to create and maintain GeoEvent Services were refined even further, reducing the number of clicks necessary to complete a task. In GeoEvent Sampler, support for non-English languages has been improved.
A new real-time processing element and several new analytic capabilities were added at this release. The new choice element can be added to a GeoEvent Service in place of a filter element. The new choice element offers a more refined approach to event routing, providing an IF, ELSE IF, …, ELSE approach to evaluating events. By using the new choice element, workflows involving many filter elements can be simplified and streamlined.
Parallel Filtering | Choice |
| 
|
| 
|
In addition to the new choice element, several processors were updated with new capabilities. The Field Mapper Processor has expanded capabilities to allow Field Calculator Processor functions in the field mapping. Now multiple calculations across many fields can be done all at once, in parallel. This new capability provides the opportunity to condense long chains of Field Calculator nodes down into a single Field Mapper node.
Multiple Field Calculators | Updated Field Mapper |
| 
|
Also, the Incident Detector Processor now supports the optional ability to retain the source event’s original fields. This allows the Incident Detector to emit events with a combination of the original event’s field schema and the GeoEvent incident’s field schema.
All these improvements in the analytic capabilities of GeoEvent Server provide an opportunity to drastically simplify your event processing workflows, contributing to improved stability and maintainability.
And lastly, a deprecation notice. Support has been deprecated for multi-machine deployments where multiple GeoEvent Server instances coordinate through a single ArcGIS Server site. This is a deployment pattern we’ve encouraged customers to move away from for a little over a year now. Beginning with the 10.9 release, every instance of GeoEvent Server you deploy must run beneath its own ArcGIS Server with its own ArcGIS Server site. This extends the single-machine high-availability active/active and single-machine high-availability active/passive deployment patterns promoted by ArcGIS Server.
The decision to remove support for multiple-machine / single-site deployments is based on observations over time that GeoEvent Server deployments which coordinate through a single ArcGIS Server site do not meet reliability objectives. In rare cases of complete hardware failure – where a single server node in a multi-machine deployment went permanently offline – the deprecated deployment pattern did provide fault-tolerance. More frequently, however, when a deployment was challenged by a disadvantaged network, or a machine was temporarily unavailable, or servers were restarted out of sync, the whole deployment could become unusable. Recovery was tedious and error prone, which led to promises that a system architecture would provide high-availability failing to meet expectations.
As a result of this deprecation, the GeoEvent Gateway has been refactored to provide better resiliency and overall system stability for most users by removing cluster leader election and in-sync replication between peer brokers/consumers. This means that multiple instances of GeoEvent Server will no longer be able to synchronize a shared configuration or support a "clustered computing" architecture. But in the end, it achieves a better, more resilient, and more stable product.
GeoEvent Server’s on-line help documentation has been updated with a new help topic: Deployment Considerations. In particular you might want to review the help topic: Strategies for scalability, reliability, and resiliency.