Skip navigation
All Places > GIS > Enterprise GIS > GeoEvent > Blog > 2016 > February
2016

Changes made to the Text adaptor for the 10.4 product release might catch a few folks off guard, so I want to call attention to what you might expect to see and why.

 

 

Several inbound connectors – specifically those using the Generic-JSON and XML adaptors – provide the ability to ‘Construct Geometry From Fields’ so that when event data is received which contains coordinate information on a point location a Geometry can be constructed by the GeoEvent input prior to sending the event to a GeoEvent Service.

 

At the 10.3.1 release, inputs such as ‘Receive Text from a TCP Socket’ and ‘Watch a Folder for New CSV Files‘ do not have this capability because it was not included in the Text adapter.

 

It was observed that if a user allowed the input to create a GeoEvent Definition and then later reconfigured the input to request that it construct a Geometry from specified event fields without also editing the event definition to include a Geometry field in which the constructed Geometry could be placed … that the input would stop ingesting event data.

 

For the 10.4 release, an enhancement was made to the Text adaptor to bring it in line with the Generic-JSON and XML adaptors:

 

Issue #945:  Text adapter needs to follow Generic-JSON adapter's behavior and create a field of type Geometry, tagged GEOMETRY, when creating a GeoEvent Definition

 

Now, at the 10.4 release, when you select the ‘Construct Geometry From Fields’ option and specify the name of event attribute fields containing coordinate values, the GeoEvent Definition generated for you by the input will include a field named “Geometry”.  The field will be added as the last field in the event definition and will be tagged with the GEOMETRY GeoTag.

 

Capture.png

Capture1.png

 

If you leave the ‘Construct Geometry From Fields’ parameter set to its default ‘No’ the generated event definition will not have the Geometry field highlighted above.

 

If you elect to edit the generated GeoEvent Definition to replace ‘Field1’, ‘Field2’, ‘Field3’ (etc.) with meaningful names, but neglect to include a field in the GeoEvent Definition into which the constructed Geometry can be placed, and then alter your input to switch ‘Construct Geometry From Fields’ from ‘No’ to ‘Yes’ … beginning with the 10.4 release the input will alter the event definition for you to create the needed Geometry field.

 

Here’s where this enhancement might produce undesired behavior …

 

Let’s say that you had been using GeoEvent at the 10.3.1 release with a ‘Receive Text from a TCP Socket’ input successfully receiving event data sent from the GeoEvent Simulator. Your GeoEvent Definition might look something like the following:

 

Capture2.png

 

You export your 10.3.1 GeoEvent product configuration as an XML file, upgrade to 10.4, and import your configuration. When you try simulating the same data which was working at the 10.3.1 release, the input’s event count no longer increments and it does not appear that your GeoEvent is receiving any of the data you’re simulating. You look in the GeoEvent logs and see a message:

 

Cannot find matching GeoEvent Definition. Event is not created.

The incoming text is SWA2706,3/16/2012 02:25:30 PM,IAD,TPA,B733,37000,-79.585739,34.265521

 

What’s going on?

 

It is likely that the field named “Location” is not the field the ‘Construct Geometry From Fields’ operation expects. Even though you were careful to copy and edit the GeoEvent Definition, back in 10.3.1, to include a field whose data type is Geometry and tag the field GEOMETRY … its name is not “Geometry”, so the input doesn’t recognize it.

 

Remember that delimited text is not well-defined like JSON or XML. If the inbound events contained field names then the adapter would be able to map the received data into the correct fields in the event definition. The 10.4 Text adapter does not assume that a field of type Geometry is sufficient (even the field is tagged GEOMETRY). It looks for a field named “Geometry” and, failing to find one, it logs the error shown above and discards the event.

 

To fix the problem, all you have to do is edit the GeoEvent Definition imported with your configuration and rename the last field from “Location” to “Geometry”.

 

This is probably a scenario that many users will encounter when upgrading 10.3.1 configurations which include a TCP/Text input to the 10.4 release. You need to remember that at 10.4 your Geometry fields should be named “Geometry” (not “Location”, or “Target”, or “Geom”). The field must still be the last field in the GeoEvent Definition.

 

