Asset management with WSO2 Governance Registry

Saranki Magenthirarajah
7 min readJun 21, 2020
[Source: https://blog-assets.freshworks.com/freshservice/wp-content/uploads/2019/01/18120225/groot-trainee.gif]

In today’s tech world an organization’s assets are no longer restricted to be just the tangible properties, knowledge, or manpower. Anything and everything that brings turnover to a business, play a key role in the day-to-day routine activities or strategy level planning are considered to be assets of an organization. Intangible assets such as APIs, swaggers, contact details, files are some examples for an organization’s assets these days.

WSO2: The solution provider

[Source: https://3.bp.blogspot.com/-HBoEEee22js/V6bTv1bkVuI/AAAAAAAAEhM/bW5sBoLIL2ks-1fy1N3V4qUJfUDrglpUgCLcB/s1600/Screen%2BShot%2B2016-08-07%2Bat%2B11.57.22%2BAM.png]

WSO2 is one of the leading key players in open-source technologies. When the company was started back in 2006 they had products such as Application server, App Manager, Business Process Server, Message Broker, etc. One such product that holds the record of being one of the oldest products of WSO2 is Governance Registry, also known as GReg.

WSO2 Governance Registry: A walk-through

We all have heard about WSO2 products such as API Manager, Identity Server, and Enterprise Integrator. Governance Registry might sound very new to most of us. This is one of the oldest products of WSO2. To be more specific this is a feature matured product that is no longer in the development phase. Therefore, the product will not have any major releases in the future except for the WUM updates that are provided only for the subscribed users.

WSO2 GReg is an enterprise-level open-source product used for asset management. This includes storing, monitoring, governing assets, lifecycles, and team collaboration. GReg is an optimal solution to manage assets for rapidly growing and large scale businesses.

WSO2 GReg consists of 3 profiles. They are Publisher portal, Store portal, and Carbon Management Console. This is somewhat similar to the API Manager of WSO2. Unlike, the API Manager, GReg doesn’t have any gateway or traffic manager. Therefore, it doesn’t have a runtime environment to manage API calls.

Though GReg is a feature matured product it is highly customizable in order to adhere to the users’ requirements. This is mainly because each organization’s asset model could be different from one another. So having one standard product with limited features will be a bottleneck for the users. As a result, GReg is developed to be a highly customizable product with various extension points. We’ll have a separate discussion on these extension points in the upcoming reads.

Asset management in GReg

When it comes to asset management in GReg there are few terminologies you should know and get familiar with. The most important terms are as follows.

  1. RXT
  2. Life Cycle

Let’s get some clear understanding of RXTs and lifecycles in WSO2 GReg.

RXT

The WSO2 GReg Registry Extensions are known as RXTs. The RXT is a configurable governance artifact is one of the many well-defined extension points supported by the WSO2 Governance Registry. In simple terms, RXTs are templates for each asset that is to be governed by the WSO2 Governance Registry which can be easily configured to cater to our use cases. The schema we define in the carbon management console will get reflected in the GReg Publisher portal by default.

Once the asset is created through Publisher/REST APIs/carbon console, it will be saved in the storage path that is defined in the respective asset’s RXT.

In GReg, RXTs can be categorized into 2 types. They are as follows,

  1. Generic Type RXT
  2. Content-Type RXT

Generic Type RXT

These types of RXTs are a combination of different types of attributes. For example, REST Service, SOAP service. By default when we create a new generic type RXT in the carbon management console, it will be reflected in the publisher’s UI.

Content-Type RXT

Content-type RXTs are used to create assets that contain file content as their main attribute. In simple terms, if an asset is using an external source to get the content into the GReg, it is known as Content-type RXT. For example, in GReg swagger is created by importing content from a URL and uploading a file. Since it has 2 sources of getting the content, the default UI delivered by the RXT created in the carbon console is not sufficient enough to cater to both the swagger creation options. Therefore, the default UI needs to be overridden in the front-end(jaggery level).

Unlike the generic type RXTs, the content type RXTs have several limitations. If we are to override the default UI for a particular asset anything we provide inside the content tag will not get reflected in the publisher. This limits us from using some predefined functionalities in the RXT such as validating the attribute format using the “validate” keyword and dynamic population of dropdown values.

NOTE: Even though the GReg product can be customized we highly recommend avoiding the customization on content type RXTs, especially if they have various types of sources to get the asset’s content.

Creating an RXT

RXT is an XML formatted schema used to create assets in a carbon console. The following are the general guidelines to create the RXTs in carbon console. Please note that throughout this blog I’ll be using wso2greg-5.4.0 to demonstrate the examples.

Steps to create an RXT in the carbon management console

  1. Go to the carbon management console and log in
  2. On the left corner, you will be able to see 4 menu options as Main, Monitor, Configure, and Extensions
  3. In that click on “Extensions” option
[Fig 1: Click on “Extensions” menu option on the left corner]

4. Next, you will be directed to the following page where you can select the type of extension you wanted to create. In our case, we have to create RXT which is labeled as “Artifact Types” as follows

[Fig 2: “Artifact Types” option to create new RXT]

5. Click on the “Artifact Types” option and you will be able to see the following page. In that click on the “Add New Artifact” button under the Artifacts table to create a new RXT.

[Fig 3: “Add new Artifacts” option to create new RXT]

6. Next, you will be directed to the page in which you can create the new RXT. A predefined RXT template will be presented on this page on which you can make changes or you also can remove the content completely and create your own RXT.

[Fig 4: New RXT template]

7. Once you complete the changes press on the “save” button.

[Fig 5: Save the newly created RXT]

8. The page will be redirected to the list of artifact types. The newly created RXT can be found in the artifact types list.

[Fig 6: Newly created RXT in the artifact types list]

9. The newly created asset will be displayed in the GReg Publisher portal.

[Fig 7: A newly created asset in the Publisher portal]

10. The newly created asset will be displayed in the GReg Store portal.

[Fig 8: A newly created asset in the Store portal]

If you create the RXTs using management console it will be only stored in the database. However, you can add soft copies of RXTs to the <GREG_HOME>/repository/resources/rxts/ location as well.

Life cycles

The lifecycles in WSO2 GReg plays an important role in promoting and demoting an asset from one state to another. While changing the lifecycle states of an asset you also can add checklists upon which you can perform the lifecycle changing events. The life cycle consists of the definition of the states an asset can transit through and all the related configurations for the states such as permissions, validations, transitions approval, etc.

Steps to create a lifecycle in the carbon management console

  1. Go to the carbon management console and log in.
  2. On the left corner, you will be able to see 4 menu options as Main, Monitor, Configure, and Extensions
  3. In that click on “Extensions” option and then under “Configure” click on “Lifecycles”
[Fig 9: “Lifecycles” to create new lifecycle]

4. Next click on “Add New Lifecycle”

[Fig 10: “Add new Lifecycles” option to create new Lifecycle]

5. By default, a sample lifecycle template will be displayed. You can modify the lifecycle accordingly.

[Fig 11:Create and save the newly created lifecycle]

6. The newly created Lifecycle will be listed on the lifecycle list.

[Fig 12: The newly created Lifecycle on the lifecycle list]

Simple, isn’t it? But this is not the end. This blog is just to give a heads-up on WSO2 Greg product, it’s basic concepts, and the structure for you to get familiarized with. There’s a lot to discuss on this topic as it has so many extension points that help us to customize this product based on our use-cases. Since this is a very vast area to discuss I’ll be splitting the topics into several posts and have dedicated discussions on them.

Recap…!

To give a quick recap, we have seen what is asset management in organizations, how can WSO2 address those problems with GReg product, some terminologies to get start off with Greg, the story behind RXT and lifecycles and how to create those artifacts. Hope this will be a good read for those who are looking for resources to know about Greg step-by-step and in an easy to understand form. Let’s see you guys in another interesting blog post.

Happy Learning…!

Be safe and stay hygienic…!!!

[Source: https://thumbs.gfycat.com/AssuredYellowDamselfly-size_restricted.gif]

--

--