Meengla

Windows/IIS Reverse Proxy for GeoEvent WebSocket

Discussion created by Meengla on Oct 11, 2016

Hi,

This is rather a quick write up / instructions-set then a question. It took me quite a while to make IIS to act as reverse proxy to process websocket requests for GeoEvent extension and I am sharing my experience here to help the larger community. I am mentioning a couple of people here who might find this post particularly useful: Marc Graham and RJ Sunderman . Please feel free to modify/improve this write up--this is really a quick job--with at least possibly grammar errors

 

Some background info:

1) For general info on ArcGIS Reverse Proxy setup, please refer to: How To: Set up a reverse proxy with ArcGIS 10.1 for Server on IIS ARR 

2) For GeoEvent extension's Reverse Proxy setup, please refer to: Using IIS Application Request Routing (ARR) to proxy GeoEvent Stream Services 

 

My setup (a development setup!):

1) Windows 10 Pro running IIS 10 with the latest ARR installed (I think via the Web Platform installer--it's important because the standalone ARR/URL Rewrite on Microsoft site **seems** to have some problems). 

2) A VM running ArcGIS 10.3.1 Server with the GeoEvent extension and ArcGIS WebAdaptor

2b) Possibly NO network level port forwarding to the VM needed in this case?  

3) Setup in IIS: See this screen cap: Pretty much sums up! Although I think the Rewrite rules could be improved?

IIS Setup for GeoEvent Reverse Proxy

4) On the ArcGIS Server VM, go to: http://localhost:6080/arcgis/admin/system/properties and enter: {"WebSocketContextURL": "ws://dev.myfqdn.com:6180"} . Note, the because in step #1 above, per the screen cap, there is a Server Farm entry for port 6180 this works. 

 

And that's it! In any client/javascript applications, to point to, say a streaming service, put in: 

http://dev.myfqdn.com/arcgis/rest/services/issmon3/StreamServer  and it will work.

 

With this setup, there is no need to instal Nginx on Windows: IIS's newer ARR/Url-rewrite module are able to handle Websocket requests fine. Also, any changes to the Url-ReWrite rules are reflected/processed immediately.

 

Finally, this write up is for a non-secure setup; for a secure setup, you will have to at least use "WebSocketContextURL": "wsS://dev.myfqdn.com:6180" along with SSL install and other changes in the Url Rewrite rules. 

 

I hope this helps someone!

Outcomes