Skip to content

Workbench Input

When your quotes are keyed in through the project's workbench, its schema already defines the quote's tables. The Workbench Input is the pipeline's entry point for those quotes: its tables are the workbench's input tables, read from the workbench's files wherever the pipeline runs, so they change as you save the schema.

When to use

While the project's workbench is enabled in haute.toml ([workbench] enabled = true, which haute init --workbench writes), the palette offers the Workbench Input in place of the Quote Input. Use it as the entry point for live pricing of keyed-in quotes. Without a workbench, use the Quote Input and build its tables from a sample file.

A Workbench Input has no inputs. Each table of the workbench's schema that has inputs is a separate output, named by the table's name with _input (ce_equipment_input), holding the table's inputs; connect each output to the node that uses it. A pipeline has only one Quote Input or Workbench Input: once it has either, the palette entry is greyed out with "Only one Quote Input or Workbench Input allowed per pipeline". Enabling or disabling the workbench changes only what the palette offers; to swap a Quote Input for a Workbench Input, delete it and drag in the other.

The panel has no tabs. A banner at the top reads "This node receives live API requests at deploy time", and a note under it says what previews run on: "Previews run on the workbench's sample values, read as a request is: a table with many rows and nothing typed has none." once the workbench supplies a sample, and "Previews run on one row of nulls per table until the workbench supplies values." until then.

The node reads no data file. While you build, it runs on the workbench's sample quote: the values typed into the workbench's Tables and Collections in its Preview, saved or not, so a value you type there shows in the pipeline's previews when you switch back to Pricing, with no save. Once you have opened the Workbench, the editor sends the sample it holds with each preview, trace and data panel (a Rating Step's levels, Banding's statistics, Explore, the cache report); until then, the sample is read from the workbench's files (The workbench's files) for each preview, so a change to the files reaches the next one. Back in Pricing, the preview on screen runs again when the sample has changed; in manual calculation it is marked out of date until you press Refresh. Only the sample is live: the tables, their columns and the sheets' Show when rules are the saved ones, so a table or column you have added or renamed but not saved isn't in the pipeline yet, and values typed under it read as nothing typed until you save. Everything else reads the sample as saved: writing a Data Output, training a model, running an optimiser, the Assistant, test quotes, haute run, deploy and the app's build. Each table is the sample's rows for it, with the types the workbench declares, read as a request is read: a table with one row per quote that you typed nothing into is one row whose values are all null, and a table with many rows and nothing typed has no rows, as it has in a request. Before anything is typed at all, every table is one row of nulls. Nodes downstream run on those rows, so a preview shows every node's values as the sample gives them. A node that can't take a null fails on a null as it would on any: a Rating Step table whose factor is null finds no entry, so with an empty DEFAULT and ON MISS on Stop the run it stops with a RatingTableMissError. A value that doesn't fit its column, such as text in a number column, stops the previews with "The workbench's sample does not fit this Workbench Input's tables: ...": correct it in the workbench, and save it so that runs reading the saved sample take it too. A live request holds one quote the same way, each table under its name (an object for a table with one row per quote, a list of objects for one with many), and is read into the tables the same way; it never uses the sample.

Every table but quote_details leads with the quote's quote_reference and quote_option. A request names them in its quote_details and nowhere else, and the node puts them on every row of the other tables; a request without them, or giving them in another table, is refused naming the spot ("quote_details.quote_reference is None: the request names the quote's reference, a text"), and one with no quote_details at all is told what to add. The sample is read as quote PREVIEW, option 1. The other columns of quote_details a request may leave out, the ones the underwriter app sets among them (its stage and who made and last changed the quote), which are then null. To join the tables, see Joining the schema's tables.

TABLES FROM THE WORKBENCH

The section lists the workbench's tables that have inputs, each holding its inputs. You can't edit them here:

Shown What it means
The table's name with _input The output's name, and the input name downstream nodes see.
one per quote or many per quote Whether a quote has one row of the table or a list of them.
Its columns Each column's name and type.
A warning under the name The name can't be an output: it isn't an identifier, it's a Python keyword, or another table has it. Rename the table in the workbench.
No columns yet, so no port. The table has no inputs, so there is nothing to read into it. Add its inputs in the workbench.

The tables are the workbench's schema, edited in the Workbench view: Edit in Workbench in this section opens it, and the switcher at the bottom of the node palette brings you back to Pricing. When you save (Save, or Ctrl+S, from either view), the workbench's files are saved first, the editor fetches the tables again and the node's outputs follow, then the pipeline is saved. The editor fetches them too when the workbench's files change on disk, by hand or with a branch switch. Connections follow table names: a connection to a table that keeps its name stays, and one to a table that was renamed or removed is removed, with a message; an undo never brings it back. Schema changes not yet saved in the Workbench are priced on the Workbench's own sheets but don't reach the pipeline until saved; the sample reaches it at once (above). A Workbench Input inside a submodel takes the same tables.

A Workbench Input needs the project's workbench: in a project whose workbench is not enabled, its previews and runs stop with "The Workbench Input reads its tables from the project's workbench, which haute.toml does not enable."

In the pipeline file

A pipeline holds one Workbench Input, so the node is always named workbench_input, and it has no rename.

The node's decorator in the pipeline's .py file names its JSON sidecar, @pipeline.workbench_input(config="config/workbench_input/workbench_input.json"), which holds none of its tables: they and the sample are the workbench's files, the pipeline folder's workbench/, which the pipeline reads wherever it runs from its source, in the editor, in haute run and in its own run().

Setting in the editor Stored as
The tables the workbench's files, a table each in workbench/schema/, never the sidecar
The sample the workbench's files, a table's rows each in workbench/sample/, never the sidecar

A sidecar holding tables or sample, as one an earlier Haute wrote holds copies of them, is refused naming them ("workbenchInput config contains the removed tables and sample fields."); open the pipeline in the editor and repair the node, or delete the two keys.

The pipeline reads a request, and its previews and run() the sample, into one dataframe per table. haute deploy and haute app build read the workbench's files once and carry the tables in what they build, never the sample. Deploying takes the request's shape from the tables too, so it needs no sample file, and never reads sample: it checks the pipeline on one quote with nothing filled in, one row of nulls per table under the reference PREVIEW and option 1, so a node that can't take a null stops the deploy as it stops a preview of a table with no values. A served request is read from the records as they were sent, so a value that doesn't fit answers the request with a 422 naming it, and a quote may leave a table out. On Databricks, the model's signature lists each table as an object, or a list of objects, of any values: the node reads the request's tables and columns itself, so a column the tables don't name is left unread there as it is everywhere else.

Every key the config may hold:

Key Type Description
input_mapping map of text to text The input names the node's code uses, each mapped to the connected input it reads.
contract "opaque" or object The node's column contract as its decorator declares it: "opaque", or the columns it reads and produces.
selected_columns list of text The columns the node passes downstream, chosen on its Columns tab; absent passes all.
column_renames map of text to text New names for columns passed downstream, from each column's name to its new one.

See also: