SOA 12c Maven demonstration from OpenWorld 2014

Here is a copy of the SOA 12c Maven demonstration that Robert Wunderlich and I gave at OpenWorld this year:

Posted in Uncategorized | Tagged , , | Leave a comment

Groovy scripting in BPM 12c with Christopher Chan

My friend Christopher Chan posted a blog article on the A-Team Chronicles about using Groovy in BPM 12c.

It includes a tutorial that you can work though to learn how to use BPM Groovy Scripting to help with a complex transformation.  It demonstrates the power of scripting and you can run it on your laptop using a BPM Quickstart installation – you don’t need a full server install.

Read the post here.

Posted in Uncategorized | Tagged , , | Leave a comment

Adding an ADF Human Task User Interface to our SOA Maven build

With the new Maven support in 12c, it is much simpler now to include our ADF projects in our SOA Application build.  Continuing on from this earlier post, we will now add the ADF project.

You can do this by opening the Human Task (from the composite view) and clicking on Form and Auto-Generate Task Form.

image

Then in the popup Create Project dialog box, give the project a name, I used HTUI1, and click on OK.  It will take a few minutes to generate the project.  When it is done, do a Save All for good measure.

Now if you want to take a look, you will see that you have three POM files – one for the SOA Project (composite), one for the ADF project, and also your application level POM.  If you open the application level POM (that’s the one under Application Resources/Build Files, you will see that is is a multi-modules project that lists the other two, as you can see in the image below.  It also has some configuration to tell Maven where to find ojdeploy.  In this release, we still need to run ojdeploy to build and package the ADF projects, so you do need to have JDeveloper available to your build server if you want to build ADF projects there.

image

ojdeploy also expects the have oracleHome set, but to a different value, so let’s go update our SOA project POM to set the oracleHome it expects there:

<oracleHome>c:/bpm1213/soa</oracleHome>

Now we can run our build from the command line or JDeveloper, for example to compile and package the composite and the ADF application, we can say something like this:

mvn package -DoracleHome=c:\bpm1213

Now let’s take that one step further and deploy the ADF application too.  You may recall that each ADF HT UI project is built into a WAR and these are then assembled into an EAR file, so it is this EAR file we want to deploy.  We can tell Maven to use the WebLogic Maven Plugin to deploy the EAR by adding a plugin entry to the build section of the SOA Application POM.  Make sure you put it in the Application level POM!   Here is what you need to add:


<plugin>
  <groupId>com.oracle.weblogic</groupId>
  <artifactId>weblogic-maven-plugin</artifactId>
  <version>12.1.3-0-0</version>
  <executions>
    <execution>
      <goals>
        <goal>deploy</goal>
      </goals>
      <phase>pre-integration-test</phase>
      <configuration>
        <adminurl>t3://my.server:7001</adminurl>
        <user>weblogic</user>
        <password>welcome1</password>
        <source>${project.basedir}/deploy/HTUI1.ear</source>
        <verbose>true</verbose>
        <name>${project.build.finalName}</name>
        <targets>soa_server1</targets>
      </configuration>
    </execution>
  </executions>
</plugin> 

Now we can use a command like this to deploy everything to our servers:

mvn pre-integration-test -DoracleHome=c:\bpm1213

Enjoy!

Posted in Uncategorized | Tagged , , , , | Leave a comment

Continuous Integration without SNAPSHOTs

Maven includes a feature called SNAPSHOT which allows you to tell Maven that a particular artifact is a “work in progress”, not a finished version.  This also acts as a hint to let Maven know that it should pick up the newest version of artifacts referred to as SNAPSHOTs.  This is all very useful, but it can present some challenges in a Continuous Integration environment.

When we are automating our builds and testing with CI, one thing that we really want is deterministic builds.  Said another way, we want to be able to run a particular job again and get the same result.  SNAPSHOTs introduce an element of non-determinism to the build – artifacts with SNAPSHOT versions will resolve to the latest snapshot version that happens to be available when the build is run, and they all have the same ‘version’ – snapshot versions look like ‘2.1.2-SNAPSHOT’.

So this means that SNAPSHOTs and CI do not play well together.

But there is a relatively simple way to get the behavior we want without using SNAPSHOTs.  To be clear on that, the behavior we want is this:

  • whenever we do a build, we want to pick up the latest available version of the (in development) dependencies,
  • we want to know which particular version/build of a dependency we actually used in any given build,
  • we want to be able to repeat the build and get the same outcome.

For the purpose of discussion, let’s assume our source code is in git, we build our projects with Maven, perform CI on a Hudson server, and we publish our artifacts to Artifactory.

So let’s consider two projects that are both under active development at the same time – i.e. they are both changing day to day:

  • super-common, version 2.0.1– this contains common code that is used by a number of applications,
  • super-webapp, version 1.0.0 – this is a ‘Super’ web application that we are building, it depends on super-common.

Let’s look at super-common first, since it is at the bottom of the dependency tree.

We need to do two things to make this work:

First, in the POM, set the version to something like 2.0.1-CIVERSION – this creates a placeholder that we will later replace with a unique identifier made up from the timestamp and the build number.

Then, update the Hudson job as follows:

Add a new Execute Shell build step at the beginning of the job (before the Maven step) and set it up as follows:

export DATE=`date +"%y%m%d.%H%M"`
export BUILDVERSION="$DATE.$BUILD_NUMBER"
sed -i -e "s#2.0.1-CIVERSION#2.0.1-$BUILDVERSION#g" pom.xml

Install the Maven3-Artifactory integration Hudson plugin (from Manage Hudson/Plugins) if you do not already have it.  Then edit your job and select the chcekbox for Maven3-Artifactory Integration.  Select your Artifactory server and repository (it should be a repository that holds releases, not snapshots) and make sure you select two options – Deploy artifacts to Artifactory and Capture and publish build info.

Finally, make sure your Maven step’s goals includes the Maven install goal, and does not include the Maven deploy goal.  This will ensure that the maven-metadata.xml is generated/updated, but will allow the Mavn2-Artifactory plugin to control the deployment to Artifactory, rather than Maven trying to do it.

Note: You do not need and should not have a distributionManagment section in you project POM.

Now, when your job runs, it is going to update the version number in your POM to include the time and the Hudson build number.  If you browse your Artifactory repository, you will find each build creates a new artifact.  So this solves the first part of the problem – now we have a reliable way to describe which particular version/build of the artifact we want to use when we are expressing a dependency.

Now, let’s look at super-webapp.

Here we have a dependency on super-common.  In your POM, go ahead and put in any valid version number – just copy the latest one from Artifactory for example.   We will see how we update this later.

Next, make sure you have the scm entry in your POM, and in particular its developerConnection element is specified.

Now, we go to the Hudson job that builds super-webapp.  You can, of course do the same things we did above so that we have unique builds of super-webapp as well.  But for now, let’s just focus on consuming the latest super-common.

In the Maven step in the build, update the goals to look like this:

clean versions:use-latest-versions 
      scm:checkin -Dmessage="update versions" -DpushChanges 
      install

Of course, you can add any others that you need.  Here we are using the Maven ‘Versions’ Plugin to go find the latest available version of the dependencies and to update the POM for us.  Without any further configuration, it will check and update all dependencies.  If this is not what you want, you can add configuration to the build section with include and exclude lists, like most Maven plugins.  Check out the documentation for more details.

Now, this is going to change our POM – so we need to make sure we don’t lose that change – or we still wont be sure what versions of dependencies were used to build this version of super-webapp.  So we need to commit this change back to our version control system.  The scm:checkin goal takes care of that for us.  Of course, we need to provide a commit message, and then we also define pushChanges to tell it to not just commit, but also push to the upstream repository, otherwise we would lose it when the workspace is replaced during the next execution of the build.

Finally, we have install for the same reason as before.

When this job runs, Maven is going to go to Artifactory and find the latest version of super-common, update the POM for super-webapp with that version, commit that change to git, and then proceed with the build.

So now we have what we wanted.  We have no SNAPSHOTs, but each build picks up the latest available version of its dependencies, and we know exactly what version was used (we have the git revision ID and the build number), and we can rerun the exact same build if we wanted to.  Of course, to do that we would have to take the use-latest-versions out of the Maven goals so that it does not grab newer dependencies.

This is a much more CI-friendly approach than using Maven snapshots.

I am indebted to Adam Dent and Leon Franzen for parts of this approach.

Posted in Uncategorized | Tagged , , , , , , | Leave a comment

Adding a Human Task to our SOA Maven Build

In this post, we will make our SOA Application slightly more interesting, and see what we need to do to build it with Maven.  The logical next thing to add is a component that depends on MDS, so we can see the configuration required for MDS-dependent composites.  Human Tasks and Business Rules depend on MDS – they both read an XSD from MDS.  Let’s use a Human Task.

Open your composite and drag a Human Task on to the composite.  Hit OK, then double click on the new Human Task to open it.

In the Assignment tab, drag a Single Participant into Stage 1.  Now double click on the participant and select Add User and add the weblogic user.  This will route the human task to weblogic for approval.

Go to the Data tab.  In the Data section, click on the green plus icon and select Add a string parameter.  Hit OK to take the default name.

Now, open the BPEL process and drag in a Human Task from SOA Components.  Double click on the Human Task activity to open its properties.  In the Task Definition pull down box, select the Human Task you just created.  Click on the “” button in the parameters table, and assign something to the parameter.  I just used one of the inputs.

Configuring which MDS to compile against

Now we need to tell Maven about the MDS configuration.  The simplest choice is to just use the file based MDS that is included in JDeveloper.  It is already defined in the .adf/META-INF/adf-config.xml file in the SOA Application that was generated when you created the application (either with Maven or JDeveloper).


<adf-mds-config xmlns="<a href="http://xmlns.oracle.com/adf/mds/config&quot;">http://xmlns.oracle.com/adf/mds/config"</a>>
  <mds-config xmlns="<a href="http://xmlns.oracle.com/mds/config&quot;">http://xmlns.oracle.com/mds/config"</a>>
    <persistence-config>
      <metadata-namespaces>
        <namespace path="/soa/shared" metadata-store-usage="mstore-usage_1"/>
      </metadata-namespaces>
      <metadata-store-usages>
        <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>
      </metadata-store-usages>
    </persistence-config>
  </mds-config>
</adf-mds-config>

If you are just going to be compiling on your own machine, this is going to be fine.  However, if you want to be able to build the composite on another machine, like a build server, then you might want to configure MDS to point to a shared repository, like a DB-backed MDS repository that is accessible to your machine and to the build server too.

To do this, you just need to update the adf-config.xml to point to the correct MDS.  Here is an example that is configured to point to a DB-backed MDS repository:


<adf-mds-config xmlns="<a href="http://xmlns.oracle.com/adf/mds/config&quot;">http://xmlns.oracle.com/adf/mds/config"</a>>
  <mds-config xmlns="<a href="http://xmlns.oracle.com/mds/config&quot;">http://xmlns.oracle.com/mds/config"</a>>
    <persistence-config>
      <metadata-namespaces>
        <namespace path="/soa/shared" metadata-store-usage="mstore-usage_1"/>
      </metadata-namespaces>
      <metadata-store-usages>
        <metadata-store-usage id="mstore-usage_1">
          <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
            <property name="jdbc-userid" value="myuser_mds"/>
            <property name="jdbc-password" value="welcome1"/>
            <property name="jdbc-url"
            value="jdbc:oracle:thin://@my.database.server:1521/my.service.name"/>
            <property name="partition-name" value="soa-infra"/>
          </metadata-store>
        </metadata-store-usage>
      </metadata-store-usages>
    </persistence-config>
  </mds-config>
</adf-mds-config>

You also need to update the POM to tell Maven where to find the adf-config.xml file.  This is done with the appHome property, which needs to point the the SOA Application (not the SOA Project) directory.  You can just uncomment it, as shown below:

image

You also need to tell Maven where your JDeveloper is installed.  You can put this into the oracleHome property in the POM, or you can specify it on the command line, as shown in the example below:


C:\src2\soaApp1>mvn compile -DoracleHome=c:\bpm1213\soa
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.redstack:soaProject1:sar:1.0-SNAPSHOT
[WARNING] The expression ${version} is deprecated. Please use ${project.version} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] soaProject1
[INFO] soaApp1
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building soaProject1 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ soaProject1 ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\src2\soaApp1\soaProject1\src\main\resources
[INFO] Copying 1 resource
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:compile (default-compile) @ soaProject1 ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - COMPILE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] ABOUT TO RUN oracle.soa.scac.ValidateComposite...
[INFO] compile: Executing: [cmd:[c:\java\jdk1.8.0_05\bin\java, -Djava.protocol.handler.pkgs=oracle.mds.net.protocol|oracle.fabric.comm
on.classloaderurl.handler|oracle.fabric.common.uddiurl.handler, oracle.soa.scac.ValidateComposite, C:\src2\soaApp1\soaProject1/SOA//co
mposite.xml, -level=1, -appHome=C:\src2\soaApp1\soaProject1/..]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] 2014-07-14 08:12:34.678/6.375 Oracle Coherence 12.1.3.0.0 <Info> (thread=main, member=n/a): Loaded operational configura
tion from "jar:file:/C:/Users/Mark/.m2/repository/com/oracle/coherence/coherence/12.1.3-0-0/coherence-12.1.3-0-0.jar!/tangosol-coheren
ce.xml"
[INFO] [exec] 2014-07-14 08:12:34.768/6.465 Oracle Coherence 12.1.3.0.0 <Info> (thread=main, member=n/a): Loaded operational overrides
 from "jar:file:/C:/Users/Mark/.m2/repository/com/oracle/coherence/coherence/12.1.3-0-0/coherence-12.1.3-0-0.jar!/tangosol-coherence-o
