This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.
Configuring Lifecycles
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
Static Configuration
Static lifecycle configuration could be done either through the GREG_HOME/repository/conf/registry.xml or through a resource. See Managing Lifecycle.
The following configuration specifies the aspect ServiceLifeCycle in the registry.
Note
When you specify the lifecycle as an aspect in the registry.xml, it will not be listed under "Lifecycles" section.
Configuration through registry.xml
<aspect name="ServiceLifeCycle" class="org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle">
<configuration type="literal">
<lifecycle>
<scxml xmlns="http://www.w3.org/2005/07/scxml"
version="1.0"
initialstate="Development">
<state id="Development">
<datamodel>
<data name="checkItems">
<item name="Code Completed" forEvent="">
</item>
<item name="WSDL, Schema Created" forEvent="">
</item>
<item name="QoS Created" forEvent="">
</item>
</data>
</datamodel>
<transition event="Promote" target="Tested"/>
</state>
<state id="Tested">
<datamodel>
<data name="checkItems">
<item name="Effective Inspection Completed" forEvent="">
</item>
<item name="Test Cases Passed" forEvent="">
</item>
<item name="Smoke Test Passed" forEvent="">
</item>
</data>
</datamodel>
<transition event="Promote" target="Production"/>
<transition event="Demote" target="Development"/>
</state>
<state id="Production">
<transition event="Demote" target="Tested"/>
</state>
</scxml>
</lifecycle>
</configuration>
</aspect>
Configuration through a resource
The following should appear in the registry.xml file.
<aspect name="ServiceLifeCycle" class="org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle"> <configuration type="resource">/configurations/checklist</configuration> </aspect>
Note
When you specify the above aspect configuration in the registry.xml and start the server without creating the "checklist" resource, it will throw exceptions when accessing "Add Service" option. The lifecycle combo will be blank. Therefore, the checklist resource should be added to the registry, before you start the server after specific configuration in the registry.xml.
The following should be the content of the /configurations/checklist resource.
<lifecycle>
<scxml xmlns="http://www.w3.org/2005/07/scxml"
version="1.0"
initialstate="Development">
<state id="Development">
<datamodel>
<data name="checkItems">
<item name="Code Completed" forEvent="">
</item>
<item name="WSDL, Schema Created" forEvent="">
</item>
<item name="QoS Created" forEvent="">
</item>
</data>
</datamodel>
<transition event="Promote" target="Tested"/>
</state>
<state id="Tested">
<datamodel>
<data name="checkItems">
<item name="Effective Inspection Completed" forEvent="">
</item>
<item name="Test Cases Passed" forEvent="">
</item>
<item name="Smoke Test Passed" forEvent="">
</item>
</data>
</datamodel>
<transition event="Promote" target="Production"/>
<transition event="Demote" target="Development"/>
</state>
<state id="Production">
<transition event="Demote" target="Tested"/>
</state>
</scxml>
</lifecycle>
The Lifecycle Template
The template of the lifecycle configuration model is as follows:
<aspect name="" class="org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle">
<!-- name - used to give the name of the life cycle
class - gives the default life cycle class. This can be any class that extends an aspect -->
<configuration type="">
<!--type - can have either 'literal' or 'resource' as values -->
<lifecycle>
<scxml xmlns="http://www.w3.org/2005/07/scxml"
version="1.0"
initialstate="">
<!--initialstate - defines the starting state of the life cycle and can not be null or empty-->
<state id="">
<!-- state element - defines a life cycle state
id - defines the name of the state-->
<datamodel>
<!--contains 6 data elements that defines check items, transition validations, transition permissions
transition executions, transition UIs and transition scripts-->
<data name="checkItems">
<!--name - defines that this element contains the set of check items. It is required to be
set to 'checkItems'-->
<item name="" forEvent="">
<!--name - defines the check item name
forEvent - de fines the set of transitions that this check item is required. Accepts a
',' separated list-->
<permissions>
<permission roles=""/>
<!--roles - defines the set of roles that has the ability to check/un-check this check item-->
</permissions>
<validations>
<validation forEvent="" class="">
<!--forEvent - defines the event that the custom validation should be done
class - defines the full qualified name of the custom validations class -->
<parameter name="" value=""/>
<!--name - defines the custom parameter name
value - defines the custom parameter value-->
</validation>
</validations>
</item>
</data>
<data name="transitionValidation">
<!--name - defines that this element contains the set of transition validations. It is required to be
set to 'transitionValidation'-->
<validation forEvent="" class="">
<!--forEvent - defines the event that the custom validation should be done
class - defines the full qualified name of the custom validations class -->
<parameter name="" value=""/>
<!--name - defines the custom parameter name
value - defines the custom parameter value-->
</validation>
</data>
<data name="transitionExecution">
<!--name - defines that this element contains the set of transition executions. It is required to be
set to 'transitionExecution'-->
<execution forEvent="" class="">
<!--forEvent - defines the event that the execution should be done
class - defines the full qualified name of the execution class -->
<parameter name="" value=""/>
<!--name - defines the custom parameter name
value - defines the custom parameter value-->
</execution>
</data>
<data name="transitionUI">
<!--name - defines that this element contains a reference to a transition UI. It is required to be
set to 'transitionUI'-->
<ui forEvent="" href=""/>
<!--forEvent - defines the event that the UI should be displayed for
href - the hyperlink of the page to open on the browser -->
</data>
<data name="transitionPermission">
<!--name - defines that this element contains the set of transition permissions. It is required to be
set to 'transitionPermission'-->
<permission forEvent="" roles=""/>
</data>
<data name="transitionScripts">
<!--name - defines that this element contains the set of transition scripts. It is required to be
set to 'transitionScripts'-->
<js forEvent="">
<!--forEvent - defines the event that this script block will execute-->
<console function="">
<!--function - defines the name of the function-->
<script type="text/javascript">
<!--contains the script-->
</script>
</console>
<server function="">
<script type="text/javascript"></script>
</server>
</js>
</data>
</datamodel>
<transition event="" target=""/>
<!--event - defines the name of the transition event
target - defines the next state of the transition-->
</state>
</scxml>
</lifecycle>
</configuration>
</aspect>
The lifecycle configuration gives the user the ability to define custom validations. This can be done by providing a custom class for the class parameter in the following element. The class attribute in the above element should be filled with the full qualified name of the custom class. For example, org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle.
<validation forEvent="" class="">
<parameter name="" value=""/>
</validation>
The user can either use one of the Supported Standard Validators or implement the org.wso2.carbon.governance.registry.extensions.interfaces.CustomValidations interface which has the following structure. The values in the parameter elements are passed to the init method of the custom class at runtime.
public interface CustomValidations {
void init(Map parameterMap);
boolean validate(RequestContext context);
}
Similarly, users can also define executions that would be invoked as a result of a transition.
<execution forEvent="" class="" >
<parameter name="" value=""/>
</execution>
The user can either use one of the Supported Standard Executors or implement the org.wso2.carbon.governance.registry.extensions.interfaces.Execution interface which has the following structure. The values in the parameter elements are passed to the init method of the custom class at runtime.
public interface Execution {
void init(Map parameterMap);
boolean execute(RequestContext context, String currentState, String targetState);
}
The user can also define customized user interfaces to assist the transition operations. Please read about the Default Transition UI.
Note
The configuration model which was used in previous Governance Registry releases is still supported.
See also Lifecycle Configuration Elements.