Admin GUI

Admin GUI has the following URL by default: /web/admin/console/

Admin GUI is a lightweight graphic user interface to support general and frequent scenarios for administration of OpenHub framework solutions such as observation and search information about processes in case of problems.

Admin GUI contains only basic functionality that is OpenHub's specific or is very useful for OpenHub's administration.

There are so many great open-source or commercial tools which can be used together with OpenHub and therefore we don't want to waste time with developing things again - Kibana for searching logs, for camel routes administration etc.

The homepage without credentials allows you to view the current version. Version is in format 1.1.0-SNAPSHOT [v59] where 1.1.0-SNAPSHOT is the main version, r59 is number of revision from version control system.

Admin console allows authenticated users only. Sign in by username and password.

There are the following default user and password from

# username and password for accessing web admin GUI

There is dashboard after successful logging in.


Searching asynchronous messages

REST: web/admin/api/messages (DOC)

This page allows to filter asynchronous message by specified message parameters.

Each asynchronous message is exactly identified by external system that sent this message and correlation ID. Correlation ID is unique identifier set by external system. With these two parameters you can search just one specific message. 

Count of returned messages is limited.

There is property ohf.admin.console.messages.limit for setting. Default value is 100.

Searching is case sensitive and apart from fulltext only whole search strings are searched. You can use "%" for searching parts of values, e.g. "%Hello" in Operation Name parameter searches for syncHello or asyncHello operation names.

You can go to detail of asynchronous message by clicking on selected message.

Detail of message contains all necessary information which are stored by OpenHub and also contains the list of external calls and their statuses which identifies concrete place in process with potential error. If the message is not properly processed the state is FAILED with error code and description. 

Each request and response into external system could be logged (by configuration, see Request/response tracking) and these records are showed below detail of message. 

Recommendation steps for handling message errors:

  1. search specific message and check status, error and reason description
  2. if information is insufficient you have to go to application logs for more details
  3. each message contains message (body) of request that could be useful for reproducing
  4. the largest percentage of errors are caused by communication with external system - wrong data format, unexpected value, error in external system and so on - for this reason it is necessary to search requests/responses in external system

Restart FAILED messages

REST: web/admin/api/messages/id/action (DOC)

Sometimes happens that asynchronous messages fails (is in FAILED state). In this cases it is possible restart the message.

There are "through points" (external calls) defined by developers during processing of asynchronous message. It is our customized implementation of the idempotent component and it is used to filter out duplicate messages. This uses an expression to calculate a unique message identifier (ID) string (as subpart of process) for a given message exchange; this ID can then be looked up in the idempotent repository (external_call table) to see if it has been before; if it has the message consumed; if its not then the message is processed and the ID is added to the repository. Thanks to that each process can be divided into independent parts which have own status (OK, FAILED). During next iteration the message can be processed from the through point in which message was not processed correctly (with error). You can choose whether the message will be processed from scratch (=total restart) or from the point where message processing failed.

Cancel next processing of the message - CANCEL

REST: web/admin/api/messages/id/action (DOC)

Administrator can manually cancel next iteration of processing the message. After that the message will be in final state CANCEL.


Cluster nodes

REST: web/admin/api/cluster/nodes (DOC)

Overview of all cluster nodes.

Nodes can be updated and deleted.

Shutdown OpenHub instance

Stopping OpenHub instance is useful function for correctly shutdown when integration platform starts to reject new incoming messages. See Stopping mode for more details.

This function correctly stops OpenHub instance for example for upgrade reason. If OpenHub is configured in clustered environment we can upgrade each node separately without stop the whole solution (under certain conditions).

Exposed WSDLs overview

REST: web/admin/api/services/wsdl (DOC)

Overview of exposed WSDL contracts - see Web Services for more details. 


Configuration parameters

REST: web/admin/api/config-params (DOC)

Overview of OpenHub configuration parameters which are stored in the database (see External configuration model for more details).

These parameters can be changed on the fly. 

There can be some config parameters (e.g. ohf.asynch.concurrentConsumers) which can be changed on the fly but really impact will be after OpenHub instance restart. 

Logging configuration

REST: web/admin/mgmt/loggers (DOC)

Overview of logging configuration - loggers and logging levels. 

Logging levels can be updated.

Environment properties

REST: web/admin/mgmt/env (DOC)

Overview of environment configuration parameters.

Error catalog

REST: web/admin/api/errors-catalog (DOC)

Displaying a catalog of error codes that shows all error codes which are defined by developers - see Error handling for more details. This allows consumers of your services to trace a specific meaning return error code.


Ping service (for test)

REST: web/admin/mgmt/info (DOC) (not accessible from the menu)

Service for checking if the OpenHub respectively admin GUI is still active, whether the application is running.

You can also use health endpoint - web/admin/mgmt/health (DOC).

List of changes

REST: /web/admin/changes (DOC) 

This page displays content of the file /web-admin/src/main/resources/changes.MD that contains list of changes that have occurred primarily on input interfaces and services that provides OpenHub. 

This file/page serves for consuments of your services to be able watch changes in your APIs.

There are links in the menu to external applications.

Java melody

The goal of JavaMelody is to monitor Java or Java EE applications in QA and production environments.

Menu customization

Menu structure is configurable via properties. 

There is class org.openhubframework.openhub.admin.web.console.rpc.ConsoleConfigRpc that defines possible property parameters - look at

# Configuration of menu items = true = true = true = ${endpoints.configprops.enabled:true} = ${endpoints.loggers.enabled:true} = ${endpoints.env.enabled:true} = true = true[0].title = Javamelody Monitoring[0].link = ${javamelody.init-parameters.monitoring-path}[0].enabled = ${javamelody.enabled} = true

# Messages api configuration
ohf.admin.console.messages.limit = 100

# Logged user session concurrency limit
ohf.admin.console.session-concurrency.limit = 2

Browser support

Admin GUI supports all major browsers with latest versions, there are few known bugs in IE 11 ...