In my previous posts, I have explained about the lifecycle management functionality in WSO2 Governance Registry. These posts covered a variety of topics ranging from the configuration model to its extension points. Executors are one such extension point and I have given an introduction to executors and about the default executors in couple of my previous posts.
This post explains about the default copyExecutor that is shipped with WSO2 Governance Registry 4.5.0. First, lets look at the code of the copyExecutor. You can find the original code segment using this link (which in located in WSO2 code base).
Before explaining the copyExecutor code, we need to get an understanding about how to configure the copyExecutor. The copyExecutor is designed to do one specific registry operation. That is to do an copy operation of a resource from one location to another. With the lifecycle configuration model of WSO2 Governance Registry, we are able to pass parameters to an executor class and because of that, we have made those resource paths (the source path and the target path) configurable from the lifecycle configuration. So altogether the copyExcutor has the following configurations.
Let us go through the copyExecutor code and see how we have implemented these.
In one of my earlier posts, I explained that each executor must implement the Execution interface. This interface has 2 methods.
Finally, we do all the other operations such as doing the copy operation and copying tags,ratings,comments and associations.
As you all can see, the copyExecutor has a simple code but has a great set of use cases. During this webinar we used the same copyExecutor to copy artifacts from one environment to another. Likewise it has many use-cases when it comes to governance scenarios.
This post explains about the default copyExecutor that is shipped with WSO2 Governance Registry 4.5.0. First, lets look at the code of the copyExecutor. You can find the original code segment using this link (which in located in WSO2 code base).
Before explaining the copyExecutor code, we need to get an understanding about how to configure the copyExecutor. The copyExecutor is designed to do one specific registry operation. That is to do an copy operation of a resource from one location to another. With the lifecycle configuration model of WSO2 Governance Registry, we are able to pass parameters to an executor class and because of that, we have made those resource paths (the source path and the target path) configurable from the lifecycle configuration. So altogether the copyExcutor has the following configurations.
- Source path
- Target path
- Copy comments
- Copy tags
- Copy ratings
- Copy associations
In one of my earlier posts, I explained that each executor must implement the Execution interface. This interface has 2 methods.
- void init(Map parameterMap)
- boolean execute(RequestContext context,String currentState,String targetState)
Out of these 2, the init method is called when we parse the lifecycle configuration and initialize the aspect. Also this method gets the static parameters we defined in the lifecycle configuration. Hence in the copy executor, we pass these parameters and we keep track of them using several variables.
The execute method is called when we invoke a lifecycle operation. Inside this method, we do all the operations. The copyExecutor has the ability to append a version to a given path and these versions can be sent from the Management Console. Hence inside this execute method, we read the parameters that were sent from the UI and create a path according to them. The underlying code segment is as follows.
After that we are checking whether the resource path is in the given current environment. If not, we can not proceed further in the code but the executor should not fail. Hence we return "true" to inform the lifecycle implementation that the executor executed successfully.
As you all can see, the copyExecutor has a simple code but has a great set of use cases. During this webinar we used the same copyExecutor to copy artifacts from one environment to another. Likewise it has many use-cases when it comes to governance scenarios.
No comments:
Post a Comment