Processors

Processors are a component of a GeoEvent Service that perform specific actions on GeoEvents, such as identification or enrichment, as the events are routed from inputs to outputs.

GeoEvent includes the following processors:

Field Calculator

A Field Calculator Processor writes a computed value into either an existing field or a new field created by the processor. The processor uses values retrieved from the current event's fields and constant values included in the processor's configuration to perform its calculations. The Field Calculator can evaluate mathematical expressions and recombine string values to produce derivative event data; it can also write constant values to enrich or refine event data.

Calculations performed using a Field Calculator Processor can be mathematical or lexical (based on strings, rather than numerical values). When a computed value is written to an existing field, the computed value replaces the current field's value within the event being processed. The processor will attempt to convert the calculated value to match the existing field’s data type; a null value will be written if the data type conversion fails.

Field Calculator Processor existing field properties.

Writing a computed value to a new field alters an event’s schema, which requires GeoEvent to create a new GeoEvent Definition, which the system will manage. When using the processor to create new fields, a field name and data type must be specified. A name for the GeoEvent Definition can be specified, as well as an optional tag, which should be applied to the new field.

Field Calculator Processor new field properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties of a Field Calculator Processor are illustrated above.

The Field Calculator Processor supports general mathematical, lexical, and logical expressions. The operands within an expression can be literal field names from the GeoEvent Definition or tags that have been applied to the fields within the GeoEvent Definition. For example, the expression Odom1 + Odom2 could be used to add the values in the fields named Odom1 and Odom2 to produce a simple sum. If the field Odom1 was tagged MILEAGEA and the field Odom2 was tagged MILEAGEB, the expression MILEAGEA + MILEAGEB could be used.

The operators and functions supported by the Field Calculator Processor are illustrated below.

Operation Operator Example

Addition

+
Odom1 + Odom2

Expression adds the numeric values from the fields Odom1 and Odom2 to produce a simple summation. String concatenation (for example, "Hello" + "World") is also supported.

Subtraction

-
VALUEA - VALUEB

Expression subtracts the numeric values found in the fields tagged VALUEA and VALUEB to produce a simple difference.

Unlike addition, which supports string concatenation, you cannot use subtraction to calculate the difference between two strings.

Multiplication

*
Altitude * 0.3048

Expression multiplies the numeric value in the field named Altitude and the constant 0.3048 to produce a simple product (in this case converting a value in feet to an equivalent value in meters).

Division

/
Distance / 1.609344

Expression divides the numeric value in the field named Distance by the constant 1.609344 to produce a simple quotient (converting a value in kilometers to an equivalent value in miles).

Modulus

%
VALUEA % VALUEB

Expression divides the numeric value in the field tagged VALUEA by the numeric value in the field tagged VALUEB and returns the remainder as a double value.

Logical AND

&&
Flag1 && Flag2

Expression performs a logical AND on the Boolean values from the fields named Flag1 and Flag2 to produce a Boolean result. Input fields must be of type Boolean. Literal strings (for example, "TRUE") and constant values (for example, 1) in an expression will not be converted to an equivalent Boolean as part of the evaluation.

Logical OR

||
Flag1 || Flag2

Expression performs a logical OR on the Boolean values from the fields named Flag1 and Flag2 to produce a Boolean result.

Logical NOT

!
!(Flag1)

Expression performs a logical negation on the Boolean value from the field Flag1 to produce a Boolean result. Supports nested expressions such as !(Flag1 && Flag2).

Greater-Than

>
Altitude > 12500

Expression performs a logical evaluation to determine if the value in the field named Altitude is greater than the specified constant (result is a Boolean value).

Greater-or-Equal

>=
Altitude >= 12500

Expression performs a logical evaluation to determine if the value in the field named Altitude is greater than or equal to the specified constant (result is a Boolean value).

Less-Than

<
Altitude < 1500

Expression performs a logical evaluation to determine if the value in the field named Altitude is less than the specified constant (result is a Boolean value).

Less-or-Equal

<=
Altitude <= 1500

Expression performs a logical evaluation to determine if the value in the field named Altitude is less than or equal to the specified constant (result is a Boolean value).

Equality

==
VALUEA == VALUEB

Expression performs a logical evaluation to determine if the values found in the fields tagged VALUEA and VALUEB are equivalent (result is a Boolean value). Equivalency is only supported for numeric types with the initial product release (10.2.0).

Inequality

!=
VALUEA != VALUEB

