This little web application enables you to search for datasources within MapServices of various ArcGIS Servers.
The app can be hosted on-premise and there is a small demo available (take me there).
The app is made up of three different components:
- Client
- Backend
- Search index based on Elasticsearch that can be accessed via its REST API
- FME (if you don't know FME: it has a super simple approach and you can apply for a Free Home Use License 👍)
- Workspace is based on FME Desktop 2018
- Extraction of the datasources from MapServices hosted on several ArcGIS Servers
In the FME Workspace, all ArcGIS Servers to analyze are stored as a JSON object, so the list of ArcGIS Servers to process can be extended easily. For each ArcGIS Server the Workspace retrieves all MapServices. Afterwards, all the relevant information of each MapService are extracted and combined. By doing this, the processing provides the following information:
- Name of the MapService
- Environment of the ArcGIS Server (e. g. Staging or Production)
- Type of the ArcGIS Server (e. g. Intranet or Internet)
- All used datasources with the following details:
- Type of the datasource (e. g. SDE or File Geodatabase)
- Name of the datasource (e. g. name of the Oracle or SQL Server instance)
- Name of the dataset (name of the Feature Class, table, file, etc.)
- Authentication mode (e. g. Operating System Authentication or Database Authentication)
- Username used to access the datasource (only in case of an Enterprise Geodatabase)
Finally, all the information are exported with HTTP POST
requests through the Elasticsearch REST API into the search index.
To ensure that the search index is always up-to-date, the FME Workspace has to be executed regularly, e. g. with a batch job or FME Server.
The client communicates with the search index through the Elasticsearch REST API and executes a search. The search results are processed and displayed. The processing includes marking the datasets matching the search term so that they can be highlighted/colourized.
The code contains no mechanism to prohibit a malicious modification of the search index. If you do not protect the Elasticsearch backend, everybody knowing the URL of your backend can edit your search index via HTTP PUT/POST/DELETE
. You have to handle this on your own, e. g. by using API keys (like Searchly does) or through the web server.
The code has been developed with Visual Studio 2015.
For local development, the client can be hosted in IIS Express. In order to work with a local backend, the following things are required:
- Local instance of Elasticsearch must be installed and running
- Elasticsearch index must have been created (e. g. with the FME Workspace
FME\MapServiceSearch_CreateIndex.fmw
)
After this, you have to set the Elasticsearch URL (either of the local backend or a hosted solution) in MapServiceSearch.Web.App\script.js
:
MapServiceSearchApp.service("client", function (esFactory) {
return esFactory({
host: "<<your URL goes here>>"
});
});
Since the AngularJS app is embedded into an ASP.NET Web Application, the publish mechanism of this project type can be used for deployment. The file Deployment\Deployment.targets
contains the two MSBuild-Targets DeployServer
and DeployClient
. If you use a CI server, you can easily call them for an automated deployment:
-
Client
msbuild Deployment\Deployment.targets /t:DeployClient
-
Backend
msbuild Deployment\Deployment.targets /t:DeployServer
The destination path of the client is managed within the publish profile MapServiceSearch.Web.App\Properties\PublishProfiles\Production.pubxml
. The MSBuild-Target copies all files belonging to the client to the destination path.
The MSBuild-Target to deploy the backend assumes that there is an on-premise installation of Elasticsearch on the same server where the web application is hosted. Since Elasticsearch typically runs under http:https://localhost:9200, you need a Reverse Proxy to expose the REST API of Elasticsearch. When using IIS, this can be easily accomplished by using the IIS module URL Rewrite. The file api\web.config
contains an URL rewrite rule redirecting all traffic to http:https://localhost:9200. The MSBuild-Target simply copies this file to the destination path specified in Deployment\Deployment.targets
and now IIS treats the folder api
as an application, uses web.config
with the URL rewrite rule and acts as a Reverse Proxy.