Deploying Semantic Models to production

A Semantic Model has no production location of its own: each entity references a dataset (see Create, import and manage Semantic Models), so a Semantic Model reaches production the same way as the rest of its project, through the standard bundle deployment workflow described in Production deployments and bundles.

Before deploying, validate the Semantic Model’s accuracy with Testing Semantic Models.

Parameterizing the underlying datasets

To let the same Semantic Model run against different databases or schemas on the Design and Automation nodes, replace the hardcoded values in the entities’ underlying datasets with variables (for example ${sf_database} and ${sf_schema}), using the standard variables expansion mechanism. On a SQL dataset, this is set in the dataset’s Settings, under its connection parameters.

Choosing where the variables are defined

• Project variables, defined in the project’s Settings > Variables, can be overridden per deployment in the Project Deployer (see below).

• Instance variables, defined by an administrator in Administration > Settings > Variables, are node-specific: the Design node and each Automation node keep their own values. Defining sf_database and sf_schema as instance variables on each node, pointing to that node’s own storage, removes the need to set variables again at deployment time.

Building and publishing the bundle

Create a bundle of the project on the Design node, then publish it to the Project Deployer, as described in deploying-bundles.

If an entity references a dataset shared from another project, that upstream project’s bundle must be published and activated before this one, otherwise updates to the shared dataset will not be reflected in the Semantic Model.

Deploying on the Automation node

From the Project Deployer, deploy the bundle to an Automation node infrastructure, then activate the deployment. Two settings determine which database and schema the Semantic Model resolves to in production:

• Connection remapping, configured on the infrastructure or overridden on the deployment, points a connection used on the Design node (for example db-sql) to a differently-named connection on the Automation node.

• Project variables, set from the deployment’s Settings tab, override the values of ${sf_database} and ${sf_schema} for that deployment.

If sf_database and sf_schema are defined as instance variables on the Automation node (see above), this step can be skipped: the values already resolve correctly once the bundle is activated.

See deploying-bundles for the full deployment and activation workflow.