Lifecycle extentions in WSO2 G-Reg - Part 1

This post applies to WSO2 Governance Registry 4.1.1 and upwards.

As you all know, WSO2 Governance Registry supports adding extensions to the execution logic of a lifecycle.This blog post covers about one particular extension point which is called an executor.

From this post, I'm planning to cover the following topics.

1. What is an Executor
2. How to write a Executor
3. Add a custom Executor to a lifecycle

What is an Executor

In WSO2 Governance Registry lifecycle model, there are several extension points that one can use to plug there own execution logic. There are several types of pluggable extension points. One of them is called the "executor". An executor is an execution logic that is executed once a state transition happens in a lifecycle.

How to write an Executor

Writing an Executor in G-Reg is very easy. We have an interface called "Execution" in G-Reg which can be found in "org.wso2.carbon.governance.registry.extensions" bundle. This interface has 2 methods.

• void init(Map parameterMap)

This method is called when the execution class is initialized. All the execution classes are initialized only once.
@param parameterMap Static parameter map given by the user. These are the parameters that have been given in the lifecycle configuration as the parameters of the executor.
Eg:- 
   

The parameters defined here are passed to the executor using this method.

• boolean execute(RequestContext context,String currentState,String targetState)

This method will be called when the invoke() method of the default lifecycle implementation is called. Execution logic should reside in this method since the default lifecycle implementation will determine

the execution output by looking at the output of this method.


@param context The request context that was generated from the registry core for the invoke() call. The request context contains the resource, resource path and other variables generated during the initial call.

@param currentState The current lifecycle state.

@param targetState The target lifecycle state.

@return Returns whether the execution was successful or not.

To write a custom executor, an user has to implement this interface and add the custom logic inside the execute method. The runtime will execute all the executors that is registered against a particular event an a particular state.

Add a custom Executor to a lifecycle

Adding an Executor to a lifecycle has several steps to follow. 

1. Compile the class and create a jar file out of it
2. If the jar file is an OSGI bundle add it to "GREG_HOME/repository/components/dropins" folder and if the jar file is not an OSGI bundle then add it to "GREG_HOME/repository/components/lib" folder. Here what we did is that we added the executor implementation to the classpath of the G-Reg server. 
3. Add the executor to the lifecycle configuration. Following is a segment of a lifecycle configuration that has an executor. 

There are 3 things that we need to focus our attention on. 

1. The event that we register the executor - defined by the "forEvent" attribute of the execution element.
2. The class of the executor - defined by the "class" attribute of the execution element.
3. Static parameters that is passed to it(optional) - defined by the "parameter" elements of the execution element. 

Using these configurations, an user has the ability to attach their own execution logic to a lifecycle in G-Reg.