/
Denodo User Guide

Denodo User Guide

Owned by Matthew Girard
Last updated: Jan 23, 2025
25 min read

Introduction

Denodo is a Data Virtualization platform that allows us to provide a single interface to all of the data spread across the university.  

Denodo-8-0-architecture.png
Data Virtualization Diagram

 

The benefits of the Denodo platform are as follows: 

  • An abstraction layer across all enterprise data assets - a single pane of glass. 

  • Virtualized data access capabilities. 

  • Semantic modeling capabilities reveal the relationship between entities and makes the data easier to understand. 

  • An excellent user experience. 

  • Smart query capabilities. 

  • Seamless security and governance. 

  • A Cloud ready, data services layer. 

Those unfamiliar with Denodo or Data Virtualization can get an overview of both here. 

Users of Denodo can be divided into two groups, General Users and Developers depending on use case and skill level. If you’re only seeking to consume data then you'd be considered a General User. If you’re looking to create views of your own, and you have the appropriate skillset, you can be considered a Developer. There are sections of this guide dedicated to each of these users. While the General Users section contains information relevant to all Denodo users, the Developers section is only relevant to developers.

While this guide is sufficient to help you get started, there’s a lot of additional information available in Denodo’s documentation which we highly encourage everyone to read and have bookmarked.

The Denodo documentation is available here: Virtual DataPort Administration Guide — Virtual DataPort Administration Guide 8.0

Sections of this guide may reference specific parts of the documentation.

If you have a request or need assistance, please email data-virtualization@tufts.edu.

Data Journey Tips 

  • Know the question you’re trying to answer or the problem you’re trying to solve ahead of time.

  • Those looking to have something implemented, but who don’t possess the necessary development skills, can work with the Data Strategy team to perform the implementation, so long as adequate requirements are provided.

  • When working with Data Strategy, allow them to craft the appropriate solution based on the above.

General Users 

This section is dedicated to general read users and knowledge relevant to all Denodo users.

Onboarding Steps 

  1. Data needs determined 

  2. Added to appropriate AD groups

  3. Joined Denodo Teams channel

Connecting to Denodo

This section outlines all of Denodo’s services and ways to connect to them.

You must be connected to the VPN or Tufts_Secure to access Denodo.

Environments

Our Denodo architecture consists of the following environments:

  • Development: All development takes place here. All other environments are read-only and can only have their code updated through deployments. ***No enterprise or production reporting can connect to the Dev environment.

  • Stage: Used for testing code before deploying to Production.

  • Production: Stable, high-performance environment for end users.

Data Catalog

URLs

The Data Catalog is an interactive tool that allows users to explore all of the data available in Denodo and see relevant meta data.

To connect to the Data Catalog, navigate to one of the above URLs (most users will want to use Production).

When presented with the following screen, click Single Sign-On, which will direct you through the standard Tufts login process.

Data Catalog Sign-in Screen

Once signed in, you’ll be presented with the following landing page.

To get familiar with the Data Catalog, we encourage you to check out the following resources:

Virtual Data Port (VDP)

URLs

Ports

  • JDBC: 9999

  • ODBC: 9996

Driver

https://tufts.box.com/s/xjg66jukqt9vln5g6552x8kky0tp0d06

The VDP is Denodo’s primary data service for querying data. There are many ways to connect to the VDP, some of which are outlined below.

Tableau

To connect to Denodo with Tableau, you’ll want to use/install the Denodo JDBC connector (called Denodo JDBC by Denodo Technologies). The install guide is linked below. The driver is linked above.

Install Guide

Once you have the connector installed, click on the connector and fill in the following:

  • Server (use one of the VDP URLs above)

  • Database (VDB you want to connect to)

  • Port (9999),

  • Check Require SSL

  • Enter your Username and Password. These can be your Tufts credentials or a service account.

For development work, you should use the development VDP server. For local or deployed production workbooks you should use the production VDP server.

Tableau and Denodo Best Practices

Known Issues
Denodo Connection Times Out