verride-dev.xml"
[INFO] [exec] 2014-07-14 08:12:34.771/6.468 Oracle Coherence 12.1.3.0.0 <D5> (thread=main, member=n/a): Optional configuration overrid
e "/tangosol-coherence-override.xml" is not specified
[INFO] [exec] 2014-07-14 08:12:34.775/6.473 Oracle Coherence 12.1.3.0.0 <D5> (thread=main, member=n/a): Optional configuration overrid
e "cache-factory-config.xml" is not specified
[INFO] [exec] 2014-07-14 08:12:34.778/6.475 Oracle Coherence 12.1.3.0.0 <D5> (thread=main, member=n/a): Optional configuration overrid
e "cache-factory-builder-config.xml" is not specified
[INFO] [exec] 2014-07-14 08:12:34.780/6.477 Oracle Coherence 12.1.3.0.0 <D5> (thread=main, member=n/a): Optional configuration overrid
e "/custom-mbeans.xml" is not specified
[INFO] [exec]
[INFO] [exec] Oracle Coherence Version 12.1.3.0.0 Build 52031
[INFO] [exec]  Grid Edition: Development mode
[INFO] [exec] Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.
[INFO] [exec]
[INFO] [exec] 2014-07-14 08:12:34.890/6.587 Oracle Coherence GE 12.1.3.0.0 <Info> (thread=main, member=n/a): Created cache factory com
.tangosol.net.DefaultConfigurableCacheFactory
[INFO] [exec] Jul 14, 2014 8:13:51 AM oracle.fabric.common.wsdl.SchemaManager isIncrementalBuildSupported
[INFO] [exec] INFO: XMLSchema incremental build enabled.
[INFO] [exec] HumanTasks/Humantask1.task: warning: Task title not specified
[INFO] [exec] HumanTasks/Humantask1.task: warning: Empty Participant definition for Stage1.Participant1
[INFO] [exec] HumanTasks/Humantask1.task: warning: Task owner not specified
[INFO] [exec] HumanTasks/Humantask1.task: warning: Error assignee not specified
[INFO] [exec] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] [exec] >> modified xmlbean locale class in use
[INFO] [exec] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] compile: [cmd:[c:\java\jdk1.8.0_05\bin\java, -Djava.protocol.handler.pkgs=oracle.mds.net.protocol|oracle.fabric.common.classloa
derurl.handler|oracle.fabric.common.uddiurl.handler, oracle.soa.scac.ValidateComposite, C:\src2\soaApp1\soaProject1/SOA//composite.xml
, -level=1, -appHome=C:\src2\soaApp1\soaProject1/..]] exit code=0
[INFO] SOA COMPILE DONE
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building soaApp1 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] soaProject1 ....................................... SUCCESS [01:39 min]
[INFO] soaApp1 ........................................... SUCCESS [  0.003 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:43 min
[INFO] Finished at: 2014-07-14T08:14:05+10:00
[INFO] Final Memory: 14M/347M
[INFO] ------------------------------------------------------------------------
C:\src2\soaApp1>

Now our compile connects to the DB-backed MDS and uses the XSDs there to build the composite with a Human Task in it.  In the next post, let’s add an ADF User Interface for the Human Task and incorporate that into our Maven build as well.

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Running SCA Tests from Maven

In this post, let’s look at how we can run SCA test suites from Maven.

To get started, we are going to need a test.  Let’s set up our process to add two numbers.  Go ahead and open the XML Schema for the inputs and outputs and change it to take two int’s as input and return a single int as output, as shown below:

image

Now update the assign activity’s copy rule in the BPEL process to add the two numbers together.  The “from” part of the copy rule should look like this:

$inputVariable.payload/client:a + $inputVariable.payload/client:b

Now, let’s define a test.

Right click on the testsuites folder, and choose Create Test Suite.  Give it a name like test_suite1.  Then the Create Composite Test wizard will open.  Click on Next twice to get to the Input Message page.  Click on Generate Sample and set the values for a and b to 1 and 2, like this:

<process xmlns="http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1">
  <a>1</a>
  <b>2</b>
</process>

Click on Next and then Generate Sample again and set the output to look like this:

<processResponse xmlns="http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1">
  <result>3</result>
</processResponse>

Click on Finish.  Now we have a test.

Next, we need to create a jndi.properties file.  This file is required by sca-test – regardless of whether you run it from ANT or Maven, etc.

Create a new file in your project and set up the content like this:

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=t3://my.server:7003/soa-infra
java.naming.security.principal=weblogic
java.naming.security.credentials=welcome1
dedicated.connection=true
dedicated.rmicontext=true

We also need to update the POM to tell Maven where the jndi.properties is located.

Open the POM, uncomment the jndi.properties.input property and make sure it points to the right file.  If you called your file jndi.properties and put it in the root of your project, then the example provided in the POM is the right value for you.

<!-- these parameters are used by the test goal -->
<!-- if you are using the sca-test (test) goal, you need to uncomment the following
     line and point it to your jndi.properties file. -->
<jndi.properties.input>${basedir}/jndi.properties</jndi.properties.input>
<scatest.result>${scac.output.dir}/testResult</scatest.result>
<!--  input is the name of the composite to run test suties against -->
<input>soaProject1</input>

Now you can run the tests by executing the Maven verify goal – either in JDeveloper or from the command line.

The output will look something like this:


C:\src2\soaApp1>mvn verify
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.redstack:soaProject1:sar:1.0-SNAPSHOT
[WARNING] The expression ${version} is deprecated. Please use ${project.version} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] soaProject1
[INFO] soaApp1
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building soaProject1 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ soaProject1 ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\src2\soaApp1\soaProject1\src\main\resources
[INFO] Copying 1 resource
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:compile (default-compile) @ soaProject1 ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - COMPILE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] ABOUT TO RUN oracle.soa.scac.ValidateComposite...
[INFO] The environment variable/property 'oracle.home' is not set.
[INFO] If you want to compile a composite with a component that depends
on MDS - like a Human Task or Business Rule - AND you want to use a file
based MDS repository, you will need to specify 'oracle.home' OR update
your .adf/META-INF/adf-config.xml to point to your file-based MDS.
If you specify oracle.home it must point to the SOA Quickstart or
JDeveloper install directory with '/soa' appended to it, unless you
update the adf-config.xml to remove the reference to oracle.home.
[INFO] compile: Executing: [cmd:[c:\java\jdk1.8.0_05\bin\java, -Djava.protocol.handler.pkgs=oracle.mds.net.protocol|oracle.fabric.comm
on.classloaderurl.handler|oracle.fabric.common.uddiurl.handler, oracle.soa.scac.ValidateComposite, C:\src2\soaApp1\soaProject1/SOA//co
mposite.xml, -level=1]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] Jul 11, 2014 9:57:39 AM oracle.fabric.common.wsdl.SchemaManager isIncrementalBuildSupported
[INFO] [exec] INFO: XMLSchema incremental build enabled.
[INFO] [exec] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] [exec] >> modified xmlbean locale class in use
[INFO] [exec] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] compile: [cmd:[c:\java\jdk1.8.0_05\bin\java, -Djava.protocol.handler.pkgs=oracle.mds.net.protocol|oracle.fabric.common.classloa
derurl.handler|oracle.fabric.common.uddiurl.handler, oracle.soa.scac.ValidateComposite, C:\src2\soaApp1\soaProject1/SOA//composite.xml
, -level=1]] exit code=0
[INFO] SOA COMPILE DONE
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ soaProject1 ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\src2\soaApp1\soaProject1\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ soaProject1 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ soaProject1 ---
[INFO] No tests to run.
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:sar (default-sar) @ soaProject1 ---
[INFO] Building sar: C:\src2\soaApp1\soaProject1\target\sca_soaProject1_rev1.0-SNAPSHOT.jar
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:deploy (default-deploy) @ soaProject1 ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - DEPLOY COMPOSITE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] setting user/password..., user=weblogic
Processing sar=C:\src2\soaApp1\soaProject1/target/sca_soaProject1_rev1.0-SNAPSHOT.jar
Adding sar file - C:\src2\soaApp1\soaProject1\target\sca_soaProject1_rev1.0-SNAPSHOT.jar
INFO: Creating HTTP connection to host:slc05evl.us.oracle.com, port:7003
INFO: Received HTTP response from the server, response code=200
---->Deploying composite success.
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:test (default-test) @ soaProject1 ---
[INFO] native formatting
[INFO] native
[INFO] [<test:testRunResults compositeDN="default/soaProject1" errorCount="0" failureCount="0" testCount="1" passCount="1" inProgressC
ount="0" runId="25f6b51184bcfb61:-3d069c46:1471d21b49b:-7ffc" runName="oracle-soa-plugin-scatest" startDate="2014-07-10T16:58:02.423-0
7:00" endDate="2014-07-10T16:58:05.314-07:00" xmlns:test="<a href="http://xmlns.oracle.com/sca/2006/test&quot;">http://xmlns.oracle.com/sca/2006/test"</a>><test:testSuite suiteName="test_suite
1"><test:testResult compositeDN="default/soaProject1!1.0-SNAPSHOT*soa_2d677f20-07e9-47bc-9448-7922926a37d5" flowId="10001" scaPartitio
nId="1" endDate="2014-07-10T16:58:05.314-07:00" startDate="2014-07-10T16:58:03.457-07:00" suiteName="test_suite1" testName="test1.xml"
testRunName="oracle-soa-plugin-scatest" testRunId="25f6b51184bcfb61:-3d069c46:1471d21b49b:-7ffc" outcome="passed" callHandlerClassNam
e=""><test:wireActionResults wireSource="bpelprocess1_client_ep"><test:assertionOutcome outcome="passed"><assertion comparisonMethod="
xml-similar" xmlns="<a href="http://xmlns.oracle.com/sca/2006/test&quot;">http://xmlns.oracle.com/sca/2006/test"</a>>
<description/>
<expected>
<location key="output" callbackOperation="processResponse"/>
<message>
<part partName="payload">
<content>

<processResponse xmlns="<a href="http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1&quot;">http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1"</a>>
<result>3</result>
</processResponse></content>
</part>
</message>
</expected>
</assertion><test:actual><test:message><test:part partName="payload"><test:content><bpel:processResponse xmlns:bpel="<a href="http://xmln">http://xmln</a>
s.oracle.com/soaApp1/soaProject1/BPELProcess1"><bpel:result>3</bpel:result></bpel:processResponse></test:content></test:part></test:me
ssage></test:actual></test:assertionOutcome></test:wireActionResults></test:testResult></test:testSuite><test:property propertyName="d
b.type" propertyValue="oracle"/><test:property propertyName="bpel.host.name" propertyValue="slc05evl.us.oracle.com"/><test:property pr
opertyName="soa.oracle.home" propertyValue="/scratch/marnelso/newsoa/final/server/soa"/></test:testRunResults>]
[INFO] C:\Users\Mark\AppData\Local\Temp\out\oracle-soa-plugin-scatest.xml
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building soaApp1 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] soaProject1 ....................................... SUCCESS [01:31 min]
[INFO] soaApp1 ........................................... SUCCESS [  0.002 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:38 min
[INFO] Finished at: 2014-07-11T09:58:55+10:00
[INFO] Final Memory: 15M/91M
[INFO] ------------------------------------------------------------------------

Now, if you were running this build in a CI server, like Hudson, then you could have it collect the results and chart them for you.

In the next post, let’s add some more interesting things to our SOA Application.

Posted in Uncategorized | Tagged , , , , , | 1 Comment

Creating SOA Applications using Maven

In this post, let’s look at how to create a SOA/BPM application from a Maven archetype.

This is fairly simple to do – we just need to use the standard Maven archetype:generate goal and identify the SOA archetype we want to use.

There are two archetypes provided for SOA:

  • com.oracle.soa.archetype:oracle-soa-application:12.1.3-0-0
    This one creates a SOA Application which contains one SOA Project.  This is the equivalent of going into JDeveloper and doing File/New/Application…/SOA Application.
  • com.oracle.soa.archetype:oracle-soa-project:12.1.3-0-0
    This one creates a new SOA Project – it assumes that you will run it inside an existing SOA Application that you want to add another SOA Project to.  This is the equivalent of opening a SOA application in JDeveloper and then doing File/New/Project…/SOA Project.

So let’s create a new SOA Application.  Two notes on this command – first, you need to type it all on one line, or add continuation characters, and second – the archetypeRepository=local is optional – that just tells Maven not to bother looking in remote repositories for the archetype.  If you leave that out, it will just take a little longer for the command to run while Maven checks for the archetype in Maven Central and any other repositories you have defined in your Maven settings.xml.

mvn archetype:generate
    -DarchetypeRepository=local
    -DarchetypeGroupId=com.oracle.soa.archetype
    -DarchetypeArtifactId=oracle-soa-application
    -DarchetypeVersion=12.1.3-0-0

You can also specify the remaining properties on the command line if you want to.  In this example, we will just let Maven prompt us for them, as you see below.  These are all the standard Maven properties that you would get prompted for on any archetype, except for projectName – that one is used to set the name of the SOA Project.  You should make that different to the name of the SOA Application – otherwise the Maven coordinates will clash.

[INFO] Generating project in Interactive mode
[INFO] Archetype defined by properties
Define value for property 'groupId': : com.redstack
Define value for property 'artifactId': : soaApp1
Define value for property 'version':  1.0-SNAPSHOT: :
Define value for property 'package':  com.redstack: :
[INFO] Using property: adf = .adf
[INFO] Using property: data = .data
Define value for property 'projectName': : soaProject1
Confirm properties configuration:
groupId: com.redstack
artifactId: soaApp1
version: 1.0-SNAPSHOT
package: com.redstack
adf: .adf
data: .data
projectName: soaProject1
Y: :
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Archetype: oracle-soa-application:12.1.3-0-0
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: com.redstack
[INFO] Parameter: artifactId, Value: soaApp1
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: com.redstack
[INFO] Parameter: packageInPathFormat, Value: com/redstack
[INFO] Parameter: package, Value: com.redstack
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: projectName, Value: soaProject1
[INFO] Parameter: groupId, Value: com.redstack
[INFO] Parameter: adf, Value: .adf
[INFO] Parameter: data, Value: .data
[INFO] Parameter: artifactId, Value: soaApp1
[WARNING] Don't override file C:\src2\soaApp1\pom.xml
[WARNING] Don't override file C:\src2\soaApp1\src\META-INF
[WARNING] Don't override file C:\src2\soaApp1\src\META-INF\jps-config.xml
[WARNING] Don't override file C:\src2\soaApp1\.adf\META-INF
[WARNING] Don't override file C:\src2\soaApp1\.adf\META-INF\adf-config.xml
[INFO] project created from Archetype in dir: C:\src2\soaApp1
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.386 s
[INFO] Finished at: 2014-07-10T07:01:28+10:00
[INFO] Final Memory: 11M/298M
[INFO] ------------------------------------------------------------------------

Now you can take a look in that new soaApp1 directory and you will see a new, empty SOA Application – exactly the same set of files and directories you get when you create a new SOA Application in JDeveloper.

Just for fun, you could go ahead and build a SAR by running:

mvn package

Of course, that SAR wont be terribly interesting because we have not added any SCA components to our composite yet, but nonetheless you will be able to deploy it if you want to.  You will find the SAR in soaProject1/target (assuming you used the same names as I did).

Editing our Application in JDeveloper

Let’s open up our new application in JDeveloper and add a BPEL process to it!

In JDeveloper, select File/Import…/Maven Project.  In the dialog box that appears, type in the location where your new application is located, and click on the Refresh button.

image

Tick the boxes for the POMs (as shown above) and click on OK.  The Create Application dialog box will appear.  Put in the same name and parent directory location (as shown below) and JDeveloper will create the JWS file right in the same directory.  If you prefer, you can let JDeveloper copy the application to some other location – if you want to do this, make sure you tick the box next to Also import source files into application in the Import Maven Projects dialog box.

image

When you click on OK, JDeveloper will ask you to confirm you want to overwrite the application.  Click on Yes.  Don’t worry – it wont really overwrite anything, it will just go and add the JWS and JPR files.

image

Your new application will open in JDeveloper:

image

Now we are ready to add something to the application.  Let’s just add a simple BPEL “echo” process.  I am going to assume you are familiar with this, so here are the high level steps:

  • Double click on the soaProject1 composite to open it in the editor.
  • Drag a BPEL Process from the Components pane on to the composite.
  • Give it a name, etc.
  • Save.
  • Double click on the new BPEL process to edit it.
  • Drag an Assign activity out and drop it between the receiveInput and the callbackClient activities.
  • Double click on the Assign activity and add a new copy rule to copy the input to the output.
  • Save.

Now we have something we can deploy and look at.

At this point, you want to set up the POM with the details for your test server.  You might want to use the embedded server in JDeveloper, or maybe you have a separate server to use.

image

Go ahead and open the pom.xml file in soaProject1 and switch to the Source view.

Here are the properties you will want to update to match your environment:

<serverUrl>http://my.server:7003</serverUrl>
<user>weblogic</user>
<password>welcome1</password>

While you are there, you might notice a few other useful properties you might want later on:

<overwrite>true</overwrite>
<forceDefault>true</forceDefault>
<regenerateRulebase>false</regenerateRulebase>
<keepInstancesOnRedeploy>false</keepInstancesOnRedeploy>

Now save the POM.

We can now deploy our composite to the server using Maven.  This can be done right in JDeveloper, or from the command line.

Deploying from JDeveloper (using Maven)

The Maven goal we want to use is pre-integration-test.  This is not shown in the JDeveloper popup menu by default, so let’s go add it in.  (This is a one time operation)  We are going to want to use verify as well (later on) so let’s add it in to.

Right click on the POM, then select Manage Goal Profiles…  In the dialog box (shown below) highligt verify and click on the little blue right arrow to add it to the selected list on the right.  Then add pre-integration-test as well.  Then click OK.

image

With that done, now we can right click on the POM and select Run Maven Goal Profile “Default” and then pre-integration-test.

Deploying from the command line

To deploy from the command line, we just go to the application directory and run:

mvn pre-integration-test

Either way, you will get your composite deployed.  You can go log on to FMW Control/Enterprise Manager and have a look at it.

image

In the next post, lets add some SCA Tests and see how we can execute them with Maven.

Posted in Uncategorized | Tagged , , , , , | Leave a comment