Using Jenkins for SOA Deployment Automation

  Last month, my client wanted me  to have a framework for automating the builds.Already the build scripts were in place. Because of the amount of changes/code fixes that different teams were checking in, the situation called for daily/frequent builds to be initiated.To make my customers job easy I was on the lookout for automating the deployments using a GUI automation tool. In my previous project we had used Cruise Control. After comparing different automation tools, I decided on Jenkins (Hudson) a more light weight easy to use tool and having strong support base.

To get started download Jenkins.war file from http://jenkins-ci.org/

There are 2 ways in which you can use Jenkins

1. Run Jenkins in Winstone servlet container

The easiest way to execute Jenkins is through the built in Winstone servlet container. You can execute Jenkins like this:

Set JAVA_HOME

Then run java -jar jenkins.war

Accessing Jenkins

To see Jenkins, simply bring up a web browser and go to URL http://myServer:8080 where myServer is the name of the system running Jenkins.

2. Deploy  Jenkins into Weblogic server

The Jenkins.war cannot be deployed to Weblogic server without some changes. These are necessary because of Weblogic's proprietary class loaders which behave differently compared to Tomcat, JBoss, et. al.

Refer the  steps @ https://wiki.jenkins-ci.org/display/JENKINS/Weblogic

 

Once the web app is up and running.

In Dashboard --> Create New Job 

Add steps to Execute shell scripts and build files

Once the build is initiated the log entries and progress of build can be monitored in the Console output.

If you ask me which automation tool to pick for your project my answer will be Jenkins.

Compilation issue with MDS repository

Recently while migrating the code from DEV to Test environment, customer had issues with respect to MDS repository. Since the customer was using MDS for the first time there were many queries on how the migration will work, the amount of work involved in the process of migration. They had used MDS store as the common repository for all the artifacts (DVM,XSD’s,XRef). The different processes refer these artifacts from MDS.

The build scripts are being used for the compilation /deployment of processes to the Server. During compilation build script looks up adf-config.xml to get the MDS store connection details. Everything works fine when customer uses connection string/username/pwd in adf-config.xml.

As a pre-requisite for migrating codebase, all the shared artifacts@ MDS were migrated to the new environment. So for compilation, the team was planning to use the new environment MDS details, but customer was not willing to expose the MDS store credentials in different process files.

These are some approaches that we tried out for resolving the issue and completing the deployment to the new environment.

1.    First approach was to mention jndi-datasource as mentioned in release notes  @ http://download.oracle.com/docs/cd/E17904_01/relnotes.1111/e10133/soa.htm

If the MDS database has a JNDI name, then use the following entries in adf-config.xml:

<metadata-store

  class-name="oracle.mds.persistence.stores.db.DBMetadataStore">

     <property name="jndi-datasource" value="${db.jndi.name}"/>

     <property name="partition-name" value="soa-infra"/>

Here db.jndi.name = jdbc/mds/MDS_LocalTxDataSource , the JNDI name of mds-soa datasource.

But this did not work out as the build scripts were not able to look up the JNDI from the server.

The error stacktrace while compiling the process.

     [scac]     at oracle.adf.share.config.ADFContextMDSConfigHelperImpl.createMDSSession(ADFContextMDSConfigHelperImpl.java:50)

     [scac]     ... 26 more

     [scac] Caused by: oracle.mds.config.MDSConfigurationException: MDS-01330: unable to load MDS configuration document

     [scac] MDS-01329: unable to load element "persistence-config"

     [scac] MDS-01370: MetadataStore configuration for metadata-store-usage "mstore-usage_2" is invalid.

     [scac] MDS-00922: The ConnectionManager "oracle.mds.internal.persistence.db.JNDIConnectionManagerImpl" cannot be instantiated.

     [scac] MDS-00929: unable to look up name "jdbc/mds/MDS_LocalTxDataSource" in JNDI context

     [scac] Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

This approach was a failure. Not yet fully incorporated into 11g build scripts.

         

2.       Use any file based repository and complete the deployment. The Compilation process will look up the adf-config.xml for using the MDS store details to validate the XSD’s referred in the process. Place all the XSD’s referred by the process in a machine and specify the path in metadata-path.

          File –based repository can be referred in adf-config.xml as below.

            <metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore">

              <property value="/GEO_BUILD/mdsutil"  name="metadata-path"/>

              <property value="seed" name="partition-name"/>

3.       Use any dev MDS repository connection details and complete the deployment. The Compilation process will look up the adf-config.xml for using the MDS store details to validate the XSD’s referred in the process.

            <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">

              <property value="DEV_MDS" name="jdbc-userid"/>

              <property value="password" name="jdbc-password"/>

              <property value="jdbc:oracle:thin:@//localhost:1522/GEODB"

                        name="jdbc-url"/>

              <property value="soa-infra" name="partition-name"/>

            </metadata-store>

This 2 & 3 approaches will work fine because the adf-config.xml details are used only during compilation /validation. At runtime the BPEL engine will refer the artifacts directly from MDS store configured in the environment.

Hope this helps.

How to export shared artifacts from MDS

   As a best practice in projects, shared artifacts like WSDL’s/XSD’s/DVM’s are stored in MDS. It is really difficult to maintain consistency of these files in case multiple updates are made on these files. All developers will be familiar with the use of version control, where first step would be to get the latest from the Repository and make modifications to the source code and commit the changes. Similar approach needs to be followed here, where exportSharedData task in ant-sca-deploy.xml needs to be used to get all the latest artifacts in a jar file. Extract the files and update your local folders.

Initial steps include setting of environment variables.

set ORACLE_HOME=D:\Oracle\Middleware

set ANT_HOME=%ORACLE_HOME%\jdeveloper\ant

set PATH=%ANT_HOME%\bin;%PATH%

set JAVA_HOME=%ORACLE_HOME%\jdk160_18

You can always export the artifacts from MDS using the exportSharedData ant task.

>> ant -f ant-sca-deploy.xml exportSharedData -DserverURL=server.url -DjarFile=jar.file -Dpattern=pattern ex/** -Duser=username –Dpassword=pwd

• exportSharedData :: is the ant task in ant-sca-deploy.xml
• serverURL  ::The URL of the server that hosts the SOA Infrastructure application (for example, http://hostname:8001).
• jarFile :: The absolute path of the JAR file to be generated. (C:\temp\dvm.jar)
• pattern :: The file pattern supported by MDS transfer APIs. Use the semicolon delimiter (;) if multiple patterns are specified.

Exclude the shared data namespace /apps in the pattern.

 For example:
/dvm/**;/xref/**
This example exports all documents under /apps/dvm and /apps/xref.

• user ::  The user name for accessing the server
• password  :: The password for accessing the server

Thanks to Edwin for all the help.