Expression performs a logical evaluation to determine if the values found in the fields tagged VALUEA and VALUEB are not equal (result is a Boolean value). Inequality is only supported for numeric types with the initial product release (10.2.0).

Operators and functions supported by Field Calculator
NoteNote:
The Field Calculator Processor will attempt to auto-convert values when presented with mixed types. For example, the expression 10.0 + 5 would auto-convert to handle the summation as the addition of two floating point values. Mixing numeric values and string values such as codeValue + "SomeString" where codeValue is a numeric value will produce an unspecified result. The correct approach would be to explicitly convert codeValue to a string using a string function such as valueOf(object) described below.
NoteNote:

The Field Calculator Processor equality and inequality operators should not be applied directly to floating point values. To correctly compare if two decimal values are equal, you must first scale the values, round the values to long integers, and then compare the long integer values.

The Field Calculator Processor includes functions that mirror those found in java.lang.Math. For a complete technical specification and list of functions, refer to the Java developer documentation. A summary of the most popular functions is included below.

Constants
Function Description

E()

Returns Euler's number (e) raised to the power of the specified double value.

PI()

Returns a double representation of pi (the ratio of a circle's circumference to its diameter).

Constants for Field Calculator

Common Functions

Function Description

abs(value)

Returns the absolute value of the argument.

ceil(double)

Returns the ceiling (next greatest integer) of the specified double value.

floor(double)

Returns the floor (next smallest integer) of the specified double value.

hypot(double x, double y)

Returns sqrt((x*x) + (y*y)) without intermediate overflow or underflow.

max(value a, value b)

Returns the greater of two specified argument values.

min(value a, value b)

Returns the smaller of two specified argument values.

random()

Returns a double value greater than or equal to 0.0 and less than 1.0.

round(value)

Returns the closest long to the argument (given a double value).

Common functions for Field Calculator
NoteNote:

A Field Calculator Processor will handle numeric type conversions when possible. For example, when providing different numeric types to a function (for example, max(3.14159,25)), the values will be cast to comparable types (int, float, or double) in order to perform the comparison. The processor will also cast calculated values when writing the values to an event's attribute field (for example, 6 + 7 will be written as 13.0 when the event's field is of type double).

Exponentials

Function

Description

sqrt(double)

Returns the square root of the specified double value.

cbrt(value)

Returns the cube root of the specified double value.

exp(double)

Returns Euler's number (e) raised to the power of the specified double value.

pow(double, double)

Returns the value of the first argument raised to the power of the second argument.

Exponentials for Field Calculator

Logarithms

Function

Description

log(double)

Returns the natural logarithm (base e) of a double value.

log10(double)

Returns the base 10 logarithm of a double value.

Logarithms for Field Calculator

String Functions

Function

Description

int length(source)

Returns the length of the string.

boolean isEmpty(source)

Returns true if source's length is 0.

boolean isNull(source)

Returns true if source value is null.

boolean equals(source, Object anObject)

Compares the source string to the specified object. Returns true if the given object represents a string, equivalent to the source string; false otherwise.

boolean equalsIgnore(source, String anotherString)

Compares the source string to another string, ignoring case considerations. Two strings are considered equal, ignoring case, if they are of the same length and corresponding characters in the two strings are equal, ignoring case. Returns true if the argument is not null and it represents an equivalent string, ignoring case; false otherwise.

int compareTo(source, String prefix)

Compares two strings lexicographically. Returns the value 0 if the str argument is equal to the source string; a value less than 0 if the source string is lexicographically less than the str argument; and a value greater than 0 if the source string is lexicographically greater than the str argument.

int compareToIgnore(source, String str)

Compares two strings lexicographically, ignoring case differences. Returns a negative integer, zero, or a positive integer if the specified string is greater than, equal to, or less than the source string, ignoring case considerations.

boolean startsWith(source, String prefix)

Tests if the source string starts with the specified prefix. Returns true if the character sequence represented by the prefix argument is a prefix of the character sequence represented by the source string; false otherwise.

boolean endsWith(source, String suffix)

Tests if the source string ends with the specified suffix. Returns true if the character sequence represented by the suffix argument is a suffix of the character sequence represented by the source object; false otherwise.

int indexOf(source, String str)

Returns the index within the source string of the first occurrence of the specified substring str. Returns if the string argument occurs as a substring within the source object, then the index of the first character of the first such substring is returned; if it does not occur as a substring, -1 is returned.

int indexOf(source, String str, int fromIndex)

