ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
latest (15.4.0) 15.3.0 15.2.0 15.1.x 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x 13.5.0 13.4.x 13.3.x 13.2.x
User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

RDM 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.

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.

See Moving Records Through RDM Workflows.

Notifications

Notifications can be configured based on events or actions taken on data going through workflows. They are sent as email messages, and you can create tailored templates for different events and workflow transitions.

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.

Online enrichers

Similarly to online validation processes, you can create enrichment web services from ONE plans. This provides autocompletion capabilities based on the input data: fields can be filled in or corrected based on the input in other fields.

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:

  1. Via text files, with a possibility to transfer files to and from a remote server.

  2. With external databases (in both directions).

  3. 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.

See Setting Permissions in RDM.

Was this page useful?