User Community Service Desk Downloads

Application Validation Checks

Overview

System validations check the internal consistency of data stored in the Metadata Management Module (MMM) database. In an ideal state, there are no inconsistencies in the MMM data. However, inconsistencies can be created under some circumstances, such as concurrent deletion of the same metadata node.

System validations are accessible for admin users at <ONE_URL>/organization/application/validations.

To run validation checks, you need superadmin permissions (MMM_admin or admin user roles).

You can view the recently run validations in any application mode in Global Settings > Validations in the Maintenance Center section.

Run validations

To run validations checks, select Run validations from the Validations screen:

Validation runs

Validation options

From the Run validations options, run either all validation checks (All validators) or only some. The following validations are available:

  • System tables validators: Check pre-computed permission tables and dictionary tables storing type and path names as numbers.

  • Node tables validators: Check content of system columns of the data tables. For example, they check that parent_id_i is not null and many other system column validations.

  • Computed content validators: Check if computed content nodes have correct SQL syntax.

  • Tables schema validators: Check if the tables generated by MMM have the expected definition.

  • Application validations validators: Check all PUBLISHED data stored in the MMM to ensure they satisfy the schema. These validations are executed after each editing of data in MMM. For example, they check if references point to existing nodes, if required properties have non-null values and if nodes are unique.

Running all validations might take a long time to complete, depending on the database size.

View validation run results

The Validation Runs tab displays a list of validation runs that can be executed manually or scheduled (usually once a day).

After the validation checks are complete, you can see the results on the Validation Runs tab. In Info, the status of the validation run and its start and end time are shown.

Validation run states

A validation run can end in the following states:

  • FINISHED: Validation run finished.

    • White row: No inconsistencies found.

    • Red row: Inconsistencies found.

  • ABORTED: Execution canceled, probably by a user.

  • FAILED: The run failed due to an unexpected error.

View all validations or the failed validations only (if there are any) by filtering the checks:

View errors

The Validation Checks section shows all performed validations with their status and error count:

Validation checks list

Expand the validation groups to see each validation result:

Expand validation result

Validation categories

Under the node node, there are two main categories of validations:

  • Internal validations: Check for issues such as null system columns. Display one metadata node ID per row.

  • Application validations: Execute the same validations that run during editing of metadata nodes. These validations check PUBLISHED data stored in the MMM:

    • Property is required

    • Reference missing

    • Unique constraint is violated

The two validation types display results in different formats. Internal validations list each affected metadata node on a separate row. Application validations group all affected nodes together by the constraint they violated, showing the list of IDs followed by the constraint details.

Understanding error messages

When you expand an erroneous validation, the red rows show IDs of erroneous nodes followed by a message.

Application validation errors

Application validations display errors grouped by constraint violations:

Application validation errors

For example:

[UId(15bbce34-0000-7000-0000-000000161e90), UId(15bbce34-0000-7000-0000-0000001981f0), UId(36ed325c-0000-7000-0000-0000008b8d91)]:
DbPublishValidationsSession.PublishConstraintViolationGroupingKey(constraintId=PARENT_EXISTS,
nodePath=NodePath(path=/sources/workspace/catalogItems/profilingConfigurationInstances/profiles/anomalyState),
constraintType=PARENT_EXISTS, code=PARENT_DOES_NOT_EXIST, entityName=anomalyState, propertyName=null, propertyNames=null)

In this example, the entity anomalyState does not have a parent. The IDs show the exact metadata nodes that are missing parent nodes.

The list of IDs can be duplicated. For the same entity, there can be multiple node paths. To get a unique set of affected nodes, collect all IDs and deduplicate them.

Internal validation errors

Internal validations display one error per row with the error message and affected node ID:

Internal validation errors

Resolve errors

If the validation runs fail, expand the validation to see the error message.

  • If errors are found in validations for precomputed data stored in _q tables, you can recalculate the ancestors using the following GraphQL mutation:

    mutation {
      _recalculateAncestors
    }
  • If errors are found in other validations, the issues are in the database itself. Follow the error message to resolve the issue.

    For example, for missing parent errors such as anomalyState, delete and publish the entities using GraphQL mutations.

GraphQL API for system validations

You can access and manage system validations through the GraphQL API. For more information about using GraphQL in ONE, see ONE API.

Query validation runs

Retrieve the most recent validation run with errors:

query e {
  _systemValidationRuns(size: 1, withErrorsOnly: true) {
    edges {
      node {
        errorsCount
        start
        status
        id
        checks {
          edges {
            node {
              id
              errorMessage
              distinctErrorsCount
              validator {
                name
              }
            }
          }
        }
      }
    }
  }
}

Query validation errors

Retrieve detailed error information for a specific validation check:

query e1 {
  _systemValidationErrors(runId: "4155c8b9-0000-7000-0000-000000201aa0", checkId: "4155c8b9-0000-7000-0000-000000201b0b") {
    edges {
      node {
        message
        record
        checkId
      }
    }
  }
}

Replace runId and checkId with the appropriate values from your validation run.

Delete and stop validation runs

You can delete a finished validation run and stop the running one.

  • To delete the old validation run, hover over the run and select the bin icon:

    Delete run
  • To stop the running validation, hover over the run and select the cross icon:

    Stop run

Was this page useful?