Returns the index within the source string of the first occurrence of the specified substring, starting at the specified index. Returns the index within the source string of the first occurrence of the specified substring, starting at the specified index.

int lastIndexOf(source, String str)

Returns the index within the source string of the rightmost occurrence of the specified substring. If the string argument occurs one or more times as a substring within the source object, then the index of the first character of the last such substring is returned. If it does not occur as a substring, -1 is returned.

int lastIndexOf(source, String str, int fromIndex)

Returns the index within the source string of the last occurrence of the specified substring, searching backward starting at the specified index. Returns the index within the source string of the last occurrence of the specified substring.

String substring(int beginIndex)

Returns a new string that is a substring of the source string. The substring begins with the character at the specified index and extends to the end of the source string.

String substring(source, int beginIndex, int endIndex)

Returns a new string that is a substring of the source string. The substring begins at the specified beginIndex and extends to the character at index endIndex - 1.

String concat(source, String str)

Concatenates the specified string to the end of the source string.

boolean matches(source, String regex)

Tells whether or not the source string matches the given regular expression. Returns only if the source string matches the given regular expression.

boolean contains (CharSequence s)

Returns true only if the source string contains the specified sequence of char values. Returns true if the source string contains s; false otherwise.

String replaceFirst(source, String regex, String replacement)

Replaces the first substring of the source string that matches the given regular expression with the given replacement. Returns the resulting string.

String replaceAll(source, String regex, String replacement)

Replaces each substring of the source string that matches the given regular expression with the given replacement. Returns the resulting string.

String replace(source, CharSequence target, CharSequence replacement)

Replaces each substring of the source string that matches the literal target sequence with the specified literal replacement sequence. The replacement proceeds from the beginning of the string to the end. Returns the resulting string.

String toLowerCase(source)

Converts all of the characters in the source string to lowercase using the rules of the default locale. Returns the string, converted to lowercase.

String toUpperCase(source)

Converts all of the characters in the source string to uppercase using the rules of the default locale. Returns the string, converted to uppercase.

String trim(source)

Returns a copy of the source string, with leading and trailing white space omitted.

String valueOf(Object obj)

Returns the string representation of the Object argument.

String functions for Field Calculator

Trigonometric Functions

Function

Description

acos(double)

Returns the arc cosine of a value (returned angle is between 0.0 and pi).

asin(double)

Returns the arc sine of a value (returned angle is between -pi/2 and pi/2).

atan(double)

Returns the arc tangent of a value (returned angle is between -pi/2 and pi/2).

atax2(double y, double x)

Returns the angle theta from the conversion of rectangular coordinates (x, y) to polar coordinates (r, theta).

cos(double)

Returns the trigonometric cosine of an angle.

cosh(double)

Returns the hyperbolic cosine of a double value.

sin(double)

Returns the trigonometric sine of an angle.

sinh(double)

Returns the hyperbolic sine of a double value.

tan(double)

Returns the trigonometric tangent of an angle.

tanh(double)

Returns the hyperbolic tangent of a double value.

toDegrees(double)

Converts an angle measured in radians to an approximate angle in degrees.

toRadians(double)

Converts an angle measured in degrees to an approximate angle in radians.

Trigonometric functions for Field Calculator

Field Calculator (Regular Expression)

The Field Calculator (Regular Expression) Processor supports the use of regular expressions to find a pattern within a target field. Regular expression pattern matching can be a powerful tool for calculating and building derivative values from attribute data received with an event. The Field Calculator (Regular Expression) Processor does not support the general mathematical, lexical, and logical expressions supported by the regular Field Calculator Processor.

Field Calculator Processor (Regular Expression) Processor existing field properties.

Writing a computed value to a new field alters an event’s schema, which requires GeoEvent to create a new GeoEvent Definition, which the system will manage. When using the processor to create new fields, a field name and data type must be specified. A name for the GeoEvent Definition can be specified, as well as an optional tag, which should be applied to the new field.

Field Calculator Processor (Regular Expression) Processor new field properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a Field Calculator (Regular Expression) Processor are illustrated above.

The Field Calculator (Regular Expression) Processor is generally used to identify and extract substrings within a target field. The extracted substrings are then either written back to the target field, replacing the field’s original value, or written to a new field.

The processor supports a wide range of regular expressions. A processor of this type could be configured with a regular expression to extract the numeric portion of a FlightID and write the value to a new field named FlightNumber. A step-by-step illustration of this is included in the Introduction to GeoEvent tutorial, available from the GeoEvent Processor tutorials page.

