Since september 2014, SOA & BPM Suites are available as 12c Release 1. As you may know, the biggest difference in developer experience is the introduction of the QuickStarts, that installs a JDeveloper including a preconfigured IntegratedWeblogic that has the SOA and BPM components have installed. So there is no direct need for a complete Development Server to run and test your developments. By the way, in a project I do think you'll still need a Development Environment to do the end2end testing of your team's complete solution.

But with SOA & BPM 12c you can't do with the standard JDeveloper 12c Studio.

For the SOA 12.2.1 QuickStart a description of the installation process is described here. For BPM the installation is the same, as well as for the 12.1.3 version of both products.

Important to notice is the need for a recent JDK 8 (currently update 65 or 66). Download and install the 64 bit version for your OS.

Download and unzip the BPM or SOA QuickStart files in a temp folder, like 'c:\temp\soa_bpm_1221'). You should then have two files there:

• fmw_12.2.1.0.0_bpm_quickstart.jar
• fmw_12.2.1.0.0_bpm_quickstart2.jar

Then for windows you should open an command window as Administrator. For Linux open a terminal window as the user you want to install the product with.

I won't go through the manual install in detail, but given you're working under Windows (for Linux I assume you'll be able to translate it to shell), set the JAVA_HOME and start the intaller as follows:

c:\Temp\soa_bpm_1221>set JAVA_HOME=c:\Program Files\Java\jdk1.8.0_65

c:\Temp\soa_bpm_1221>echo %JAVA_HOME%
c:\Program Files\Java\jdk1.8.0_65

c:\Temp\soa_bpm_1221>"%JAVA_HOME%\bin\java.exe" -jar fmw_12.2.1.0.0_bpm_quickstart.jar
Launcher log file is C:\Users\MAG\AppData\Local\Temp\OraInstall2015-12-09_09-03-34AM\launcher2015-12-09_09-03-34AM.log.

Running through the wizard, in the 'Installation Summary' screen you'll get the chance to save your choices to a response file:
 
I did my installation in  'C:\oracle\JDeveloper\12210_BPMQS' resulting in the following response file that I named 'bpmqs1221_silentInstall.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=<secure value="">

#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=<secure value="">

#The oracle home location. This can be an existing Oracle Home or a new Oracle Home
ORACLE_HOME=C:\oracle\JDeveloper\12210_BPMQS

Save this as 'bpmqs1221_silentInstall.rsp' (or adapt it if you use either the 12.1.3 version or the SOA QuickStart).
You can change the ORACLE_HOME parameter in this file if you choose to put it elsewhere. I used this because I have all the Oracle software always in a oracle folder, and different JDeveloper installs under JDeveloper. I postfixed the version folder with BPMQS to explicitly state it's a JDeveloper resulting from the QuickStart and not a standard studio install.

To run the silent install you'll issue the following command:

"%JAVA_HOME%\bin\java.exe" -jar fmw_12.2.1.0.0_bpm_quickstart.jar -silent -responseFile %cd%\bpmqs1221_silentInstall.rsp -nowait

I put this in a windows bat file as follows:

@echo off
set JAVA_HOME=c:\Program Files\Java\jdk1.8.0_65
echo JAVA_HOME=%JAVA_HOME%
rem echo "Current dir2:" %~dp0
echo "Silent install BPM QuickStart, using response file:" %cd%\bpmqs1221_silentInstall.rsp
"%JAVA_HOME%\bin\java.exe" -jar fmw_12.2.1.0.0_bpm_quickstart.jar -silent -responseFile %cd%\bpmqs1221_silentInstall.rsp -nowait

BTW: the variable '%cd%' means the current directory. The quickstart installer expects an absolute path to the response file.

UPDATE 26-05-2016:
Some time ago I enhanced this script:

@echo off
@rem set JAVA_HOME="c:\Program Files\Java\jdk1.8.0_65"
set JAVA_HOME=c:\Program Files\Java\jdk1.8.0_65
echo setx -m JAVA_HOME "%JAVA_HOME%"
setx -m JAVA_HOME "%JAVA_HOME%"
echo JAVA_HOME=%JAVA_HOME%
rem Check Java
if exist "%JAVA_HOME%" goto :JAVA_HOME_EXISTS
echo Install %JAVA_HOME% 
jdk-8u65-windows-x64.exe /s INSTALLDIR="%JAVA_HOME%"
:JAVA_HOME_EXISTS
echo %JAVA_HOME% exists
rem check BPM12.2 QS
set FMW_HOME=C:\oracle\JDeveloper\12210_BPMQS
if exist "%FMW_HOME%" goto :BPMQS_HOME_EXISTS
echo Install %FMW_HOME% 
rem echo "Current dir2:" %~dp0
echo "Silent install BPM QuickStart, using response file:" %cd%\bpmqs1221_silentInstall.rsp
"%JAVA_HOME%\bin\java.exe" -jar fmw_12.2.1.0.0_bpm_quickstart.jar -silent -responseFile %cd%\bpmqs1221_silentInstall.rsp -nowait
:BPMQS_HOME_EXISTS
echo %FMW_HOME% exists
if not exist c:\Data mkdir c:\Data
if not exist C:\Data\Jdeveloper\SOA mkdir C:\Data\Jdeveloper\SOA
if not exist C:\Data\Jdeveloper\SOA\SOA mkdir C:\Data\Jdeveloper\SOA\SOA
rem set  JDEV_USER_DIR_SOA and JDEV_USER_HOME_SOA as 'C:\Data\Jdeveloper\SOA\SOA'
echo set  JDEV_USER_DIR_SOA and JDEV_USER_HOME_SOA as C:\Data\Jdeveloper\SOA\SOA
setx -m JDEV_USER_DIR_SOA C:\Data\Jdeveloper\SOA\SOA
setx -m JDEV_USER_HOME_SOA C:\Data\Jdeveloper\SOA\SOA
echo copy jdev.boot naar "%FMW_HOME%\jdeveloper\jdev\bin"
copy jdev.boot "%FMW_HOME%\jdeveloper\jdev\bin" /Y
echo done

This one checks if Java 8 in the given update (in this example 65) is installed and if not it installs it. So the particular java installer should be in the same folder It does not check if there's another version, by the way.
In the end it creates a seperate folder for the User data for JDeveloper. This includes the DefaultServer (Integrated Weblogic) domain. Normally it goes under the user's local settings.
To use that the scripts copies a adapted jdev.boot file to the JDev home, that tells JDeveloper to use the JDEV_USER_DIR_SOA and JDEV_USER_HOME_SOA environment variables for these settings. The adapted jdev.boot file is as follows:

#--------------------------------------------------------------------------
#
#  Oracle JDeveloper Boot Configuration File
#  Copyright 2000-2012 Oracle Corporation. 
#  All Rights Reserved.
#
#--------------------------------------------------------------------------
include ../../ide/bin/ide.boot

#
# The extension ID of the extension that has the <product-hook>
# with the IDE product's branding information. Users of JDeveloper
# should not change this property.
#
ide.product = oracle.jdeveloper

#
# Fallback list of extension IDs that represent the different
# product editions. Users of JDeveloper should not change this
# property.
#
ide.editions = oracle.studio, oracle.j2ee, oracle.jdeveloper

#
# The image file for the splash screen. This should generally not
# be changed by end users.
#
ide.splash.screen = splash.png

#
# The image file for the initial hidden frame icon. This should generally not
# be changed by end users.
#
hidden.frame.icon=jdev_icon.gif

#
# Copyright start is the first copyright displayed. Users of JDeveloper
# should not change this property.
#
copyright.year.start = 1997

#
# Copyright end is the second copyright displayed. Users of JDeveloper
# should not change this property.
#
copyright.year.end = 2014

#
# The ide.user.dir.var specifies the name of the environment variable
# that points to the root directory for user files.  The system and
# mywork directories will be created there.  If not defined, the IDE
# product will use its base directory as the user directory.
#
#ide.user.dir.var = JDEV_USER_HOME,JDEV_USER_DIR
ide.user.dir.var = JDEV_USER_HOME_SOA,JDEV_USER_DIR_SOA

#
# This will enable a "virtual" file system feature within JDeveloper.
# This can help performance for projects with a lot of files,
# particularly under source control.  For non-Windows platforms however,
# any file changes made outside of JDeveloper, or by deployment for
# example, may not be picked by the "virtual" file system feature.  Do
# not enable this for example, on a Linux OS if you use an external editor.
#
#VFS_ENABLE = true

#
# If set to true, prevent laucher from checking/setting the shell
# integration mechanism. Shell integration on Windows associates 
# files with JDeveloper.
#
# The shell integration feature is enabled by default
#
#no.shell.integration = true

#
# Text buffer deadlock detection setting (OFF by default.)  Uncomment
# out the following option if encountering deadlocks that you suspect
# buffer deadlocks that may be due to locks not being released properly.
#
#buffer.deadlock.detection = true

#
# This option controls the parser delay (i.e., for Java error underlining)
# for "small" Java files (<20k).  The delay is in milliseconds.  Files 
# between the "small" (<20k) and "large" (>100k) range will scale the
# parser delay accordingly between the two delay numbers.
#
# The minimum value of this delay is 100 (ms), the default is 300 (ms).
#
ceditor.java.parse.small = 300

#
# This option controls the parser delay (i.e., for Java error underlining)
# for "large" Java files (>100k).  The delay is in milliseconds.
#
# The minimum value for this delay is 500 (ms), the default is 1500 (ms).
#
ceditor.java.parse.large = 1500

#
# This option is to pass additional vm arguments to the out-of-process
# java compiler used to build the project(s).  The arguments
# are used for both Ojc & Javac.
#
compiler.vmargs = -Xmx512m

#
# Additional (product specific) places to look for extension jars.
#
ide.extension.search.path=jdev/extensions:sqldeveloper/extensions

#
# Additional (product specific) places to look for roles.
#
ide.extension.role.search.path=jdev/roles

#
# Tell code insight to suppress @hidden elements 
#
insight.suppresshidden=true

#
# Disable Feedback Manager. The feedback manager is for internal use
# only.
#
feedbackmanager.disable=false

#
# Prevents the product from showing translations for languages other
# than english (en) and japanese (ja). The IDE core is translated into
# other languages, but other parts of JDeveloper are not. To avoid
# partial translations, we throttle all locales other than en and ja.
#
ide.throttleLocale=true

#
# Specifies the locales that we support translations for when 
# ide.throttleLocale is true. This is a comma separated list of 
# languages. The default value is en,ja.
#
ide.supportedLocales=en,ja

#
# Specifies the maximum number of JAR file handles that will be kept
# open by the IDE class loader.  A lower number keeps JDeveloper from
# opening too many file handles, but can reduce performance.
#
ide.max.jar.handles=500

#
# Specifies the classloading layer as OSGi. In the transition period
# to OSGi this flag can be used to check if JDev is running in OSGi
# mode.
#
oracle.ide.classload.layer=osgi

For a few weeks, BPM 12cR2 is released, next to SOA 12cR2. But if you go to the download area of BPM on OTN, you'll find that the downloads suggest Release 12c (12.1.3.0.0).

Just now on community.oracle.com, I found  an answer to the question I had quitely my self for a few weeks: where to download BPM12cR2?

I didn't check-out edelivery.oracle.com my self yet, but you can go to Oracle BPM Suite Downloads | Oracle Technology Network | Oracle. Then accept the download agreements on the page, as though you were to download the links on the page. Then use the following links to download part one and two of the BPM QuickStart installer:

• http://download.oracle.com/otn/nt/middleware/12c/1221/fmw_12.2.1.0.0_bpmqs_Disk1_1of2.zip
• http://download.oracle.com/otn/nt/middleware/12c/1221/fmw_12.2.1.0.0_bpmqs_Disk1_2of2.zip 

Thanks mr. Atwood. Hopefully Oracle repairs the links soon.

On the eve of OOW15, I read that Oracle Fusion Middleware 12.2.1 is released, including Oracle SOASuite, but apparently excluding BPM Suite.

You can download the quickinstaller here. Although it is not explicitly stated on the download pages and in the install guide, you'll need Java 8, update 51+ to install. Which is good news actually, because although Weblogic 12c was already Java 8 certified, and SQLDeveloper 4.1 was introduced on Java 8, SOASuite and BPM suite 12c (12.1.3) was not, and actually won't be (I presume).

You can check out the certification in the certification matrix of Fusion Middleware.

Happy OOW15 all the attendees at the other side of the 'big pool'. We'll guard the fortresses over here... ;)

Oh, and in my previous blog I posted about BPM 12.1.3 Bundle Patch 4, but that there was no BP4 yet for SOASuite. Now a moment ago, I saw since october 20th, there is one for SOASuite.

Earlier this year I wrote about some bugs and patches on SOA & BPM suite, I experienced, and the recommended patches I extracted from that journey. A few weeks ago I found that Jan van Zoggel wrote about the latest bundlepatches on SOA and BPM 12c.

It turns out that there are now 4 Bundlepatches:

• Bundle patch 1: Patch 19707784: SOA/BPM Bundle Patch 12.1.3.0.1
• Bundle patch 2: Patch 20423408: SOA/BPM Bundle Patch 12.1.3.0.2
• Bundle patch 3 for SOA: Patch 20900599: SOA Bundle Patch 12.1.3.0.3
• Bundle patch 3 for BPM: Patch 20645340: BPM Bundle Patch 12.1.3.0.3

Jan mentioned that the both BP3's conflict with each other according to OPatch. So I assume that if you installed the SOA Quickstart you use the BP3 for SOA, and the BPM variant for the BPM Quickstart.

On downloading the Bundle patch 3 for BPM on support.oracle.com, I got the message that it was supersededby Patch 21640312: BPM Bundle Patch 12.1.3.0.4, per 21-Aug-2015.
However for the Bundle patch 3 for SOA (20900599) I could not found an upgrade-patch yet.

At my current customer I use a company supplied laptop. In the office, when I logon I get connected to a Home Folder on a network drive. SoapUI stores it's default workspace in the root of that folder, based on Windows settings.

At home I connect using VPN and somehow this Home Folder is unreachable. Very inconvenient, because with every restart I need to open/import my projects again.

As with the increase of the heap settings like I showed a few days ago, also for the location of the user-home, there is a property, that can be set as a Java -D argument.

So you can add that to the "SoapUI-5.1.3.vmoptions", just add the Duser.home property as follows:

-Xms1024m
-Xmx1536m
-Duser.home=c:\dev\SoapUI
-Dsoapui.properties=soapui.properties
-Dsoapui.home=C:\Program Files\SmartBear\SoapUI-5.1.3/bin
-Dsoapui.ext.libraries=C:\Program Files\SmartBear\SoapUI-5.1.3/bin/ext
-Dsoapui.ext.listeners=C:\Program Files\SmartBear\SoapUI-5.1.3/bin/listeners
-Dsoapui.ext.actions=C:\Program Files\SmartBear\SoapUI-5.1.3/bin/actions
-Dwsi.dir=C:\Program Files\SmartBear\SoapUI-5.1.3/wsi-test-tools
-Djava.library.path=C:\Program Files\SmartBear\SoapUI-5.1.3/bin
-Djava.util.Arrays.useLegacyMergeSort=true
-splash:soapui-splash.png

As easy as that.

The folder needs to exist of course. You can also add it to the JAVA_OPTS variable in soapui.bat/.sh:

rem JVM parameters, modify as appropriate
set JAVA_OPTS=-Xms128m -Xmx1024m -Dsoapui.properties=soapui.properties "-Dsoapui.home=%SOAPUI_HOME%\" -splash:soapui-splash.png -Duser.home=c:\dev\SoapUI

On a restart and a subsequent close of SoapUI you'll notice that it writes the workspace in the denoted folder.

By the way, I found this tip here.

I have some testcases to run a complex of OSB services that processes documents in a content server.
Using a customization file I changed the endpoints of the content server's webservices to mock-services in SoapUI.

In these testcases I kick-off the OSB services, and in successive MockResponse-teststeps I try to catch the service-requests of OSB. This enables me to set assertions on the messages that OSB sends out to the content server, and thus validate the messages built in the OSB-proxies.

I found that one testcase can run correctly for one time, but running it the second time, or running a second testcase succesively, may fail.


Now it is quite important to have the successive MockResponse-teststeps started at the start of the previous teststep.


At the failing test step, OSB apparently sends a request that isn't caught by SoapUI or SoapUI responds with a HTTP-500 (Internal Server error).


Using JVisualVM, monitored the Heap of the JVM of SoapUI, and I found that just about the time the start/run of the failing teststep, there is an increase in heap. Now, since I found that having the set the Start Step property of each MockResponse-step is important, I figured it seems that timing is everything: also an increase of the Heap consumes time, and is presumably triggered by a major Garbage Collect, that halts the application for a brief moment.


So I wanted to increase the amount of heap. Since SoapUI is started with an .exe file (under Windows that is), the JVM properties (SoapUI is a Java application) are stored in a file. Under windows it can be found in "c:\Program Files\SmartBear\SoapUI-5.1.3\bin", depending on the version of SoapUI.
The file is called "SoapUI-5.1.3.vmoptions" and has the following contents:

-Xms1024m
-Xmx1536m
-Dsoapui.properties=soapui.properties
-Dsoapui.home=C:\Program Files\SmartBear\SoapUI-5.1.3/bin
-Dsoapui.ext.libraries=C:\Program Files\SmartBear\SoapUI-5.1.3/bin/ext
-Dsoapui.ext.listeners=C:\Program Files\SmartBear\SoapUI-5.1.3/bin/listeners
-Dsoapui.ext.actions=C:\Program Files\SmartBear\SoapUI-5.1.3/bin/actions
-Dwsi.dir=C:\Program Files\SmartBear\SoapUI-5.1.3/wsi-test-tools
-Djava.library.path=C:\Program Files\SmartBear\SoapUI-5.1.3/bin
-Djava.util.Arrays.useLegacyMergeSort=true
-splash:soapui-splash.png

You'll need to change the security properties to enable yourself to edit/save it. Then change the -Xms and -Xmx properties according to your needs. The defaults are quite "cautious": -Xms200m and -Xms1000m.

Using JVisualVM you can see that with a restart the new memory settings are picked up and in my case that no increase in Heap is needed during the tests.

Last july I wrote about setting environment depended properties in SoapUI. I'm looking for the best way to make SoapUI testcases environment independend and to make it easy to switch between target environments.

In that article I suggested to create a set of properties with the actual working values on project level to be refered in the endpoint urls (hostname:port + URI), username/passwords and so on. And per environment a distinct set of the same properties holding the values of that target environment. Then I created a test case per target environment that copies those target-environment values to the working properties.

This works fine for me. However, in my quest to the most comfortable way of registering and toggling between those values, I found a few enhancements quite convenient.

First of all, after the property-transfer step, I created a manual step, listing the values of the working properties, with a remark that it should contain the values of the particular target environment:



My Localhost version of this testcase will run into:
Don't forget to click 'Ok' after this step. Unfortunately I did not find a way to increase the 'Expected Result" Textarea.

The second enhancement was that I moved my Target Environment property values to the "setEnvironment" test case. I found that with an increasing number of properties it is quite hard to have a clear overview of the properties. And I need to think about a proper naming convention. But when I moved those to the "setEnvironment" test case I have a distinctive set of properties per environment and on project level a distinctive set of working properties.
Since the testcase is environment-specific, I don't need a target-environment reference in the property-names. And also, they are scoped and thus not referable within other testsuites/testcases, preventing errors.

Moving those properties in SoapUI is pretty labor-intensive. But moving those in the source is quick (and dirty). If you open the SoapUI project xml file, you'll find the project-properties at the bottom of the file:
For instance:

<con:properties>
<con:property><con:name>CSServiceURI</con:name><con:value>ContentServer/PS_StoreDocumentToCSStage_v1</con:value>
</con:property><con:property><con:name>CSServiceHost</con:name><con:value>localhost:7001</con:value></con:property>
<con:property><con:name>CSUser</con:name><con:value>svc_GSA</con:value></con:property>
<con:property><con:name>CSPassword</con:name><con:value>welcome1</con:value></con:property>
<con:property><con:name>CSHost</con:name><con:value>localhost:8088</con:value></con:property>
<con:property><con:name>CSAuthenticationURI</con:name><con:value>ContentServer/Authentication</con:value></con:property>
<con:property><con:name>CSSearchServiceURI</con:name><con:value>ContentServer/SearchService</con:value></con:property>
<con:property><con:name>CSDocumentManagementURI</con:name><con:value>ContentServer/DocumentManagement</con:value></con:property>
<con:property><con:name>CSAuthenticationToken</con:name><con:value>TsiKqmREU78MhR4Po%2FJFlsv3OzGUAnDsDsPDcymSnxI%3D</con:value></con:property>
</con:properties>

Copy and paste the properties to move (since I did so allready you'll don't find my target-env properties here anymore) to a seperate  file to get them together.
Then find the target-testcase in the file (in this example "SetLocalEnvironment"):

You'll find at the end of the testcase an empty properties element (<con:properties/>). Open it up (<con:properties> </con:properties> ) and copy and paste the properties within the element.
SoapUI doesn't do formatting of the xml, so you might want to add line-feeds like I did in this example.
Finally you need to change the property-transfer-lines. In the example above, you'll see that I found the transfer-step and added line-feeds for each "<con:transfers ..."

<con:transfers setNullOnMissingSource="true"... some other properties... ><con:name>CSServiceHost</con:name><con:sourceType>CSServiceHost-Dev</con:sourceType><con:sourceStep>#Project#</con:sourceStep><con:targetType>CSServiceHost</con:targetType><con:targetStep>#Project#</con:targetStep><con:upgraded>true</con:upgraded></con:transfers>

You'll find in this line the source step: "<con:sourceStep>#Project#</con:sourceStep>" and target step: "<con:targetStep>#Project#</con:targetStep>". Change the value of the source step to: "<con:sourceStep>#TestCase#</con:sourceStep>". Now the property is refered from the testcase instead of the project. The property on project level can be deleted.

Renaming the properties can better be done from the UI, since SoapUI will then change the property-name also in every reference. Even in soap-requests. So after changing the file in your ascii-editor reload the project in SoapUI. And make the final changes and do the tests.

Now, although this is a nice example of source-hacking from outside the UI, you can't expect any support on this of course. So enable a proper version-control and test the SoapUI properly.