Overview
This document describes the relationship between server_registry, service_status, and failover_service table. These tables hold information and status of all the servers as well as the services running on a standalone server, or on a specific server in a cluster. Ephesoft’s failover mechanism provides high-availability support for services across servers and helps recover servers from crashes. If one of the servers fails, then the failover mechanism initializes another live server in a multi-server environment and starts to provide service through the newly initialized server.
The status of the server can be seen in the server_registry table and services can be seen in the service_status table along with the server ID which is currently assigned for that service. These tables are automatically populated.
Server_Registry – This table keeps a record of active and inactive servers. This contains details of server whether its clustered environment or standalone server, this will have entries of all the servers. Below is a brief description of columns in this table.
Column Name | Column Description |
ID | This is the primary key of server_registry. |
Creation_Date | This contains creation date of the current record in this table. |
Last_Modified | This contains last modification date e.g. Change in execution capacity, active status etc. |
IS_Active | This shows whether server currently active or down. For active server value will be 1 and 0 for in-active server.(only if its clustered environment) |
App_Context | This contains the application context like /dcma. |
Execution_Capacity | This shows the current execution capacity for the server. Here execution capacity is workflow process capacity i.e. Number of batches processing at a time on a server in a cluster. |
IP_Address | This contains server’s host name or ip address. |
Port_Number | This contains the port number on which application is running like: 8080 |
Service_Status – This table keeps mapping information of services currently allocated to different servers.
Column Name | Column Description |
ID | ID is primary key of service_status. |
Creation_Date | This contains creation date of the current record in this table. |
Last_Modified | This contains last modification date e.g. If any server is down, then currently assigned services will be taken up by other available server and server_registry_id (Referring ID column of Server_Registry table) will be updated accordingly. Switching service to any other available server is an automated process. |
Service_Type | This defines type of available services:
APP_SCRIPT – This represents Application level script execution service. Refer this wiki for more detailed information about Application level script. ETL_SERVICE – This represents reporting service. Only one server runs reporting service in a cluster. Server_Registry_Id column in this table will tell you about the server which is currently assigned for reporting service. Refer this wiki for more detailed information about Reporting. FOLDER_MONITOR – This represents Folder monitor service and this service is responsible for creating new batches if any file/folder is placed in UNC folder. This service keeps watching the UNC/Drop folder for any new file/folder dropped/placed in UNC/Drop folder. Once this service finds any new file/folder in drop/UNC folder then it creates new batch/entry in batch_instance database table and later Workflow engine picks and process that batch. LICENSE_SERVICE – This represents the license service. Refer this wiki for more detailed information about license server failover mechanism. PICKUP_SERVICE – This represents pickup service. Pickup service is responsible to pick batches in New and Ready state for further processing. Refer this wiki for more detailed information about pickup cron/job configuration. |
Server_Registry_Id | ID of server which is currently assigned for this service. Referring ID column of Service_Registry table. This is the foreign key to server_registry table. |
Failover_Service – This table contains details of services that will be taken up by the next available server if the currently assigned server is offline. Below is a screenshot showing that the Folder_Monitor service can be taken up by either server_registry_id 1, 2, and 3 but the server that is currently working as Folder_Monitor service can be verified in Service_Status table.