Concept - IOM Server Health Check

1 Introduction

This concept gives an overview of IOM server health checks and how they can be used within an HA installation of IOM. The document is mainly addressed to application administration.

1.1 Glossary



Application Programming Interface

HAHigh Availability
IOMThe abbreviation for Intershop Order Management
RESTRepresentational State Transfer
WatchdogA tool of IOM to monitor and manage the availablity of IOM application servers

1.2 References

2 Health Status of Application Servers

An application server is one single application server within a cluster of multiple application servers.

The health status of an application server reflects whether the server is able to adequately fulfill all tasks it is responsible for.

For Intershop Order Management, the status can be requested using the REST API. Additionally, the result will be persisted to the database as part of the cluster status.

The health check includes basic connecting to the database. Further checks, e.g., access to shared file-system is possible.

2.1 Application Server Monitoring

The main purpose of a health status support is to enable server monitoring applications to manage the application cluster, i. e., not to host unhealthy/broken servers and/or to trigger the repair/restart of unhealthy/broken servers.

Especially in case of HA health checks are required to always ensure a running application.

The IOM provides Watchdog to monitor the application server health statuses and to control the application server based on this information.

3 Cluster Status

The cluster status reflects the general health status of each application server of a server cluster. Basically it can be used to give a quick overview of the healthiness of the server cluster.

The cluster status can be requested using REST API which returns the persisted results from the last health status check of each application server.


The REST response for the application server health status will return a status code that reflects the health status and can be used by the server monitoring application.

An additional payload gives detailed information on the processed checks and their results.

  "services": [
      "name": "ftp-media-host",
      "checked": false,
      "statusCode": 204,
      "description": "The service was configured not to be checked."
      "name": "ftp-pdf-host",
      "checked": true,
      "statusCode": 200,
      "description": "OK"
      "name": "database",
      "checked": true,
      "statusCode": 200,
      "description": "OK"
  "serverId": "jdevoms06.rnd.j.intershop.de_0.0.0.0",
  "serverType": "frontend",
  "statusCode": 200,
  "description": "OK",
  "lastCheckEpoch": 1484838994495,
  "lastSuccessfulCheckEpoch": 1484838994495,
  "lastCheck": "2017-01-19 16:16:34:495 +0100",
  "lastSuccessfulCheck": "2017-01-19 16:16:34:495 +0100"

5 Further Information

5.1 Deployment

To offer the health check for an IOM application server, the artifact oms.monitoring must be deployed.

5.2 Configuration of Checked Services

The following list describes the current checks that are done by a health check.

Ftp-Media Host

removed with IOM 2.12

A connection to the ftp-media host will be established if configured.

Configurable using cluster property = true|false
Ftp-Pdf Host

removed with IOM 2.12

A connection to the ftp-pdf host will be established if configured.

Configurable using cluster property is.oms.pdf.healthcheck = true|false
Shared FS

removed with IOM 3.1

A file is written/deleted at $OMS_SHARE/.healthcheck.

Configurable using cluster property is.oms.sharedfs.healthcheck = true|false
DatabaseA connection to the database will always be established.Always performed

Also see Guide - Setup Intershop Order Management 2.2 or later, see Overview - IOM Setup, for cluster properties.

5.3 Triggering Health Checks

The following list describes how the check works for different versions.

IOM VersionHealth Check
Prior to IOM request to get the health status triggers the check of all services.
Since IOM performed check will be cached, and subsequent requests are served from that cache as long as the lastCheck time was not older than the value configured with is.oms.healthcheck.cachelivetime.
Since IOM

Health checks are performed by a Java timer and cannot be triggered by the REST requests any more.
The result will be cached for responding REST calls.

With this improvement, the signification of the property is.oms.healthcheck.cachelivetime has changed, and is.oms.healthcheck.recurringtime has been added.

Also see Guide - Setup Intershop Order Management 2.2 or later, see Overview - IOM Setup, for cluster properties.

5.4 Expandability

The health check can be extended within of artifact oms.monitoring by adding a new check.


The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources