Denodo Governance Bridge - User Manual


Denodo Governance Bridge Tool exports Virtual DataPort (VDP) elements, including the lineage, to IBM® InfoSphere® Information Governance Catalog (IGC) to support governance across Denodo databases.

To achieve this Denodo Governance Bridge Tool extends IGC by registering new types of assets from the Denodo catalog:

  • Database-icon.gif Databases
  • DataSource-icon.gif Data Sources  
  • BaseView-icon.gif Base Views
  • DerivedView-icon.gif Derived Views
  • InterfaceView-icon.gif Interface Views
  • Column-icon.gif Columns
  • Association-icon.gif Associations
  • StoredProcedure-bigIcon.gif Stored Procedures
  • Parameter-bigIcon.gif Parameters
  • Folder-icon.gif Folders

These Denodo assets:

  • Are available in IGC via the “detailed browse” option and appear in the query tool.

  • Can be be governed using Glossary Terms, Governance Rule, Data Stewards, Custom Properties and Collections.

  • Support Data Lineage.

Governance Tool.png

Figure 1 Denodo Governance Bridge architecture

The Denodo Governance Bridge bridges the gap between IBM IGC and Denodo VDP metadata repository. The tool loads VDP elements, and the flow of data that defines the lineage into IGC using the IGC REST API. Under the hood, Denodo Governance Bridge Tool generates XMLs from VDP elements metadata accessible through the Denodo JDBC API. This process is hidden to the user, who only interacts with the web interface.

IGC Requirements

Denodo Governance Bridge requires Open IGC. Open IGC is the technology that allows to define new asset types within the Information Governance Catalog with their own names, icons, custom properties and containment relationships.

Denodo Governance Bridge requires at least:


  • Information Server release 19, or

  • Information Server 11.5 rollup 1.1 these versions are the first that allow the possibility to assign more than one parent type to an asset in Open  IGC.

More information about Open IGC is available at


The Denodo Governance Bridge distribution consists of:

  • Command-line executable scripts for Windows and Linux (/bin folder)

  • This user manual (/doc folder)

  • A Java jar binary file (/lib folder)

For installing it just download the .zip file and extract the tool into the desired folder.

In order to run the Denodo Governance Bridge you will need at least Java 7 (or Java 8 if you are using the Governance Bridge Tool for interacting with Denodo 7.0) and a PATH environment variable correctly configured to run it from the console. It is also required that you define the JAVA_HOME environment variable.

After running the script in the /bin folder point your browser to http://localhost:10099 to access the home page:


                         Figure 2 Denodo Governance Bridge Tool home page

Enable SSL Connection

When SSL is enabled in IGC server, Denodo Governance Bridge has to trust the public key of the IGC server.

For this to happen you need to import the certificate into the trust store of the Denodo Governance Bridge.

  1. Copy the file igc_server_public_key.cer from the IGC Server to the Denodo Governance Bridge Tool computer.

  1. Locate the Java Runtime Environment (JRE) the Denodo Governance Bridge Tool uses.

  1. Open a command line there and execute this:

keytool -importcert -alias some_alias

    -file igc_server_public_key.cer

    -keystore jre\lib\security\cacerts 

    -storepass "changeit" -noprompt


Register Denodo Asset Types in IGC

The registration of Denodo asset types in IGC is done transparently by the Denodo Governance Bridge tool before the first synchronization between a VDP database and IGC.

After this operation Denodo asset types are displayed in the IGC browser in the Denodo Models group:

Figure 3 Denodo type assets in IGC

Synchronize VDP with IGC  

First, the Denodo Governance Bridge needs the connection details to communicate with the Denodo VDP server:

  • Host

  • Port

  • A database the login user has privileges to connect to.

Once the authentication is complete, the user could choose the database to synchronize with IGC, among all the databases the user can connect to.

Take into account that for the elements involved in the synchronization process, the login user should have:

  • connect privileges over the databases

  • for views and stored procedures

  • write privileges in Denodo 7.0

  • read privileges in Denodo 6.0

  • for the rest of elements

  • metadata privileges in Denodo 7.0

  • read privileges in Denodo 6.0

Figure 4 VDP server connection

Then, the process to synchronize a Denodo VDP model with IGC is a four-step process.

Step 1. User select which database in the VDP server they are interested in.

Figure 5 Databases listing

Step 2. The tool introspects the database and let users choose the elements to export to IGC.

Figure 6 Database elements tree

Figure 7 Database elements selection

Step 3. The tool informs users about which are the transitive dependencies for the selected elements. These dependencies will be also exported to IGC.

In the picture below we can see that the derived view web_logs_all_with_blokinfo depends of:

  • Derived views: web_logs_all, linux_web_logs, nonlinux_web_logs_impala

  • Base views: web_logs, web_logs_impala, hbase_cloudera_blocklistip

  • DataSources: hive_ds, impala_ds, hbase_cloudera_ds

All these VDP elements will be present in IGC at the end of the process.

Figure 8 Transitive dependencies are also synchronized

Step 4. Users give the details to connect to an IGC server.

The Update Denodo bundle version in IGC? checkbox should only be checked after installing a Governance Bridge Tool update, the first time a synchronization process is executed.

Because the registration of the Denodo bundle in IGC is done transparently by the Denodo Governance Bridge tool before the first synchronization between a VDP database and IGC. But posterior updates of the Governance Bridge Tool could need to modify the Denodo bundle. So this checkbox updates the previously Denodo registered bundle.

Figure 9 IGC server connection

In the end, the tool shows all the elements, the selected and the dependent ones, that were synchronized to the IGC.

The flow of data that defines the lineage is not explicitly displayed but it will also be loaded in the IGC server.

Figure 10 Synchronization complete

Let’s show the synchronization process result in the IGC side.

The image below shows the details of the web_logs_all_with_blockinfo derived view: the database it belongs to, the columns assets that it contains, the VQL expression that defined it, etc.

Figure 11 Derived view in IGC

And, these two images below display the data lineage for the same view, web_logs_all_with_blockinfo.

Figure 12 Derived view lineage in IGC

Figure 13  After drilling down on the derived view lineage

Data lineage view in IGC is similar to the Data lineage view available in the VDP Admin Tool. The following image shows the VDP data lineage for the web_logs_all_with_blockinfo derived view.

Figure 14  Data lineage view in VDP


View deletion

Successive exportations of the same database (or folder) accomplished by the Denodo Governance Bridge tool do not delete views in IGC that no longer exist in Denodo VDP. In these cases the user should delete these views manually in IGC.

Lineage between Denodo elements and other IGC elements

The Denodo Governance Bridge exclusively manages Denodo elements. It is not aware of the presence of metadata elements for the Denodo data sources (such as database tables) or the Denodo client applications, both of which could be present in IGC or not, and managed in ways that might not be recognizable by external tools such as the Governance Bridge.

So associations among metadata elements imported from Denodo and from other data storage/integration systems that might also be present in an IGC installation should be managed using other metadata management tools that may have visibility on the complete set of IGC metadata.