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.