Developer Cloud Service: Continuous Integration with JDeveloper 12.2.1

The last blog showed that the Oracle Developer Cloud Service is now available for JDeveloper and ADF 12.2.1 (Developer Cloud Service with JDeveloper 12.2.1 available). The missing part is the connection of the DCS to the newly created JCS for version 12.2.1. This we show in the blog.

The ground work, how to set up a build system for the DCS has been shown in Fasten your seat belts: Flying the Oracle Development Cloud Service (3 – Take Off – ROTATE). We now have to find out which environment variable to use for the 12.2.1 installation. At the time I wrote the mentioned blog there where only environment variables for 11.1.1.7.1 and 12.1.3.0 available. Looking at the documentation Using Hudson Environment Variables we find that the variables

• ORACLE_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1/jdeveloper
  
• MIDDLEWARE_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1
  
• WLS_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1/wlserver

Are the right ones (and the only ones which point to 12.2.1). In the application.properties file (from the ‘… Take Off…’ blog) we exchange

# Don't change anything below!
 oracle.home=${env.ORACLE_HOME_12C3}
oracle.commons=${env.MIDDLEWARE_HOME_12C3}/oracle_common
middleware.home=${env.MIDDLEWARE_HOME_12C3}
install.dir=${env.ORACLE_HOME_12C3} 

with

# Don't change anything below!
oracle.home=${env.ORACLE_HOME_SOA_12_2_1}
oracle.commons=${env.MIDDLEWARE_HOME_SOA_12_2_1}/oracle_common
middleware.home=${env.MIDDLEWARE_HOME_SOA_12_2_1}
install.dir=${env.ORACLE_HOME_SOA_12_2_1} 

This change will use the JDeveloper 12.2.1 to run ojdeploy and configure the application to run on a WebLogic Server 12.2.1. This should do the trick and we can use the DCS build system to create application using ADF 12.2.1. As the application I used for the ‘Fasten your seat belts…’ blog series was pretty simple I like to show the result using the application I used for a presentation at the DOAG DevCamp2016, named AppsClouUIKit. You can read all about this application in a blog I wrote here DOAG DevCamp2016.

The application was build using JDeveloper 11.1.1.9.0 and has been migrated during the DevCamp to 12.1.3. This was the DCS version which was available at the time of the DevCamp. The first task is to migrate the source to 12.2.1 by creating a new branch in the GIT repository for the new 12.2.1 version.

We Clone the repository and create a new branch 12_2_1 which we use to build the AppsCloudUIKit for 12.2.1. As we are now running JDeveloper 12.2.1 we can use the Team-Server to get the sources from the DCS GIT repository

But we can use any other GIT client to get it. As this is covers in other blogs I’ll skip the details here. In the end we have this branch tree

Where the green marked local branch 12_2_1 is the one we are working on.

After changing the application.properies as shown above we can run the build using ant on the local machine

By selecting the ‘deploy’ target.

The result is an EAR file in the deploy folder

Setting up the build job

Let’s check-in the changes and setup the build in the DCS. Here are the steps for the build job

With this we can build the application to get the result

Setting up the Deployment

The final task is to set up the deploy task to deploy the application on the JCS_12_2_1. When we select the ‘Deploy’ tab we see the existing deployment configuration for the 12.1.3 JCS.

For the JCS 12.2.1 we created a new JCS instance with a different IP (public). Before we can create a new configuration for the 12.2.1 JCS instance we have to allow the Hudson user access to the JCS. This process is described in detail at Deploying an Application from Oracle Developer Cloud Service to Oracle Java Cloud Service

It’s absolutely necessary to get the Oracle Developer Cloud Service SSH public key and add this key to the JSC 12.2.1 instance as authorized key. Please follow the instructions given in the link above to do so.

After this is done we can create a new deployment configuration

Start filling in the dialog by giving the configuration a name. Next we create a new ‘Deployment Target’

In the dialog fill in the public IP address from the new JC 12.2.1 and select SSH Tunnel. The user name and password is the one you selected when you created the JCD instance. Test the connection and close the dialog by clicking ‘Use Connection’

Finally we can complete the Deployment dialog

We choose ‘On Demand’ here which let us specify which job/Build and artifact to use. A click to ‘Save and Deploy’ closes the dialog and the artifact will be deployed to the JCS 12.2.1. The URL to open the application is AppsCloudUIKit 12.2.1

And we should see

JDev 12.2.1: Remote Task Flows in Action

The new JDeveloper version 12.2.1 is just out and has a lot of new features to investigate. In this post we see how remote task flows work. Yes, they are finally here and they are working. At least if you install a patch available from support.oracle.com.
The downloadable version on JDev 12.2.1 has a small bug which prevents you from running remote task flows (refer to https://community.oracle.com/thread/3816032). Support and the dev team quickly delivered a patch for this. To get the patch, open a service request and ask for a patch for bug 22132843.

Let’s start. We need two applications to show how remote task flows are implmented. One is the remote task flow producer, one consumes the remote task flow. An application can be both, producer and consumer. For this sample we keep it simple and define one app as producer and one as consumer.

Producer Application
This application is really simple as it consists of only one page and one task flow which shows the departments and its employees of the HR DB schema.

Remote Task Flow Producer Application

The image above shows the running application stand alone. The single page has the header and a simple task flow beneath it to show the departments and their employees.

Remote Task Flow

Need to be remote invocable

Transaction must be isolated

There are two properties to set in the task flow.
1) in must be remote invocable
2) the transaction must be isolated

Next we have to make the application aware that it should be a remote task flow producer. For this we edit the projects properties and select the ‘ADF Task Flow’ node.

Project Properties for Producer Application

Please note is the second checkbox selected which allows anonymous users to access the remote task flow. This should not be used in a production environment as this would allow anybody to access the task flow. The doc shows how to secure the access to a remote task flow (see link below).

These settings will add a special servlet and a servlet filter to the web.xml file of the application.

Remote Servlet

Remote Servlet Filter

There are more things to consider which you find in the docs at How to Configure an Application to Render Remote Regions

That’s it for the simple producer application.

Consumer Application
The second application is simple too. Here we use a single page which again uses the HR DB schema to show the departments as an editable table in a panel splitter. On the right of this we show the remote task flow of the producer application.

Consumer Application

In the image above the remote task flow isn’t visible as it is not added at the moment.
To make the remote task flow available we need to run the producer application. Here we have to be careful if we try this out using the embedded WebLogic Server. As only one application can be started in debug mode, we need to start the producer application as a normal application.

Run Producer Application

In the consumer application we set the project properties for the ADF Task Flow to allow it to consume remote task flows

Consumer Application Project Properties

Now we create a remote task flow connection. Open the resource palette and select to create a ‘Remote Region Producer…’ from the IDE connections.
Here we fill in the needed info like the path to the remote producer servlet which will get us the names of all remote task flows the application holds. To access the remote task flow we define the URL endpoint

Create Remote Connection

Setup Remote Task Flow Connection_623

Resulting connection

The details about what to fill in are again from the doc.

In the consumer application we now open the one page and drag the remote task flow from the ressource palette onto the page and drop it in the right hand splitter

Drop Remote Region in Consumer Application

This will give us the known image in design mode as if you use a normal region

Consumer Page

We are ready to run the consumer application and get

Running Consumer Application

Nice!

You can download the sample application from GitHub:
Consumer Application
Producer Application
Both application use the HR DB schema. Make sure to adjust the DB connection to point to your db server.