Issue

A error saying “Unable to complete action” claiming there is a “Bad Connection”. This appears 5-10 minutes after connecting to/refreshing a Denodo data source.

Cause

Tableau connector for Denodo doesn’t keep connection alive and doesn’t reconnect after the connection closes.

Solution

  1. If Live connection is a must, click Refresh in the Data Source tab.

  2. If Extract is accpetable, set connection to Extract. If encountering error while creating/refreshing an extract, refresh the Data Source.

 

DBeaver

Updating the Driver

Download the driver linked above

In dBeaver, go to the Database Manager and select Driver Manager.

Find the Denodo driver and then go to the Libraries tab.  Delete the driver entry that is there and then Add File.  Point to the location of the driver - (eg. <Denodo Home Directory>/tools/client-drivers)

In the settings tab, ensure that the fields match the screenshot below

 

Creating a Connection

Once that is done, add a Database connection as such.

Use the Virtual Data Port URL’s laid out above.

 

 

Enabling SSL Connectivity

You need to configure DBeaver to connect using SSL. You can accomplish this by updating the Driver Properties of a Denodo connection in DBeaver.

 

 

Python

How to connect to Denodo in Python

Dealing with Firewalls

If you like to connect to Denodo from a system other than your local machine, like a service on-prem or in the cloud, you’ll need to submit a firewall request to noc@tufts.edu. You can use this template when making you request:

Hello, Please update the firewall to allow the following bi-directional traffic: Source Hostname and IP of your system Destination Group_Denodo_TSS (Firewall Group) Port 9999,9996 (tcp)

Production Usage

When using Denodo in production, it’s required that service accounts be used in place of personal credentials. With personal credentials, anything that relies on those credentials will break if you leave the university. Using a service account prevents this. You can ask the Data Strategy team to have a service account created for you and assigned the appropriate privileges.

Raising an Urgent Issue

If an urgent issue arises with Denodo that needs immediate attention, you should create a ticket in ServiceNow with the following field values:

  • Urgency: High
    This will spawn the following prompt. Click Yes

  • Paging Location: Denodo (if known, include the specific Denodo component at issue as well)

  • Service: Denodo

  • Assignment Group: TTS Data Virtualization

This will push the ticket through the On-Call schedule set up for Denodo.

Developers

This section is dedicated to users who will be developing in Denodo and contains a collection of information to help you get started and succeed with Denodo at Tufts.

Skill requirements 

  • SQL 

  • Data modeling

Training

  1. There is an “Introduction to Denodo' class available in the Tufts Learning Center which we require all new users to complete. Simply log in and search for “Denodo”.

  2. There is also comprehensive, free on-demand training available on the Denodo website. Simply create an account using your Tufts email to access the training.
    For questions, email: training@denodo.com Please note that courses may expire if you do not complete them within a certain timeframe; however, you can simply register for the course again to extend that timeframe.

  3. Additionally, there is a Denodo Online User Community. If you create an account with your Tufts email, you can avoid entering the promotion code above for each course.

  4. Denodo Tutorials

Onboarding Steps  

  1. Team new to Denodo

    1. Data needs determined

    2. Virtual Database (VDB) created in Denodo 

    3. AD groups created in Grouper 

    4. AD groups imported into Denodo

  2. Team exists in Denodo

    1. Dev AD group for team assigned

Connecting to Denodo

This section outlines Denodo’s services specific to developers and ways to connect to them

Design Studio

URL: https://denodo-solution-manager.it.tufts.edu:19443/denodo-design-studio/#/

Design Studio is a web-based IDE for developing with Denodo and will be your primary tool for Denodo development. To connect to Design Studio, follow the steps below.

  1. Navigate to the above URL

  2. When presented with the following screen, enter the hostname for the Development VDP (found under Virtual Data Port in the General Users section) in the following format //denodo-dev.it.tufts.edu:9999 and click Single Sign-On.

While you can use Design Studio to connect to the Stage and Production VDP’s, your access will be read-only. You can only make edits in the Development VDP.

