SBT Enhancements from MTA

This page cover enhancements in SBT from the Multi-Tenant Project. Since we have migrated our app running customers to MTA, we can now take advantage of all the features below.

TLDR — MTA SBT Features

  • Now, we are post MTA migration we can leverage two beneficial features

  • bundled sources (no more manual database mapping)

  • RLS parameters (no more manual mappings tables)

1. New Capabilities Unlocked by MTA

Now that we have migrated our customers to MTA, we can take advantage of new features that come with MTA. The configuration of each lives in you app’s YAML.

In order to take advantage of these features please upgrade your version of SBT to 1.0.7

Bundled Sources

To eliminate manually defined source, we now support bundling tables in your source YAML. This must be defined for each table source that you want.

To bundle sources, you simply add a bundled flag to your source YAML file. Insight Cloud then automatically inserts the correct database mapping for every table in that source, for every org. No more manual mapping. If any sources are left unbundled, the platform will only ask for unknown sources upon install.

# In your source YAML file, add:
is_bundled: true

# Example: in the below all tables are bundled, except DATASHARE_SEEK_INSIGHTS_CUSTOMERS

sources:
  - name: seek_ads
    description: "Seek Ad Data"
    database: seek
    schema: ads
    tables:
      - name: impression
        is_bundled: true
      - name: click
        is_bundled: true
  - name: seek_insights
    description: "Seek Sales Data"
    database: seek_pos
    schema: seek_insights
    tables:
      - name: DATASHARE_SEEK_INSIGHTS_CUSTOMERS
      - name: DATASHARE_SEEK_INSIGHTS_PROD_CATALOG 
        is_bundled: true

Without bundled sources

With bundled sources

For every new org install, someone manually enters the source database name in the platform.

Source database mappings are auto-inserted for every org. Zero manual work.

No automated install

When all sources are bundled, adding app access to an org auto-installs the app.

When sources are bundled, as a Seek Admin, you will see a small locked icon on the Source Mappings screen for that org.

This will display next to any mapping that was bundled and the text will be greyed out.

These mappings cannot be edited outside of changing the SBT configuration of the defined source in the Publishers source yaml.

RLS Parameters

RLS parameters allow you as an app builder to define and control how required data selections are processed in your app.

With RLS parameters, you add a parameter to your model YAML configuration. Once that app is published, the platform will enforce the parameter is defined in either a Seek Admin app provisioning workflow or during app subscription flows from the app store.

# In your source YAML file, add:
rls: true

# In your model YAML, add a variable and mark it as rls:
variables:
models:
    - name: seek_scorecard_category_summary
    config:
      variables:
        - name: DEPARTMENT
          display_name: Department
          type: array
          default: all_departments
          values_query: seek_departments
          rls: true

The parameter type determines how the selection behavior is configured and used for the parameter. The type select enables Seek Admins to grant app permissions for one parameter value (e.g. one department) to a subscriber org, while array enables permissioning multiple parameter values (e.g. several departments) for a subscriber org.

Without RLS parameters

With RLS parameters

D&A manually creates lookup tables for each org, each app, each filter. Repeats constantly.

D&A adds a new param to replace any customer filtering needs.

Manual tables must be named exactly right or the app breaks.

Data powering the param is sourced from the Publisher’s data

After publishing an app that has an RLS param configured, Seek Administrators will be able to interact with this parameter during app installation, as a required input.

Based on the configuration of the parameter (select vs. array), the dropdown can support single or multiple selections.

Alternatively, in future focused workflows, Subscribers on the app store will select their desired Data Access options during a “checkout” process. Publishers will have the ability oversee / modify Data Access on a subscription basis.