Enabling artifact types in WSO2 Governance Registry Publisher and Store UI’s


New generation of WSO2 Governance Registry (5.x) releases has its own publisher and store user interfaces to publish and consume assets. Asset owners can publish the assets from the Publisher UI and manage the lifecycle of these assets from this UI, while consumers of assets can discover them from the Store UI. WSO2 Governance Registry currently ships many asset types however not every asset type is enabled in the Governance Registry Publisher and Store UI’s. Let’s take the asset type endpoints. This asset type is available in the default Governance Registry distribution but the Publisher and Store UI’s doesn’t have this asset type. Hence it is not possible to create endpoints from the PublisherUI or consume/view these assets from the Store UI. As you see below the Publisher doesn’t show an asset type endpoint in the Publisher UI.


To enable the asset in the Publisher lets open the following config file

<G-Reg Home>\repository\deployment\server\jaggeryapps\publisher\extensions\app\greg_publisher\app.js

You will find the following code snippet; remove the asset from the disabledAssets section.

Restart the server, the asset type is now available in the Publisher UI.


You can also enable a given asset type in the store UI. In order to do this you will need to do the same change in the following file.

<G-Reg Home>\repository\deployment\server\jaggeryapps\store\extensions\app\greg_store\app.js

WSO2 Registry Explained!

What is a Registry?

Registry in essence is a storage space in which data and configuration relating to a product can be persisted and referred from. The Registry uses a database for data persistence and it can be mounted to any type of Relational DB. Registry is a Carbon Kernel component hence all WSO2 products have a registry space built into the product.

Registry Spaces

Each registry can be divided into 3 spaces.

  1. Local Registry space

Local Registry space is specific to each WSO2 product and is not shared with other products in the deployment. Local registry stores artifacts that are local to that particular server.

  1. Config Registry space

Config Registry is shared between similar products in the cluster. For example all ESB nodes in the cluster would share a single Config Registry space. All product specific artifacts are stored inside this Registry.

  1. Governance Registry space

The governance registry space is a common space that is shared by all WSO2 products in the deployment. This registry space will store all artifacts that are common to all WSO2 products in the deployment. Governance Registry space should not be confused with the WSO2 Governance Registry.

Registry spaces are conceptual and all 3 spaces can mount to a single location. In the vanilla distribution of a WSO2 product, all these 3 spaces are pointed to the local H2 Database.

What is Registry mounting?

Registry mounting refers to a concept of linking the registry to a database. By Default the registry is mounted to the local H2 Database. It is possible to mount different Registry spaces of the same registry to different databases. For example the Local Registry space can be mounted to the H2 database whilst other spaces can be mounted to a remote database. In a production system it is recommend to mount the Config and Governance spaces of the Registry to a remote database.

Governance Registry Space != Governance Registry

Even though they sound similar, the Governance Registry space is not the same as WSO2 Governance Registry Product. Governance Registry simply refers to a registry space that is common to all WSO2 Products. Whereas the WSO2 Governance Registry product is a registry and a repository to store any type of data or metadata. It provides a rich set of features including SOA governance, lifecycle management, and a strong framework for governing anything.

What is remote Registry mounting

In a production deployment it is recommended to mount the Config and Governance space of the Registry to a remote database. This allows these registry spaces to be shared by the other products in the cluster or in the deployment. For example if you mount the Config space in a remote location all similar products in the cluster can use this remote location, where as if you mount the Governance space in a remote location all the WSO2 products in the deployment can use this remote Governance space.

How WSO2 Governance Registry comes into the picture

WSO2 governance registry can be used to manage the registry spaces of WSO2 products. This provides the capability to incorporate registry features to the registry spaces so that the registry can be managed better from a central point.

Mounting WSO2 instances on a MS SQL Database which is secured via Windows authentication

A multi instance deployment of WSO2 products would require the registry (config and governance) space to be mounted on an external database.  WSO2 Products can be mounted on many types of databases. Below instructions explain how WSO2 products can be mounted on a MS SQL database that is secured via Windows Authentication.

  1. download jTDS from the following link


  1. Extract the folder and copy the jtds-1.2.2.Jarfile to the {WSO2 Product}/components/lib folder
  1. The extracted folder also includes ntlmauth.dllfile in the \x64\SSOfolder copy the dll file to java bin folder(C:\Program Files\Java\jre7\bin)
  1. download and install the jdbc driver for mssql from the following location


  1. Once this is installed set the class path to the following location {JDBC driver Installation Path}\sqljdbc_4.0\enu\auth\x86
  1. Make sure that the IP and the port is enabled at the MSSQL side, this can be verified through telnet.
  1. Change the datasources.xml to the following configuration (Please change the DB name and the hostname accordingly)
  1. Start the ESB.