Solution Manager

URL: https://denodo-solution-manager.it.tufts.edu:19443/solution-manager-web-tool/Login

The Solution Manager is the central management tool for all Denodo environments. For developers, it’s used for deploying code through our Denodo environments.

Scheduler

URLs:

The Scheduler is used for creating jobs that need to run on a regular basis against the VDP.

When prompted for Scheduler Server, using one of the VDP URLs, enter //${VDP_URL}:8000/

Requesting access

In order to request access to data, please send a TechConnect ticket to the Data Virtualization team (data-virtualization@tufts.edu). In your ticket please include the following information:

  • Please provide a brief description of the business problem you are trying to solve and what you are requesting in order to address it. E.g. I am creating a dashboard for the Med School admissions team so that they can see year over year trends by degree and demographic information. I require 2 data sources to be made available in Tableau and refreshed weekly.

  • Data Source System

    • Is the source system managed internally or externally?

    • Please include connection information if applicable

    • Do you already have access to this data by other means?

  • Please supply a list of the data fields or tables by data source you are requesting and include what system they originate from. These do not need to be the official data field names if you do not know them- a description is fine. E.g. student name/SIS, academic program/SIS, application date/Slate.

  • If you are requesting any protected or sensitive data (PHI, PII, FERPA), please provide a rationale for having access to this data and the name of who has authorized the access if applicable. E.g. phone number, race, DOB, grades, admit status, vaccination status, etc.

  • Any additional helpful information

  • If you are requesting that Data Strategy create a specific view for you and/or end users, in additional to the above steps please also:

    • Specify what level of aggregation you need for each data source. Individual student level? Rolled up at the school or degree level?

    • Note any calculated fields that need to be developed and provide the business logic behind them.

Connecting Data Sources

Denodo allows you to connect to a wide variety of data sources. The sections below outline how to connect to some common types of data sources at Tufts.

A full listing of supported data sources and documentation can be found here: Creating Data Sources and Base Views &mdash; Virtual DataPort Administration Guide .

Dealing with Firewalls

Connection to most data sources will require a firewall change request to allow traffic between the Denodo servers and the database.

Send the request to noc@tufts.edu and use the template below

Hello, Please update the firewall to allow the following bi-directional traffic: Source Group_Denodo_TSS (Firewall Group) Destination ${DATASOURCE_HOSTNAME} (${DATASOURCE_IP_ADDRESS}) Port ${PORT_NUMBER} (tcp/udp)

For vendor-hosted data sources, an additional step may be needed to allow Denodo traffic from Tufts on their side.

Providing the following CIDR block to vendors will allow outbound traffic from Tufts:

130.64.0.0/16

Databases

Databases are the preferred data source when working with Denodo because they are the easiest to set up and work with.

JDBC

JDBC is the most common and preferred way to connect to databases and provides support for a wide array of different different databases. The steps below outline the general steps for creating a JDBC connection. Additional sections provide details for specific databases.

  1. Click the three dots on the right side of the 01-connections folder (inside the 01-base_layer folder) in your VDB then go to New → Data Source → JDBC.

  2. Give your connection a Name

  3. Select your Database Adapter

  4. Enter the Database URI. The format depends on the database you’re connecting to. Check the JDBC documentation for your database.

  5. Provide the Username and Password for your database.

  6. Test Connection and Save

A list of supported DBMS’s can be found here: Supported JDBC Data Sources &mdash; Virtual DataPort Administration Guide

If your DBMS is listed, but the driver isn’t included, or if your DBMS isn’t included, follow the process outlined here: Importing Extensions &mdash; Virtual DataPort Administration Guide 8.0

Oracle
Connection Strings

Oracle connection strings can be converted into JDBC connect strings by pre-pending jdbc:oracle:thin:@ as show in the example below.

Original Connect String

(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = some-db.it.tufts.edu)(PORT = 11003)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = SOMESVC) ) )

JDBC Connect String:

Importing Metadata

