Earlier I wrote about the automatic or silent install of JDeveloper. As a preperation for an automatic install of the complete SOASuite I translated this to Linux.

To do so in Linux you'll need to adapt the sudoers file.

Log in als root via het commando

[oracle@darlin-vce-db ~]$ su -
Password: 
Last login: Fri Feb 26 06:44:05 EST 2016 on pts/0

Then edit the sudo-ers file:

[root@darlin-vce-db ~]# vi /etc/sudoers

Uncomment the lines for the Cmnd_Alias-es SOFTWARE en SERVICES (remove the hash ’#’ from the start of the lines)

## Installation and management of software
Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum

## Services
Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig

Then add the following two lines to the end of the file:

## Extra rights for oracle to do for instance rpm without password.
oracle          ALL=  NOPASSWD: SERVICES, SOFTWARE

Save the file (use an exclamation-mark in the ‘:wq!’ command, since sudoers is a read-only-file.
I separated the settings for the environment in a seperate file, called 'jdev12c_env.sh', so you can use that before starting JDeveloper later on or to add these settings in your profile:

#!/bin/bash
echo set Jdeveloper BPM Quickstart 12cR2 environment
export JAVA_HOME=/usr/java/jdk1.8.0_74
export JDEV_HOME=/u01/app/oracle/JDeveloper/12210_BPMQS
export JDEV_USER_HOME_SOA=/home/oracle/JDeveloper/SOA
export JDEV_USER_DIR_SOA=/home/oracle/JDeveloper/SOA

I adapted the response file because of a different ORACLE_HOME path under Linux and renamed it to 'bpmqs1221_silentInstall-lnx.rsp':

[ENGINE]
 
#DO NOT CHANGE THIS.
Response File Version=1.0.0.0.0
 
[GENERIC]
 
#Set this to true if you wish to skip software updates
DECLINE_AUTO_UPDATES=true
 
#
MOS_USERNAME=
 
#
MOS_PASSWORD=
 
#If the Software updates are already downloaded and available on your local system, then specify the path to the directory where these patches are available and set SPECIFY_DOWNLOAD_LOCATION to true
AUTO_UPDATES_LOCATION=
 
#
SOFTWARE_UPDATES_PROXY_SERVER=
 
#
SOFTWARE_UPDATES_PROXY_PORT=
 
#
SOFTWARE_UPDATES_PROXY_USER=
 
#
SOFTWARE_UPDATES_PROXY_PASSWORD=
 
#The oracle home location. This can be an existing Oracle Home or a new Oracle Home
ORACLE_HOME=/u01/app/oracle/JDeveloper/12210_BPMQS

As an extra I also created an start script called 'jdev12c.sh':

#!/bin/bash
. $PWD/jdev12c_env.sh
echo start Jdeveloper BPM Quickstart 12cR2 
$JDEV_HOME/jdeveloper/jdev/bin/jdev

The actual install script is as

#!/bin/bash
. $PWD/jdev12c_env.sh
echo JAVA_HOME=$JAVA_HOME
if [ ! -d "$JAVA_HOME" ]; then
  # Install jdk
  echo Install jdk 1.8
  sudo rpm -ihv ./jdk-8u74-linux-x64.rpm
else
  echo jdk 1.8 already installed
fi
# Install BPM QS
if [ ! -d "$JDEV_HOME" ]; then
  # Install JDeveloper BPM QuickStart
  echo Install JDeveloper BPM QuickStart 12cR2
  $JAVA_HOME/bin/java -jar fmw_12.2.1.0.0_bpm_quickstart.jar -silent -responseFile $PWD/bpmqs1221_silentInstall-lnx.rsp
else
  echo JDeveloper BPM QuickStart 12cR2 already installed
fi
echo copy jdev.boot naar $JDEV_HOME/jdeveloper/jdev/bin
mv $JDEV_HOME/jdeveloper/jdev/bin/jdev.boot $JDEV_HOME/jdeveloper/jdev/bin/jdev.boot.org
cp $PWD/jdev.boot $JDEV_HOME/jdeveloper/jdev/bin/
echo copy JDeveloper BPM QuickStart 12cR2 environment and start scripts to ~/bin
cp $PWD/jdev12c_env.sh ~/bin 
cp $PWD/jdev12c.sh ~/bin

As described in the Windows variant of this install this script copies an adapted version of the jdev.boot file to use the JDEV_USER_HOME_SOA and JDEV_USER_DIR_SOA environment variables as set in the jdev12c_env.sh. Also it copies the jdev12c_env.sh and jdev12c.sh scripts to the ~/bin folder (user home dir), so after install you're good to go by running the jdev12c.sh script for starting JDeveloper.

In BPM/SOA projects, we use the MDS all the time, for sharing xsd's and wsdl's between projects.

Since 12cR1 (12.1.3) we have the QuickStart installers for SOA and BPM,  that allows you to create an Integrated Weblogic domain to use for SOASuite and/or BPMSuite.

In most projects we have the contents of the MDS in subversion and of course a check out of that in a local svn working copy.

My whitepaper mentioned in this blog entry describes how you can use the mds in a SOA Suite project from 11g onwards.

But how use the MDS in your integrated weblogic? I would expect that some how 'magically' the integrated weblogic would 'know' of the mds references that I have in the adf-config.xml file in my SOA/BPM Application. But unfortunately it hasn't. That is only used on design/compile time.

Now you could just deploy/sync your MDS to your integrated weblogic as you would do to your test/production server and did on 11g.

But I wouldn't write this blog-entry if I did not find a cool trick: symbolic links, even on Windows.

As denoted by the JDEV_USER_DIR variable your (see also this blog entry), your DefaultDomain would be in 'c:\Data\JDeveloper\SOA\system12.2.1.0.42.151011.0031\DefaultDomain' or 'c:\Users\MAG\AppData\Roaming\JDeveloper\system12.2.1.0.42.151011.0031\DefaultDomain' (on Windows).

Within the  Domain folder you'll find the following folder structure: 'store\gmds\mds-soa\soa-infra'.
 This is apparently the folder that is used for the MDS for SOA and BPM Suite. Within there you'll find the folders:

• deployed-composites
• soa

In there you can create a symbolic link (in Windows a Junctions) named 'apps' and pointing to the folder in your svn working copy that holds the 'oramds://apps'-related content. In Windows this is done like:

C:\...\DefaultDomain\store\gmds\mds-soa\soa-infra>mklink /J apps y:\Generiek\MDS\trunk\SOA\soa-infra\apps

The /J makes it a 'hard symbolic link' or a 'Junction'. Under Linux you woud use 'ln -s ...'.

You'll get a response like:

C:\...\DefaultDomain\store\gmds\mds-soa\soa-infra>Junction created for apps <<===>> y:\Generiek\MDS\trunk\SOA\soa-infra\apps

When you perform a dir you'll see:

c:\Data\JDeveloper\SOA\system12.2.1.0.42.151011.0031\DefaultDomain\store\gmds\mds-soa\soa-infra>dir
 Volume in drive C is System
 Volume Serial Number is E257-B299

 Directory of c:\Data\JDeveloper\SOA\system12.2.1.0.42.151011.0031\DefaultDomain\store\gmds\mds-soa\soa-infra

02-02-2016  12:06    <DIR>          .
02-02-2016  12:06    <DIR>          ..
02-02-2016  12:06    <JUNCTION>     apps [y:\Generiek\MDS\trunk\SOA\soa-infra\apps]
02-02-2016  12:07    <DIR>          deployed-composites
02-02-2016  11:23    <DIR>          soa
               0 File(s)              0 bytes
               5 Dir(s)  18.475.872.256 bytes free

You can just CD to the apps folder and do a DIR there, it will then list the contents of the svn working copy folder of your MDS but just from within your Default Domain.

Just refire your Integrated Domain's DefaultServer and you should be able to deploy your composites that depend on the MDS.