Starting from the version 3.4, EVA ICS uses structured document database as the primary storage of all configurations. In EVA ICS it is called “document registry system” or just “registry”.
EVA ICS uses YEDB as the structured database. YEDB is fast, easy to repair and crash-free.
Registry server is started with “/opt/eva/sbin/registry-control start” and MUST be always online. When YEDB is upgraded, all EVA ICS components should be stopped (vendor-provided upgrade scripts stop everything automatically).
Registry can be managed with “eva-registry”, “eva registry manage” and “sbin/eva-registry-cli” command-line tools.
Why EVA ICS has been switched to the registry database, instead of using simple “ini” and “json” files:
- Crash-free storage of configurations, inventory and data objects;
- easy management with command line tools and API;
- strict data schemas;
- easy-to-use SDK.
YEDB configuration is defined in “etc/eva_config”.
#SYSTEM_NAME=nodename #YEDB_REGISTRY_DIR=/opt/eva/runtime/registry #YEDB_SOCKET=/opt/eva/var/registry.sock #YEDB_SERVER_ENABLED=1 #YEDB_TIMEOUT=5 #YEDB_AUTO_BAK=10 #YEDB_WORKERS=2 #YEDB_CACHE_SIZE=10000 #YEDB_STRICT_SCHEMA=1 #YEDB_SUPERVISORD_PROGRAM=eva-registry #YEDB_USER=
It is also possible to use a single registry database for different EVA ICS nodes. if “YEDB_SERVER_ENABLED” is set to “0”, the server is not stared/stopped locally.
It is highly recommended to keep strict data schema (enabled by default).
If configuration file is not created, EVA ICS starts and uses registry server with the default settings.
When deploying / undeploying lots of items, old registry keys are not deleted but moved to the database trash. It is a good idea to clean it from time to time with “eva-registry purge” or “registry_safe_purge” API method.
“.trash” folder can also be used to restore keys deleted by accident.
When key data is changed, the server keeps its 10 backup copies by default, which can be also used to restore data if necessary.
To list deleted and backup copies, use “ls -a” command of “eva-registry” tool.
All data is stored in “runtime/registry” directory, which should not be accessed directly, unless data loss occur.
Each EVA ICS node creates registry key “eva3/<SYSTEM_NAME>”, all data is being stored in its sub-keys.
A strict schema “.schema/eva3/<SYSTEM_NAME>” is created for all data keys, except “userdata” key, which (as well as its subkeys) can contain any fields.
Keys can be edited with “eva-registry” and “eva-registry-cli” CLI tools.
|config/<controller>/main||yes||primary controller configuration|
|config/<controller>/apikeys/<key>||yes||static API keys|
|config/uc/drivers||not rec.||UC drivers|
|config/inventory||not rec.||inventory key (EVA ICS items)|
|config/userdata||yes||any user-defined data|
eva.registry module provides functions for registry management. All functions set key prefix (“eva3/<SYSTEM_NAME>/”) automatically.
The module can be imported and used in plugins, LM PLC macros or anywhere else. When imported by 3rd-party scripts with EVA ICS “lib” directory added to the import path, the module automatically initializes itself with the proper system name and connection settings from “eva_config” file.
Get key as configuration object
Get keys recursive as a dict
Work with key as with a dict
with key_as_dict(key): …
Decrement key value
key_delete_field(key, field, **kwargs)
Delete key field
Delete keys recursive
key_get(key, default=<class 'KeyError'>)
key_get_field(key, field, default=<class 'KeyError'>)
Get key field
Get keys recursive as [(key, value)] list
Import key from stream or file
Increment key value
key_set(key, value, **kwargs)
key_set_field(key, field, value, **kwargs)
Set key field
Purge database, keep broken keys
- SYSTEM_NAME name of the current node
- db YEDB Python object, can be used e.g. to manipulate keys without auto-prefixing.
It is also possible to work with registry server using the official API and clients. See https://www.yedb.org/ for more details.