Parameters are a pasUnity construct similar to variables in a programming language. The purpose is to be able to persist values that would otherwise be transient between job steps.

To keep things simple all parameters are essentially string-based key/value pairs. The names are case-insensitive to keep things easy and avoid mistakes. They are created on first reference (whether read or write) and persist until job execution is complete at which point they go out of scope and are lost.

Parameters can make use of a very rich macro expression language and special tokens that are exposed by the job, impellers, and job steps.

You access the values of parameters using the <Parameter> macro syntax. You can write macro expressions and test them using the Macro Designer which can be activated by pressing F2.

Precedence

Parameters can be created at the job, impeller, or job step levels. Job parameters are scoped at the highest level and are available to all impellers and job steps. Impellers can add new parameters of their own or override those defined at the job level. This allows a single job definition to perform an unlimited number of work permutations. All Job and Impeller scoped parameters are resolved prior to the execution of the first job step.

Editing

The parameter editor will expose a varying level of detail and features depending on the level that the parameter is scoped. At the Job and Remote Impeller levels the editor expose a number of advanced attributes that can be used to construct user interfaces, validate input, dictate user interface elements, and provide dynamically sourced values, In all other locations only basic name/value pair options are exposed.

Parameter Grid

•Name: This is the unique name of a parameter. If a parameter with the same name was defined at a higher scope it will be replaced during job execution with the current definition. Macro expressions may be used.

•Value: This is the value of the parameter. Macro expressions may be used.

•Hidden: Available only at the Job and Remote Impeller scopes this is used to determine whether the parameters are exposed via the user interfaces to collect initial values from a user or override a default value. No parameters marked as hidden at either the job or impeller level are ever exposed to the users.

Parameter Editor Panel:

The Parameter Editor appears upon selection of a Parameter row, after a Parameter Name and Value have been entered.

•Option Source: Allows the designer to determine if a range of values will be presented to the user for selection in a user interface prior to job execution. When Static is selected the designer can provide a hard-coded list of values for the user to select from. When Dynamic is selected the values presented to the user are sourced from a SQL statement against a database.

•Dynamic: Dynamic mode will prompt the user to provide Connection String details for a SQL Server, ODBC, or OLEDB data source. Additionally, they will need to provide a SQL script and determine whether macros are applied. When processing the results only the first column of each result set returned will be aggregated and duplicate values removed prior to results being presented to the user.

•Static: The designer enters a set of hard-coded values into the data table.

•Input Type: This determines the type of control that will be presented to the end user in a user interface. The types of control vary based on the option source. For example only radio buttons, drop down lists, and multiple select lists are available when the option source is set to Dynamic or Static but a wide variety of editor controls such as check boxes and spinners are available when the option source is None. The default is Text when option source is None and DropDown for other modes.

•Input Validation Expression: This is an optional regular expression that is applied at the user interface to ensure that the user is providing valid values. If the expression fails to validate the user input an error message is displayed and no work can be enqueued until the value is corrected and the input validation expression yields a match. To learn more consult the regular expressions topic. You can also press F3 and launch the Regular Expression designer to build and test your expressions.

•Resolved Validation Expression: This is an optional regular expression that is applied within the application to ensure that end-user input (which may have contained macro expressions) truly is valid after macro parsing occurs. This can be used to prevent injection attacks against the product by providing an additional level of input sanitation. To learn more consult the regular expressions topic. You can also press F3 and launch the Regular Expression designer to build and test your expressions.

Send comments on this topic.