Environment-Based Schema and Table Naming

Overview

In some installations, schema and table names contain an identifier that reflects the specific environment, for example A, B, or C environments.

When using Compatibility Table Copy Tasks (CTC) or Native Table Copy Tasks in XDM, these environment identifiers often need to be set dynamically based on the selected source and target connections.

This guide explains how to dynamically assign schema and table name identifiers by:

detecting the environment from the selected connection,
storing the detected values in custom parameters,
using these parameters in Selection Rules and Mapping Rules.

Prerequisites

To apply this solution, the user should:

Be capable of configuring and executing XDM Workflows with Task Templates.
understand Groovy-like scripting used in workflow configuration.

Steps

Step 1: Create Custom Parameters

Define two custom parameters of type STRING.

These parameters hold the environment identifier for source and target schemas or tables.

- type: "CustomParameter"
  attributes:
    displayName: "Source Environment Letter"
    variableName: "sourceLetter"
    parameterType: "STRING"
    options:
      - displayName: "A-Environment"
        value: "A"
      - displayName: "B-Environment"
        value: "B"
      - displayName: "C-Environment"
        value: "C"

- type: "CustomParameter"
  attributes:
    displayName: "Target Environment Letter"
    variableName: "targetLetter"
    parameterType: "STRING"
    options:
      - displayName: "A-Environment"
        value: "A"
      - displayName: "B-Environment"
        value: "B"
      - displayName: "C-Environment"
        value: "C"

The parameters are filled dynamically in the workflow based on the selected source and target connections.

Step 2: Use Parameters in Selection and Mapping Rules

Reference the parameters sourceLetter and targetLetter in your rules.

Example: Selection Rule

This rule matches schemas and tables based on the source environment letter.

Selection Type

Pattern

Object Type

TABLE

Schema pattern

DB2${sourceLetter}

Name pattern

TEST${sourceLetter}

Example: Mapping Rule for Table Names

This rule maps table names dynamically.

Field Selection Mode

Simple

Object Type

TABLE

Field Type

NAME

Source selection pattern

TEST${sourceLetter}

Target value mode

Simple Pattern

Target Value

%${targetLetter}

Example: Mapping Rule for Schema Names

This rule maps schema names dynamically.

Field Selection Mode

Simple

Object Type

ANY

Field Type

SCHEMA

Source selection pattern

DB2${sourceLetter}

Target value mode

Simple Pattern

Target Value

%${targetLetter}

Step 3: Dynamically Assign Parameters in the Workflow

Use the workflow to extract the environment letter from the connection display name.

The custom parameters must be added to the workflow.

def sourceConnectionName = workflow.mySource.displayName
def targetConnectionName = workflow.myTarget.displayName

def getEnvironmentLetter = { connectionName ->
    if (connectionName.startsWith("A")) {
        return "A"
    }
    if (connectionName.startsWith("B")) {
        return "B"
    }
    if (connectionName.startsWith("C")) {
        return "C"
    }
    return ""
}

def sourceConnectionLetter = getEnvironmentLetter(sourceConnectionName)
def targetConnectionLetter = getEnvironmentLetter(targetConnectionName)

TaskTemplateRunner()
    .taskTemplate('DynamicCTC')
    .taskNamePattern('Workflow of ${taskTemplate.displayName} at ${.now?iso_local}')
    .parameter('sourceConnection', workflow.mySource)
    .parameter('targetConnection', workflow.myTarget)
    .parameter('sourceLetter', sourceConnectionLetter)
    .parameter('targetLetter', targetConnectionLetter)
    .run()

The complete workflow can be found here:

Dynamic settings in table copy

Step 4: Execute the Workflow

If data should be copied from the A environment to the C environment, create or execute the workflow and select:

mySource: connection for environment A
myTarget: connection for environment C

During execution:

The workflow detects A as the source environment.
The workflow detects C as the target environment.
The values are passed to the Task Template as sourceLetter and targetLetter.
The Selection Rules and Mapping Rules use these values.
The data is copied from the A environment to the C environment.

Benefits

This approach provides the following benefits:

Dynamic configuration: Schema and table names do not need to be hard-coded for each environment.
Reusability: The same Task Template can be reused across different environments.
Flexibility: Adding a new environment, for example D, only requires extending the parameter options and detection logic.
Automation: The environment identifier is determined automatically from the connection display name.
Integration readiness: The approach is suitable for Data Shops and workflow integration pipelines.
Maintainability: Environment-specific naming logic is centralized in the workflow.

Conclusion

This approach allows Copy Tasks in XDM to adapt dynamically to different technical environments.

By combining custom parameters with workflow logic, schema and table naming can be configured in a scalable and environment-independent way.

For further optimization, consider moving the environment detection logic into a reusable function or using metadata instead of connection name prefixes.