Do I need to expose a proxy server externally to route GPS data to a GeoEvent input connector?

Question

I actually need the same solution. However I'm approaching this differently. Can you confirm if my method will work? I am exposing a proxy server externally that will simply route streaming GPS data internally to the input connector of the GeoEvent process. Since this applicaion will only used internal to our network it not required to expose the Stream Service to the outsode world. Its my streaming data is coming from an external source.

JavierDelgadillo · Answer

A B,

To your follow-up questions:

1 If the ArcGIS Server is configured so that the WebSocketContextURL points to the external proxy and the proxy is correctly configured to proxy the WebSocket connections to GeoEvent, then clients will not need to see port 6143.  (The screenshot is used as a sample of how to set the property, not as an example of how to configure the property without a port.)

2 As far as SSL Certificates are concerned, if the proxy is configured to proxy connections to https://geoevent:6143/... for the WebSocket connections, then you'll have to configure the Proxy server to trust the certificate configured for use by GeoEvent.  If you want your clients to use HTTPS when connecting to the external proxy, then the certificate for your proxy must be one that the clients will trust.  Some browsers will show the Mixed content message if you have an HTML page loaded using HTTPS but then get some images or other content using HTTP.  So configuring the certificate (either on GeoEvent or the Proxy) so that it is trusted by all clients may or may not get rid of the warnings depending on your webapp implementation.

Hope this helps.

-Javier

AB12 · Answer

Hello RJ, you say: ArcGIS Server’s REST handler would need to be configured to provide the correct Websocket address to clients, without the port number embedded in them. However, in your attached screenshot, the JSON statement contains the port number 6180. Is this intended? What I understand from your post is the following, please correct me if i'm wrong: * AGS REST provides wss:///arcgis to clients (without port). * The client uses this address to establish a connection to the GeoEvent server (through the proxy). * The proxy maps wss:///arcgis to wss://:6143/arcgis. This leads me to the following questions: * From the client's perspective, this mapping is done transparently. It never sees the Port 6143? * Since the proxy handles all communications to the client, this is the only place where I need to provide a proper ssl certificate to prevent "mixed content errors" in the client's browser? Kind regards, - AB

RJSunderman · Answer

Hello Mike - I've branched your question to a new thread, as you are asking for advice on bringing data into GeoEvent rather than using a stream service to broadcast data out from GeoEvent. When working internally, behind your firewall, data you HTTP/POST to a GeoEvent hosted REST endpoint would need to be sent to the default port 6180. For example: http //server-name:6180/geoevent/rest/receiver/rest-json-in On another thread - Geoevent Processor and Verizon Networkfleet - Daniel mentions that your IT department might be able to create a specific tunnel for your device to reach the default port 6180 on the server running your GeoEvent Instance. I also describe, on that thread, how you might use a pair of GeoEvent instances, one running in the cloud, to relay data from a provider into your organization. One of Esri's solution engineers asked what sounds like a similar question to the one you pose. He indicated that he had a public facing Web Server with a JavaScript application submitting event data to GeoEvent via a ‘Receive JSON on a REST Endpoint’ inbound connector. The public facing server was actually a Reverse Proxy (Apache) to an ArcGIS/GeoEvent Server (IIS) communicating with GeoEvent using port 6180 in the httpd.conf file: * ProxyPass /geoevent http://10.61.3.5:6180/geoevent * ProxyPassReverse /geoevent http://10.61.3.5:6180/geoevent With a reverse proxy in place the URL for the JSON request does not contain the port. So rather than sending data to http//host:6180/geoevent/rest/receiver/ you would send it to something more like http//proxy/geoevent/rest/receiver/ . The advice provided was to install the Apache Module mod_proxy_wstunnel to enable the reverse proxy to handle websocket tunneling. One of the developers on the GeoEvent team evaluated the Nginx reverse proxy, so I don't have the exact syntax needed to configure the Apache reverse proxy. You would need to create a rule something like the following so that websocket connections from the client would get routed to the web server listening for those connection requests: * ProxyPass /arcgis/ws ws://10.61.3.5:6180/arcgis/ws ArcGIS Server’s REST handler would need to be configured to provide the correct Websocket address to clients, without the port number embedded in them. To do this you need to use the AGS Admin Directory to add a property to the Server to register your proxy of choice. (Refer to the attached illustration...) If you are working with a machine where the HTTP port for the GeoEvent Extension has been changed from the defaults (6180 / 6143) to something else (e.g. 8080 / 8443) … be sure to specify the correct port when updating the ArcGIS Server properties above. Hope this information is helpful. - RJ Capture.png