Parameters allow flexibility in replacing attribute values within Production scripts. Parameters are also used under the covers to communicate between the server and clients, for example DiveLine and Production, DiveLine and DivePort, and Production and DivePort.
You can define parameters so that they are available at the following levels:
- Entire script—Create in the Overview pane of the script. These parameters are available to all nodes that accept parameters in all branches.
- Script Configurations—Create in the Overview pane of the script using different configurations. These parameters are available as run-time configuration parameters and can be set both manually as you run and test a script as well as on scheduled jobs.
- Node—Create in the attributes pane of any nodes that accept parameters. These parameters are only available for the node where they are created.
- Branch—Create using the Parameter process node. These parameters are available from this node and downstream in the branch in which they appear, and in any child branches.
Production Scripts that run from DivePort automatically have access to certain Portal parameters such as QuickViews. For example, Sales Region=North becomes a parameter $(_Sales Region) with the value North. Multi-valued parameters from DivePort are not loaded directly into the parameter system, but are written to a flat file in the Production logs.
Parameters can be defined on many levels. When a Production script executes, the parameter merge order is:
-
Script-level parameters such as "Warehouse"
- Solution parameters such as "_diveline_dataroot"
- DivePort QuickView parameters such as "_Sales Region"
- DivePort run-time parameters such as "_USER"
-
Parameter node parameters such as "Year"
In the merge order list, at a given level, a parameter can reference any parameter that is earlier in the list. For example, Parameter nodes can override or reference any values in this list. Parameter node parameters are never overridden, while script level parameters are overridden by any values passed into the script, either when called by another Production script, by DivePort, or from the UI.
This is also the order that a parameter is prioritized over another parameter with the same name. A Parameter node parameter named _USER is prioritized over the run-time parameter _USER.
NOTES
-
When using Production nodes, any parameters and values defined in the Production node's parameters section, override parameters of the same name in the target script, including the target script's Configuration parameters.
- Array parameters cannot be defined directly in a Production parameter grid in Workbench. To work with an array of values, specify an external flat file to read or write the parameters. Using a flat file is how DivePort passes multiple values to a Production script.
- When parameters are retrieved, they are treated in a case insensitive manner. That is, a parameter named “Year” in a Production script matches a parameter name “year” in an Integrator Script.
- In general, the panels where parameters are defined support sorting—click the column heading in the grid.
- When dealing with separate Development, Test, and Production environments, consider using a parameter-file that is in the same relative position in your Development, Test, and Production projects. Controlling values can be set once, as appropriate, and not impact testing. For example, you can set a parameter with the full path used to run commands in each environment.
-
When Production launches Integrator or Builder, it sets environment variables: DI_INTEG and DI_BUILDER, whose values are the paths to those two executable files. These environment variables do not overwrite existing DI_INTEG or DI_BUILDER variables as set by parameter nodes, so users can override this behavior.
-
On Windows, environment variables are case insensitive, while on Linux they are case sensitive. Production Service on Linux before
Automatic Global Parameters
Production has access to a series of global solution parameters that start with an underscore character.
| Parameter | Purpose |
|---|---|
| _diveline_dataroot | The data root for the current DiveLine connection. |
| _diveline_machine_name | The machine name of the computer running the Production script. |
| _diveline_port | The port of the DiveLine running the Production script, if not running in disconnected mode. If the script is run in disconnected mode, then this parameter is not defined. |
| _extension_directory | The globally unique identifier of the Extension. Only Production scripts used as Extensions have access to this parameter. If the parameter is used to set a path, it is translated into the system location for the Extension, that is the DiveLine path, so the Extension has access to this space on disk. |
| _<QuickView Name> | The name of the QuickView passed by the DivePort page to the Production script. This parameter is only valid if DivePort launches the script. |
| _run_configuration | The run configuration set for the Production script. See Script Configurations |
| _started_by |
The name of whoever started the script. If the script is manually started, then this parameter specifies the username. If the script is called by another script, then this parameter specifies the path to the calling script. |
| _user | The username of the DivePort user who triggers the Production script. This parameter is only valid if DivePort launches the script. |