Automatic for the People: Governance Automation
DavidSeager 110000C5XS Visits (1710)
One of the powerful features of WebSphere Service Registry and Repository (WSRR) is the customization. One such avenue for customization is the Configurable Modifier that I have touched on before. This can be used to automate some steps in the default governance process and save your WSRR users some clicks. In this post I show how you can automate the creation of a version and Service Level Definition when a business service is approved.
So what is the Configurable Modifier?
The Configurable Modifier (CM) is an XML driven modifier, which can change content in WSRR in reaction to things happening, such as creation, update, delete, transition of objects in WSRR. The WSRR Governance Profile uses the CM extensively to place objects into life cycles when the object is created. The rules say if an object of type X is created, then run an action which will govern the object and place it into life cycle Y. In such a way we map objects to their life cycles. The rule file which contains the "what actions to run when things happen" rules is called Triggers.xml. The actions themselves are stored in separate files. All of these files are configuration in the WSRR profile of type
However you can also code your own CM rules. A good action is to, when a business service is approved, automatically create a version and an SLD on that version. Approving a business service means that the organization will develop an implementation of the service, so the next thing that generally happens in the workflow is that a version is created.
<?xml version="1.0" encoding="UTF-8"?> <act
The first create-action section creates an entity of type SLD and assigns it to variable $2. You can see that the name is set to "SLD - name of service (1.0.0)", the namespace is set to the namespace of the trigger object (which is the service) and the description set to something appropriate.
The second create-action creates a service version and assigns it to variable $1. The name is the same as the business service, the description appropriate and the version set to "1.0.0". The owning organization is set to that of the business service by finding the owning organization of the business service. The relationship that has an SLD is set to point to the SLD created in the first create-action, by referring to the variable $2.
Finally the update-action updates the business service to point to the version by adding the variable $1 to the end of the versions relationship.
You can load the above as a Configurable Modifier config item and give it any name. Then to make the action work you edit the Triggers config item (found in the Web UI Configuration perspective in the menu Active Profile - Modifiers - Configurable Modifier) and add the following to the end:
The trigger rule means that when a business service is pushed through the approve charter transition, so it is approved, the action is run and a new version and SLD are created.
Download the Gene