You can import table and column metadata from Oracle by adjusting the driver settings using this procedure: How to import column descriptions from Oracle data sources

APIs/Web Services

Slate

Creating Web Services for Queries within Slate

Slate allows queries to be called via web services, as outlined in this guide. Using the Slate guide as a reference, follow the steps below for setting up a query web service for Denodo to interact with.

  1. Click Edit Web Service and select JSON as the Service Type. If necessary, select Include NULL Values for Include NULLs.

  2. Click Edit Permissions, then click Add Grantee

     

    Under Type, select User Token
    Under Name, type Denodo
    Under Permissions, check Web Service
    Click Save

     

  3. Retrieve the Web Service URL by clicking on the link next to Web Service. In the dialog the appears, select User Token - Denodo as the Service Account and select Query String as the Authorization Type. Copy the URL from the URL box. This URL will be used for creating the connection to the web service in Denodo.

Connecting Denodo to Slate Web Services
Creating Web Service Connection

Run the following VQL within your target VDB to create a connection to a Slate web service within Denodo. Replace {{SLATE_CONNECTION_NAME}} and {{SLATE_URL}} with the desired connection object name and the URL to the Slate web service retrieved by following the above.

 

After running this, make sure to navigate to the new connection and test it.

 

Creating Web Service Base View

Inside the edit tab for the new connection, click Create Base View. For the first dialog, just click OK.

In the second dialog, uncheck Json Root and type /JSONFile/row into the adjacent text field, then click Create Base View. This will create a base view with the same name as the connection and in the same folder as the connection. You can rename the base view and move it as needed.

Creating a Projection View

It’s recommended that you create a projection. The projection will allow you to point to another base view if your data source changes later on. If performance of the projection is inadquate, consult the Data Strategy team on enabling caching for the projection.

Diagram

Salesforce

Salesforce Sources &mdash; Virtual DataPort Administration Guide 8.0

Parameterizing Base URL

Denodo doesn’t natively support parameterizing the Salesforce Base URL when deploying via Solution Manager. This results in the value in DEV being statically propogated to STAGE and PROD via VQL. To parameterize Base URL do the following:

  1. For any revision where a Salesforce connection is being deployed either by itself or as a depedency (Include VDP Dependencies checked), download the VQL for that revision and put the following in place of the BASE_URL line for the Salesforce connection VQL (replacing VDB_NAME and SF_CONNECTION_NAME with your VDB name and name of the Salesforce connection).

  2. If this is your first time deploying, or you’re looking to update properties, perform validation against STAGE and PROD for your initial revision. This is only needed to allow faster copying of certain properties from DEV. Delete the initial revision after this to avoid risk of deploying it.

  3. Create a second revision using the edited VQL file from step 1

  4. Validate the second revision. You should only need to input the BASE_URL value at this point if you performed step 2.

  5. Deploy your second revision.

Repeat these steps any time you deploy a Salesforce revision,

 

Flat Files

Box

In Denodo, you can query files in Box by creating connections and base views for individual files.

Please note, it is always best practice to connect to a source system and not to a static exported file. We understand this is not always possible; however, we request that connecting to static data files in Box be used only when absolutely necessary.

To create a connection and base view for a file, follow the steps below.

  1. Add the file(s) to the Data Strategy drop folder. Ask a Data Strategy team member to create a sub folder for your team if one does not already exist. This approach is strongly encouraged since it prevents dependency on files owned by individual users.

    If adding files to the drop folder isn’t an option, you can share files or folders with the Box service account for Denodo by giving view access to AutomationUser_1958391_MbvCoOnEz5@boxdevedition.com.

  2. Get the ID of the Box file. To get the ID of a Box file, navigate to the file in the Box web UI and copy the ID from the end of the URL.

     

  3. Open the VQL Shell

  4. Make sure you have the correct virtual database (VDB) selected in the top left corner of the VQL shell.

  5. Follow the sections below based on the type of file you want to connect to. You’ll need to request the CLIENTIDENTIFIER and CLIENTSECRET values by submitting a ticket to data-virtualization@tufts.edu.

