Release Notes 4.5

FME Server is now offered as a new data source for central information collection, aggregation and analysis. At regular intervals, the jobs executed and logged in the FME Server are queried and stored in the index. On this basis, the utilisation of the FME Engines, the success rate of the jobs and any waiting times can be analysed. In addition, the graphical visualisation of the job utilisation allows a quick impression and good assistance in creating new job schedules to achieve an optimal utilisation of the engines.

In addition to the job information, the associated job logs are also available in service.monitor. This is another building block for gaining a holistic overview of what is happening in a GeoIT solution.

service.monitor now supports Elastic Index Lifecycle Management to achieve a lower-maintenance operation of the Elasticsearch cluster. If ILM is used, Elastic is responsible for when indices are created or deleted (e.g. for log files). This also simplifies the configuration of Logstash.

ArcGIS Enterprise dashboards now show more information and are better tailored to the needs of users. This also includes the option to enrich events in terms of time so that analyses are possible on an hourly or daily basis. For example, it can be quickly recognised whether longer response times are to be expected at certain times of the day.

Detailed mechanisms now exist to use service.monitor to check the reliability, stability and capacity of FME Server. This includes simple queries about the available engines, checks to see if jobs are lingering in the queue for a long time and whether scheduled jobs have been successfully executed according to plan.

The user interface is now easier to use because there are direct jump options from a job to its expectations. It is now also possible to navigate directly between the individual jobs in the properties page of a service.

The next execution time of a job can now be seen directly in the dashboard.

Monitoring does no longer get installed by executing an installer program. Rather it gets deployed by using a web archive. In future this will simplify automation processes.

Another notification channel is available with the http-json web hook. In the notification case, a json message can be sent to any endpoint.

In order to replace the data type LONG RAW, which is no longer recommended for Oracle databases, with the data type BLOB, the SQL script located under resources\sql\upgrade\4.5 can be executed. The migration forces the application.property value db.type to be set to the value oracle.

INSPIRE’s Quality of Service requirements have evolved during the past few years. It now make some more flexible assumptions on how request shall be sent to the instance under monitoring and how the response of those instances shall be interpreted correctly. For INSPIRE View Services the GetMap request shall make use of varying BoundingBoxes and a blank response image cannot be considered as valid if features are present in the requested area.

However, service.monitor currently is not able to perform those variable and aggregated checks mentioned above. We recommend you to make use of the job configuration options to mimic the desired behavior in a similar way. I.e. when you are going to test the Performance of an INSPIRE View Service create a service endpoint with two jobs, one caring for GetCapabilities operation and the other for GetMap operation. Via the job execution interval you can try to weigh the number of requests performing a GetCapabilities and the number of requests performing a GetMap. For enabling this please see Flexible configuring INSPIRE services.