Default transition UI - Part 02

WSO2 Governance Registry lifecycle model has many extension points. One of them is called the transition UI. In one of my previous posts, I have given an insight to what transition UIs are. This post is an continuation of my previous post.

WSO2 G-Reg distribution includes a single transition UI. This transition UI is used by the default service lifecycle for its service version functionality(more information can be found here). This transition UI does the following.

The name of the default transition UI is "pre_invoke_ajaxprocessor.jsp".

The main functionality of this UI is to take user input for the versions of services and their dependent resources, so that they can be passed to the service version executor.

It is displayed only for services. It will ignore all other media types.

It will list down all the dependencies of a service resource. These dependencies are gathered recursively. Hence all the dependencies of that service and its dependent resources, will be displayed in the UI.

Parameters can be passed to these UIs. The lifecycle configuration model supports adding parameters to a transition UI element and these parameters are added as URL parameters. Please note the section after the "?" in the following example.

The "pre_invoke_ajaxprocessor.jsp" accepts 5 different parameters and all of these are optional.

1. preserveOriginal - Setting this parameter will allow users to instruct the server to keep the old resource or whether to delete it. If this parameter is set to "false", then the underlying implementation will delete the resource after a state transition. This parameter is set to "true" by default.
2. viewVersion - This parameter is there to instruct the jsp page to avoid displaying the content of the page. If the viewVersions is set to "false", the underlying implementation of the jsp page will do an invokeAspct() call including parameters like "preserveOriginal". We use this parameter to pass the value of the "preserveOriginal" parameter to the server without displaying any additional UI to the user.
3. displayMediaType - This parameter is used to override the default media type which is checked by the jsp page. By default, this UI checks whether the resource has a media type equal to "application/vnd.wso2-service+xml"(which is the default service media type of WSO2 G-Reg). By setting this parameter, users can override the above mentioned value. 
4. showDependencies - Instructs the jsp page to not to show the dependent resources of the service. If this parameter is set to "false", the jsp file will only show an input field for the service resource in the custom UI(it will not give input fields for any dependent resources).
5. currentEnvironment - Defines what is the current environment of the service(or its dependencies). The value of this parameter should be a path in the registry. If this parameter is set, the jsp page will not show input fields for resources that are not in the given registry path. 

Default transition UI - Part 01

In one of my previous posts, I discussed about few improvements that we did in the lifecycle configuration of WSO2 Governance Registry 4.1.1. In that post I explained about one of those points, which is the executor interface. Today lets have some insight into the other improvement we did, which is the transition UI.

What is a transition UI?

We use the term "transition UI" to describe a portlet that is displayed as an result of an lifecycle action. In other words, transition UIs are used to get user input at runtime, as a part of a lifecycle transition. To get some clear idea about it, lets look at the following use case. 

Eg:-

Say that I'm a user who is going to govern all my services in WSO2 G-Reg using its lifecycle management capabilities. As a part of the governance process, I need to keep my services in different locations of G-Reg based on the lifecycle state of a service. As a part of this operation I also need to add a version to my services.

Adding a version to a service that is been moved to different environment is somewhat a tricky operation. The version that needs to be added, should be given by a user at runtime. For this, we need some kind of a mechanism to give user inputs for a lifecycle state transition.

We introduced the transition UI feature to achieve the above, which is to give user input for a lifecycle state transition. There are few key things that a user should know about transition UIs.

Transition UIs are registered for an action/event in a particular state. The registration happens through the lifecycle configuration.

If the lifecycle configuration demands the same transition UI for multiple actions/events, then it has to be re-registered.

Only one transition UI can be given for a action/event in a particular state.

Parameters can be passed to transition UI. These parameters are defined in the lifecycle configuration and they are considered as static parameters. Hence they can not be changed at runtime.

The input values that are given through the transition UI are passed to back-end and they can be read using an executor.

Transition UI appears below the lifecycle portlet and there are no popup windows.

There are few transition UIs that we ship by default. I'll be covering about them in another post.

WSO2 Governance Registry 4.5.0 - Lifecycles

At the time of this post, we are preparing for the release of WSO2 Governance Registry 4.5.0. This new version has lots of new features and performance improvements. From this post, I would like to mention one such improvement that we did for G-Reg Lifecycle management feature.

Lifecycles in a nutshell

WSO2 G-Reg has a powerful lifecycle model with lots of flexibility. In WSO2 G-Reg, users have the ability to define their own lifecycle model using a simple XML configuration. The default lifecycle configuration of G-Reg has the ability to define states,check items,permissions,transition UIs, pre and post transition actions. A detailed description about the lifecycle model of WSO2 G-Reg can be found in this post.


In G-Reg 4.5.0 we have introduced the ability to audit lifecycle operations. This means we capture all the lifecycle operations of a particular resource. Following are some key points when it comes to lifecycle auditing.

Lifecycle auditing is turned on by default.

Auditing can be turned off from the lifecycle configuration. This can be done by setting audit=false in the lifecycle element in the lifecycle configuration.

Lifecycle auditing happens per lifecycle. Based on the configuration, all the resources associated with that lifecycle are audited.

Audit logs are kept as a resource in G-Reg. These resources are stored under, "/_system/governance/repository/components/org.wso2.carbon.governance/lifecycles/history" collection. A resource is created for every resource/collection that is associated with a lifecycle. The name of this resource is calculated by replacing all the "/" with "_" of its full path.

Audit logs are kept as a XML file. A sample audit log is as follows.