Lead your team forward
OCT 24 / 9AM ET Register nowRDM Features
The following are the high-level features that RDM offers.
Model and metadata configuration
Ataccama RDM configuration is metadata-based, allowing for a fast setup. The configuration relies on a central or canonical reference data model, which accommodates all reference data used across the company.
The central RDM model is used to generate all important processes in the application, including integration interfaces, synchronization processes, data entity definitions, and relationships.
To learn how to configure the model, see RDM Configuration.
Data management
Ataccama RDM supports the full cycle of reference data management, and is suitable as a central and unique authority for all reference data changes, including maintaining consistency of the data across different systems.
These operations (such as creating, modifying, or deleting reference data) are done through the RDM web application interface. See Working with Records in RDM.
Workflows
RDM also allows defining processes (called workflows) that depend on various policy and other requirements for reference data changes. For details, see web-application:configuring-rdm-workflows.adoc.
Business dates
In RDM, you can define the effective life of data, the so-called record business dates.
To learn more, see Versioning Records in RDM. For configuration details, see Tables.
Browsing and data navigation
RDM brings advanced data browsing capabilities using special views and structures that can be configured as needed:
- Tables
-
Reference data entities. They are composed of attributes and represent the record structure of reference data tables.
This structure is the only mandatory structure in the data model.
- Hierarchies
-
Defined by relationships between different entities, hierarchies allow to explore data through parent-child trees. This form of inspecting data is particularly suitable for relationship-oriented reference data.
- Views
-
Consist of different bits of data across entities which are joined and grouped to form a table-oriented data representation. Views are created by selecting specific attributes or using relationships between different entities in the data model.
- Categories
-
A collection of different types of data structures that share a common abstract domain. Therefore, categories can be composed of entities, hierarchies, and views, and help structuring and selecting data when dealing with a wide range of reference data structures.
- Data sets
-
Custom reports about reference data. Formed via SQL queries, these reports can provide aggregated information about data from several tables connected by foreign keys.
These different structures are fully configurable and are abstractions over the central data model.
To learn more, see Data Tab Overview. For configuration details, see Creating the RDM Data Model, Creating Additional Reference Data Views.
Viewing modes
In addition to the structures that can be defined for browsing data, you can also define application-wide view modes. These modes help you browse data depending on its state in the publishing cycle:
To learn more, see Data Viewing Modes for more information.
Navigation features
To navigate your reference data more easily and focus only on the data that is of interest, you can use:
- Preset filters
-
Filtering by attribute values. Filters can be combined when searching for particular reference data records.
- Custom filters
-
SQL-type operations that can enable refined filters. While more complex, these filters deliver more powerful search capabilities.
- User-defined cart
-
You can earmark records for further work or publishing by putting them into the cart. This way, you can easily apply bulk operations to the selected records.
See Filters and Marking records for later use.
Workflows
Workflows are a central feature of RDM as they allow defining formal processes around reference data changes over time. Workflows have the following features:
-
Defined on a table basis (per each entity defined in the model).
-
Can be set for different types of actions (for example, creating, modifying, or deleting reference data).
-
Support an advanced role-based approach for resolving workflows.
Workflows are also exposed in the web application as a dedicated section where users are notified of their pending actions on the reference data records that are being modified. Each step of the process can be revoked or approved by a party with sufficient permissions, and notifications can be set for each transition between workflow states.
Data quality validation and enrichment
Built on top of the Ataccama platform, RDM takes full advantage of its capabilities by adding data quality validation and enrichment features to the reference data management process.
Attribute-based validation
Attributes in a reference data entity can be validated using data domains. A domain consists of a set of constraints applied to one data attribute, such as:
- Data type validation
-
Validation by native data types of the Ataccama platform (for example, Boolean, string, integer, float, date). This basic validation ensures that the given attribute complies with the applicable data type restrictions.
- Regular expression (regex) validation
-
For string data types, constraints can be set in the form of regular expressions, which define a pattern that must be matched by the input data, otherwise the input is considered as invalid.
- Ranges, formatting, and sizes
-
You can define ranges by using maximum and minimum values, as well as configure the size of string values, maximum number of lines, and further restrictions on the data format.
- Foreign key validation
-
Attribute integrity can be validated as a foreign key of another entity, provided that this is also defined in the model.
See Domains.
Record-based validation
In addition to the attribute-based validation, RDM provides a list of different record-based validation methods that allow you to define cross-attribute validation logic.
For configuration details, see Tables.
Unique and primary key validation
Unique key validation ensures that the attribute or a combination of attributes unequivocally identifies a record in the reference data. Any violation of this is immediately reported when the key appears as a duplicate in the data or when you create a new record in the web application.
SQL validations
These validations are defined by SQL-type queries that check for custom conditions across columns, rows, and tables.
See Tables, section SQL validations.
ONE expressions
Expressions written in a special Ataccama syntax can be used to define any combination of conditions that one or several records in a table must satisfy. You can define multiple expressions as well as a message to be displayed whenever the check is violated.
Online validations
These are the web services defined from ONE plans that provide real-time feedback on user validation. They can be built to create very complex data processing.
Online validations can access all values used by a record and apply additional dictionary or third-party services checks, as well as various transformations before the actual DQ evaluation.
Record validation on application or configuration restart
When RDM is first started, all records are validated by default. After this, whenever the application is restarted, validation is performed only if it previously failed on a particular table or if a change has been detected in the table structure. Otherwise, validation is skipped in order to improve the startup time.
If the web application configuration is modified, records are validated following the same logic (that is, validation is only applied to the tables that have been altered).
Additionally, you can schedule full validation that runs once the application is restarted again.
To do this, navigate to RDM Admin console (http://{rdm_url}:8060/admin
) in your web browser and select Schedule revalidation.
The following message appears to confirm your request:
If you change your mind, you can cancel revalidation after you schedule it by selecting Disable revalidation from the same screen. |
Integration and provisioning interfaces
RDM can integrate with a number of other components through batch or real-time interfaces. The interfaces can use all functionalities for data transformation or data preparation available in the platform, adapting to the needs of the final exposed interfaces.
Batch interfaces
Import and export data in batch mode through defined interfaces, which can use additional logic to support data transfer. In terms of integration, the following data formats are supported:
-
All types of text files, delimited or fixed-width.
-
Microsoft Excel files, supporting different versions.
-
Binary files through a special reader step.
-
Any database or system with an available JDBC connector.
In addition to integrating with these formats out-of-the-box, RDM can use third-party connectors to access proprietary, non-relational systems such as CRM/ERP and other legacy systems.
For configuration details, see synchronization:configuring-rdm-synchronization-via-text-files.adoc and synchronization:configuring-rdm-synchronization-with-external-databases.adoc.
SOA interfaces
It is also possible to specify standard interfaces through services, which can be further modified to define additional logic and wrap it as a service. Out-of-the-box, the online interfaces are SOAP (over HTTP or over JMS) and are generated as part of the configuration.
However, other service types are also supported (for example, JSON services for RESTful interfaces, bulk CSV services, and more).
For configuration details, see synchronization:configuring-rdm-synchronization-via-web-services.adoc.
Synchronization
RDM can be synchronized with external systems in several ways:
-
Via text files, with a possibility to transfer files to and from a remote server.
-
With external databases (in both directions).
-
By writing data to and reading data from selected RDM tables via web services.
In addition, it is possible to configure an on-publish service (based on a ONE plan), which runs each time a user tries to publish data in the web application.
Connected systems (databases) are independent, and integration with the tool can be done at the attribute level, thus enabling synchronization of systems that are structurally different from the central reference data model maintained by RDM. All systems can be defined by importing their models to the tool, which preserves references and relations between the data hosted by the systems and that hosted in RDM.
Synchronization jobs are automatically generated, and information about them is logged in the application. These jobs can be either scheduled, triggered through events, or executed on demand.
For configuration details, see Synchronization.
To learn how to monitor the synchronization with external databases, see Monitoring Synchronization.
History and auditing
Monitor the history of reference data as well as the application and user activity.
Data history and auditing
RDM keeps historical versions of all reference data, making it possible to trace any reference data changes through the life of a record. Two modes (History and All History) allow users to:
-
Access the state of data at a defined point in time (History mode).
-
Define a time range and view the course of changes of data during that period (All History).
See Data Viewing Modes.
Action and event auditing
RDM also keeps history logs of all processes and actions performed on the data, allowing you to trace particular events, such as synchronization with systems and changes to reference data made by users.
These logs can also be accessed in a persisted form. See RDM Change Log.
Permissions and data access
In RDM, permissions are managed using a role-based approach, that is, users are granted roles that define their permissions over different reference data entities. The roles are also important for the formal processes defined by workflows as access to particular workflow actions also depends on the roles assigned to a given user.
Permissions can be divided as follows:
-
View permissions: Allow to view data in a read-only mode.
-
Creation permissions: Allow to create new records.
-
Modify permissions: Allow to edit an existing record but not create or delete records.
-
Delete permissions: Allow to delete reference data (logical delete, as the change has to be published in order to be visible).
-
Publish permissions: Allow to publish reference data that has been created, modified, or deleted (effective deletion).
Permissions can also be set on attribute and row level using row rules (implemented as SQL statements).
You can manage permissions directly from the web application interface, provided that you are one of RDM administrators.
The application can also integrate with LDAP-compliant systems for both authorization and authentication.
Was this page useful?