Category Archives: Oracle Public Cloud

Building Developer Cloud Applications Using Gradle

The Spring Boot Getting Started application includes build files for both Maven and Gradle. Given that the Oracle Developer Cloud Service also supports Gradle I thought this would be a good opportunity to demonstrate it in action.

I’m going to pick up where I left off in my previous entry, simply creating a new build that will use Gradle instead of Maven.

Step 1: Configure for Deployment to the Application Container Cloud Service (ACCS)

manifest.json

This file already exists and doesn’t need to change.

Deployment Archive

Just like with Maven, we need to instruct Gradle to package our application into a zip file for deployment to ACCS. With Gradle, this is achieved using the Zip plugin.

Edit build.gradle and add the following:

apply plugin: 'spring-boot'

task zip(type: Zip) {
    from jar.outputs.files   
    from( 'manifest.json' ) 
}

Step 2: Commit and Push the Changes

You know the drill.

Step 3: Create the Build

I could modify the existing Maven build, but instead I’m going to create a new build from the existing build.

Create a new Build Job by copying the Spring Boot GS. Name it something like Spring Boot GS (Gradle).

g00_copy-job

Switch to the Build Steps tab, delete the Invoke Maven 3 step and add a Gradle build step. Set the Tasks to build zip. Everything else can remain as is:

g01_build-step

