Parameters in Production

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. See Creating Script-Level Parameters.
  • 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. See Script Configurations.
  • Node—Create in the attributes pane of any nodes that accept parameters. These parameters are only available for the node where they are created. See specific node topics in the Process Nodes and Control Nodes folders in the Help table of contents.
  • 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. See Parameter Process Node.

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.

  • 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 Year in a Production script matches a parameter year in an Integrator script.
  • In general, the panels where parameters are defined support sorting—click the column heading in the grid to do so.
  • 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 7.0(54) only sets lowercase versions of environment variables. Starting with 7.0(54), Production Service on Linux preserves case in environment variables but also sets lowercase versions to maintain compatibility with any scripts that might rely on the prior behavior.

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 runs in disconnected mode, 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.
_<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, this parameter specifies the username. If the script is called by another script, 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.

Mentioned in: