WSO2 Governance Registry - Lifecycle Management Part 1 - Check Items

The Lifecycle Management(LCM) plays a major role in SOA Governance. The default LCM supported by the WSO2 Governance Registry allows users to promote and demote life cycle states of a given resource. Furthermore, it can be configured to use checklists as well check out the documentation here.

The Lifecycle configuration templates allows advance users to extend its functionality through 6 data elements which are listed below
  • check items
  • transition validations
  • transition permissions
  • transition executions
  • transition UI
  • transition scripts
Bellow is the full template of the lifecycle configuration. in this article series we will take a look at each item and see how they can be used to customize lifecycle management in WSO2 Governance Registry. In this article we will look at check items. 

check items

Check items allow you to define a list, ideally an check list that can be used to control changes in lifecycle states and make sure specific requirements are met before the lifecycle is changed to the next state. It is also possible to
  • Define permissions for each check item
  • Define custom validations for each check item
To check this out we will create a sample lifecycle with a new set of check items. First we have to create a new  lifecycle. The steps to create a new lifecycle can be found here - Adding Lifecycles. There will be a default lifecycle configuration when you create one using the steps since it is a complex configuration we will replace it with the following configuration. 

<aspect name="SimpleLifeCycle" 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="Promote">
                               <permissions>
                                    <permission roles="wso2.eng,admin"/>
                                </permissions>
                                <!--<validations>
                                 <validation forEvent="" class="">
                                         <parameter name="" value=""/>
                                 </validation>
                                </validations>-->
                            </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>

As you can see several check items are listed below the "Development" and "Tested" states, the two main attributes in the check list data item is name and forEvent. 

name - The name of the check item, this is the text that will be displayed for the check item.
forEvent - The event that is associated with this check item, for example if the forEvent is set to "Promote" this check item must be clicked in order to proceed with the promote operation for that state.

Custom permissions

As you can see in the "Development" state there is a sub element as follows
 
<permissions>
     <permission roles="eng,admin"/>
</permissions>

In this element it is possible to define a set of roles that are allowed to check this check item. in this sample only engineers and admins are allowed to check this item

Custom validations
 
<validations>
     <validation forEvent="" class="">
          <parameter name="" value=""/>
     </validation>
</validations>>

As seen in the commented out section under the "Code Completed" check item it is also possible to define custom validations. But the validations will only be called when during a state transition. we will look into custom validations under "transition validations" in the next post. 

Now you can save the newly created lifecycle configuration and use it in an artifact like an "api" or "service" and see its functionality.

We will look at Transition Validations and how to use them in the next post of this series.

Comments

Popular posts from this blog

Writing Unit Tests to test JMS Queue listener code with ActiveMQ

Reading and Writing Binary files in java - Converting Endianness ( between Big-endian byte order and Little-endian byte order)

Setting up Heron Cluster with Apache Aurora Locally