Friday, August 21, 2009

Production Deployments of your ESB Applications

By now you probably have been working away for quite sometime using JDeveloper to build your Adapters, Web Service calls and chaining them all together with Routing Services.

So far life has been pretty easy, but what happens when its time to deploy your project to a production environment? You have network issues to consider, possibly firewall rules to contend with and what about user credentials in general. If that is not enough to think about there is also the issue of keeping track of the correct version of the code base being deployed. Keep in mind that ESB code cannot be nicely archived up into a pretty ear file like those of web based applications.

So how does MagicLamp deal with going to production? We have found that the best solution for this is to implement ant tasks, build scripts and version control tagging.

The following steps assume that everything is local to the current project. If the project is using XSL or WSDL files located on an external server then a pre-compile target should be created which will perform multiple ‘customizeDocument’ ant task’s on files to ensure that the schema location is set properly.

Step 1 (Create Deployment Plans): By creating a deployment plan what you are in fact doing is creating one large xml file which contains the xml representation of all of the single ‘esbsvc’ files located in your project. This includes all of the JCA operations and properties associated with each service. It is very important to note that every time JCA related information changes in a service by JDeveloper that the user re-run the deployment plan ant task so that the new changes are reflected in the deployment plan xml file.

Step 2 (Un-deploy ESB Entities): Un-deploying the ESB Services task can take sometime to generate. This task is based on the GUIDs of the services themselves, so it is very important that as new services get created in JDeveloper a corresponding un-deploy esb entity entry be created in the un-deploy target for the project.

Step 3 (Deploy ESB Suitcase): The deploy ESB Suitcase is the main ant task used to send the entire project to the ESB server. This task requires the following properties

Esbmetadataserverhostname: The host url of the Oracle ESB Application server.

Esbmetadataserverport: The port that the Oracle ESB Application server is listening on.

Sourcedirectory: The directory that the project source is located

Deploymentplanfilename: The corresponding deployment plan created for the source directory.

Forceddeployment (true / false): A true of false value forcing the esb server to take the new service.

Step 4 (Source Control Tagging): Once the final version of the project has completed QA and gone to production it is very important to tag the source control versioning system accordingly. This will ensure that if required, the deployment team will be able to get back to a particular version of a project that is in production.

Some last thoughts on deployments. When re-deploying an ESB application / project it is best to first look into the j2ee//persistence folder of the application server for any signs of contention that may have occurred during the running of the desired project. Contentions are stored in this area and should be dealt with before any redeployment should happen. By default there should be nothing in this folder.