Page Comparison

Governance Registry allows

to define check items

for each transition.

The permissions element defines permissions for that specified action

and hold more than one child element which defines permissions. Under check items, the permissions element defines the users that have the capability of checking (check/uncheck) that check item. If a user does not have permissions to check a check item, then the management console will display that specific item in disabled mode. The idea behind this is to let the user know that there are some more check items in that state, but that he or she does not have permission to check them (so as to avoid user confusion).

This element is a child element of the permissions element and will define the roles that have permissions to do the specified action. Here, the attribute roles accepts a comma (",") separated list and these roles should be present in Governance Registry.

Defines the validations that need to be completed for each action. This element can contain one or more validation elements

. Check Item Validators are one of many well-defined extension points supported by the WSO2 Governance Registry. Read more on Supported Extension Points for a complete list of extension points supported by WSO2 Governance Registry.

Validations are an important part of lifeCycles. The validation element defines the event and the validation class that has to be invoked at runtime.

Defines the event for which this validation should be performed. This gives user the flexibility to define validations for each event. The user has the ability to define validations for check items, which makes it easy to validate different things at different levels.

The parameter elements are used to give parameters to the validation and execution classes. It is up to the user to define the name value pairs, and the parameter element has attributes to define these values. A validation element or an execution element can have more than one parameter element and it is up to the user code to handle this. The underline implementation of the DefaultLifeCycle class will pass all the parameters in a map object.

Governance Registry lifeCycle configuration has the ability to allow JavaScript functions to execute on both the server side and the client side. The js element defines the scripts that need to be executed for different events.

 Defines the transition action where this JavaScript function needs to be executed.

Defines the JavaScript function that needs to be executed on the client side.

Defines the name of the function which will be executed at a transition from one state to another.

Contains the actual JavaScript code segment. A user has the ability to define any code segment here.

This is the same as the console function and the only difference is that this element defines the scripts that need to be executed on the server side.

An executor is business logic that is executed once a state transition happens in a lifecycle. The execution element defines the event and the execution class that will be invoked at runtime.

Defines the event for which this execution should be performed. It gives user the flexibility to define executions for each event. A valid event value must be given to this attribute.

N/A

• Promote - Event transits the LC state to next level.(development to QA)
• Demote - Event transits the LC state to previous state.(QA to development)
• Publish - Event transits the LC state from production to publish.(production to API Store).

promote/demote/publish - When this event is invoked, the life cycle's state changes from its current state to the target state which is defined in the "target" attribute of the <transition> element.

Defines the class that needs to be executed at runtime, when the user invokes the corresponding event within a given state. This class consists of business logic to be executed and facilitates environment changes during state transitions.

A user must give the full, qualified name of a class that implements the Execution interface.

org.wso2.carbon.governance.registry.extensions.
executors.ServiceVersionExecutor

The class named "org.wso2.carbon.governance

.registry.extensions.executors.ServiceVersionExecutor" does provide the necessary business logic for the complete default lifecycle configuration model.

The parameter elements incorporate the transition of the underlying resource by changing the environment during the state transition by providing the necessary arguments for the methods defined in the business class which is declared by the class attribute within the <execution> element. The value of the name attribute can be given any name, but it has to be referred by the given name at the back end class defined within the <execution> element. If we omit the <parameter> element under the <execution> element during the state transition, the underlying resource does not move its environment(its storage path).

The 'name' attribute is referred by the business logic defined in the 'class' attribute of the <execution> element.

String

• currentEnvironment - Denotes the fully-qualified path of the resource under the current state, which is the state in which the resource is currently in.
• targetEnvironment - Denotes the path to which the resource has to move during state transition. 
• service.mediatype - Points out the MIME mediatype of the service artifact.
• wsdl.mediatype - Points out the MIME mediatype of the WSDL artifact.
• endpoint.mediatype - Points out the MIME mediatype of the artifact name Endpoint.

A UI element is a mechanism to associate a user interface with a particular event during a given transition. This provides a convenient way for a user to pass input that would be utilized when performing a transition.

Defines the event for which this UI will be presented.

Defines the transitions of a state. In Governance Registry 4.1.1, users are allowed to define the transitions (the name and the target state) instead of using static transitions.

Previously, the configuration did not have a direct method of defining the transition event names or, most importantly, the target of the transition. There were only two transitions that were supported by default.

With the new, SCXML-based configuration model, any number of transitions from one state are supported. Also, this model has the capacity to define the target state of the transition and

the name of the event as well.

Defines the transition event name, for example, to "Promote" or "Demote" or any name that the user specifies.