Modular architecture

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.

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

  • Common. System module. A collection of all app types.
  • 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;
    • Service for working with modules;
    • Data processing services;
  • Meta. System module. Works with the data model.
  • Data (included in the Community Edition). Interacts with the data subsystem.
  • Draft. Working with data model, classifier, and record drafts.

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);
  • Draft. Working with data model, classifier, and record drafts.
  • 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, and etc.
  • 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.

Options for implementing new modules

Below is a list of modules that can be implemented as needed. 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;

Use frontend modules

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.