Introduction

When defining a DTP, it is possible to use parametric elements that are resolved at runtime.

Specifically:

• Attributes, which are resolved by the system automatically, based on the specifications entered in the DTP definition step.
• Parameters defined for reporting or data entry purposes, which must be defined at runtime by the user running the data processing.
• Parameters defined in the DTP, which are defined by the administrator in the DTP definition step and resolved automatically at runtime.

Attributes

In DTP fields that accept SQL formulas (e.g. filters and formulas for defining dataset fields), it is possible to refer to attributes related to CCH Tagetik lists (e.g. Scenarios).

For example, attributes can be used to filter a field based on the currency of the entity on which the DTP is being run or define a field with the description from the Previous Scenario before the run scenario.

Attributes must be defined with the syntax used in the reporting for the cell fields and applicable to all dimensional attributes.

The syntax must be between braces :${}.

Example

To filter the reading of data from a dataset, only for records whose CURRENCY field matches the currency of the entity, which you have selected in the process cockpit when running the DTP, you must:

1. Define an Insert from another dataset operation.
2. Specify the CURRENCY = ${$Entity.currency.code} clause in the Filter field.

Example

To define the PREVIOUS_SCENARIO field with the code of the previous scenario that came before the run scenario in an Enrichment with formula operation, you must specify the ${$Scenario.prev.code} syntax in the SQL formula field.

Attributes can also be used to define query type database objects in the datasource mapping, special methods and dictionaries.

Parameters for reporting

In DTP fields that support SQL formulas, it is possible to refer to reporting parameters (see ).

Note: it is possible to refer to all types of parameters (dimensional, dictionary, text, numeric, date or flag).

If a DTP uses reporting parameters, when it is run the system will ask you to select one of the values defined as the parameter's options. It is also possible to define a default value.

Dependencies between parameters can be defined in the DTP using advanced selection scripts. Only explicit dependencies are allowed.

Dependent parameters defined in the parameter definition window, Excel add-in side, can also be used within the DTP. Thus, when running a DTP with dependent parameters, the quick search combo box will only show the values that are consistent with the selected dimension.

Example

It is possible to make one or several DTP operations optional. To do this, a Flag type reporting parameter must be defined. Then, in the DTP, in the activity's Run condition field, define an activity that encompasses all optional Operations using the following syntax: ${@Parameter_code}.

At runtime, the user selects a flag to decide whether or not to define the parameter.

Reporting parameters return codes reported in inverted commas, with the exception of the syntax DATASETPARTITION(), which refers to the name of a partition. This is generally used in the FROM clause of a query to refer to the physical name of a partition.

Note: If the syntax DATASETPARTITION() is used in the FROM clause in a query and the body of the query contains parameters, and the parameters are not correctly defined when running, the system will show an incorrect query syntax warning. In this case, it is advisable to carry out checks on the correct use of the parameters.

IMPORTANT: It is not possible to use reporting parameters in the default AW parameter formula and in the Analytical workspace dictionaries. If the parameter is used in dictionary queries, it will not be displayed at runtime. If the parameter is used in an object that supports it, it can be defined on the dictionary.

Parameters defined in the DTP

Parameters defined in the DTP can identify a value or an SQL formula, which will be resolved at runtime and can be used in any DTP field that accepts SQL formulas.

For example, they can be defined to use the same DTP on different processes, basing the data processing logic on the current process. Or they can be defined to determine the filters to be applied to the data processing, or to define a certain dataset field.

Element	Description
Workspace parameters	Parameters defined at the workspace level and referred to using the syntax : @NOME_PARAMETRO@. Its value, or the SQL formula, is defined on creation. When the DTP is run, the parameter is replaced with the value that it takes on or. based on the parametrization, its value is requested at launch.
System parameters	See System parameters.
Special method parameters	Parameters defined in the special method and referred to in the SQL formula using the syntax &NOME_PARAMETRO&. The value or SQL formula with which to replace the parameters is defined on the operation, in the special method settings (see Special method).

IMPORTANT: in SQL formulas, both reporting parameters and DTP parameters can be used simultaneously. No reporting parameters can be used when defining the default formula of the AW parameters or the value to be assigned to the parameter.

IMPORTANT: When the parameter refers to a dimension not belonging to the launch context, the parameter is not automatically resolved.

For example, if the user launches a DTP or QDL with a parameter of #ENTITIES# type and the process launch phase is by analytical dimension, the parameter will not be resolved and will be left untouched.

Note: In the case of execution on the process cockpit with dimension by step, the same limitations apply as for the Loading to Analytical Workspace task.

System parameters

Predefined parameters automatically resolved when the DTP is run depending on the execution context. They can be referred to using the syntax #NOME_PARAMETRO#. There are the following system parameters:

• #USER#: user who run the data processing
• #AW_CODE#: workspace code of the DTP run in the data processing
• #PROCESS#: process code on which the data processing was run
• #ENTITIES#: list of entities for which the request to run the DTP was made (separated by commas)
• #ANALYTICAL_DIMENSIONS#: list of analytical dimensions on which DTP execution was requested, separated by commas;
• #CUSTOM_DIMENSIONS#: list of custom dimensions on which DTP execution was requested, separated by commas;
• #PERIODS#: list of periods for which the request to run the DTP was made
• #SCENARIOS#: list of scenarios for which the request to run the DTP was made
• #SCENARIOPERIODS#: scenario/period on which execution was requested (with single-submission processes, it contains the list of scenarios/periods sorted by increasing reference date)

• REFERENCE_DATE#: reference date of the scenario/period of the execution or of the business cycle in case of a single submission process

• #TARGET_PARTITION#: target dataset partition of the activity being run
• #ITERATION_VALUE#: iteration value within an activity loop
• #ITERATION_VALUE_OPERATIONS#: iteration value within an operation loop
• #AIV#: returns the n-tuple of iteration values within an activity loop. It may refer to a field (#AIV.FIELD#): the value of the FIELD field of the corresponding iteration within an activity loop is returned. It may refer to the alias (#AIV.ALIAS#)
• #OIV#: returns the n-tuple of iteration values within a loop of the operation. It may refer to a field (#OIV.FIELD#): the value of the FIELD field of the corresponding iteration within a loop of the operation is returned. You can refer to the alias (#OIV.ALIAS#)
• #PROCESS_STEP#: code of the step to which the running DTP belongs.

Note: The codes returned by system parameters are not reported in inverted commas. For the codes to be reported in inverted commas, you must specify that condition in the SQL formula that calls the parameter.