Publishing content to Orgs

Publishing content to Orgs

The publishing feature Beta enables administrators to efficiently manage and distribute ThoughtSpot metadata objects across multiple Orgs within a multi-tenant instance.

Unlike the deployment method that relies on TML import and Git integration, publishing allows administrators to create an object in the Primary Org and publish it directly to target Orgs without generating duplicate copies. It also allows dynamic customization of the underlying Table or Connection properties using variables.

Starting with the 10.10.0.cl release, ThoughtSpot provides a set of REST APIs for administrators to create and assign variables, parameterize object properties, and publish objects from the Primary Org to other Orgs on their instances.

Important

The publishing feature—including the REST APIs for variable creation and update, metadata parameterization, and publishing content across Orgs—is in beta and turned off by default on ThoughtSpot instances. To enable this feature on your instance, contact ThoughtSpot Support.

When to use publishing feature🔗

ThoughtSpot recommends using the publishing feature if you have a multi-tenant ThoughtSpot instance with Orgs and your deployment requires the same metadata objects across different tenant Orgs.

Currently, ThoughtSpot allows publishing content to different instances or Orgs via TML import and Git integration. The Publishing feature automates some of these procedures and simplifies content propagation for large-scale deployments.

The following table lists the key differences and use cases for both these methods.

Publishing featureTML Import/Git-based Deployment and publishing

Recommended for multi-tenant instances requiring standardized and re-usable content

If a tenant Org requires unique customizations that cannot be handled by variables, use TML-based deployment to create and maintain a separate object for that Org.

Allows publishing content from the Primary Org to different Orgs within an instance

Allows publishing content to Orgs within a ThoughtSpot instance, or from one ThoughtSpot instance to another

Maintains a single source of the object and publishes content to Orgs without creating a duplicate object

Creates a separate copy per Org / per instance and can result in a higher memory usage.

Allows customizing data properties with variables

Creates new copies per Org or instance and thus allows full customization of objects.

No change to metadata object IDs and references. Hence, GUID mapping is not required.

Requires GUID mapping.

Parameters and variables🔗

The Connection and Table objects required for building analytics content can vary between data environments. To customize Connection and Table properties for each Org, you can use variables and parameterize object properties.

You can create the following types of variables using the variable API and use them to parameterize Connection or Table properties either through the metadata parameterization API or by directly updating the TML for the Connection or Table. This approach ensures that the published metadata objects dynamically adapt to the configuration of each Org without the need for creating a copy of the object.

Variable typeDescription

TABLE_MAPPING

The TABLE_MAPPING variable allow parameterizing the following Table properties:

databaseName schemaName ** tableName

CONNECTION_PROPERTY

The CONNECTION_PROPERTY variables allow parameterizing connection properties. For example, accountName, warehouse, user, password, role and so on.

CONNECTION_PROPERTY_PER_PRINCIPLE

Note
 This feature is disabled by default. To enable this option, contact ThoughtSpot Support.

This variable supports modifying connection properties per principal (user or user group). This means you can set different values for connection properties depending on the user or group accessing the connection. For example, warehouse, role, user, password.

The CONNECTION_PROPERTY_PER_PRINCIPLE variable does not allow parameterizing core connection properties such as accountName, host, or port. These properties must be derived from the connection configuration and cannot be set per user or user group.

The following figure illustrates variable substitution in Connections and Tables:

Variables

Version control🔗

For the objects in the Primary Org, you can use the Git integration APIs for development, change tracking, and version control. However, Git integration for the objects published in the target Orgs is not supported.

User access to objects🔗

ThoughtSpot administrator with access to all Orgs can publish content from the Primary Org to other Orgs on a ThoughtSpot instance. The administrators will also require edit access to the object and the underlying data source in the Primary Org.

The visibility of a published object in an Org depends on its sharing settings. Org administrators can view the objects published in their Org and grant view access to other users in their Org by sharing the object.

Limitations🔗

Note the following feature limitations in the beta version:

  • Only ThoughtSpot administrators with access to all Orgs can publish objects.

  • Objects can be published only from the Primary Org to other Orgs.

  • In the target Orgs, published objects are available in read-only mode. The original object in the Primary Org remains editable by the cluster administrator and users with edit permissions.

  • Spotter functionality is not supported for published objects.

  • Search data indexing is disabled for published tables.

  • Git integration is not supported for published objects.

Note

ThoughtSpot is actively working on enhancements to support critical features and key user scenarios. Some of these existing limitations will be addressed in upcoming releases.

Publishing workflow🔗

The content publishing process with the new publishing method involves the following steps:

  1. Step 1: Create a master object
    This step involves building Answers and Liveboard from a Model or data object in Primary Org. Ensure that the object references Tables or Connections that can be parameterized with variables. Note that parameterizing default system tables is not supported.

  2. Step 2: Define variables
    Create a variable for each Org using the /api/rest/2.0/template/variables/create API endpoint. For example, you can create a variable for table attributes, such as schema, database, or table name, and assign the variable to the relevant table properties using the metadata parameterization API endpoint. When you publish the object, the object properties with the variables are dynamically assigned appropriate values configured for the Org.

  3. Step 3: Parameterize metadata objects
    Replace the static values of object properties with variables created from the previous step. You can use the /api/rest/2.0/metadata/parameterize API endpoint or directly edit the TML to assign variables to the relevant properties. This step is required to enable the use of the same metadata object across different Orgs, with the actual values being supplied at runtime for each Org.

  4. Step 4: Publish the objects
    Publish the objects from the source Org (Primary Org) to target Orgs using the publish metadata API (/api/rest/2.0/security/metadata/publish).

  5. Step 5: Verify published objects
    After publishing an object, verify the published object and the associated TML object in each Org to ensure that the variables are correctly substituted with the appropriate values for that Org.

    Try updating the original object in the Primary Org and verify whether the published objects in the target Orgs are updated accordingly.

The following figure provides a visual representation of the publishing workflow:

Publishing process