Parameters

A parameter is a value a pipeline asks for when it runs. You type ${name} wherever it should land; the person running it, a schedule or a Flow step supplies the value.

Declaring a parameter

Open the pipeline's Parameters dialog and give each one a name, a type and a default. The types are the column types Trinium uses everywhere. Two rules keep them safe:

• Every parameter has a default. It is what the builder uses to show columns while ${name} is still in a query, and what Run to here runs with.
• A text parameter is a list of choices. Whoever runs the pipeline picks one of the values you declared, so a parameter can never carry text you did not allow into a query.

Using it

Type ${name} into any node's settings: a source's query, a filter, an output path, a pre-SQL statement, an email subject. One value can land in several nodes, so a region used in the query and in the output path can never disagree. A connection cannot be chosen by a parameter.

Once a pipeline declares a parameter, a ${…} it does not declare stops the run by name, rather than reaching a database or a file name as literal text.

Supplying values

• Run asks for each value, filled with its default.
• A schedule stores the values it runs with.
• A Flow step passes exactly the values written on it.

A date value supplied by a schedule or a Flow step, or a date parameter's default, can be relative, such as ${date-1}, read from the moment the run was queued.

Built-in tokens

These need no declaration and fill themselves in on every run:

They work in every setting except a REST request's address, body and headers, where ${name} means the row's column of that name.

One pipeline, many sources

A text parameter runs one pipeline against another region, customer or folder. Put ${region} in the input's folder or query and in the output's path or table, then give each value its own schedule or Flow step. A fix to the logic reaches every value at the next deploy. Each value keeps its own bookmark, and its runs, notifications and log lines say which value they ran with.

Clone the pipeline when the difference cannot be typed into a setting: another connection, or a choice from a list such as a write mode. A clone is a separate pipeline with its own versions, deploys, schedules and bookmarks. It starts with no bookmark, so a clone that appends to the original's output loads those rows again. A fix to one clone reaches no other.

When runs overlap

Two Live runs of a pipeline in one environment may overlap only when a text parameter they both use has different values. Such runs queue, take turns on one server and run side by side on several.

Runs with the same text values never overlap, even when a date or a number differs, because they share one bookmark. The later start is refused or waits, as Schedules, Flows and the Run API each describe. To backfill two dates, run them one after the other in a Flow.

Runs side by side share whatever you point them both at, so a pipeline is designed with that in mind:

• A fixed output table or file. An append collects both values, and a write that empties the target first keeps only the last. Put ${region} in the name, or upsert on a key.
• A staging table emptied by pre-SQL. One value can empty it while the other is loading. Put ${region} in the table's name.
• A folder a File Action moves or deletes from. The first value to finish leaves nothing for the next. File Action's help shows three ways to lay this out.
• Two text parameters. Each is chosen on its own, so nothing stops region = EU running with folder = us/. Use one parameter in both places.

Parameters and bookmarks

When a pipeline uses a text parameter, each value keeps its own bookmark, so a run for region = EU never moves the bookmark of region = US. Number, true/false and date parameters do not split a bookmark.

Who may do what

Declaring parameters needs the right to edit the pipeline. Supplying values needs only the right to run it. The values a run was given are recorded with it.