Using Shared Object in Soa Suite 11g with MDS

(From http://biemond.blogspot.com/search/label/MDS)

Inspired by Eric Elzinga , who was wondering how MDS can work in Soa Suite 11g , I made some screenshots how you can use a XSD from a central MDS repository in your composite application. Clemens already blogged about re-using common metadata and he made a great ant utility to import or delete MDS files. For 11G R1 PS1 or higher use this instead of the Clemens utility


First I make a local MDS repository. If you install the Soa plugin you already have a seed folder in the integration folder. Under this folder create an new folder called apps. ( this have has to be apps else you will get a permission denied error ) . Under this apps folder we can create our own definitions.

To use my local SOA-MDS repository I create a new MDS File Connection

I want to re-use these common objects in every Soa project so I choose for the resource palette option

select the seed folder in the integration folder

Here we can see our common application objects.

Open the application resources window and open the adf-config.xml

Here we define a new metadata namespace with apps as path. And use the integration folder as metadata-path value.

We are ready to use these common objects in a mediator.. Here I will use a schema from the local MDS as input parameter for the mediator.

Import a new schema

Select the resource browser and here we can select our schema from the local MDS

I uncheck the Copy to project option, because this XSD already exists in the MDS

Our Project is ready but If we want to deploy this Soa project, we will receive a error, it can't find the schema. So we need to export the local MDS files to the SOA Suite database MDS.

To do this we have 2 options , the first option is to create a MAR deployment ( Application properties ) or do this with Ant.

I stripped the Clemens ant project so this ant build file has only two tasks , add and delete. It uses the adf-config.xml ( config folder) for the location of the target MDS and I use the local MDS as source.

Here is the target adf-config.xml which is located in the config folder

Change the build.properties so it matches your environment

This will import your local MDS object to the remote MDS. After this you can deploy your Soa Suite project.

Here you can download my ant project. Thanks to Clemens.

Active the installed adapters in Oracle SOA suite.

Recently, I installed the latest version of Oracle SOA Suite, but I found there are some adapters' status is not active, such as SocketApdater and OracleAppsAdapter. Googled on the internet and found somebody said these adapters weren't deployed to a target server. I checked the setting of these adapters on targets tab and it is true. By selecting the target server, the adapter becomes active and then the configuration works.

Re-using common metadata (wsdl / xsd / edl) in SOA Suite 11g

(From http://blogs.oracle.com/soabpm/entry/reusing_common_metadata_wsdl_x)

As promised here is the first of a set of tips for the brand new SOA Suite 11g.

Managing dependencies between services at development as well as runtime is a challenging task when people implement Service-Providers and -Consumers.

There are a few approaches that worked well in the past and will continue to work well on 11g - yet there are a few notable differences between the releases that should make dependency mgmt way easier in 11g.

Preface:
In the 10.1.3. BPEL world we used to have one global cache for wsdls and schemas. Hence having twice the same (with possible differences) would get you one that overwrites the other.

In 11g SOA Suite, each composite (and revision) has its own store for artifacts, so they don't clash.

Four approaches are in use today (in 10.1.3.x)

a. not preferred at all) Don't bother much and have copies of concrete wsdls in your consuming artifacts. Well that is not sharing, and if the provider changes you need to redeploy the consumer

b. and still not a good approach) Reference the deployed concrete wsdl of a Service Provider. Problem here: Provider not deployed, consumer can't compile or be deployed

c. and the first step to reuse) Introduce a common directory of abstract wsdls and copy them around from project to project. Use wsdlRuntimeLocation on the partnerlink to point to the concrete implementation. Eventually change that during deployment time with the deployment plan.

d. and the next step to reuse) Store abstract wsdls on a centrally accessible endpoint (that might be a war or just an http server) employ the same approach from (c). Problem here - we cache them, you need to refresh the wsdl cache on the BPEL Server.

In SOA Suite 11g we introduced a set of changes that helps you sharing, notable the biggest being the introduction of MDS (MetaData Service) that backs your application (and hence your composites) at designtime as well as runtime.

Think of MDS like a version management system that is used all accross the platform, that you can use to share common artifacts at design and runtime.

So where is your mds located, and how does an application know which one to take?

The configuration sits in $application_home/.adf/META-INF/adf-config.xml and by default points to your local - JDeveloper file system based mds.

Let's examine mine used for fusion order demo

The first important thing to note is the store type. By default this is file based - described with oracle.mds.persistence.stores.file.FileMetadataStore. Now the base path to your mds is described with the property called metadata-path. From here on you can have multiple partitions, but usually one per application. In our case, the partition is called seed. From here, namespaces are used that map to directory structures. These are defined in the section, and by default you get the one that points to internally shared artifacts for your SOA projects, called /soa/shared.

How is mds used in your SOA project then? For example if you create a business rule (yup and that is one of the new features on the JDeveloper UI side) we create you a bunch of artifacts, but the common ones are imported from mds.

An example is
<xsd:import namespace=http://xmlns.oracle.com/bpel
             schemaLocation="oramds:/soa/shared/rules/BpelProcess.xsd"/>
 
Note the namespace being used. If you follow the directory structure based on your adf-config.xml you find this schema. In my case the BpelProcess.xsd is located in C:\JDeveloper\JDev_11.1.1.0\jdeveloper\integration\seed\soa\shared\rules.


A few thoughts here to consider (and succeed):
a) this default namespace is reserved for soa suite infrastructure, and something you should NOT use

b) if you add stuff to the local mds and use it through oramds:/, you need to transfer those artifacts to the server MDS, so the deployment does work.

c) the namespace you should use, that is known to the soa server as well is called apps. To use it - add another namespace to, as I did above in my adf config that says , and create an apps directory under the seed folder. On the server this directory is already there.

Using the shared artifacts:

If you expand the resource browser, there is a section called soa mds connections. Create one for your local environment by picking file as type and specify $ORACLE_HOME\jdeveloper\integration\seed. Whatever you pick now in the resource browser when you work on your composite will be automatically based on the right urls.

Last but not least - create a mar deployment profile on the application level with those shared artifacts, and deploy them to the server.