Switch to the Post Build tab select Archive the Artifacts. Change the Files to Archive to build/distributions/*.zip:

g02_post-build

Save the configuration and click Build Now.

The build fails with the following:

> Connect to repo1.maven.org:443 [repo1.maven.org/151.101.68.209] failed: Connection timed out

The Gradle plug-in doesn’t (yet) pick up the proxy settings from the build engine so we need to provide this information to Gradle. The Developer Cloud Service exposes environment variables that include proxy information:

g03_env

Using these variables we can dynamically create a gradle.properties file as follows (see Accessing the web via a proxy):

#
# Generate a gradle.properties file for the DevCS environment running the build...
#
echo "systemProp.http.proxyHost="$HTTPS_PROXY_HOST >> gradle.properties
echo "systemProp.http.proxyPort="$HTTP_PROXY_PORT >> gradle.properties
echo "systemProp.http.nonProxyHosts="$NO_PROXY >> gradle.properties
echo "systemProp.https.proxyHost="$HTTPS_PROXY_HOST >> gradle.properties
echo "systemProp.https.proxyPort="$HTTPS_PROXY_PORT >> gradle.properties
echo "systemProp.http.nonProxyHosts="$NO_PROXY >> gradle.properties

I’m going to add these commands to a shell script, create_gradle_properties.sh, which I will execute before I call the Gradle build.

Once the script is created and pushed to the repository, return to the Build Steps tab. Unfortunately, there’s not a way to insert a step before an existing step, so delete the Invoke Gradle build step and add an Execute shell step. Set the Command to sh create_gradle_properties.sh. Then add back the Invoke Gradle step as we did before:

g04_shell

Click Save and Build Now (if the Build Now button is disabled, click the Enable Build button).

Yikes, another failed build. It seems Gradle is configured to run an additional integration test which Maven was not. So wee also need to update the HelloControllerIT.java with our new greeting:

   @Test
    public void getHello() throws Exception {
        ResponseEntity<String> response = template.getForEntity(base.toString(),
                String.class);
        assertThat(response.getBody(), equalTo("Greetings from Spring Boot running on ACCS!"));
    }

Commit and push to GitHub, which should trigger the build again (third time’s a charm, right?).

g05_build-history

Continuous Deployment of Spring Boot Applications using Developer Cloud and Application Container Cloud

After my post on continuous deployment using Dropwizard a colleague asked me if the same could be achieved with Spring Boot. Absolutely. The steps are virtually identical. Any Java, Node or PHP application can be continuously deployed using these developer tools. However, the proof is in the pudding, so let’s examine how this would work for a Spring Boot application.

As a starting point, I’ve decided to use the Spring Boot Getting Started application.

Step 1: Clone the Getting Started Repository

Clone the Spring Boot Getting Started guide to your local workstation:

$ git clone https://github.com/spring-guides/gs-spring-boot
Cloning into 'gs-spring-boot'...
remote: Counting objects: 943, done.
remote: Total 943 (delta 0), reused 0 (delta 0), pack-reused 943R
Receiving objects: 100% (943/943), 417.57 KiB | 428.00 KiB/s, done.
Resolving deltas: 100% (599/599), done.
Checking connectivity... done.

Since this isn’t an exercise in Spring Boot, we will jump directly to the completed application.

Step 2: Create a New Git Repository

The Developer Cloud Service deployment server polls a Git repository for changes, hence, we need to store our source in a new repository. The Developer Cloud Service provides a Git repository, but for this example I’m going to use an external GitHub repository:

https://github.com/wbleonard/accs-spring-boot.git

Step 3: Push the Getting Started Application

Return to the command prompt, switch to the completed application directory and initialize Git:

bbleonar_us@DELL-M4700 /c/GitProjects
$ cd gs-spring-boot/complete/

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git init
Initialized empty Git repository in c:/GitProjects/gs-spring-boot/complete/.git/

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git add .

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git commit -m "first commit"
[master (root-commit) 2055653] first commit
 14 files changed, 850 insertions(+)
 create mode 100644 .mvn/wrapper/maven-wrapper.jar
 create mode 100644 .mvn/wrapper/maven-wrapper.properties
 create mode 100644 build.gradle
 create mode 100644 gradle/wrapper/gradle-wrapper.jar
 create mode 100644 gradle/wrapper/gradle-wrapper.properties
 create mode 100644 gradlew
 create mode 100644 gradlew.bat
 create mode 100644 mvnw
 create mode 100644 mvnw.cmd
 create mode 100644 pom.xml
 create mode 100644 src/main/java/hello/Application.java
 create mode 100644 src/main/java/hello/HelloController.java
 create mode 100644 src/test/java/hello/HelloControllerIT.java
 create mode 100644 src/test/java/hello/HelloControllerTest.java

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git remote add origin https://github.com/wbleonard/accs-spring-boot.git

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git push -u origin master
Username for 'https://github.com': wbleonard
Password for 'https://wbleonard@github.com':
Counting objects: 27, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (21/21), done.
Writing objects: 100% (27/27), 99.87 KiB | 0 bytes/s, done.
Total 27 (delta 0), reused 0 (delta 0)
To https://github.com/wbleonard/accs-spring-boot.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

 Step 4: Configure for Deployment to the Application Container Cloud Service (ACCS)

manifest.json

At a minimum, we need to inform ACCS how to start the service, as well as the version of Java we want to use. This is specified in a metadata file called manifest.json. For other optional settings, see Creating Metadata Files.

Create a new manifest.json with the following contents. The command is exactly the same as if you were going to run the application locally:

{
 "runtime": {
 "majorVersion": "8"
 },
 "command": "java -jar target/gs-spring-boot-0.1.0.jar"
}

Deployment Archive

The application JAR file and the manifest.json file need to be packaged into a zip file for deployment to ACCS. We will use the Maven Assembly Plugin to accomplish this task. See the Guide to creating assemblies for more details.

Create a new folder named assembly in the src folder.

Create a new file named accs.xml in assembly folder. The name of this file is arbitrary as it will be referenced later when we configure the assembly plugin:

<?xml version="1.0" encoding="UTF-8"?>
<assembly>
    <id>ACCS</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <files>
        <file>
            <source>manifest.json</source>
            <outputDirectory>/</outputDirectory>
        </file>
    </files>
    <fileSets>
        <fileSet>
            <directory>target</directory>
            <outputDirectory>target</outputDirectory>
            <includes>
                <include>*.jar</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

Add the Maven Assembly build plugin to pom.xml:

            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                  <descriptor>src/assembly/accs.xml</descriptor>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>                
            </plugin>

If you run the build package you would now have a gs-spring-boot-0.1.0-ACCS.zip file. This artifact is what gets deployed to ACCS.

Step 5: Commit and Push the Changes

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   pom.xml

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        manifest.json
        src/assembly/

no changes added to commit (use "git add" and/or "git commit -a")

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git add pom.xml manifest.json src/assembly/accs.xml

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git commit -m "Configured application for deployment to ACCS"
[master 9d1003b] Configured application for deployment to ACCS
 3 files changed, 44 insertions(+)
 create mode 100644 manifest.json
 create mode 100644 src/assembly/accs.xml

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git push
Username for 'https://github.com': wbleonard
Password for 'https://wbleonard@github.com':
Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 1.00 KiB | 0 bytes/s, done.
Total 7 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/wbleonard/accs-spring-boot.git
   2055653..9d1003b  master -> master

Step 6: Configure for Continuous Delivery

Create a Build Job

Log into the Developer Cloud Service and create a new Build job as follows:

Create a new free-style Build Job named something like Spring Boot GS:

sb01_new-job

Set the JDK to JDK 8:

sb02_jdk

Switch to the Source Control tab and set the URL to your Git repository:

sb03_repo

Switch to the Triggers tab and and select Based on SCM Polling schedule and set the Schedule to * * * * *, which will poll for changes every minute. See Configuring Build Triggers for details on how to adjust this expression to suite your needs.

sb04_triggers

Switch to the Build Steps tab and add a Maven 3 build step. Set the Goals to package. Everything else can remain as is:

sb05_build-step

Switch to the Post Build tab select Archive the Artifacts. Set the Files to Archive to **/target/*.zip:

sb06_archive

Save the configuration and click Build Now. Wait while the build is queued and picked up by the build server:

sb07_build

Once the build build begins you can monitor the console output. It should take about 1 1/2 minutes to complete.

Create a Deploy Configuration

Switch to the Deploy tab and create a New Configuration. For the Deployment Target, either select and existing or create a New Application Container Cloud:

sb08_target

Set the remaining values as follows:

Configuration Name: BootStrapGS
Application Name: BootStrapGS

Verify the Runtime is Java.

Be sure to set the Type to  Automatic and select Deploy stable builds only.

Set the Job to Spring Boot GS and set the Artifact to target/gs-spring-boot-0.1.0-ACCS.zip.

sb09_depoy

Click Save and then Start the deployment:

sb10_start

Wait for the deployment to complete, which should only take about a minute:

sb11_started

Use

Switch to the Application Contain Cloud Service to see your deployed application:

sb12_accs

And click the link provided to launch your application. Here’s mine:

https://springbootgs-gse00001975.apaas.em2.oraclecloud.com/

sb13_run

Notice you have all the mapping goodness that comes with Spring Boot, such as:

Continuous Deployment

Now let’s make a change to the application and watch it propagate through to deployment.

Return to the local copy of the application and edit the text returned from HelloController.java. For example:

package hello;

import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;

@RestController
public class HelloController {
    
    @RequestMapping("/")
    public String index() {
        return "Greetings from Spring Boot running on ACCS!";
    }
    
}

Then commit and push the change to GitHub:

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   src/main/java/hello/HelloController.java

no changes added to commit (use "git add" and/or "git commit -a")

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git add src/main/java/hello/HelloController.java

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git commit -m "Updated the greeting"
[master 5245eec] Updated the greeting
 1 file changed, 1 insertion(+), 1 deletion(-)

bbleonar_us@DELL-M4700 /c/GitProjects/gs-spring-boot/complete (master)
$ git push
Username for 'https://github.com': wbleonard
Password for 'https://wbleonard@github.com':
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 557 bytes | 0 bytes/s, done.
Total 7 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://github.com/wbleonard/accs-spring-boot.git
   9d1003b..5245eec  master -> master

This will trigger a build and if the build is successful, a deploy. However, our change caused the build to fail a test:

sb14_failed-test

We also need to update the test with our new greeting.

public class HelloControllerTest {

    @Autowired
    private MockMvc mvc;

    @Test
    public void getHello() throws Exception {
        mvc.perform(MockMvcRequestBuilders.get("/").accept(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk())
                .andExpect(content().string(equalTo("Greetings from Spring Boot running on ACCS!")));
    }
}

Once we commit and push that change, the build will trigger again, successfully complete and trigger a deploy. After a few minutes, our updated application will be running:
https://springbootgs-gse00001975.apaas.em2.oraclecloud.com/.

 

Application Container Cloud and Factor III. Config

Dropwizard applications deployed to Oracle’s Application Container Cloud Service (ACCS) check off most of the best practices recommend by the twelve-factor methodology. In this article I’m going to address Factor III. Config – Store config in the environment.

Dropwizard has extensive support for Configuration (See Creating a Configuration Class). The configuration parameters are externalized in a YAML configuration file. This was demonstrated in the HelloWorld getting started application where the following was defined:

template: Hello, %s!
defaultName: Stranger

Dropwizard also supports substituting these configuration settings with the value of environment variables.

As a test, I augmented the HelloWorldApplication class’ initialize method with the following boilerplate code:

    @Override
    public void initialize(Bootstrap<HelloWorldConfiguration> bootstrap) {
        // Enable variable substitution with environment variables
        bootstrap.setConfigurationSourceProvider(
            new SubstitutingSourceProvider(bootstrap.getConfigurationSourceProvider(),
                    new EnvironmentVariableSubstitutor(false)
                    )
            );
    }

I then updated the hello-world.yml as follows:

template: ${template:-Hello, %s!}
defaultName: ${defaultName:-Stranger Danger}

Now, on initialization, the application will first look for environment variables named “template” and “defaultName”. If the variables are not defined, the application will use the strings as defined in the YAML file.

On deployment to the Application Container Cloud Service (ACCS), the application shows the following when run:

{"id":1,"content":"Hello, Stranger Danger!"}

Now if I log into the ACCS Service Console and select the Deployments tab, I can create user-defined environment variables. For example:

c01-add_env_var
I then have to apply the edits, which will restart the application:

c02-apply_edits.JPG

The application quickly restarts (Factor IX. Disposability):
c03-deploying_release

And a refresh of my browser now pulls the default name from my environment:

{"id":1,"content":"Hello, Application Container Cloud Service!"}

https://helloworld-gse00001975.apaas.em2.oraclecloud.com/hello-world

Thus, I now have the ability to configure the application without needing to redeploy.

 

Continuous Delivery of Microservices using Dropwizard, Developer Cloud and Application Container Cloud

I recently came across Dropwizard, which just reached their 1.0.0 release milestone (congratulations). Dropwizard has assembled popular Java libraries such as Jetty, Jersey and Jackson to create a framework for developing RESTful web services.

A Java framework like Dropwizard is ideally suited for a runtime environment like Oracle’s Application Container Cloud Service (ACCS). ACCS provisions Java SE (or Node.js) environments as required, on demand.

Additionally, we can use Oracle Developer Cloud Service, an integrated DevOps platform, to automate deployment.

In this tutorial I will cover the steps necessary to package and deploy a Dropwizard application to the Application Container Cloud Service. This will be achieved in an automated fashion using the Developer Cloud Service.

Since the focus isn’t on the application but on the process, I selected to use the Dropwizard Getting Started application.

Step 1: Create the Dropwizard Application

Follow the steps in the Getting Started guide to create the HelloWorld application. Or feel free to use your own Dropwizard application. I’ll review the high-level steps here.

Generate the application. My inputs are highlighted in bold:

C:\mvnProjects>mvn archetype:generate 
-DarchetypeGroupId=io.dropwizard.archetypes 
-DarchetypeArtifactId=java-simple -DarchetypeVersion=1.0.0
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.4:generate (default-cli) > generate-sources @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.4:generate (default-cli) < generate-sources @ standalone-pom <<<
[INFO]
[INFO] --- maven-archetype-plugin:2.4:generate (default-cli) @ standalone-pom ---
[INFO] Generating project in Interactive mode
[INFO] Archetype repository not defined. Using the one from [io.dropwizard.archetypes:java-simple:1.0.0] found in catalog remote
Define value for property 'groupId': : com.example.helloworld
Define value for property 'artifactId': : HelloWorld
Define value for property 'version':  1.0-SNAPSHOT: :
Define value for property 'package':  com.example.helloworld: :
[INFO] Using property: description = null
Define value for property 'name': : HelloWorld
[INFO] Using property: shaded = true
Confirm properties configuration:
groupId: com.example.helloworld
artifactId: HelloWorld
version: 1.0-SNAPSHOT
package: com.example.helloworld
description: null
name: HelloWorld
shaded: true
 Y: : Y
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Archetype: java-simple:1.0.0
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: com.example.helloworld
[INFO] Parameter: artifactId, Value: HelloWorld
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: com.example.helloworld
[INFO] Parameter: packageInPathFormat, Value: com/example/helloworld
[INFO] Parameter: package, Value: com.example.helloworld
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: name, Value: HelloWorld
[INFO] Parameter: groupId, Value: com.example.helloworld
[INFO] Parameter: description, Value: null
[INFO] Parameter: shaded, Value: true
[INFO] Parameter: artifactId, Value: HelloWorld
[INFO] project created from Archetype in dir: C:\mvnProjects\HelloWorld
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:25 min
[INFO] Finished at: 2016-08-04T11:09:23-04:00
[INFO] Final Memory: 14M/293M
[INFO] ------------------------------------------------------------------------
C:\mvnProjects>

Use Eclipse (or your favorite IDE) to import an existing Maven project.

Complete the steps as outlined in the Dropwizard Getting Started Guide.

If using Eclipse, right-click the project and select Run As > Maven Build…. Set the goal to package and click Run:

dw10-package

Test Locally

This is still part of the Dropwizard Getting Started exercise. This information we need here is the Java command to start the server. We will use this same exact command string later when we instruct the Application Container Cloud to run our server.

C:\mvnProjects\HelloWorld>java -jar target/HelloWorld-1.0-SNAPSHOT.jar server 
hello-world.yml
INFO  [2016-08-04 15:46:48,845] org.eclipse.jetty.util.log: Logging initialized @929ms
INFO  [2016-08-04 15:46:48,896] io.dropwizard.server.DefaultServerFactory: Registering jersey handler with root path prefix: /
INFO  [2016-08-04 15:46:48,896] io.dropwizard.server.DefaultServerFactory: Registering admin handler with root path prefix: /
INFO  [2016-08-04 15:46:48,899] io.dropwizard.server.DefaultServerFactory: Registering jersey handler with root path prefix: /
INFO  [2016-08-04 15:46:48,899] io.dropwizard.server.DefaultServerFactory: Registering admin handler with root path prefix: /
INFO  [2016-08-04 15:46:48,903] io.dropwizard.server.ServerFactory: Starting hello-world
================================================================================

                              HelloWorld

================================================================================


INFO  [2016-08-04 15:46:48,974] org.eclipse.jetty.setuid.SetUIDListener: Opened application@470a696f{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
INFO  [2016-08-04 15:46:48,977] org.eclipse.jetty.setuid.SetUIDListener: Opened admin@1bc715b8{HTTP/1.1,[http/1.1]}{0.0.0.0:8081}
INFO  [2016-08-04 15:46:48,978] org.eclipse.jetty.server.Server: jetty-9.3.z-SNAPSHOT
INFO  [2016-08-04 15:46:49,400] io.dropwizard.jersey.DropwizardResourceConfig: The following paths were found for the configured resources:

    GET     /hello-world (com.example.helloworld.resources.HelloWorldResource)

INFO  [2016-08-04 15:46:49,401] org.eclipse.jetty.server.handler.ContextHandler: Started i.d.j.MutableServletContextHandler@f72203{/,null,AVAILABLE}
INFO  [2016-08-04 15:46:49,404] io.dropwizard.setup.AdminEnvironment: tasks =

    POST    /tasks/log-level (io.dropwizard.servlets.tasks.LogConfigurationTask)
    POST    /tasks/gc (io.dropwizard.servlets.tasks.GarbageCollectionTask)

INFO  [2016-08-04 15:46:49,409] org.eclipse.jetty.server.handler.ContextHandler: Started i.d.j.MutableServletContextHandler@4a5905d9{/,null,AVAILABLE}
INFO  [2016-08-04 15:46:49,440] org.eclipse.jetty.server.AbstractConnector: Started application@470a696f{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
INFO  [2016-08-04 15:46:49,453] org.eclipse.jetty.server.AbstractConnector: Started admin@1bc715b8{HTTP/1.1,[http/1.1]}{0.0.0.0:8081}
INFO  [2016-08-04 15:46:49,453] org.eclipse.jetty.server.Server: Started @1538ms

Configure for Deployment to ACCS

manifest.json

At a minimum, we need to inform ACCS how to start the service, as well as the version of Java we want to use. This is specified in a metadata file called manifest.json. For other optional settings, see Creating Metadata Files.

Create a new manifest.json with the following contents. The command is exactly as when we ran it from the command line when testing the service locally:

{
 "runtime": {
 "majorVersion": "8"
 },
 "command": "java -jar target/HelloWorld-1.0-SNAPSHOT.jar server hello-world.yml"
}

Deployment Archive

The application JAR file, the hello-world.yml configuration file and the manifest.json file need to be packaged into a zip file for deployment to ACCS. We will use the Maven Assembly Plugin to accomplish this task. See the Guide to creating assemblies for more details.

Create a new folder named assembly in the src folder.

Create a new file named accs.xml in assembly folder. The name of this file is arbitrary as it will be referenced later when we configure the assembly plugin:

<?xml version="1.0" encoding="UTF-8"?>
<assembly>
    <id>ACCS</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <files>
        <file>
            <source>manifest.json</source>
            <outputDirectory>/</outputDirectory>
        </file>
        <file>
            <source>hello-world.yml</source>
            <outputDirectory>/</outputDirectory>
        </file>
    </files>
    <fileSets>
        <fileSet>
            <directory>target</directory>
            <outputDirectory>target</outputDirectory>
            <includes>
                <include>HelloWorld-*-SNAPSHOT.jar</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

Add the Maven Assembly build plugin to pom.xml:

            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                  <descriptor>src/assembly/accs.xml</descriptor>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>                
            </plugin>

Run the build package again and you should now have a HelloWorld-1.0-SNAPSHOT-ACCS.zip file. This artifact can be deployed to ACCS.

Configure for Continuous Delivery

We could use the ACCS Service Console to manually deploy the application, however this would violate “Continuous Delivery” notion in the title of my tutorial. Instead, we’ll use the Oracle Developer Cloud Service to support continuous delivery of our application changes.

Step 1: Initialize a local Git repository

If using Eclipse, right-click the project and select New > Other. The select Git > Git Repository:

dw20-git

Then set the Repository Directory as your project directory:

dw-21-git2

Step 2: Create a Developer Cloud Service Project

Alternatively, you can add a new repository to an existing project. This is the approach I’m going to take. I’ve created a new repository named Dropwizard-HelloWorld:

dw51-new_repository

Copy the HTTP URL. We need this when we push our local changes to this repository:

dw51-http_url

Step 3: Push the local project to the Developer Cloud

Right-click the HelloWorld Eclipse project and select Team > Add to Index. Right-click the project again and select Team > Commit…, which will open the Git Staging window. Add a Commit message, such as Initial push and click Commit and Push…:

dw32-git_staging

Set the URI (that you copied from Developer Cloud) and click Next:

dw33-git3

Select Force overwrite branch in remote if it exists and has diverged:

dw34-git_force

Click Next and Finish on the Push Confirmation page:

dw35-push_confim

And you’ll see the Push Results:

dw36-push_confirm

Step 4: Create a Build Job

Create a new free-style Build Job named something like Dropwizard-HelloWorld:

dw52-new_build_job

Set the JDK to JDK 8:

dw53-JDK

Switch to the Source Control tab and select the Dropwizard_HelloWorld.git repository:

dw54-Git

Switch to the Triggers tab and and select Based on SCM Polling schedule:

dw55-triggers

Switch to the Build Steps tab and add a Maven 3 build step. Set the Goals to package. Everything else can remain as is:

dw56-build_step

Switch to the Post Build tab select Archive the Artifacts. Set the Files to Archive to **/target/*.zip:

dw56-post_build

Save the configuration and click Build Now. Wait while the build is queued and picked up by the build server:

dw57-build_now

Once the build build begins you can monitor the console output. It should take about 1 minute to complete:

dw58_console

Step 5: Create a Deploy Configuration

Switch to the Deploy tab and create a New Configuration:

dw60_new_config

For the Deployment Target, create a New Application Container Cloud. Note, this is all that’s required to establish your deployment runtime!

dw64-new_deployment_target

Set the remaining values as follows:

Configuration Name: DropwizardHelloWorld
Application Name: HelloWorld

Verify the Runtime is Java.

Be sure to set the Type to  Automatic and select Deploy stable builds only.

Select target/HelloWorld-1.0-SNAPSHOT-ACCS.zip as the artifact.

dw65-new_deployment_config

Click Save and Deploy. Wait for the deployment to complete, which should only take a couple of minutes:

dw66-deployment_complete

Use

Switch to the Application Contain Cloud Service to see your deployed application:

dw70-accs

Click the link to open your application is a new browser tab. Don’t forget to append the hello-world resource:

dw71-run

Continuous Delivery

Now let’s make a change to our application and watch it propagate through to deployment.

Return to Eclipse and edit hello-world.yml file. Change the defaultName from Stranger to Stranger Danger (Yes, technically I’m just making a configuration change, but code changes would propagate just the same):

dw80-stranger_danger

Stage and Commit and Push the change as we did before.

If you return to Developer Cloud Service, the home page will indicate a new build has been triggered:

dw90-home

Likewise, when the build completes, the Deploy will trigger.

After a few minutes, you’re updated application will be running

https://helloworld-gse00001975.apaas.em2.oraclecloud.com/hello-world

dw91_run

Certainly, your process might not be as streamlined. Ideally a branch would be created before making a change. A code review would occur before the branch is merged. Tests would run before the build is deemed a success. All of those options are possible using this same set of tools.

 

An Introduction to Oracle Business Activity Monitoring (BAM) – Part 3: Dashboard Design

This is the third part of my introduction to Oracle Business Activity Monitoring (BAM). The first part focused on getting the information into a state that could be consumed by BAM.The second part focused on consuming the data into BAM.

So, we’ve gotten to the point where we are producing messages that are being consumed by a data object. At this point, the BAM Composer could be handed over to a business analyst. From here, the business analyst would generally create a Project, add one or more data objects to the project, create Business Queries, create Business Views from the Business Queries and finally assemble the Business Views into Dashboards. In the exercise below, I will cover all of these steps.

Step 1: Create a New Project

  1. Switch to the Designer tab in BAM Composer.
  2. The virtual machine already has a sample project open, Process Analytics v2. Click the down arrow to the right of the project name and select Create.
    bam2-08_new_project
  3. Name the project Payment and set the Description to Payment Activities:
    bam2-09_new_project

Step 2: Add a Data Object to the Project

  1. Click the Data Objects to add the Payment data object:
    bam2-10_data_objects

Step 3: Create a Business Query

Business Queries are used to populate Business Views. We will create a Flat SQL Query to list the incoming requests and a Group SQL Query to count the requests by card type (AMEX, VISA, etc.) For more see Understanding Business Queries.

Incoming Requests

A list of incoming requests.

  1. Click the Business Queries to create a new Flat SQL Query named IncomingRequests.
    bam2-11_incoming_requests
  2. Select the e2e_1201_composite/Payment Data Object.
  3. Select all fields but BEAM_ID, DATAOBJECT_CREATED and DATAOBJECT_MODIFIED.
  4. Use the arrows to order the fields. I’ve ordered mine as follows:
    bam2-12_incomingrequests
  5. Click Save and you’ll see the results of your query:
    bam2-13_incomingrequests

Requests By Type

A count of requests by card type (American Express, Visa, Master Card, etc.).

  1. Click the Business Queries to create a new Group SQL Query named RequestsByType.
  2. Select the e2e_1201_composite/Payment Data Object.
  3. Select COUNT(*) as the Measures (Y-axis).
  4. Select Card Name as the Dimension.
  5. Click Save and you’ll see the results of your query:
    bam2-14_requestsbytype

Requests By Authorization (Optional)

A count of requests by authorization status (Authorized, Denied). This step is informational only, as I don’t use this query in my example going forward.

  • Click the Business Queries to create a new Group SQL Query named RequestsByAuthorization.
  • Select the e2e_1201_composite/Payment Data Object.
  • Select COUNT(*) as the Measures (Y-axis).
  • Select Payment Status as the Dimension.
  • Click Save and you’ll see the results of your query. Note, you can also click the Bar Graph icon to see your data in graph format (this will look more exciting when we add more sample data:
    bam2-15_requestsbyauth

Step 4: Business Views

Business Views are used the create dashboards. Here we will spruce up the Incoming Requests and Requests By Type to our liking. I’ll show some basic examples, but feel free to adjust to your preferences.

Incoming Requests

  1. Click the Business Views to open the create dialog.
  2. Name the Business View IncomingRequests and set the Display Name to Incoming Requests.
  3. Select the Table category and select List as the View Type and click Create:
    bam2-16_incomingrequests_bv
  4. Set the Query to IncomingRequests:
    bam2-17_incomingrequests_bv
  5. Select Properties. Select the Text tab.
    1. Set the Title Text font to Helvetica 14.
    2. Set the Column header text color to Blue.
      bam2-18_properties
    3. Click Apply and Close and Save to see the changes.
      bam2-19_properties
  6. Select Runtime-Interaction.
    1. Select the Active Data tab and Turn this query into a continuous query.
    2. Set Active Data Collapsing to 2 seconds.
    3. Click Apply, Close and Save.
      bam2-20_runtime_interaction

Requests By Type

  1. Click the Business Views to open the create dialog.
  2. Name the Business View RequestsByCardType and set the Display Name to Requests By Card Type.
  3. Select the Pie category and and select the Pie Chart View Type and click Create.
  4. Select RequestsByType as the Query.
  5. Select Properties.
    1. Set the Predefined Style to Alta. Click Apply to see the effect of the changes.
    2. Select the Titles tab and set the Title Text to Helvetica 14. Click Apply to see the effect of the changes.
    3. Select the Slice tab and set the Slice Label to Slice Name and Value. Click Apply to see the effect of the changes.
      bam2-20_slice_label
    4. Select the Legend tab. Set Display Legend to No. Click Apply, Close and Save to see the effect of the changes.

      Your pie chart should look something like the following:
      bam2-21_pie_chart

Step 5: Dashboards

Dashboards are assembled from the Business Views.

  1. Click the Dashboards to open the create dialog.
  2. Name the Dashboard PaymentRequests and set the Display Name to Payment Requests.
  3. Set the Description to A live dashboard of incoming payment requests by card type.
  4. Select Type 4 as the style template and click Create:
    bam2-22_create_dashboard
  5. Drag Incoming Requests to the top pane and Requests By Type to the bottom pane and click Save:
    bam2-23_dashboard
  6. Switch to the Home Tab and open the Payment  Requests Dashboard.
    bam2-24_dashboard

    The dashboard URL can be shared with and bookmarked. The green icon in the top right indicates the business view is active. The table data can also be downloaded.

Step 6: Test

Let’s generate some more activity so we can see the dashboard in action.

  1. In another browser window (leave the dashboard open), open Enterprise Manger Fusion Middleware Control.
  2. Navigate to the Test Web Service page for the ValidatePayment composite.
  3. Expand the Additional Test Options and:
    1. Enable Stress Test.
    2. Set Concurrent Threads to 1.
  4. Load the PaymentInfoSample_Authorized_soap.xml for the Input Arguments. However, change the CardName from AMEX to Visa.
    bam2-25_load
  5. Before clicking Test Web Service, make sure you have the Dashboard open and visible in another window so you can see the dashboard update in real time. The stress test should take 10 seconds to complete as configured. Every 2 seconds (our Active Data Collapsing setting) the dashboard should update. At the conclusion of the test, the dashboard should look something like the following:
    bam2-25_results

Once the foundation is put in place, the directions you can go are kind of limitless.

 

 

An Introduction to Oracle Business Activity Monitoring (BAM) – Part 2: Message Consumption

This is the second part of my introduction to Oracle Business Activity Monitoring (BAM). The first part focused on getting the information into a state that could be consumed by BAM (For this example we decided to employ a JMS queue). Now that we have data in the queue, let’s see how it can be consumed. Part 3 will then focus on how the data can be displayed in a Dashboard.

Step 1: Start the BAM Server

  1. If you’re following along using the Pre-built Virtual Machine for SOA Suite, open the BAM and SX folder on the virtual machine desktop and click Start Business Activity Monitoring.
  2. Monitor the log until you see <Server State Changed to Running>.

Step 2: Create an Outbound Connection Pool

We will reference this connection later on in BAM Composer when we define our Enterprise Message Source.

  1. Launch the WebLogic Admin Console. Log in using weblogic / welcome1.
  2. Select Deployments.
  3. Expand the BamServer node and select BeamAdapter.rar.
  4. Select the Configuration > Outbound Connection Pools tab:
    bam2-00_outbound_conn_pools
  5. Create a New outbound connection pool configuration and select the oracle.tip.adapter.jms.IJmsConnectionFactory:
    bam2-00_outbound_conn_groups
  6. Set the JNDI Name to eis/bam/PaymentQueue:
    bam2-00_jndi
  7. Click OK to save the deployment plan:
    bam2-00_deployment_plan
  8. Opent the eis/bam/PaymentQueue connection factory and set the ConnectionFactoryLocation to jms/PaymentConnectionFactory.
  9. Set the FactoryProperties to:
    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
    java.naming.provider.url=t3://localhost:8001;
    java.naming.security.principal=weblogic;
    java.naming.security.credentials=welcome1;

    bam2-00_properties
    For a deeper explanation of these settings, see: Creating an Outbound Connection JNDI.

  10. Save.
  11. Return to Deployments and Update the BamServer.

Step 3: Create a Data Object

The Data Object will hold the data displayed in our dashboards. It will be populated by the Enterprise Message Source that we will create after the data object is created.

  1. Launch BAM Composer. Log in using weblogic / welcome1.
  2. Switch to the Administrator tab.
  3. Create a new Data Object named Payment.
  4. Set the Display Name to e2e_1201_composite/Payment. By prefixing the data object name with a folder name, the e2e_1201_composite sub-folder will be created.
  5. Set the Type to Simple Data Object.
  6. This data object will map to the PaymentForBAM.xsd that was created in Part 1 of this exercise. It will have 6 String columns and 2 Float columns.
  7. Set a Description. This is important as the business analysts that will be creating dashboards from these data objects need to understand what these data objects provide (so my example Description is too generic):
    bam2-01_create_data_object
  8. Add columns to match the PaymentForBAM schema:
    bam2-02_create_data_object
  9. Save.

Step 4: Create the Enterprise Message Source

The Enterprise Message Source will retrieve messages from the PaymentQueue and populate the message contents into the Payment Data Object.

  1. Click the Enterprise Message Sources folder on the left, which will open the dialog to create a new EMS. Set the Name to PaymentEMS and the Display Name to e2e_1201_composite/PaymentEMS. Like with the data object, this will create a e23_1201_composite sub-folder:
    bam2-03_ems

Connection Information

  1. Select eis/bam/PaymentQueue as the Outbound Connection JNDI name. This was the outbound connection JNDI we defined when we created the Connection Pool above.
  2. Set Auto-Start to Yes.
  3. Set the Topic/Queue Name to jms/PaymentQueue:
    bam2-04_conn_info

XML Message Formatting

  1. Set the Message Element Name to PaymentAutorization (note the incorrect spelling) and set the Message Element Namespace to http://www.oracle.com/bampayment. This is the element and namespace defined in our PaymentForBAM.xsd:
    bam2-05_xml_message_format

Source To Data-Object Field Mapping

  1. Copy the Data Object Field names and paste them into the Tag/Attr Name field:
    bam2-06_field_mapping
  2. Save and Start the PaymentEMS.

Step 5: Test

  1. Send a test message using Enterprise Manager Fusion Middleware Control and verify the message data made it to the PaymentValidation data object:
    bam2-07_testExcellent. Now we can start having some fun. Step 3 of this tutorial will cover the steps required to create a dashboard.

References

 

 

An Introduction to Oracle Business Activity Monitoring (BAM) – Part 1: Message Production

The majority of my Oracle SOA Suite customers are not taking advantage of the Business Activity Monitoring (BAM) capabilities of the platform. This is a real shame, because gaining the type of real time insight into your business that BAM can provide should be one of the primary reasons for adopting a SOA architecture in the first place.

For the uninitiated, Business Activity Monitoring allows you to visually see how your business is performing in the moment and then react if necessary. What you visualize is up to you – orders processed, carts abandoned,  reservations booked, reservations cancelled, etc. The beauty of using a SOA platform is that you already have all of this data flowing through a central system, so it just needs to be captured as it’s streaming by. Therefore, the first step after deciding that you want BAM is to decide what you want BAM do show.

For this exercise, I’m going to use a credit card processing service, so we can monitor things like authorizations, declines, purchase amounts, etc. Once I know what I want to monitor, I need to produce the data in a format that’s consumable by BAM. Oracle BAM can consume data from several source types. For this tutorial we are going to use an Enterprise Message Source, which is one of the more flexible and popular types.

I’ve decided to break the tutorial into three Parts. Part 1 (this part) will focus on the production of data. Part 2 will focus on the consumption of that data into BAM. Part 3 will conclude with using the data to design a dashboard.

Prerequisites

As a starting point, I’m going to use the ValidatePayment composite from the Oracle SOA Suite 12.1.3 end-to-end tutorial. This composite contains a simple web service which validates a credit purchase.  I’ve documented the steps of installing the ValidatePayment composite into the Pre-built Virtual Machine for SOA Suite. So if you want to follow along, as a starting point, please complete Deploying ValidatePayment to the OTN SOA VM.

Step 1: Create JMS Artifacts

  1. Open the WebLogic Admin Console.

Create a Persistent Store

By creating a persistent store we will be able to view the message text in the console (that last step of this exercise).

  1. Select Peristent Stores.
  2. Create a New FileStore named PaymentJMSFileStore:

    bam1-01_create_file_store

  3. Target the file store to soa_server1. The JMS resources must be targeted to the SOA server so that the composite (deployed to the SOA server) can locate them:

    bam1-02_file_store_target

  4. Click Finish.

Create a JMS Server

  1. Select JMS Servers.
  2. Create a new JMS Server named PaymentJMSServer:

    bam1-03_payment_jms_server

  3. Select the PaymentJMSFileStore Persistent Store:

    bam1-04_select_persistent_store

  4. Target the file store to soa_server1 and click Finish.

Create a JMS Module

  1. Select JMS Modules.
  2. Create a new JMS Module named PaymentJMSModule:

    bam1-05_create_jms_module

  3. Target the JMS Module to the AdminServer, bam_server1, and soa_server1. The JMS resources should then be locatable from any of these servers. At a minimum, the deployed composite will look at soa_server1 and BAM Composer will look at bam_server1:

    bam1-06_target_jms_module

  4. Click Next and select Would you like to add resources to this JMS system module? and click Finish:

    bam1-07_add_resources

    This will take you directly to the page where you can added resources.

Create JMS Resources

Subdeployment

We will use a subdeployment to group all of our JMS resources together. It’s also via the subdeployment that we target our resources to the appropriate managed servers.

  1. Click the Subdeployments tab create a new subdeployment named PaymentSubdeployment:

    bam1-08_create_payment_subdeployment

  2. Target the subdeployment to the PaymentJMServer we just created:

    bam1-09_target_subdeployment

Queue

  1. Switch to the Configuration tab and create a new Queue named PaymentQueue with the JNDI Name of jms/PaymentQueue:

    bam1-10_create_payment_queue

  2. Select the PaymentSupdeployment we just created and click Finish:

    bam1-11_select_subdeployment

Connection Factory

  1. Create a new Connection Factory named PaymentConnectionFactory with the JNDI Name of jms/PaymentConnectionFactory and click Finish.

    bam1-12_create_connection_factory

Step 2: Configure the JMS Adapter

The JMS Adapter from the ValidatePayment SOA composite will connect via this connection.

  1. Select Deployments.
  2. Select the JmsAdapter and select the Configuration tab and Outbound Connection Pools sub-tab. Create a new Outbound Connection Pool configuration and select oracle.tip.adapter.jms.IJmsConnectionFactory as the Outbound Connection Group:

    bam1-13_create_outbound_connection

  3. Set the JNDI Name to eis/jms/PaymentQueue and click Finish:

    bam1-14_jndi_name

  4. Change the plan file name to JMSPlan.xml and save the Deployment Plan:

    bam1-15_save_deployment_plan

  5. Edit the eis/jms/PaymentQueue configuration we just created and set the ConnectionFactoryLocation to jms/PaymentConnectionFactory. Now we have mapped the JMS Adapter to the JMS Connection Factory.

    bam1-14_connection_factory_location

  6. Return to deployments, select the JmsAdpter and select Update and then Finish:

    bam1-16_update_jmsadapter

Step 3: Configure the Composite

Create a Schema

In BAM, we are going to define a data object that represents the data we want to monitor. In our composite, we need to define a schema that maps to the BAM data object we will eventually create.

  1. In JDeveloper, create a new PaymentForBAM.xsd in the SOA/Schemas folder with the following contents:
    <?xml version="1.0" encoding="UTF-8" ?>
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.oracle.com/bampayment"
               targetNamespace="http://www.oracle.com/bampayment" elementFormDefault="qualified">
    
     <xsd:complexType name="PaymentAuthorizationType">
        <xsd:sequence>
         <xsd:element name="CARD_NAME" type="xsd:string"/>
         <xsd:element name="FIRST_NAME" type="xsd:string"/>
         <xsd:element name="LAST_NAME" type="xsd:string"/>
         <xsd:element name="CITY" type="xsd:string"/>
         <xsd:element name="STATE" type="xsd:string"/>
         <xsd:element name="AUTHORIZATION_AMOUNT" type="xsd:float"/>
         <xsd:element name="CREDIT_LIMIT" type="xsd:float"/>
         <xsd:element name="PAYMENT_STATUS" type="xsd:string"/>
        </xsd:sequence>
     </xsd:complexType>
     <xsd:element name="PaymentAutorization" type="PaymentAuthorizationType"/>
    </xsd:schema>

Configure the JMS Adapter

We will use the JMS Adapter to publish messages on the queue.

  1. Open the ValidatePayment composite.
  2. Drag and drop a JMS Adapter into the External References lane. Name the reference Produce_Message:

    bam1-17_jms_adapter

  3. Select Oracle Weblogic JMS as the Oracle Enterprise Messaging Service (OEMS):

    bam1-18_oems

  4. Select SOA_Domain as the AppServer Connection:

    bam1-19_app_server

  5. For the Interface, select Define from operation and schema (specified later). This will be the PaymentForBAM.xsd we created above:

    bam1-20_interface

  6. Select Produce Message as the Operation Type and name the operation Produce_Message:

    bam1-21_produce_message

  7. Browse for Destination Name and select the PaymentJMSModule PaymentQueue (queue):

    bam1-22_browse

  8. For the JNDI Name, use the JNDI browser to ensure the name has been set up correctly in the directory:

    bam1-23_browse_jndi

    Your Produce Operation Parameters should appear as follows:

    bam1-24_produce_operation_parameters

  9. On the Messages page, browse and select the PaymentAuthorizationType from the PaymentForBAM.xsd that we created earlier:

    bam1-25_payment_authorization_type

    Your Messages page should appear as follows:

    bam1-26_messages

  10. Click Next and Finish to complete the wizard.
  11. Wire the JMS Adapter to the Composite. The composite should now look as follows:

    bam1-27_wire

Invoke the JMS Adapter

  1. Open the validatePaymentProcess BPEL component.
  2. Drag and drop and Invoke before the replyOutput and name it Invoke_Produce_Message.

    bam1-28_invoke

  3. Wire the Invoke to the Produce Message Partner Link. This will open the Edit Invoke dialog. Click the plus sign to create a new input variable. Select the default name (Invoke_Produce_Message_Produce_Message_InputVariable) and click OK.

    bam1-29_edit_invoke

  4. Click OK to close the Edit Invoke dialog.
  5. Drag and drop and Assign before the Invoke_Produce_Message and name it setMessageValues.
  6. Edit the setMessageValues assign by double-clicking it. Map the appropriate values to the Invoke_Produce_Message_Produce_Message_InputVariable.From the inputVariable you should map the following:
     CardName  -  CARD_NAME
     FirstName -  FIRST_NAME
     LastName  -  LAST_NAME
     City      -  CITY
     State     -  STATE

    From the outputVariable:

     Status    - PAYMENT_STATUS

    From the getPaymentInformation_getPaymentInformationSelect_OutputVariable:

     dailyLimit - CREDIT_LIMIT

    The result should look as follows:

    bam1-30_edit_assign

Step 4: Deploy and Test

  1. Save All and Deploy ValidatePayment to the SOA_Domain.
  2. Switch to Enterprise Manager Fusion Middleware Control and navigate to the Test Web Service page of the ValidatePayment composite.
  3. Browse and select the PaymentInfoSample_Authorized_soap.xml and click Test Web Service.
  4. Switch to the WebLogic Console and navigate to the PaymentQueue (soa_domain > Services > Messaging > JMS Modules > PaymentJMSModule). Switch to the Monitoring tab where you should see the message in the queue:

    bam1-31_monitoring

  5. Select the PaymentJMSModule!PaymentQueue and click Show Messages to see the Summary of JMS Messages:

    bam1-32_summary_of_messages

  6. Click the message ID to view the message details:

    bam1-33_message_detail

Excellent, we now have data being published to a JMS queue. In Part 2, we will consume this data for business analysis.