NoteNote:

The Field Calculator (Regular Expression) Processor does not support back references within the specified regular expression pattern.

Field Enricher (Feature Service)

The Field Enricher (Feature Service) Processor supports enrichment of event data by copying attribute information from a feature layer or nonspatial table of a published feature service to the event being processed. This is equivalent to a join operation.

Field Enricher (Feature Service) Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a Field Enricher (Feature Service) Processor are illustrated above.

A Field Enricher (Feature Service) Processor must be configured with the information needed to discover and use a feature service for event enrichment. This includes the ArcGIS Server connection, the service folder, the name of the feature service, and the target layer within the feature service.

The processor must be configured with the field name the feature service has in common with the event being enriched, as well as the field name from the event's schema on which the join should be performed. The feature service's field name is entered into the Feature Layer Join Field text box in the illustration above. The GeoEvent Join Field text box will accept either a tag that has been applied in the event’s GeoEvent Definition (for example, TRACK_ID as shown above) or the name of a specific field from the event's schema.

Specify the names of the fields to be copied from the feature layer’s table by clicking the Select Fields button for the Enrichment Fields property. Optionally specify tags that GeoEvent should apply to each new field it creates as a comma-separated list.

Enriching an event copies data from one or more fields of a feature service and appends the fields as new data to the event being processed. This alters the event’s schema and requires GeoEvent to create a new GeoEvent Definition, which the system will manage. The field names have been specified and the field data types will be carried over from the feature service, so the data types are not specified as part of the processor configuration. Specify a name GeoEvent should use for the resulting GeoEvent Definition it will create.

A step-by-step illustration using a Field Enricher (Feature Service) Processor to join event data with data from a feature service is included in the Introduction to GeoEvent tutorial exercises, available from the GeoEvent Processor tutorials page.

Field Enricher (File)

The Field Enricher (File) Processor supports enrichment of event data by copying attribute information from a system file to an event being processed. It is similar to the Field Enricher (Feature Service) Processor, except that the source of enrichment is a system file rather than a feature service.

Field Enricher (File) Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a Field Enricher (File) Processor are illustrated above.

The system folder that contains the file to be used as the source of the enrichment data must be identified. The system folder needs to be registered with GeoEvent as a data store before configuration of the processor can be completed. The file name is not a registerable item; a file name must be specified and GeoEvent looks for a file of that name in the registered data store.

The processor must be configured with the field name the system file has in common with the event being enriched, as well as the field name from the event's schema on which the join should be performed. This field name from the system file's data table is entered into the File Join Field text box in the illustration above. The GeoEvent Join Field text box will accept either a tag that has been applied within the event’s GeoEvent Definition (for example, TRACK_ID as shown above) or the name of a specific field from the event's schema.

Specify the names of the fields to be copied from the feature layer’s table as a comma-separated list in the Enrichment Fields property. Optionally specify tags that GeoEvent should apply to each new field it creates as a comma-separated list.

Enriching an event copies data from one or more fields of a system file and appends the fields as new data to the event being processed. This alters the event’s schema and requires GeoEvent to create a new GeoEvent Definition, which the system will manage. The field names have been specified and the field data types are specified within the system file, so the data types are not specified as part of the processor configuration. Specify a name GeoEvent should use for the resulting GeoEvent Definition it will create.

A step-by-step illustration using a Field Enricher (File) Processor to join event data with data from a system file is included in the Introduction to GeoEvent Processor tutorial exercises, available from the GeoEvent Processor tutorials page.

NoteNote:

When using a text file as the source for enrichment, the file must follow the format illustrated below. Specifically, the first line of the file must identify the field names as comma-separated values. The second line must specify the data type of each field. The file’s data values are entered starting with the third line of the file.

Field Mapper

The Field Mapper Processor supports data alignment. Every GeoEvent within the GeoEvent Processor has an associated schema that identifies the attribute fields and data types (date, string, integer, and so forth) for the event’s data. This schema is referred to as a GeoEvent Definition. A GeoEvent Definition for a particular input data stream might contain fields whose names do not match the schema of a published feature service to be updated by GeoEvent. In situations such as this, a Field Mapper Processor will need to be used to map fields from the input schema to align the data with the output schema.

Field Mapper Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a Field Mapper Processor are illustrated above.

Set the source and target GeoEvent Definitions by selecting the respective properties. The properties dialog box will list the GeoEvent Definitions target fields , enabling the selection of the field from the source fields, which should be mapped to the target. The data type of the target field will be listed to identify the data most appropriate to map from the source GeoEvent Definition to the target GeoEvent Definition.