CSV

  1. Copy the VQL below into the shell

  2. Replace {CONNECTION_NAME} with the desired name for the Box file connection

  3. Replace {BOX_FILE_ID} with the ID of the file in Box.

  4. Execute the VQL

  5. Navigate to, and double click on the new connection, then click Create Base View.

VQL

JSON

  1. Copy the VQL below into the shell

  2. Replace {CONNECTION_NAME} with the desired name for the Box file connection

  3. Replace {BOX_FILE_ID} with the ID of the file in Box.

  4. Execute the VQL

  5. Navigate to, and double click on the new connection, then click Create Base View.

  6. Click OK in the Configure JSON View Dialog

  7. In the next screen, for Tuple Root, enter the value that matches your file structure, then click Create Base View. A common Tuple Root value is /JSONFile/JSONArray.

     

VQL

Excel

  1. Copy the VQL below into the shell

  2. Replace {CONNECTION_NAME} with your desired connection name

  3. Replace {BOX_FILE_ID} with the ID of your file in Box

  4. Execute the VQL

  5. Open the new connection and make any changes to accomodate your spreadsheet

     

  6. Click Create Base View

VQL

 

Best Practices

Folder Structure

All VDB’s should be delivered with the following folder structure. If your VDB does not have this folder structure, you can ask an admin to create it for you. Each folder represents a layer and a step in the development process.

  • 01-base_layer: Contains all of your data source connections and their base views

    • 01-connections: Contains connections to data sources. Objects here should be prefixed with ds_. For servers with multiple nested databases (like MS SQL), you can access all databases with one connection.

    • 02-base_views: Contains base views created from data source connections. Prefix with bv_.

  • 02-transformation: Contains projections of base views with changes such as filters, column transformations, and aggregations. Use prefixes p_, f_, d_, or agg_ for projection, fact, dimension, or aggregation respectively.

  • 03-integration: Contains views that join or union 2 or more views. Prefix with j_ for joins, u_ for unions.

  • 04-interface_fulfillment: Contains user facing views. View names here should be free of prefixes. Users will only be given read access to views in this folder.

  • 05-interfaces: Transformation Layer for interface fulfillment. Provides UI Components for people to explore.

  • 06-web_services: Contains web services for provided access to denodo views. Prefix with ws_.

  • 07-associations: Contains associations between views. Used by Denodo to determine cardinality of views joined and used in aggregations. Prefix with a_.

Placement in folders is strictly for visual organization and does not impact how a view is referenced within a VDB. All views within a VDB are referenced by their name only. As an extension, all view names within a VDB must be unique.

Development Process

The development process for Denodo closely follows the folder structure above. The sections below cover each step of the development process.

Connecting Data Sources

All development starts by creating connections to data sources. Follow the steps outlined in Connecting Data Sources. Data sources are part of the base layer.

Creating Base Views

After you’ve created your data sources, you’ll want to create base views for the entities in each data source. The creation of base views is covered either in Connecting Data Sources or easily accessible in the UI for your data source connection. Base views are part of the base layer.

Creating Derived Views

Once you’ve created your base views, you can start producing derived views in the transformation, integration and interface layers.

Creating Derived Views &mdash; Virtual DataPort Administration Guide 8.0

Metadata

Since all Denodo views are visible in the Data Catalog, it’s important to provide metadata descriptions for views and columns to help keep people informed while they are browsing data.

Meta data in base tables automatically flows through to derived views (you can turn off this functionality by field), but you can enter meta data at any layer in the folder structure.

Please note that all interface fulfillment layer and above views will be required to have complete meta data before being promoted to production.

Since adding metadata manually through the Denodo UI can be cumbersome, a Python script has been made available that can generate a CSV of views or column metadata. You can add/modify your descriptions in the CSV and use the script to load the descriptions back into Denodo. The script can also generate descriptions using basic metadata and an LLM (no data values are used). Always review LLM-generated descriptions for accuracy before adding them into Denodo.

