Latest Contributions by RJSunderman

Understanding what a GeoEvent Definition is and how they are created is important for understanding the real-time analytics, filtering, and processing being performed by a GeoEvent Service. In the Making Features Come Alive exercise in Module 2 of the Introduction to GeoEvent tutorial, you are introduced to the Field Mapper Processor. One of your first experiences with GeoEvent Definitions will probably be when using a GeoEvent Service to add or update features in a feature service’s feature layer. Mapping a GeoEvent to a schema consistent with the feature layer before sending an event to an output to add/update features is a recommended best practice. You should think of every GeoEvent as having an associated GeoEvent Definition. An input connector does not receive GeoEvents. The connector has a transport which receives and hands-off a byte stream to the connector’s adapter. The adapter needs a GeoEvent Definition in order to instantiate different data values and place the data into different fields within a data structure. It’s like the adapter is sorting mail -- this field is a String, that field is a Date, that other field is a Long integer,… etc. The structure of a GeoEvent is specified by a GeoEvent Definition. Several input connectors available out-of-the-box with the GeoEvent Extension use adapters which allow you to determine whether the adapter should create a GeoEvent Definition. The adapter does this by taking the first event received, examining the data values, and then making a best-first-guess at what the GeoEvent Definition should look like. If a GeoEvent Definition already exists with the name you specified, the adapter will use (not update) this existing GeoEvent Definition. GeoEvent Definitions have owners. When an adapter creates a GeoEvent Definition for you the owner will look something like: auto-generated/com.esri.ges.adapter.inbound.JSON If you copy an existing GeoEvent Definition, import a GeoEvent Definition from a feature service, or click 'New GeoEvent Definition' to create one from scratch, the GeoEvent Definition owner will typically be displayed as either arcgis (10.2.x) or admin (10.3.x) depending on how you logged in to ArcGIS GeoEvent Manager. Only two GeoEvent Definitions come defined out-of-the-box. The incident GeoEvent Definition owner is identified as com.esri.ges.processor/IncidentDetector/xxxx. You can see this if you click to examine the incident GeoEvent Definition. The TrackGap GeoEvent Definition is the other GeoEvent Definition that is defined out-of-the-box. If you click to examine this GeoEvent Definition you will see that its owner is com.esri.ges.processor/TrackGapDetector/xxxx. These owner strings tell you which out-of-the-box processor created the GeoEvent Definitions; the xxxx identifies the GeoEvent Extension release. Sometimes a processor will modify an event’s structure or schema by either adding or removing a field. When a processor does this, it will create a new GeoEvent Definition. The Field Calculator Processor is a good example; you can configure this processor to place its calculated value into a new field. The Field Enricher Processor is another example; it is taking data from a feature service's table and adding new fields to the event it is processing. When a processor creates a GeoEvent Definition for you, you are typically required to enter the name the processor should use for the GeoEvent Definition it will create. It can be important to understand when a processor creates what I have referred to as a managed GeoEvent Definition. A processor will not create a managed GeoEvent Definition until it actually receives a GeoEvent. You have probably discovered that you cannot, for example, configure a Field Mapper Processor which follows a Field Enricher until the Field Enricher has received and processed an event. Once the Field Enricher receives a GeoEvent, it will process the event and create the necessary GeoEvent Definition. Only then can you edit your GeoEvent Service to configure your Field Mapper. Since processors own the GeoEvent Definitions they create, any change you make to the GeoEvent Service which incorporates the processor will trigger the processor to delete its managed GeoEvent Definition when you publish the GeoEvent Service to save your changes. For this reason, you should be aware of when GeoEvent Definitions are created, when they are deleted, and when they are available for reference by another processor or output connector. A few recommendations to take away from this quick discussion: Every GeoEvent has an associated GeoEvent Definition. You should become familiar with when GeoEvent Definitions are created, which components create them, and why. Don’t leave an input connector configured to create GeoEvent Definitions for you. When configuring an input connector to create a GeoEvent Definition, it is a recommended best practice to copy the GeoEvent Definition generated by the input connector’s adapter and then reconfigure your input to use the copy of the GeoEvent Definition. Processors can create GeoEvent Definitions. The GeoEvent Definition associated with an event received by a processor is not necessarily going to be the GeoEvent Definition associated with the GeoEvent which comes out of a processor. Always use a Field Mapper Processor to prepare a GeoEvent’s schema to match a feature service’s feature layer when adding/updating features. You might think you understand the structure of an event you are sending to an output – but it is a best practice to use a Field Mapper and make the schema mapping explicit. Processors may delete GeoEvent Definitions they created. If you configured a Field Mapper “downstream” from a Field Calculator or Field Enricher, for example, the “upstream” processor may delete a GeoEvent Definition referenced by the Field Mapper. As long as you do not double-click to edit the Field Mapper’s configuration you can trust the processor “upstream” will re-create the GeoEvent Definition referenced by the Field Mapper as event data is received by the processor, before GeoEvents are received by the Field Mapper. When publishing a stream service, never refer to a GeoEvent Definition which has been generated for you by an input connector’s adapter or a GeoEvent Definition created for you by a processor. Make a copy of any such GeoEvent Definition(s) and publish the stream service to reference a GeoEvent Definition which you own. ... View more

GeoRSS is a standard way of tagging an RSS feed so that applications can use embedded location information in each post. Using the GeoEvent Extension for ArcGIS Server, you can monitor a GeoRSS feed in real time and use it to update the applications and common operational pictures used by your colleagues. Should you encounter a secured GeoRSS feed that you would like to use, there is no standard connector that allows you to pass credentials. However, it is possible to configure a connector (without programming) that will allow you to access a GeoRSS service secured with basic HTTP authentication. You can use the GeoEvent Manager to combine out-of-the-box transports and adapters to configure a custom connector without resorting to the GeoEvent SDK or developing any custom code. An excellent example is available on the Support Services Blog: Configure Your GeoEvent 10.3 Connector to Use a Secure GeoRSS Feed - RJ ... View more

There is a very basic utility bundled with the Clustering tutorial which will request a status from the RabbitMQ platform service, attempt to connect, and send a message to see if the specified host is able to receive messages. Please download and unzip the attached CheckRabbitMQ.zip to a local folder on the server on which you have installed ArcGIS Server and the GeoEvent Extension. Open a Windows command shell and change directory to the folder containing the files you extracted from the ZIP archive. In your Windows command shell, execute the commands illustrated below: You should see the following usage instructions: Enter the Machine name, Port, Admin user and admin password, separated by a space. (For example: “machine 6080 admin admin_pass): I tend to specify a fully qualified server name and domain (e.g. machine_name.esri.com) - and because my ArcGIS Server is configured to allow HTTPS connections - I specify port 6443. You could also specify localhost and port 6080 if your ArcGIS Server is only configured for HTTP connections. If the utility is able to retrieve a status from the RabbitMQ platform service, connect, and receive a test message, you should see messages like the ones illustrated below: Update March 2017: The diagnostic utility rabbitmqdiag-1.0.jar is throwing a com.esri.arcgis.discovery exception when run against the 10.5 release of ArcGIS Server. Users have reported the same exception being thrown when the utility is run against the 10.4.1 release. The GeoEvent product team does not have the source code for this utility. It was provided as an elementary diagnostic to the GeoEvent team when RabbitMQ was first being integrated. It is not actually part of either the ArcGIS Server product or the GeoEvent Server product and is not being supported. If a new utility can be developed for the 10.5 product release comments will be added to this thread; otherwise please assume that the utility will only work for a 10.3.x product deployment. ... View more