Best Practices for OEMs

This is a list of best practices for OEMs when managing their Sisense data models and dashboards.

Considerations

Before starting a project to deliver Sisense dashboards to your customers as an OEM, take into account the following considerations:

  • Is time-to-market important for you?
    If you are on a tight schedule, instead of embedding dashboards, consider white-labelling your content. The process is quicker, although you have fewer options than when you embed content. For more information about white labelling, see White Labeling Sisense.

  • Which type of embedding should you use?
    There are three methods for embedding your dashboards: iFrame, Sisense SDK, SisenseJS. Before beginning, determine which method suits your needs best. For more information, see the OEM Embedding Options section of Embedding, White Labeling, and Rebranding OEMs.

  • If you are embedding Sisense dashboards, you will have to use Single Sign On (SSO). SSO is used to automatically authenticate users to Sisense . There are different SSO options that Sisense supports, so become familiar with them. For more information about SSO, see Using SSO to Access Sisense.

  • Sisense only supports one type of SSO per environment. Therefore, if your customers are using different SSO mechanisms, you might need developer support to assist you with managing authentication to your environment.

  • What architecture are you going to need to support your use-case?
    The system architecture you choose is critical to how you deploy to your customers: single-tenant, multi-tenant, hybrid, or cloud. Within the multi-tenancy option, you can decide whether there will be one instance per tenant or shared ElastiCubes with row-based data security. For more information, see OEM Architecture.

  • Which type of data models will you use?
    Will you have one ElastiCube per-customer? This enables you to import data on different schedules per-customer. It also introduces more pods into the system, which also has some limitations. This configuration comes with its own manageability and maintenance issues. Alternatively, will you have a single ElastiCube that aggregates all customer data and uses data security to ensure each customer can only access their data? This option enables you to do cross-customer analysis (if you have permission to do so). This decision also depends on whether all your customers use the same schema, or not.

  • How will you introduce new tenants?
    Consider the schema will your new tenants be using. If they will be using the same schema, will you use automation and a schema template to add new tenants?

  • Will you give your customers Data Designer or Viewer permissions?

  • It could be risky to provide Data Designer permissions to your customers. Consider a scenario where one of your customer's users has Data Designer permissions and causes damage to your environment. How will you mitigate that damage? How could that damage affect the rest of your customers or your business? If your customers do require Data Designer permissions, configure the settings appropriately. For example, make sure they cannot consume too many resources. This consideration needs to be thought about carefully.

  • Will you need development support?
    You can automate a lot of actions using Sisense APIs. Doing so enables you to scale-up fast so that you can quickly and easily support more and more customers. For more information, see Automation and Scaling for OEMs.

Data Source Types

In many cases, the best practice is to use Live models because they provide the most flexibility, are scalable, and are generally more forgiving than ElastiCube s. The decision to use Live models depends on your customers' data sources. OEM customers need to have high performing databases, such as Redshift, Snowflake, or BigQuery.

Resource Governance

Assuming that you are using ElastiCube s in multi-tenancy deployments, it is preferable to use data groups. This allows you to set limits, such as many-to-many relationships and memory usage. You should also segregate different use-cases by data groups. Also, it is critical to make sure that safe-mode configuration is enabled.

Version Control

Properly managing versions of your Sisense assets, such as dashboards, data models, configurations, and add-ons, is a very important best practice. Sisense offers various ways to achieve this:

  • Programmatic Version Control (REST APIs)
  • UI-based Version Control

For more information about this, see Version Control for OEMs.

Backups

As part of regular maintenance or before making significant changes to your deployment, you should back up Sisense . You can easily back up your Data Models, the Sisense Web Application, and any custom add-ons that you are using. Because your metadata can change frequently, Sisense recommends backing up your application database regularly. You can even run scripts to schedule periodic backups of your application database.

During backupm Sisense creates a tarball, which is an archive of your Sisense configuration, stored in a .tar file. You can then restore it when needed.

For information about backing up Sisense, see Backing up and Restoring Sisense.

Product Development Life Cycle

The Product Development Life Cycle is a process flow that helps you to quickly develop products that are production-ready, while maintaining high standards of quality.

Typically, the Product Development Life Cycle for Sisense OEMs comprises the following stages:

  1. Development: Creating your Sisense dashboards, widgets, filters, permissions, unique branding, and so on.

  2. Staging: Adding your Sisense dashboards to a staging platform to make sure they embed properly in your website (or other target environment) and that they look the way you expect them to.

  3. QA: Testing your Sisense dashboards and widgets to make sure they show the correct data in the way you want it, to check that the security measures are properly configured, and so on.

  4. Production: Deploying your Sisense dashboards to your customers and users.