EngageOne™

In our installation guide, we suggest using status or health check endpoint (e.g. http://<host-name>:<port-number>/status) in load balancers and system monitoring tools. This is a kind of general approach which should work for all the bundles that can be clustered (security, core, composition and conversion). But a better solution is possible for both security and core bundles.

For security bundle, OpenAM login page (e.g. http://<host-name>:8082/OpenAM/isAlive.jsp) can be used instead of the default health check endpoint. HTTP GET on such URL will only return a status code of 200 once security service is up and running, so such check is definitely more accurate than the general approach mentioned above. More on that can be found in Forge Rock's knowledge base article available here: https://backstage.forgerock.com/knowledge/kb/article/a66917485.

Assuming that most of our customers implemented their own solutions using our SOAP API, we can also suggest a different health check endpoint for core bundle. If at least two services from our SOAP API are used in customer's implementation (e.g. DeliveryService, TemplateService, etc.), page displaying information about all our SOAP services can be used as core service health check endpoint (e.g. http://<host-name>:8080/EngageOneWS?wsdl). The check can be even more detailed if only one of our SOAP services is used (e.g. DeliveryService). As we know that there are installations when deliverDocument is the only method called from customer's external implementation, this can be a perfect solution for them. In all such cases, health check endpoint for core can look like this: http://<host-name>:8080/EngageOneWS/DeliveryService?wsdl.

IMPORTANT: Default port numbers are used in all the examples present above. All URLs have to be properly modified if different port numbers are used.