Wouldn't it be nice to see what particular version you have deployed on your SOASuite test or production environment. How often does it occur that you thought you solved a problem but it still does not work on test or production. And after doing loads of tests and investigation you encounter that not the version you expected was deployed?

This week I tried to add the svn Id keyword in a piece of comments in the WSDL of the service. But it turns out that at deployment the SOASuite filters out the comments. So that won't work.
But since I'm writing this blog you might expect I found a trick...

First add the svn keywords  to the files you want to have the properties in. In this particular case it would be the service wsdl. This can be done with Tortoise SVN by right clicking the file, and choose TortoiseSVN->Properties. Then clicking the new button you can choose for Keywords:


 After that you can check the SVN properties you like to use. For most cases ID gives you all the info you need.
 Clicking OK will get you back to the properties screen, where you'll see:

Mark that in the list of checkboxes the Id-keyword is all in capitals, while in the comma-seperated list of keywords in the properties pane, the Id-property is in the correct spelling (one capital I).
The trick is to add the property as a namespace declaration as:

  xmlns:svnid="$Id$"
  xmlns:version="1.1"

After a SVN-commit this will expand to:

  xmlns:svnid="$Id: ImportEquipment.wsdl 765 2012-06-08 13:07:10Z makker $"
  xmlns:version="1.1"

Like such:

The reason I added a "version" namespace as well is that your wsdl will not change every time the service changes. Often you change a bit of BPEL or XSL or something like that, while your interface, the wsdl, stays unchanged. To force SVN increase the revisionid in your wsdl, you can change the xmlns:version namespace.

Here and there migrate/upgrade projects for SoaSuite10g to SoaSuite11g are running. Most of the time the source is committed to Subversion. It turns out that JDeveloper makes a full copy of the project folder at upgrade.
This means that also the .svn folders are copied. And you probably don't want that. I would have the new project in a different branch in my subversion folder.

At a former customer there was a registry file that creates a menu item in the Windows explorer pop-up menu. This would hierarchically delete all .svn folders in the selected folder. But not allways you're able to install such a shell-command.

So I created a little ant script. Since we're working with JDeveloper11g, we have an Ant install. I also created a windows bat file to run the ant script with a folder that can be given as a command line parameter.

The build.xml:

<?xml version="1.0" encoding="windows-1252" ?>
<project default="run">
  <target name="run">
    <tstamp/>
    <property environment="env"/>
    <property name="scan.folder" value="${env.SCAN_FOLDER}" />
    <!--<property file="./build.properties"/>-->
    <echo message="Delete all .svn from ${scan.folder}"></echo>
    <delete includeemptydirs="true"  verbose="true">
      <fileset dir="${scan.folder}" includes="**/.svn/**,**/.svn" defaultexcludes="false"/>
    </delete>
  </target>
</project>

The fileset in the delete can be found as an example in the doc of the Ant Delete Task. However, I found that the example did not work as such, for .svn folders with content. So I expanded the includes property to "**/.svn/**,**/.svn" to delete the content of .svn folders, before deleting them.
I set the verbose attribute, to see which folders/files are actually deleted.

The delete deleteSVNFolders.bat file is:

@echo off
cls
set ORACLE_HOME=d:\oracle\Product\JDeveloper11116\Middleware
set ANT_HOME=%ORACLE_HOME%\jdeveloper\ant
set PATH=%ANT_HOME%\bin;%PATH%
set JAVA_HOME=%ORACLE_HOME%\jdk160_24
set SCAN_FOLDER=%1
ant

You'll have have to change the ORACLE_HOME setting to point to your JDeveloper middleware home.
Of course this works on linux as well, but than you'll have to transform the bat file to a bash script. But that's no rocket science...

In a SOA application there will be many services that are dependent on each other. Naturally one would develop a service, deploy it to a server and in a next service refer to that deployed service. That means that in the new project a reference is created based on a concrete WSDL that resides on a remote server. Often the WSDL and related XSD’s are copied to the referencing project. This causes several copies of basically the same XSD and WSDL throughout the whole SOA application system. Maintaining these xsd’s is a tedious job. At compilation of a project the server delivering the deployed service should be up and running. And at the end the deployment of the whole application to a new server (System Test, Acceptance Test, Production) is constrained in the order of deploying the different components of the application.

The solution in SOASuite 11g is to use the Meta Data Store (MDS). There are a few blog-entries on how to relate to XSD’s/WSDL’s in the MDS on the server and how to synchronize the XSD’s and WSDL’s. For a good starting point the following two blog entries are helpful:

• Clemens Utschig Utschig: Re-using common metadata (wsdl / xsd / edl) in SOA Suite 11g 
• Edwin Biemond: Soa Suite 11g MDS deploy and removal ANT scripts

However, these blog entries don’t provide an overall description on how to setup your project/application for using the MDS. Also these entries don’t show how to relate the application to a shared local “MDS” folder elsewhere besides in the Jdeveloper install folder. In a regular project you would place the artifacts in a subversion (SVN) server. So the references to the XSD’s and WSDL’s would be to a folder structure in the SVN working copy and that won’t (should not) reside in the Jdeveloper install folder.
That leaves me to tie the pieces together. So I created a demo application to work-out the details and wrote a whitepaper about it. You can download the whitepaper from our site.