GeoEvent Server design principles

Several design principles should be considered when deploying and managing ArcGIS GeoEvent Server.

GeoEvent Server is not transactional

The first thing to note about GeoEvent Server is that its design assumes that events would be both frequent and periodic. If for some reason an event is not received, that event is considered lost and GeoEvent Server will never recover or process it. It is assumed another event would be received to replace the missed event at the defined interval. For example, if a vehicle was reporting its location every 30 seconds but the server experienced a technical failure, those vehicle locations would be lost until the server was running again. Once running, the server would begin to receive the event data at the defined interval, all events sent while the server was down would be considered lost.

GeoEvent Server is not transactional and is not guaranteed to properly receive, process, and disseminate every event it gets. If this level of transactional guarantee is required, then an alternative solution should be explored. Alternatively, a review of your requirements may be warranted to determine the source and validity of the transactional requirement. Assuming valid safeguards can be implemented, based on the concepts in this topic, it should be possible to enable a resilient GeoEvent Server system architecture that can provide adequate system recovery times and minimal data loss.

Dissemination of content from GeoEvent Server

While GeoEvent Server can be used to process real-time data feeds from external data sources, it is designed to work seamlessly with ArcGIS. GIS professionals use ArcGIS Pro to create content and share it with ArcGIS Enterprise. Apps such as ArcGIS Collector and ArcGIS Dashboards provide workflows and visualization capabilities to create new geospatial content in your ArcGIS Enterprise portal. ArcGIS Online can be used to share your organization’s work with the public without using your own digital infrastructure. GeoEvent Server can be used to monitor and process data feeds from all these data sources and keep them in sync and up to date.

When designing a real-time system, consider how your organization uses or could use each component of ArcGIS. If your field workers use a mobile app to update the data in your maps, for example, you should understand the ability to monitor, enhance, and actuate on this data is possible using GeoEvent Server.

If your organization serves both internal users for operations and transactions (such as GIS analysts, data scientists, and decision makers) and external users seeking information, consider setting up separate environments—using either multiple ArcGIS Enterprise deployments or ArcGIS Online. By separating internal operational and transactional users from external public users, you can prevent improper access to internal content by external users and reduce the impact of additional traffic on your infrastructure. GeoEvent Server can be utilized to translate, sanitize, and synchronize data between these separate environments.