NoteNote:

In the illustration above, <Field Name> is shown as a substitute for the actual field names of a target GeoEvent Definition. The actual list of field names and data types would depend on the GeoEvent Definition selected as the target GeoEvent Definition.

A Field Mapper Processor can be used to reduce the number of attribute fields routed from an input to an output, since only the selected fields from a source GeoEvent Definition will be mapped to the fields of a target GeoEvent Definition. This can be useful when an input data stream contains a large number of attribute values that might be of little interest. A Field Mapper Processor can also be used to handle the conversion of data types when an input's event data does not match the data types of an output GeoEvent Definition. For example, integer data can be converted to a double representation or numeric data to a string representation. This aligns the input data with the required output GeoEvent Definition.

Another use case for the Field Mapper Processor is when a data schema needs to be flattened. Real-time data streams occasionally represent attribute data not as a single discrete data type, but as a group of several attribute values of various types. A hierarchical data structure such as this cannot be used to update a published feature service, for example, without first mapping individual group elements to discrete fields of an output GeoEvent Definition that matches the schema of the published feature service.

Field Reducer

Every GeoEvent within the GeoEvent Processor has an associated schema that identifies the attribute fields and data types (date, string, integer, and so forth) for the event's data. This schema is referred to as a GeoEvent Definition. A Field Reducer Processor supports data schema refinement by removing unwanted attributes from an event, allowing a simplified version of the event to be routed for additional processing or output.

Field Reducer Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a Field Reducer Processor are illustrated above.

The GeoEvent Definition of events received by the processor specifies the field names and data types of the received event. Therefore, only the fields to be removed from the received event must be specified as a comma-separated list. The list of fields to be removed is entered in the Fields to Remove property as shown in the illustration above.

Modifying event data by removing attribute fields alters the event’s schema, requiring GeoEvent to create and manage a new GeoEvent Definition for the simplified event. In the properties dialog box, specify a name GeoEvent should use for the resulting GeoEvent Definition it will create.

GeoTagger

A GeoTagger Processor supports event enrichment by appending information about GeoFences with which an event has a spatial relationship. For example, if an event’s location is found to be within a known area of interest, the containing GeoFence category and name can be appended to the event as new attribute values. This enriches the event with information on its spatial relationship with an area of interest at a point in time.

NoteNote:

GeoFences must be imported into GeoEvent from a feature service prior to configuring a GeoTagger Processor. See Managing GeoFences to learn more about working with GeoFences in GeoEvent.

GeoTagger Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a GeoTagger Processor are illustrated above.

The processor must be configured to identify the GeoFences with which events are expected to have a spatial relationship. Specify a set of GeoFences by entering a simple regular expression into the GeoFence(s) field in the properties dialog box as illustrated above. One or more GeoFences from one or more categories within GeoEvent can be specified. For example, assume several GeoFences have been imported to a States category. A GeoTagger Processor could be configured with the expression States/.* to indicate that any named area within the States category should be considered when searching for a spatial relationship for a received event. Entering .*/.* would direct the processor to consider all known GeoFences in any named category.

The Spatial Operator property specifies the spatial relationship an event location should have with a given GeoFence. See Filters to learn more about the available spatial relationships in GeoEvent. In order to determine an event's spatial relationship with a GeoFence, the event must have a field of type Geometry. The GeoEvent Geometry Field property will accept a tag (for example, GEOMETRY as shown above) or the name of a specific field in the GeoEvent Definition.

Once a spatial relationship has been confirmed for an event, the name of the GeoFence can be appended to the event’s data to enrich the event. The name of the field the processor will create is specified in the GeoTag Field Name text box. The default action is to append the data to the event as a comma-separated list; this action is specified by the GeoTag Format property. The enrichment data can include either the GeoFence name or both the GeoFence name and category. The Include GeoFence Category in GeoTag property specifies the level of enrichment.

Enrichment performed by the GeoTagger Processor alters an event’s schema. GeoEvent will create and manage a new GeoEvent Definition for the enriched event. The processor includes a field that can specify a name the GeoEvent Processor should use for the resulting GeoEvent Definition it will create.

A step-by-step illustration using a GeoTagger Processor is included in the Introduction to GeoEvent Processor tutorial, available from the GeoEvent Processor tutorials page.

Incident Detector

