This post applies to G-Reg 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. This post discuss about the default executors that we have included in the Governance Registry distribution. To get more information about executors, please refer
this.
We have 3 default executors in G-Reg. From this post, I'm planning to give an overview about these executors.
- Service version executor
- Demote action executor
- Copy executor
Service Version Executor
The main functionality of this executor is to version services and dependent resources of services(wsdl,schema and policy) when a lifecycle promote action happens. This executor was introduced to G-Reg with the service version functionality implementation. To get an idea about this executor, we need to have some idea about the service version functionality of G-Reg.
Service Versioning
In G-Reg, we have introduced the ability version services and its dependent resources as an part of lifecycle management of the service. With this improvement, a service in G-Reg are kept in 3 environments when it is governed using the default service lifecycle.
- Trunk
- Branches/testing
- Branches/production
Each of these environments are correspond to a lifecycle state in the default service lifecycle. The default service lifecycle in G-Reg has 3 states.
- Development
- Testing
- Production
The service version functionality happens in the following way.
- At creation, the service resource(and its dependent resources) will be placed in "trunk" environment. The path structure of the service resource is like - "trunk/services/{namespace}/{name}". We limit the creation of 2 services with the same name and namespace in this environment.
- All the services in "trunk" environment are on "development" state of the lifecycle.
- When a "promote" action happens, a UI is displayed to the user to enter the new versions of the service and its dependent resources(This is done using the "transition UI" functionality of G-Reg which I will be covering in another blog post).
- After completing the above action, the service and its dependent resources are moved to "branches/testing"environment. The path structure of a service resource in this environment is like - "branches/testing/{namespace}/{version}/{name}". In this environment, we create a collection with the version that the user has given and because of that, we allow users to keep multiple versions of the same service in this environment.
- With the above step, we do some additional processing and update the dependencies with the new paths and also update the version filed in the service to reflect the new version.
- Promotion from "Testing" state to "Production" state is similar to step 3,4 and 5. All the services and the its dependencies are moved from "branches/testing" to "branches/production" environment.
The service version executor is the one who does steps 4,5 and 6 when a promote transition happens. It is written in a way such that a user can change the environments from the lifecycle configuration. To get some idea about this, we need to look at the configuration of the service version executor.
Here you will notice several "parameter" elements. We focus our attention on 2 of these which are,
- currentEnvironment
- targetEnvironment
The target environment parameter is the one who decides what is the next environment that the service is placed on. In other words, these 2 parameters say that, take the resource out from "/_system/governance/trunk/{@resourcePath}/{@resourceName}" and place it in "/_system/governance/branches/testing/{@resourcePath}/{@version}/{@resourceName}" path. By changing this configuration, an user has the ability to change the environments based on their requirement.
Also one important fact to note about this executor is that it is media type aware and it works only for services.
Demote Action Executor
The demote action executor in G-Reg 4.1.1 does not do any copying of the resources to the previous environments. We have identified that the demote action requirement varies from one user to another. The ideal demote action would be to redirect the user to the resource in the previous environment but that is again challenging because there can be multiple versions of the same service in the previous environment.
Therefore, we have introduced a demote action executor to avoid changing the lifecycle state when the demote action is performed for service in a particular state. In other words, this executor does not do anything apart from keeping the same lifecycle state when the demote action is preformed.
Copy Executor
The idea behind the copy executor is to do a basic copy of resource from the given location to another. This executor has the ability to work with any media type and it is not media type aware. This executor does a basic copy operation(registry API copy operation) of that resource and it does modify the content or make associations like the service version executor.
The configuration element of the copy executor is somewhat similar to the service version executor.
Here you will find 2 parameters called the "currentEnvironment" and "targetEnvironment". These parameters work in the following way. The copy executor will copy any resource that is inside "currentEnvironment" to the corresponding path in the "targetEnvironment".
Eg: - Say that you have a resource in the following path.
"/_system/governance/e1/foo/bar/xyz".
When the user applies a lifecycle (that is configured with the copy executor with the above configuration parameters) to resource "xyz" and do a promote operation, the copy executor will copy that resource to the following path.
"/_system/governance/e2/foo/bar/xyz"
