Modular architecture

The Unidata platform consists of a set of modules that allows you to create MDM systems that only have the necessary tools and functions. The modular architecture has the following features:

  • Frontend and backend modules differ.

  • Free and proprietary modules differ.

  • A separate MDM tool can be contained in one module or several at once. Thus, you may need to connect several modules to use separate tools.

  • There are several versions of the platform that are ready-made sets of modules.

  • There is a system set of modules that the platform cannot operate without.

The Unidata platform license contains information about all modules available to the user.

The description of the platform’s modules can be found below.

Backend modules

  • System. System module. A collection of all app types.

  • Search. System module. A utility module and is the only way to interact with ElasticSearch. The service provides the following features:

    • Manage cluster wide settings through ES settings;

    • Manage (create/delete/open/close/update the settings) the index;

    • Data indexing;

    • Data search;

  • Core. System module. The basic app functions. The module contains:

    • The audit service;

    • Access rights delimiting service;

    • Configuration service;

    • User and role management services;

    • Notification service;

    • System maintenance service;

    • License service;

    • Service for working with modules;

    • Data processing services;

  • Draft. Provides a single service for working with drafts

  • DQ core. (included in the Community Edition). Using data quality rules. It can work both in streaming mode and with the data subsystem (via the Data module).

  • Meta. Provides working with data model parts:

    • Model import/export;

    • Units;

    • Source systems;

    • Enumerations;

  • Data (included in the Community Edition). Working with data model and records.

    • Access to all the functionality for working with records and relationships between them, including storing data in a DBMS;

    • Data model management layer, includes model validation, model storage, and auxiliary services for navigating the data model;

  • Reindex Job. Implements an operation that allows data to be reindexed.

See also Appendix. Backend module schemas.

Frontend modules

System frontend modules

  • Types. General application types.

  • Core. The basic app functions. The module contains:

    • An abstract model (data);

    • Network interaction (network, operation);

    • The event mechanism (event);

    • Module management (userexit);

  • Core-app. Basic functions related to the application.

  • Uikit. Library of components.

Frontend Community Edition modules (open source)

All the specified modules are included in the default build of the platform distribution kit. All modules except Meta and Data can be made optional via the MODULES environment variable.

  • Meta. A required module. Processes everything related to the data model. The “Data model” section.

  • Data. A required module. Searches for records, works with the record card, records history, source records, backlinks, and etc.

  • Draft. A required module. Working with data model, classifier, and record drafts.

  • Security. Configuring access rights.

    • “Users” section;

    • “Roles” section;

    • “Security labels” section;

    • Application access rights system;

    • Select users in the “Logs” and “Operations” sections.

  • System-config. System configuration.

    • “Platform parameters” section;

    • “Execution threads” section;

    • “Notification routes” section;

  • Audit. “Logs” section.

  • Job. “Operations” section.

Enterprise modules

Frontend-modules, Enterprise Edition (proprietary)

All modules are optional and are specified in the MODULES environment variable.

  • Classifier. The “Classifiers” section and classifiers usage in the app.

    • In the record card;

    • In search;

    • In roles;

    • In workflow process settings;

    • In tasks;

  • DQ. Using data quality rules.

    • Configuring quality rules in the data model;

    • Configuring quality rules in the classifiers;

    • Viewing quality rules in the record card;

    • Viewing quality rules in search results;

  • Matching. Duplicate search rules.

    • Search rule settings screen;

    • View duplicate clusters in the record card;

  • Workflow. Workflow processes.

    • “Workflow processes” section;

    • “Tasks” section;

    • Task counter in the menu;

Using frontend modules

The Unidata platform contains many extension points, each of which has its own ID. Modules contain a set of extensions. Thus, when you connect a module, its extensions are connected to the application extension points. At the same time, it is possible to redefine some extension via the standard mechanism (UI UserExits).

Each extension point provides a contract for interaction between the parent and child modules. A Parent module is a module which embeds the extension, and a child module is the one embedded in the parent module.

Interaction between child modules is only possible through a mediator parent. For example, there may be basic interactions based on contracts. To write special interactions, the parent module must be available for extensions.

A module component can either store data independently or accept it externally via a contract.

Appendix. Backend module schemas

Module System

Figure 1. Module System

Module Search

Figure 2. Module Search

Module Core

Figure 3. Module Core

Module Draft

Figure 4. Module Draft

Module DQ core

Figure 5. Module DQ core

Module Meta

Figure 6. Module Meta

Module Data

Figure 7. Module Data