Mutualiser un MDS de type FileStore entre plusieurs applications composites

Le MetaDataStore ou MDS est à la SOA Suite ce qu'est une cour commune à une co-propriété (bon..je sais j'aurrai pû faire mieux mais j'avoue que je séchais un peu :-)). Il a pour but de centraliser et de mutualiser des ressources nécessaires à plusieurs composites. Ces ressources sont stockées dans l'infrastructure SOA Suite puis rendues disponibles au runtime pour les applications composites. Ces ressources peuvent être de tout genre : fichier texte, xsd, wsdl, fichier xml etc.
Dans la définition du composite (composite.xml) on fait alors directement appel à la ressource depuis le MDS en utilisant le protocole oramds.

Le MDS devient alors une partie intrinsèque de la définition du composite et est alors nécessaire à sa compilation. Il existe 2 types de MDS :

• Ceux de type DBStore, les ressources sont alors stockées dans le schéma MDS de l'installation SOA Suite
• Ceux de type FileStore, les ressources se trouvent sur le système de fichier local

En mode développement avoir un MDS de type FileStore possède plusieurs avantages :

• Gain en temps sur l'alimentation du MDS, il est plus facile de rajouter un wsdl dans un dossier sur la machine locale que de devoir le faire via une fonction wlst comme c'est le cas avec un MDS de type DBStore
• Gain sur les temps de compilation en évitant de devoir initialiser systhématiquement une connexion à une base de données à chaque compilation

Soit le fichier adf-config.xml décrivant le MDS pour mon application

Ce fichier est propre à chaque application et possède en dur le chemin vers mon MDS en local. C'est là que mon article prend du sens, imaginez que vous ayez une vingtaine d'application (Si si c'est possible et c'est mon cas), il faudrait alors que chaque développeur en local modifie systhématiquement tous les fichier adf-config.xml de toutes les applications. Vous me direz, ben...un bon coup de WinMerge et le tour est joué, c'est vrai mais à chaque fois que de nouveaux projets sont rajoutés et que vous les checkouté depuis votre scm préferré rebelotte.

Si comme moi, rien que cette idée vous herrisse tous les poils du corps alors ma solution va peut être vous interesser.

Voici un fichier adf-config.xml qui comporte une variable. Cette variable est censée représenter pour chaque développeur le chemin de son MDS.


Cette variable peut être valorisée une fois pour toute en rajoutant des lignes dans les fichiers :

• <JDev_HOME>\jdeveloper\bin\ant-sca-compile.xml


Cette modification permet de passer au SCA compiler (scac), en tant que paramètre JVM, la valeur de la propriété ${bpel.mds.root} contenue dans le fichier adf-config.xml
• <JDev_HOME>\jdev\bin\conf\jdev.conf


Cette modification permet à JDeveloper d'ouvrir une application déclarant dans son descripteur adf-config.xml une variable ${bpel.ms.root}

Avec la solution décrite ci-dessus, les descripteurs des applications (adf-config.xml) peuvent être stockés comme tel dans le scm de votre choix. A chaque checkout d'une nouvelle application, plus aucune action n'est necessaire avant de pouvoir builder en local => CQFD :-)