WLST and MDS

Developers commonly use JDeveloper to create deployment project to upload files to MDS.

To remove files from MDS, you need to use WLST tool. In fact, you can use WLST tools to import, export, delete, purge and remove MDS directories.

The following are the commonly used WLST “commands” to manipulate the MDS:

·        importMetaData – import directories and documents

·        exportMetaData – export MDS trees and documents

·        deleteMetaData – delete MDS documents (not directories)

·        purgeMetaData

·        sca_removeSharedData – remove directories and documents

These “commands” appear to be straight forward, but you can easily be tripped over if you don’t pay attention to some details.

Not All wlst.cmd Files Are Created Equal

Depends on how WLST is started, and where it’s started, you may have different “commands” available to you. Which WLST “commands” are available to you, depends on what .jar files you load into the classpath when you start WLST tool.

With my locally installed SOA suite, I found 6 different versions of “wlst.cmd”:

1.      C:\Oracle\Middleware\wlserver_10.3\common\bin

2.      C:\Oracle\jdev-mw\wlserver_10.3\common\bin

3.      C:\Oracle\jdev-mw\oracle_common\common\bin

4.      C:\Oracle\Middleware\Oracle_OSB1\common\bin

5.      C:\Oracle\Middleware\oracle_common\common\bin

6.      C:\Oracle\Middleware\Oracle_SOA1\common\bin

Not all wslt.cmd files in this list support MDS commands. I know #2 doesn’t work.

I was able to import and export MDS data using wslt.cmd under #3, C:\Oracle\jdev-mw\oracle_common\common\bin. But I have to use #6 (C:\Oracle\Middleware\Oracle_SOA1\common\bin) for sca_removeSharedData command to work.

Examples Using WSLT to Work with MDS

cd c:\Oracle\jdev-mw\oracle_common\common\bin

connect(‘weblogic’, ‘welcome1’, 't3://localhost:7001')

To export data

exportMetadata(application='soa-infra', server='soa_server1', toLocation='c:/junk/mdsout', docs='/apps/test/**')

Assuming I have some files in MDS under “/apps/test” tree, this command will create the “c:\junk\mdsout\apps\test” directory, this directory will contains all non-empty directories and files in  MDS under ‘/apps/test’ tree.

Notes:

1.      You may need to do: exportMetadata(application='soa-infra', server='soa_server1', toLocation='c:/junk/mdsout', docs='/apps/test/**', remote=’true’) if your server is remote (not localhost).
2.      You may need to do: exportMetadata(application='soa-infra', server='soa_server1', toLocation='c:/junk/mdsout/test.jar', docs='/apps/test/**') if your server is remote (not localhost) depends on which version of wlst.cmd you use.
3.      This commands only dumps out non-empty tree structures in MDS

To import data

importMetadata(application='soa-infra',server='soa_server1',fromLocation='C:/junk/mdsout', docs='/apps/test/**')

This will import data files under c:\mdsout\apps\test into MDS tree “apps/test”.
This command will not import empty directories. Like export command, you may need to import .jar file instead of directories.

To Delete Data

deleteMetadata(application='soa-infra',server='soa_server1',docs='/apps/test/**')
This will only delete all files under MDS /apps/test tree, it will not delete the directories.

To Remove the Directories

sca_removeSharedData('http://localhost:8001', ‘test’) - will remove MDS tree “/apps/test”
sca_removeSharedData('http://localhost:8001', 'test/dvm')  - will remove MDS tree “/apps/test/dvm”

Be careful, do not add / in ‘test’ or ‘test/dvm’, otherwise WLST complains cannot find documents to remove.

 

 

"Teach" JDEV where to look for MDS artifacts

A common task with JDEV is to tell it where to find the MDS connection. If JDEV fails to find MDS, then you may get errors like:

• Error: Error in getting XML input stream: oramds:/apps/xsd/foo.xsd: oracle.mds.exception.MDSException: MDS-00054: The file to be loaded oramds:/apps/xsd/foo.xsd does not exist. 

There might be many reasons for this error. One possible reason could be that JDEV does not know where to look for MDS. JDev uses ad-config.xml to look for MDS connections.

Assume you use DB based MDS, here is how I give JDev a "jolt" and make it to learn:

1. make sure you have a DB connection points to your MDS schema, create one if needed (default schema name is "DEV-MDS")

2. make sure you have your MDS connection in the resource panel, create a new MDS connection if needed and point to your DB connection above

3. finally, create a dummy SOA project, called it "junk", "dummy" or anything, create it with a BPEL process, on the BPEL process screen do these steps:

  1) click on the search glass for input schema

  2) click on search schema in "Type Chooser" popup window

  3) click on search glass in "Import Schema File" popup window

  4) select "Resource Palette" in "SOA Resource Browser" popup window

  5) find your MDS connection, and drill down to where you stored your XSD

  

pick a XSD and any element, pretend you need to use it for your "junk" project input, save your project. That should do it. We just gave JDev a "jolt", it should know where to find your missing MDS artifacts now.

 Now go back and open your adf-config.xml again, you should see the file has picked up a new entry for your MDS connection.

Misc. items about MDS and JDEV

1. to publish to MDS from JDEV, check this: http://yatanveersingh.blogspot.com/2011/07/mds-implementation-in-oracle-soa-11g.html

remember: pay careful attention between "application" deployment and "project" deployment!

2. to delete from MDS, check this: http://neeraj-soa-tips.blogspot.com/2011/06/delete-data-from-mds-single-files.html

remember you can use wild card to delete.

3. when you create a SOA application, Jdev creates a ".adf" folder where your application .jws file resides. You can find your default adf-config.xml under the meta-inf of that folder. You can view it with a text editor directly, or you can open it with JDEV. With Jdev, you can expand "application resources" tab (default on the left, right below your "project" tab. Navigate to "descriptors -> adf meta-inf" and open adf-config.xml, then click "source" view to see the content.

There are two ways to store and access MDS data. Using DB via SOA server, or store locally in your file system.

In any event, by default, you may see something like

          <metadata-store-usage id="mstore-usage_1">
            <metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore">
              <property name="metadata-path"
                        value="${oracle.home}/integration"/>
              <property name="partition-name" value="seed"/>
            </metadata-store>
          </metadata-store-usage>

be very careful, that if your JDEV is not installed under ${oracle.home}, then you won't be able to reference your local file MDS. So you know for sure where your JDEV is installed, you can find the absolute path to the "integration" folder, and replace "${oracle.home}/integration" with your absolute path (you may need to change "\" to "/" on windows.

Sharing common XSD's between OSB and SOA using MDS

Assume you have a collection of XSD's (canonical) need be shared between OSB and SOA.

Oracle recommends placing common artifacts in MDS. However, that syntax "oramds:/..." doesn't work for OSB.

I can think of two solutions:

1. Deploy your XSDs in MDS under "apps/xsd". The trick is make these XSD's accessible from OSB. Assume you have a SOA process "foo" deployed to SOA server, then you can access the above XSD like http://yourhost:8001/soa-infra/services/your-parition/foo/apps/xsd/myschema.xsd

Please note, "foo" can be a process that has nothing to do with your XSD file collections! In other words, you can use any surrogate SOA process to access MDS artifacts. All of the XSDs in MDS can be accessed this way.

2. place XSD's in OSB only, SOA access the XSDs with something like "http://your-host:your-port/sbresource?SCHEMA/your-proj-name/xsd-folder-name/xsd-resource-name". e.g. http://localhost:8011/sbresource?SCHEMA/canonical/xsd/Account

This approach works, keep in mind, the access to the following might be disabled via OSB configuration
   http://localhost:8011/sbresource?SCHEMA/...
   http://localhost:8011/sbresource?WSDL/...
if "sbresource?SCHEMA" access is disabled, then you may need to create a surrogate proxy that references these XSDs, then expose the XSDs via the proxy WSDL.

Another way to do it (not recommended) is to put the XSD file in both MDS and in OSB, There are many problems with this approach, duplicate files in two places can get out of synch. Additionally,you may run into problems with the following scenario:
 You have a BPEL process "foo" uses "oramds:/apps/xsd/myschema.xsd",
  and an OSB proxy "bar" uses the same XSD within OSB locally.
  SOA "foo" process invokes OSB "bar" proxy.
Now your "foo" process will "see" the "myschema.xsd" twice. Once via "oramds:/...", once via "bar" WSDL from OSB, which reference the same schema using  http://localhost/8011/sbresource?SCHEMA/testProj/xsd/myschema.xsd. Jdeveloper will complain about the duplicates and won't compile.