Run Oracle using the metadata CLI

In this section, we provide guides and references to use the Oracle connector.

Configure and schedule Oracle metadata and profiler workflows from the OpenMetadata UI:

• Requirements
• Metadata Ingestion
• Data Profiler and Quality Tests
• DBT Integration

Source Configuration - Source Config

The sourceConfig is defined here:

• markDeletedTables: To flag tables as soft-deleted if they are not present anymore in the source system.
• includeTables: true or false, to ingest table data. Default is true.
• includeViews: true or false, to ingest views definitions.
• schemaFilterPattern and tableFilternPattern: Note that the schemaFilterPattern and tableFilterPattern both support regex as include or exclude. E.g.,

  tableFilterPattern:
    includes:
      - users
      - type_test
  

Sink Configuration

To send the metadata to OpenMetadata, it needs to be specified as type: metadata-rest

Workflow Configuration

The main property here is the openMetadataServerConfig, where you can define the host and security provider of your OpenMetadata installation.

For a simple, local installation using our docker containers, this looks like:

workflowConfig:
  openMetadataServerConfig:
    hostPort: http://localhost:8585/api
    authProvider: no-auth

We support different security providers. You can find their definitions here. An example of an Auth0 configuration would be the following:

workflowConfig:
  openMetadataServerConfig:
    hostPort: http://localhost:8585/api
    authProvider: auth0
    securityConfig:
      clientId: <client ID>
      secretKey: <secret key>
      domain: <domain>

2. Run with the CLI

First, we will need to save the YAML file. Afterward, and with all requirements installed, we can run:

metadata ingest -c <path-to-yaml>

Note that from connector to connector, this recipe will always be the same. By updating the YAML configuration, you will be able to extract metadata from different sources.

Data Profiler and Quality Tests

The Data Profiler workflow will be using the orm-profiler processor. While the serviceConnection will still be the same to reach the source system, the sourceConfig will be updated from previous configurations.

1. Define the YAML Config

This is a sample config for the profiler:

Source Configuration

• You can find all the definitions and types for the serviceConnection here.
• The sourceConfig is defined here.

Note that the fqnFilterPattern supports regex as includes or excludes. E.g.,

fqnFilterPattern:
    includes:
    - service.database.schema.*

Processor

Choose the orm-profiler. Its config can also be updated to define tests from the YAML itself instead of the UI:

processor:
    type: orm-profiler
    config:
    test_suite:
        name: <Test Suite name>
        tests:
        - table: <Table FQN>
            table_tests:
            - testCase:
                config:
                    value: 100
                tableTestType: tableRowCountToEqual
            column_tests:
            - columnName: <Column Name>
                testCase:
                config:
                    minValue: 0
                    maxValue: 99
                columnTestType: columnValuesToBeBetween

Workflow Configuration

The same as the metadata ingestion.

2. Run with the CLI

After saving the YAML config, we will run the command the same way we did for the metadata ingestion:

metadata profile -c <path-to-yaml>

Note how instead of running ingest, we are using the profile command to select the Profiler workflow.

DBT Integration

You can learn more about how to ingest DBT models' definitions and their lineage here.