The Incident Detector Processor uses specified attribute and spatial conditions to discover and report incidents. In the processor's properties, an opening and closing condition can be specified, which allow an incident to span a series of events over a period of time. For example, an event-based data stream that reports a vehicle's position and current speed could be used to generate an incident when the vehicle exceeds a certain speed or enters a dangerous area. The incident would be closed once the vehicle resumes a safe rate of speed or leaves the dangerous area.

Incident Detector Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for an Incident Detector Processor are illustrated above.

The incidents generated by an Incident Detector Processor need to have a name by which to identify the incidents created. For example, an Incident Detector Processor created to alert for a speeding vehicle could be named SpeedingVehicle. Enter the name in the Incident Name property as shown above. All incidents generated by an Incident Detector Processor must have an opening and closing condition, which are built using an expression builder.

NoteNote:

An opening condition must be specified. If a closing condition is not specified, a logical negation of the opening condition will be used.

An Incident Detector Processor can be used to apply a specified severity to incidents generated. The available levels are notification, warning, and urgent. The incidents created by a given processor are limited to a single severity level; the processor must be edited and the GeoEvent Service republished in order to change the severity level assigned by the processor to its incidents.

The type of incidents created by an Incident Detector Processor are also part of the processor's properties. There are two possible types of incidents: Point-In-Time and Cumulative.

Each Incident Detector Processor has a specific Geometry Type associated with the incidents it generates. Most incidents and incident updates are associated with a point location at a specific time, so a point geometry is usually selected. However, MultiPoint and Polyline are also supported geometry types for incidents generated.

A use case might be to have incidents automatically close after a period of time. Configuring an Incident Detector Processor with an Expiry Time allows GeoEvent to automatically close the incident after a period of time, even if the incident's closing condition has not been met. The expiry time is a numeric value expressed in seconds; entering a value of zero disables automatic expiry for incidents created by the processor.

Step-by-step exercises illustrating how an Incident Detector Processor can be configured are included in the Introduction to GeoEvent tutorial, available from the GeoEvent Processor tutorials page.

Track Gap Detector

The Track Gap Detector Processor is used to detect the absence of events. Like the Incident Detector Processor, the Track Gap Detector will generate a new event to report when gaps are detected in an event stream. The processor can be configured to either generate continuous notifications during a period in which events expected are not being received, or generate a single notification when a gap is detected and then a second event to notify you when the processor begins receiving events once again.

Track Gap Detector Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a Track Gap Detector Processor are illustrated above.

The Gap Notification Mode property specifies the notification behavior mentioned above. Selecting OnChange specifies that a single event should be generated by the processor when a gap is detected and a second event should be generated when the processor begins receiving events once again. Selecting Continuous specifies that you want an event generated each polling interval during the period for which the processor is not receiving new events.

The Gap Duration (seconds) property specifies the amount of time (in seconds) the processor will wait before determining that a gap has occurred in the input data stream. Using the value illustrated above, the processor would only determine that a gap existed if at least 300 seconds had elapsed since the time the processor last received an event.

The Gap Detection Interval (seconds) property specifies the processor's polling interval. Again, using the value illustrated above, the processor would check every 120 seconds to see if a gap of 300 seconds or more exists since the time the processor last received an event. The polling interval also controls how often notification events are generated when the Gap Notification Mode is set to Continuous notification; when set to OnChange notification, an event will only be sent when the processor polls and discovers an event stream has stopped (when the processor was previously receiving events) and vice versa once the processor has detected a gap and then polls and discovers that events are again being received.

The Geometry Field Name property specifies the name of the event field expected to contain a geometry. The last received geometry will be appended to notification events generated by the processor. For example, if an event stream were reporting the position of vehicles and the processor was configured to poll every 30 seconds to determine if a gap of at least 120 seconds existed since the last received vehicle report, the processor could be configured to include the last reported vehicle location with its gap notification.

No Operation

A No Operation Processor takes no action and has no effect on GeoEvents it receives. Events pass through a No Operation Processor as if it were not there.

No Operation Processor properties.

When configuring a processor, a name must be specified. The name is case-sensitive and will be used to uniquely identify the processor in a GeoEvent Service. The type of processor being configured is specified using the Processor drop-down arrow; the properties for a No Operation Processor are illustrated above. This type of processor has no other properties to configure.

A No Operation Processor could be used to include a Stub or NoOp component in a GeoEvent Service as a placeholder. Another processor could replace the No Operation Processor later, allowing focus to be placed on designing and testing other parts of the GeoEvent Service.

A No Operation Processor can be a useful in other scenarios as well, including the following:

9/1/2015