Hope this information saves you a little future grief -

RJ

I received a second request recently for the information below, provided to me originally by Javier on the GeoEvent Server development team, so I thought I’d post it in case others are looking for the information.

 

See also:  GeoEvent WebSockets in 10.6 with ARR

 

 

From: Javier Delgadillo

Sent: December 01, 2015

 

Since the ArcGIS WebAdaptor does not support GeoEvent Server, you cannot use it to proxy GeoEvent requests. You can however configure Application Request Routing (ARR) and create your own rules to allow IIS to proxy the requests. Below is a screenshot of a rule created within IIS 8.5 to allow proxy of GeoEvent Server via IIS:

 

Capture.png

 

After installing ARR, double-click the URL Rewrite icon and create a similar rule (replacing the hostname of the Rewrite URL to match your environment):

Capture1.png

 

After applying the rule confirm you are able to access GeoEvent Manager through IIS:

Capture2.png

 

Configuring your SSL certificates will be important. You can use IIS to create and export a Domain Certificate with a private key and then configure ArcGIS Server and GeoEvent to use that certificate. An alternative would be to get IIS to trust the certificate that is configured with your ArcGIS Server/GeoEvent installation.

 

It was discovered that, using the 10.3.1 release of GeoEvent Server and IIS version 8.5 with WebSockets enabled, with ARR configured to create a reverse proxy for GeoEvent that StreamService connections did not work. This issue was addressed in the 10.4 release of GeoEvent Server.

 

10.3.1 deployments can create a reverse proxy similar to WebAdaptor specifically for WebSockets using NGINX.  Steps outlined below provide some detail on installing and configuring NGINX. A sample nginx.conf configuration is attached which you can use as a reference.

 

Please note:  Esri tech support cannot help troubleshoot reverse proxy configurations - whether they be NGINX, IIS, or Apache.  If you do plan on deploying a reverse proxy as part of a systems solution, make sure you have someone with appropriate experience available to you for help troubleshooting. Esri tech support has a KB article you can refer to:

http://support.esri.com/cn/knowledgebase/techarticles/detail/40680

 

  • Install a WebSocket reverse proxy server Nginx.
  • Enable HTTPS on the proxy server and configure it to use a certificate issued by a trusted 3rd party CA (Thawte, VeriSign, DigiCert).
  • Configure the proxy server to forward requests to GeoEvent Services. Attached is an example of an Nginx configuration file. You will need to change the following settings:
    • server_name <your Web Socket reverse proxy server name>
    • ssl_certificate <your CA-cert certificate file>
    • ssl_certificate_key <your CA-cert certificate key file>
    • server <list of servers that GeoEvent Extension is running on>. In this example, the server names are dev01014.esri.com, dev01015.esri.com, and dev01018.esri.com

 

Note: The WebSocket reverse proxy server is set to use HTTPS, but it connects to HTTP on the backend. In the example configuration file, the proxy_pass for port 443 is set to http: //skivmHTTP; not https: //skivmHTTP.

 

  • In a web browser, navigate to http: //<ServerName>:6080/arcgis/admin to access the ArcGIS Server Administrator Directory.
  • Login and click system -> properties-> update.
  • Enter a property called WebSocketContextURL to point to the Web Socket reverse proxy.

 

For example:

{"WebSocketContextURL": "wss://skivm.esri.com"}

 

  • In a browser, navigate to:

https: //<WAMachineName>/<context>/rest/services/<StreamServiceName>/Streamserver/subscribe

 

  • Click Subscribe to verify data is streaming. You can also verify data is streaming by navigating to:

https: //<WAMachineName>/<context>/rest/services/<StreamServicename>/StreamServer?f=jsapi

 

See Also:

https://nginx.com/resources/wiki

http://nginx.com/resources/admin-guide/reverse-proxy

http://www.iis.net/downloads/microsoft/application-request-routing

http://www.iis.net/learn/extensions/configuring-application-request-routing-(arr)

 

 

Hope this information is helpful -

RJ