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

Post a Comment

Popular posts from this blog

Setting up Heron Cluster with Apache Aurora Locally

Image
In this post we will be looking at how we can setup Heron steam processing engine in Apache Aurora in our local machine. Oh Boy this is going to be a long post :D. I am doing this on Ubuntu 14.04 and these steps should be similar to any Linux machine. Heron supports deployment in Apache Aurora out of the box. Apache Aurora will act as the Scheduler for Heron after the setup is complete. In order to do this first you will have to setup Apache Zookeeper and allow Heron to communicate with it. Here Apache Zookeeper will act as the State Manager of the Heron deployment. if you just want to setup a local cluster without the hassle of  installing aurora take a look at my previous blog post -  Getting started with Heron stream processing engine in Ubuntu 14.04 Setting Up Apache Aurora Cluster locally  First thing we need to do is to setup Apache Aurora locally. I will try to explain as much of the configurations as i can as we go on. First lets get a Apache Aurora cluster running on our
Read more

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

Image
In this post we will look into working with binary files in java. The end goal of the post will be to create simple java application that reads a binary file and write it back to a different binary file. The difference between the two files would be the byte order. If we read in a file with Big-endian byte order we will write it back with a Little-endian byte order and vice-versa. Lets first understand what is meant by byte order and what Big-endian and Little-endian are. If you are already familiar with this you can skip this section of the post You can find the complete code for Binary format converter that is explained in this post at GitHub -  https://github.com/pulasthi/binary-format-converter Understanding byte order and Endianness The endianness refers to the order that bytes are stored when storing multi byte values such as Integers and Doubles this is also known as the byte order. The endianness does not have any meaning when you consider a single byte that is s
Read more

Writing Unit Tests to test JMS Queue listener code with ActiveMQ

During my GSoC project for OpenNMS i did some work with JMS and wanted to write test classes to make sure that my code was working well. In this article i will try to explain how you can use ActiveMQ to write test cases for your JMS code. This is very handy when your code has a part that listens to a JMS queue. Apache ActiveMQ  Apache ActiveMQ is a extremely popular and very powerful open source messaging and Integration Patterns server. You can check it out here . The part we will be using to run our test classes is the embedded broker that is provided by ActiveMQ. This allows you to create a temporary broker for test purposes to create a JMS queue in our case. If you want to learn more about the embedded broker check out this article . The easiet way to create a embedded broker is through the following code line. This will automatically create a embedded broker. ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("vm://localhost?broker.persistent=false"
Read more