In transformational modeling, parameters allow for dynamic configurations across projects and environments. By defining parameters at the project or environment level, these parameters can be referenced in various parts of a project. This ensures a flexible approach to model design, where changes in parameters can influence multiple elements in a project without manual updates to each instance.
This article provides a detailed guide on how parameters are added, managed, and referenced within transformational modeling projects.
Defining Parameters
Parameters can be defined at two levels:
Project Level: Parameters defined here apply to the project in development.
Environment Level: These parameters are specific to a deployment environment.
The system validates the JSON format to ensure correctness.
Although the format and functionality are identical, project parameters and environment parameters are independent of one another.
Defining parameters
To define parameters at the project level, follow the instructions below. For instructions on configuring parameters for Environments, see the related post at the bottom of this article.
Go to Settings and Conventions > Parameters
Enter some key-value pairs in JSON format.
For this article and the following example references, we will use these sample values:
{
"region": "EMEA"
}
Defining parameters at environment level
To correctly configure an environment and its parameters, refer to the Tx. Environments article referenced in the See also section.
Referencing Parameters
Parameters can be referenced in various sections of the project, including:
SQL and Jinja inputs: Use the syntax
{{parameters.<parameter_name>}
}.YAML inputs: Parameters can be referenced within YAML configurations, such as template properties, using
${parameters.<parameter_name>}
.
Examples of usage may include using them on template properties, to ensure consistency across Tx objects, or embedding them in logic scripts within Tx objects to dynamically adjust functionality based on their values.
To reference parameters within a project, use double curly braces to dynamically include parameter values. Examples of how parameters are referenced:
In SQL and Jinja Scripts:
SELECT * FROM sales WHERE region = '{{ parameters.region }}';
In YAML or Project Properties:
name: ${parameters.region}
Parameters are resolved to their defined values when running operations such as validating, selecting, creating, or running scripts. If an error occurs or a parameter is not found, it resolves as a blank value.
When the operations are done as part of a deployment or run in an environment, the parameters set at the environment level will be used.
When the operations are triggered from within the project, the project parameters are used.
See also: