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.
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.
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.
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.
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.
This comment has been removed by the author.
ReplyDelete