Module 4 — Loading and resource definition groups

A resource definition group holds the .hdv files on its Data Vault models tab, the .hbv files on its Business Vault models tab, and the .hdm files on its Dimensional models tab, plus a Default catalog connection — the FILE catalog used when harvest, validate, tag, and the group update do not override it.

The group is not a folder of catalog record definitions. Source feeds live in the catalog, and the group points at the model files that use them; putting catalog JSON paths in a model tab is an anti-pattern.

Create the group as soon as the first .hdv checks clean and leave the Business Vault and dimensional tabs empty. Actions that take the group as their scope include Harvest source metadata (harvests every catalog source referenced by the listed models), Validate resource definitions (the schema gate), Update resource definition group (the load), Tag catalog version / List catalog versions, and the lineage and architecture exporters.

Update resource definition group is the normal load action once you have a group — including a group that lists only one .hdv. Every model runs through the same update path as the dedicated Data Vault Update / Business Vault Update / Dimensional Update actions: model check options, DDL policy, parallel pipeline copies, and optional catalog publish.

A standalone Data Vault Update action points at one .hdv file. It stays useful for debugging a single model, and Begin/End Vault Update remain the advanced way to bracket a custom per-model graph. For a standard multi-layer load, the group action is the shortest correct path.

One behavioural difference to remember: if a listed .hdv uses a read-only existing vault configuration, the group action skips that Data Vault job (and logs it) so Business Vault and dimensional updates still run — a standalone Data Vault Update pointed at the same file fails instead.

The group update always loads all Data Vault models first, then all Business Vault models, then all dimensional models. Within a layer, the order is the list order of that tab. You cannot interleave layers by shuffling the three lists; the action’s Selection tab only turns whole layers on or off (Include Data Vault models, Include Business Vault models, Include dimensional models).

With Publish target tables to catalog enabled, each successful model write in the wave upserts:

That is why a group update changes the Data Catalog even though you never edited a source feed: the action publishes targets. Your source feeds stay as they are.

While the action runs it paints a badge in its bottom-right corner — a clock, a stall warning when no transform has made progress for about a minute, or a failure. Click the badge (or use View load metrics on the action’s context menu) to open Resource group load metrics: This run lists every model in the wave with the current table, elapsed time, and live metrics; History lists recent OPS load overviews.

For per-pipeline detail: every model in the wave runs through the same update path as a dedicated update action, including the orchestrator pipeline that stages and picks up the generated update pipelines. To see which staged pipelines are being picked up and how many executor copies are busy, click a running update and choose Open execution.

Options that shape the wave: Update target database structure (execute CREATE/ALTER DDL before loading), Fail if DDL is needed (the production guard — fail instead of altering), and Do not update target database (dry run: checks and DDL handling only, no data pipelines). On the Metrics tab, Manage vault update metrics (Begin/End) assigns DV_WORKFLOW_EXECUTION_ID before the models run and publishes the workflow load overview at the end; Markdown and/or HTML reports land in the report folder (retail default: work/reports).