Extending the Framework server and Orchestration

The MidVision tooling can be used in a number of ways to leverage your existing assets. These range from having the ability to run existing scripts standalone to writing your own RapidDeploy tasks or even plugins.

Below we detail some of the options.

Leveraging your own scripts repository

The tool can run any script assets you currently maintain. Additionally, the MidVision tool can be used to manage these scripts, by allowing them to be stored and deployed from a configuration management tool in a controlled way to targrt environments, just as you would code.

You can configure the script to run with different parameters per target environment. Environment variables can be either picked up from the target users shell or set on a per environment basis or a combination of both.

This is well demonstrated in the Hello World Application.

Using ANT Scripts

RapidDeploy allows you to create and run ANT scripts similarly to shell/perl/bat scripts above. You can also specify ANT properties on a per environment basis. If you are familiar with ANT, you can also write your own ANT tasks and add these to your script.

Writing your own Orchestration Task

It is also possible to write your own Orchestration tasks and make these available through the Framework server GUI for anyone in your organisation to use.

Orcheatration tasks are written in the Java programming language. The following links detail how to write a simple task.

Set up a workspace and run a skeleton task:

Writing a RapidDeploy Java Task Part 1.

Add functionality to the task:

Writing a RapidDeploy Java Task Part 2.

Writing a Plugin

A plugin can consist of one or more of the following components.

  1. A set of Orchestration tasks (discreet functionality that runs on a target server) and a tasksMetaData.xml defining the task options and help data
  2. For a product plugin, an implementation of the Product API (including java code and screen definition and help in XML format), for example the WebSphere 7.0 plugin - defines for each project where this plugin is selected, the location of ear, config files in the project.
  3. For a product plugin, An implementation of the Environment API (including java code and screen definition and help in XML format) for example the WebSphere 7.0 plugin - defines for each target environment on this screen, attributes to snapshot the environment including the target IP address, ports, key/trust stores etc.
  4. For a product plugin, a number of implementations of the Template API, allowing an end user to generate environment template for this product. For the WebSphere plugin, cell, cluster, application etc templates are provided.
  5. For toolchains, one or more of the SCM, Artifact, Remoting, or Build APIs (including java code and screen definition and help in XML format)

A plugin is typically bundled into a jar file containing all of the above components. It is integrated with the framework server by dropping the jar file into the plugins directory (${MV_HOME}/lib.