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.

Upgrading Oracle SOA Suite 10.3.1 to 10.3.4

In our last blog entry we went through the process of installing Oracle's SOA Suite 10.3.1, which is the base install for the SOA Suite product. In this entry we'll perform the upgrade from 10.3.1 to 10.3.4 which is the latest version of the SOA Suite product in the 10 series.

• To begin download the desired 10.3.4 patch from the following location ().

• Once downloaded unzip it to a temporary folder on your local hard disk.

The first thing that is required before running the upgrade is to perform the Database schema upgrade. In the 10.3.4 patch there is no nice program to do this like there is in the base installer (irca). To do this follow these steps.

Note: Ensure the following environment variables are set

• ORACLE_HOME=

• ORACLE_SID=XE

Lets start off with the ESB Upgrade:

• Using a command prompt navigate to the following folder (/OracleInstall/Oracle10.3.4_Patch/Disk1/install/soa_schema_upgrade/esb/sql/other).

• Connect using sqlplus as your system user

• Once connected type @upgrade_10131_10134_oracle.sql

Now lets do the BPEL Upgrade:

• Using a command prompt navigate to the following folder (/OracleInstall/Oracle10.3.4_Patch/Disk1/install/soa_schema_upgrade/bpel/scripts).

• Connect using sqlplus as your system user

• Once connected type @upgrade_10131_10134_oracle.sql

Now that both the BPEL & ESB Schemas have been upgraded its now time to run the binary upgrade.

• Navigate to the following folder (/OracleInstall/Oracle10.3.4_Patch/Disk1/install).

• Execute the ./runinstaller (Program File) and follow the GUI prompts. This process will take you through the same process as the base installer did. Once the install and configuration has completed your system will now be upgraded to 10.3.4.

How do I know my SOA Suite has been upgraded?

• Using a browser, navigate to (http://localhost:8888/em) connect using oc4jadmin user and whichever password was used during the base install.
• Click on About and you should see a window pop up which reads Oracle ESB Control 10G Version 10.1.3.4.0.

Installing Oracle SOA Suite 10.3.1

We at MagicLamp Software have been working on two SOA related projects for one of our largest clients. We are using Oracles SOA Suite 10.3.4 for this project, so this entry will explain how to properly install Oracle SOA Suite 10.3.1 and the following entry will explain how to properly apply the patch from 10.3.1 to 10.3.4.

• To begin download the Oracle SOA Suite 10.1.3.X from (http://www.oracle.com/technology/software/tech/soa/index.html). We have installed this product on both Windows XP and Linux.

• Once downloaded, unzip the archive to a temp folder.

• Before installing you will require a database to hold your ESB / BPEL / WSM artifacts for this we have used Oracle XE. Oracle XE for Windows can be downloaded from here (http://www.oracle.com/technology/software/products/database/xe/index.html). If installing Oracle XE on Ubuntu Linux read (http://www.oracle.com/technology/tech/linux/install/xe-on-kubuntu.html) to find out how to perform the install using apt-get.

• Once your Oracle XE Database is installed bring up the APEX console by typing the following command in a web browser (http://localhost:8080/apex). Sign in using your system account and click on the following images, Administration / Database Users.

• From here you are going to create three new user accounts (ORABPEL, ORAESB, ORAWSM), also ensure that as you create these accounts, each user should have the CONNECT, RESOURCE and DBA Roles checked.

• Next, using SQL Developer or SQLPlus run the following commands as the system user

alter system set sessions=250 scope=spfile;
alter system set processes=200 scope=spfile;
commit;

• Before going any further please ensure that you have the two following environment variables set ORACLE_HOME (Which points to the home folder of your Oracle XE database) and JAVA_HOME (Which points to the home folder of your installed Java Virtual Machine).

• The next step is to run a program called irca. Irca will populate the schema for the SOA Suite. As irca runs it will look for your ORACLE_HOME setting, it will look for your JAVA_HOME setting and lastly will ask for your database connection settings host port and sid. These values should be localhost 1521 and XE. Once connected the script will then start asking for the user name and password for schema's that were created above.

• To run irca navigate to the following folder (/install/soa_schemas/irca). From here you will want to run icra.sh for Linux or irca.bat for windows. Follow the prompts accordingly.

• Once completed your ORABPEL, ORAESB, ORAWSM schema should now be populated. Now you are ready to run the SAO Suite Installer.

• To run the SOA Suite 10.3.1 Installer navigate to this folder /install. For windows execute the 'runinstaller.bat' file. For Linux execute the following command ./runInstaller.sh -ignoresysprereqs, this will allow you to install on another version of Linux.

• From here you will simply navigate through the prompts, we suggest advanced setup and try not to change the ports if possible the default port should be 8888 and along the way you will need to supply the user names and passwords for the schemas created above. In addition you will need to supply the username and password for the Oracle system user. This is so that the configuration tool can install the HR Schema used in all of the tutorials supplied.

• Once the installer completes, the configuration tool will automatically begin. Allow this step to complete and then the entire install should be finished.

• To start the SAO Suite in windows (Start, All Programs, Oracle ESB, Start Server). In Linux from a command prompt type (//product/10.1.3.1/OracleAS_1/opmn/bin/opmnctl startall).

• To Stop the SOA Suite in Windows (Start, All Programs, Oracle ESB, Stop Server). In Linux from a command prompt type (//product/10.1.3.1/OracleAS_1/opmn/bin/opmnctl stopall).

• What you will see. Once the server has been started launch a web browser and type http://localhost:8888/em (Enterprise Manager) you should see JDBC resources / Data Sources and Connection Pools created. Then navigate to the ESB Consule http://localhost:8888/esb (Enterprise Service Bus Console) you should see an entry called Default.

Welcome to the MagicLamp Corner

Hi there and welcome,

This blog will be maintained and visited frequently by the staff of MagicLamp Software. The goal of this blog is to provide answers to various technical issues as they arise in our everyday consulting world and share them with others.