Examples

The following are example uses of the Event Joiner Processor:

• A real-time join between live weather data and live stationary sensor data can provide ancillary information about the environment where the sensors are located. This is useful for monitoring flood, wind, and other natural conditions that could interfere with the sensors in real time.
• The output of a real-time join between two moving assets from two different feeds could be used to derive additional real-time information. For example, the location of each moving asset as a part of one new event record could be used to calculate a bearing between those assets in real time. For more information, see Bearing Calculator Processor.
• Event records derived from the Incident Detector Processor have a different schema from their original source input. Using the Event Joiner Processor, the processed event records from an Incident Detector Processor can be joined again with the original source data to maintain both schemas in real-time.

Usage notes

Keep the following in mind when working with the Event Joiner Processor:

• To configure the Event Joiner Processor, select two GeoEvent Definitions and a field from each schema whose values will be used to perform the join. Once the processor receives an event record of each GeoEvent Definition type, with a matching attribute value (or key) from the join fields, a new event record will be created. The new event record will share the combined schema of the two GeoEvent Definitions used in the join.
• While waiting to perform a join, the processor uses an internal cache to retain event records. The processor caches one event record of each unique attribute value for each GeoEvent Definition type. When the processor receives an event record with a previously observed attribute value, the older event record is discarded. This way, only the most recently received event record for a given attribute value key will be used when joining two event records.
• The Event Joiner Processor, like the Field Enricher (Feature Service) Processor, has a configurable cache size. When the number of cached event records received exceeds the configured cache size, older records in the cache will be purged to accommodate new event records.
• The cache for the processor is held in memory. The cache will be re-created if changes are made to a GeoEvent Service with an Event Joiner Processor or if the ArcGIS GeoEvent Server service is restarted. Stopping and starting a GeoEvent Service in GeoEvent Manager will not re-create the cache.
• When configuring the Event Joiner Processor, you must specify what should be done with the latest, cached event records from each GeoEvent Definition after they are used to perform an event join. By default, cached event records will be discarded after they are used and the processor will wait to receive a new event record of each type for a subsequent join. You can configure the processor, however, to retain its cached event records after a join and produce a new combined event record whenever a new event record of either GeoEvent Definition type is received.
• As a best practice, a Field Mapper Processor should be used immediately after an Event Joiner Processor for schema correction. The Event Joiner Processor makes several necessary changes to the schema of the output GeoEvent Definition including the following:
  • Existing field names are prepended with their source GeoEvent Definition name. An example field called Altitude from the first GeoEvent Definition, A, will be renamed to A_Altitude in the output GeoEvent Definition. This is necessary to distinguish what might otherwise be duplicate field names from each source GeoEvent Definition used for the join.
  • Existing tags are removed from the output GeoEvent Definition. Reserved tags such as GEOMETRY and TRACK_ID cannot be applied to more than one field in a GeoEvent Definition.
  • All the fields from each source GeoEvent Definition are included in the output GeoEvent Definition.
• As a best practice, set the Cache Size parameter to a value greater than the expected number of unique event records for the highest volume input feed. The Event Joiner Processor purges its cache once the maximum number of events has been reached, so if the value of the cache size is set too low, records may be purged before a successful join can occur. Also, take precaution setting the cache size value too high, since event records are stored in memory and a value that is set too high could result in performance implications.

Parameters

The following are the parameters for the Event Joiner Processor:

Considerations and limitations

There are several considerations to keep in mind when using the Event Joiner Processor:

• Joins cannot be made on event records sharing the same GeoEvent Definition name. The processor uses the name of the first and second GeoEvent Definition to construct separate caches for each set of event records. If data is coming from two different source feeds and they share the same schema and GeoEvent Definition, consider creating a duplicate GeoEvent Definition with a different name for one of the source feeds before passing the event records to the processor.
• Only fixed GeoEvent Definitions are supported for event joins. Managed GeoEvent Definitions are not supported.