The script can be found here: https://github.com/Tufts-Technology-Services/denodo/tree/main/scripts/denodo/metadata

Please review the README for details on how to use the script and generate/load CSV’s for your views and columns.

Row Level Security (RLS)

Row Level Security (RLS) is a security concept where the rows that a user is able to see are restricted based on some defined criteria.

Implementation

How RLS is implemented depends on where the data is being queried from and who is querying it. If the data is being queried in Denodo by a user, then you should implement RLS within Denodo following RLS in Denodo. If data is being queried outside of Denodo or by a service account, then you should implement RLS in the system where you’re presenting the data.

RLS In Denodo

Within Denodo, we implement RLS using a pattern where we define what roles are authorized to view each row, then inner join to a list of roles assigned to the user querying the view. The join limits the result set to rows where there’s a match between the authorized roles for a row and the user’s assigned roles.

Defining Authorized Roles

The easiest way to define what roles can see rows in a view is to define a column, rls for example, using a CASE statement that lists all the roles that can view the row matching the criteria in the CASE statement. An example is below. Note that string with the authorized should be comma delimited with no spaces to stay in line with this guide.

Limiting Rows based on Assigned Roles

Once you’ve created a view with the column defined above, we’ll call it view_rls, you can create a second view that joins view_rls to a pre-defined view called admin.get_user_roles_string which returns the User ID of the Denodo user executing the query, and a delimited string with all of the users roles.

The join logic should look like the following:

The function strings_have_intersection is a custom function to make this RLS approach more efficient. The Improvements section provides more details around this function.

Never cache the view that joins on a users assigned roles. If you cache, the resulting rows will be based on the user performing the cache job, not the users that end up executing the query.

Improvements

Custom Function for Role Comparison

In order to improve the efficiency of our RLS implementation a custom function, strings_have_intersection was created to reduce join complexity and eliminate the possibility for duplicate rows and need for a DISTINCT clause. This results in a run time that close to 100% faster than the previous implementation.

The diagram below outlines RLS before and after the function was created.

The code for the custom function is available here: string_intersection

RLS In Tableau

RLS Best Practices for Data Sources and Workbooks

Column Level Security (CLS)

Column Level Security (CLS) is a security concept where the columns (fields) that a user is able to see in a view are restricted based on some defined criteria.

Implementation

CLS can be implemented in Denodo by using the Column Privileges feature under the Administration - Role Management screen. If that view will be used outside of Denodo, like in Tableau then those columns will be available to see but will not return any data. This can be confusing or frustrating to the users if there are many of these fields.  Another option is to use separate projections of the view with the columns that are sensitive being deleted from that new version of the view. These would be cleaner, only showing the columns that the user would be able to use in the report to return data.

CLS In Denodo using separate views

Within Denodo, we can implement CLS by creating a projection of the view and removing any columns which we do not want the users to be able to query. These new views can then be saved in the target VDB as a level 04-interface_fullfillment user facing view. Permission to execute this view, meaning to select in a query, will be set at the role level.  Only users with the correct role will be able to access the data in that view, which only includes the columns that we have selected for them to view. We can create these separate views with different columns available to the users and even save them to separate VDBs if needed.

Version Control

Denodo allows use of version control systems (VCS) during development and deployment. The sections below outline how VCS is implemented used in these two scenarios. In both scenarios we use repositories hosted in the the Tufts TTS enterprise account.

Development VCS

VCS Configuration &mdash; Virtual DataPort Administration Guide

Environment Management &mdash; Virtual DataPort Administration Guide

Database Configuration &mdash; Virtual DataPort Administration Guide

Default repository: denodo-vcs

Version control in development allows developers to keep track of changes made in their VDB and roll back in the event a bad change is made. The sections below outline how VCS is used. We highly encourage users to make use of this functionality. If you wish to have VCS enabled on your VDB, please consult a Denodo admin.

Using the VCS
Committing Code

