WhereScape extensions

Your architecture.
Made repeatable.

WhereScape provides the modeling and code-generation foundation. As a certified WhereScape partner, we extend its model conversion rules, templates, and runtime metadata to carry your architecture standards into the details of delivery.

These examples come from our implementation work. The architecture applies across platforms; each extension is adapted to the selected platform and source behavior.

01 / Dynamic incremental loading

Set the policy.
Generate the load behavior.

We built a metadata-driven pattern that connects source-model watermark settings to generated filters and runtime parameters, reducing repeated configuration for each load.

  1. 01 / Configure

    Defaults + overrides

    Connection settings provide the defaults. Table settings handle exceptions.

  2. 02 / Generate

    Carry the metadata

    Conversion rules produce load properties and parameterized source filters.

  3. 03 / Prepare

    Resolve the watermark

    A setup task checks load metadata and sets parameters before source loads run.

  4. 04 / Load

    Apply the chosen policy

    The generated load uses the calculated boundary and configured refresh behavior.

Source metadata remains the place to change the policy. Generated settings can then be recreated consistently, while watermark values reflect each environment's loaded data.

Four ways to calculate the boundary

The strategy follows the source's change behavior, rather than a single rule for every table.

Template

Continue from stored history

Read the maximum source watermark already held in the mapped satellite and use it to set the next load parameter.

Rolling

Revisit a recent window

Calculate a configurable time window when a reliable last-change watermark is unavailable.

Rolling template

Add a lookback to the watermark

Start from the stored maximum watermark and move the boundary back by a configured interval.

Custom

Handle a source-specific rule

In the SQL implementation, a custom T-SQL statement returns a datetime parameter when the other strategies do not fit.

The pattern also handles an empty target and a requested one-time full refresh, then returns to incremental loading. Retention limits, lookback periods, and watermark fallback columns are configured for the source.

02 / Historical backfill

Load the past.
Continue with the present.

When historical and live data describe the same source structure, we have extended the loading templates to populate one satellite from both. The initial load reads the historical source; subsequent runs switch to live incremental data.

This gives downstream models one history to consume while keeping the source-switching behavior in the templates and metadata.

  • Use the historical capture timestamp during backfill, then resume normal timestamp handling for live loads.
  • Keep that technical tracking timestamp out of the descriptive change hash.
  • Record whether each row came from the historical or live source.

This pattern requires matching historical and live schemas, a shared watermark attribute, and agreed timestamp meaning. We assess those conditions before choosing a shared satellite.

Two load modes / one satellite

Initial load

Historical source

An enabled source with an empty target triggers the backfill.

Ongoing loads

Live source

The stored watermark directs later runs to incremental loading.

Shared destination

One satellite history

Consistent structure, preserved change history, and source attribution.

The source changes with the load state. Consumers use the same satellite instead of combining a separate historical and live pair.

03 / Hub load mappings

Generate the repeatable.
Review the exceptions.

A link can introduce business keys that also need to enter their hubs. We created a model conversion template that adds the corresponding hub source mappings from the link's source, mapping business keys without descriptive attributes.

The custom logic handles straightforward relationships and identifies cases that need explicit mapping. When the same hub participates in more than one role within a link, those mappings are created explicitly and reviewed by a modeler.

Why it helps: fewer repetitive mapping steps, with a clear review point for relationships that need a modeler's judgment.

04 / Model standards & provenance

Carry meaning
through generation.

Our conversion rules and design workflows apply naming, business-key, data-type, and subject-area conventions before generation. Source metadata carries those decisions into the physical model and load configuration.

For Business Vault rule outputs, custom conversion logic carries the business-rule version into the record's provenance and validates that the required metadata is present.

Why it helps: generated objects follow agreed standards, and teams can identify which rule version produced a stored result.

Built for the team that maintains it

Make the extension
part of the delivery process.

We document the configuration, generated behavior, and exception paths. Custom template copies remain separate from vendor templates, with upstream changes reviewed when WhereScape is upgraded.

The delivery process includes reviewing generated output, validating load behavior, and helping your team maintain the patterns as requirements change.

Explore our delivery process

Extend around your requirements

What should your
automation understand?

Bring your source patterns, modeling standards, and delivery goals. We can help turn them into maintainable WhereScape extensions.

Talk about your automation