You should commit often to allow for rollback of mistakes.

Right click on folder or object that you want to commit. Go to VCS -> Commit.

 

Review the commit to ensure only the necessary objects are present, then type a short informative message summarizing the commit in the Log message box. When done, click Commit.

If you decide to drop a view that you’ve committed, you’ll need to make another commit to remove it from the VDB tree and Role Management screens. Trying to use Role Management within the VDB of a dropped view may result in errors prior to committing.

Pushing Code

When all code to a VDB has been committed, and the VDB has a green source control icon and number indicating the number of commits to push, you can push code up to GitHub. To push, right click on the VDB, go to VCS and click Push. You can’t push if the icon is orange, indicating that there are uncommitted changes.

You should try to commit and push often to make recovering from an issue easier.

 

If you get the following error message when pushing, perform a pull, then try pushing again.

Rolling Back

If you want to roll back changes in your code, Denodo allows you to either discard uncomitted changes or revert to a previous commit.

Discard

If you’ve made changes to your VDB that you haven’t committed yet, you can discard them by right clicking on the object or folder and clicking Discard.

Revert

A revert can only be performed if there are no uncommited changes in your VDB

If you’ve already committed code and need to revert a commit, or series of commits, you can do so by right clicking on your VDB and clicking Revert

You’ll be given the option of select the commit you want to roll back to. Every commit after the one you select will be reverted. A revert commit will be generated and added to your commit history. The reverted commits will still be available to roll back to if necessary (e.g. you rolled back too far).

Repo Structure

The metadata for each VDB is saved in its own folder as show in the screenshot below:

Additional Articles

Scenarios And Recommended Uses &mdash; Virtual DataPort Administration Guide

Best Practices When Using the Integration with a VCS &mdash; Virtual DataPort Administration Guide

Deployment VCS

Denodo allows the VQL code that makes up each environment to be saved into a Git repository upon each successful deployment. The code is committed to the main branch and each environment has its own folder.

The repo being used for these backups is denodo-backups.

Code Promotion

To make your code available to end users, you need to have it promoted to Production.

Promotion of code is done in Solution Manager by creating and deploying Revisions.

The process below outlines how revisions are created and deployed. Revisions are reviewed by admins and deployed every Monday. Before creating revisions, make sure you’ve done adequate testing of your code.

  1. Create a revision. All revisions should use DEV as their source environment.

    1. Select your revision elements

      1. If making role changes, be sure to include any objects directly associated with that role so the necessary VQL is generated to update permissions

      2. DO NOT include any dev roles in your revisions, read roles only. This will ensure that objects are read only outside of the dev environment.

    2. Give revision a name and description and save

    3. Validate your revision against STAGE. This step will give you the ability to set properties for connections, allowing you to define new URL’s and credentials for connections deployed to STAGE. This will have to be done against PROD as well, but must be done by a Denodo admin.

    4. Deploy your revision to STAGE, confirm that it deploys successfully, and test the revision elements. If you encounter issues, delete your revision and repeat steps a through d until successful.

  2. Announce the revision in the Revisions channel of the Denodo team in Teams asking for it to be deployed at the next Monday deployment session.

  3. The admins will review your revision for security. If there are no issues, the revision will be validated against PROD and deployed. If issues are found, you will be asked to resolve them before deployment. URL’s and credentials for new datasources for PROD will need to provided to admins for entering.

Note that every connection in Denodo gets environment variables created in STAGE and PROD as part of the validation process. These variables allow you to deploy connections with different URLs in STAGE and PROD without creating separate connections and views.

Related content

Denodo Resources & Credentials
Denodo Resources & Credentials
Slate
More like this
Connecting to Denodo
Connecting to Denodo
Data Strategy
More like this
Denodo Admin Guide
Denodo Admin Guide
Data Strategy
Read with this
Random Denodo notes
Random Denodo notes
Slate
More like this
Slate
Slate
Data Strategy
Read with this
Tagging and Security
Tagging and Security
Data Strategy
More like this