DOAG DevCamp 2017: How much cost the Oracle Cloud?

February 7th, I attended the DOAG Dev Camp 2017 in Hannover, Germany. The DevCamp is held in a ‘Bar Camp’ format, meaning that everybody can bring proposals for sessions at the day the bar camp takes place. The proposals are rated at the beginning and the auditorium can decide if they want to discuss the proposal or not.

img_20170208_124925

I pitched a session on the ‘Cost of the Oracle Cloud’ which was accepted by the other attendees. At the begin of the week (around 5th of February) Oracle changed the pricing of the Oracle Cloud Trials. Before this week you could get a trail which lasted one month, now you get a credit of 300$ which you can spend on Oracles Cloud offerings in one month. Once the 300$ are gone or the month is over you get a mail asking if you like to continue to use the cloud services which are then charged on your credit card. Yes, you have to give a valid credit card if you sign up for a trail. The card is not charged until you say so, accepting the continuation of the services.

Gone are the time when you could request another trail account using a different mail address (not that anybody did such a bad thing).

Anyway, I stumbled over this change when I look at the cloud.oracle.com page in preparation of the session I planned for the DevCamp.

selection_228

Well, you see that you get 300$ to spend on the cloud trail, but not how much a specific trail costs. From my experience with the cloud I know that you need DB Cloud, Storage Cloud, Compute Cloud and Java Cloud to get a Java Development environment for ADF in the cloud. Are the 300$ enough to get all those services for a decent amount of time?

In this session I tried to get an answer to this question. The attendees of the session helped to get through the different services, live during the session, to show the process!

The first impression was that nobody knows how the 300$ are spent on the services or which offerings to add up to get the price. One hint is that after the trail is over, you are charged in the ‘pay as you go’ mode. So we ended up adding the prices for the hourly services. We started with the Developer Cloud Service pricing table

selection_229 As you see, it’s for free, but you have to subscribe other cloud services like Java, DB, Storage and Compute. We started building a table where we added all the prices for the different services

selection_231

A question nobody could really answer was how many request are needed (in the above table). Only time can tell. As the amount looks small we decided to ‘forget’ about these cost for the moment. This question will be addressed to Oracle in the near future.

Finally you can add up all these numbers for all services you need and multiply them with the hours you plan to use the services. Assuming 8 hours per day for 21 days (168 hours) you end up with about 300$. Summary is that you can work with the 300$ for about a month, so there isn’t much of a change here.

However, you have to shut down the services when you not need them, otherwise the clock is ticking and your 300$ won’t last long.

For another sample we tried to Mobile Cloud Service. There you see a ‘Pricing’ tab, but we couldn’t find the ‘Try it’ or ‘Buy Now’  button. Clicking on the ‘Get started for free’ button transfers you back to the overview page.

selection_232

It look like you can’t get a Mobile Cloud Trail at the moment. This is possibly a glitch in the web page, but it might be by intention.

Best Things Last

In the final 10 minutes of the 45 minute session we decided to go for it and to ‘buy’ the Java Cloud Service

selection_233

We clicked on the ‘Buy Now’ and Eureka!

selection_234

You land on a page where Oracle put together some shapes of services for you and what they would cost you per month. The computed prise is dependent on data like hours you plan to use the service per month a number of OCPUs you like to use. Anyway you can easily change this settings and end up with a nice detailed prise information.

And there is a nice summary where you see the detailed calculation

selection_239

I would have liked this information up front!

Who’s clicking the ‘Buy Now’ button first thing?

To whom it may concern at Oracle, you should make this information available on the pricing page or even on the Cloud Service landing page!

Advertisements

Quo vadis ADF?

Last week I attended DOAG Konferenz & Ausstellung in Nürnberg Germany. The DOAG (Deutsche ORACLE-Anwendergruppe e.V.) is the biggest German Oracle user group. The conference covers all Oracle products and technologies, way too much to name them all.

As my personal center of gravity is middle-ware and here ADF and the surrounding technologies, I attended lot’s of sessions about middle-ware, cloud, ADF, MAF and JET. The big picture of Oracle becoming a cloud company is getting clearer.

The way developers currently are working on premise with their products migrating to the cloud is getting clearer. There where about 4-5 sessions which gave explicit advice when to use which technology and what problems might arise mixing them. I’ll cover the main three here.

Frank Nimphius started with a session ‘The Future of Application Development Welcome to your new Job’ where he summarized areas of future of application development as

  • “Server-less” deployment
  • [Micro] [Cloud] Services
  • REST & JSON
  • Mobile centric
  • API first
  • Multi channel
  • Artificial Intelligence
  • Cloud Native Development
  • JavaScript
Future Application Development Summary 1

Future Application Development Summary 1

Future Application Development Summary 2

Future Application Development Summary 2

and defined different job roles around this like

  • Citizen (Low Code) Developer
  • Mobile Developer
  • Service Developer
  • Architect
  • Line of Business Manager

Each role using different technologies to fulfill the tasks. This should open spaces for new and old developers

Mobile Job Roles

Mobile Job Roles

Duncan Mills tackled the bear from a different perspective. In his session ‘Standing at Crossroads’ (Oracle ADF and Oracle JET) he pointed out the differences between ADF and JET

Oracle ADF Oracle JET
Support 5 + 3 + unlimited, no backport limitations Major release every 6 month, backports only to previous version
API are stable No guarantee of API stability
Could or on premis Cloud
Metadata focused Code focused
Full stack solution Client only solution
Has to „own“ the page Can be used „anywhere“

However, there are things both have in common, as Duncan states:

“Don’t assume the you have to go to JET to look ‘modern'”

“Don’t assume that JET will automatically be more perfomant”

There are more things you have to take into account before making a decision between ADF and JET like

  • Transaction and Services: here you have to check if your services and data model can support a stateless model. Same for your UI which handles the interaction with the user. One thing to note too is that using JET will produce less client – sever traffic.
  • Need to shape the services for the convenience of the UI: paging data, pre-computation, attribute reduction and mega endpoints

If you plan to mix ADF and JET there are a couple of things which should make you think twice:

  1. No session sharing between ADF and JET
  2. ADF and JET can’t use the same cache
  3. No shared transaction
  4. Separate timeouts
  5. geometry management
  6. Drag & drop not possible between ADF and JET
  7. Different maintenance and different libraries
  8. Different popup’s and glasspane

Summary is that there are plenty of reasons not to mix ADF and JET. If you want to mix ADF and JET in a project you should stick to module level and not mix them on one page.

duncan_doag5

The decision for ADF or  JET should take these points into account.

Shay Shmeltzer attended the German Oracle (ADF) Developer Community meeting on the DOAG and we ask him to talk about this topic ‘The Future of Developer Frameworks’.

shay2_doag1 Shay started by giving a main difference between ADF and JET:

“ADF is a framework, JET is a toolkit”

meaning that ADF allows development in all tires (MVC) whereas JET is only a client technology. Using JET you still have to have a back-end which generates the needed REST services. Here ADF comes into the picture again.

“ADF hides the complexity of the technology from the developer” 

True, building a REST service from an exiting ADFbc model is very easy and allow shaping the service too. Besides ORDS (Oracle REST Data Service, a tooling which allows to develop modern REST interfaces for relational data in the Oracle Database ) this is the easiest way I know.

During the Q&A of his talk we specifically ask him how Oracle sees the future of ADF as some rumors are that ADF is dead. Shay answered (loud and clear):

“ADF isn’t dead!”

Oracle is using ADF heavily in the SaaS products and will going on to do so. There are areas where building UI with JET is preferred (not in SaaS), but here the points mentioned by Duncan Mills are always considered.

My personal opinion is that ADF is alive will be used in the future, but there are options now which allow developers to choose different technologies in certain areas. Using ADF in the model layer and working with relational data bases, create REST or SOAP services with ease is a big plus. For the UI there are use cases where JET will be used, but ADF has its share too.

DOAG DevCamp2016: Oracle Development Cloud Service Hands On (Part 4)

In part three of the series we completed the task to setup the build system in the DCS for the AppsCloudUIKit application. This final part of the series concludes with setting up the ‘Continuous Integration’ part of the application into the JCS.

Setting up the Continuous Integration to the JCS

The final task is to setup the continuous integration to the Java Cloud Service we use. This is done in the ‘Deploy’ tab where we create a ‘New Configuration’

We then fill in the needed data:

The Configuration name and the application name must match

Nest we select a deployment target. Here we can choose between a JCS and an Application Container Cloud depending on the type of application we develop. As we have created a web application using ADF we select the Java Cloud Service.

We can decide which type of deployment we like: on ‘Demand’ or’ Automatic’. Automatic means that after each build the deploy task is triggered. With the checkbox ‘Deploy stable builds only’ we tell the task to only deploy successful builds. If we choose ‘On demand’ we can select the build we like to deploy

To see the application running in the JCS we can use the URL AppsCloudUIKit (http://140.86.8.75/AppsCloudUIKit/faces/Welcome)

DOAG DevCamp2016: Oracle Development Cloud Service Hands On (Part 3)

In part two of the series we have moved the source of the application to the DCS GIT repository and covered the agile development capabilities of the Oracle Development Cloud Service. In this final part we show how to setup the continuous build service for the application.

To build the application in the DCS we have to create ANT build files or a Maven pom. We use ANT to build the project. To create a starting set of ANT build files we can use JDeveloper (New->Ant->BuildScript from Application). This will create two files, build.xml and build.properties. The build.xml file is the ANT build file and is not dependent on the environment. All environment dependent variables are put in the build.properties file. A sample of the created build properties look like

#Mon Feb 15 21:29:41 CET 2016
oracle.commons=R\:\\Java\\12.1.3.0.0\\Oracle\\Middleware\\oracle_common
install.dir=R\:\\Java\\12.1.3.0.0\\Oracle\\Middleware
oracle.jdeveloper.ant.library=R\:\\Java\\12.1.3.0.0\\Oracle\\Middleware\\jdeveloper\\jdev\\/lib/ant-jdeveloper.jar
oracle.home=R\:\\Java\\12.1.3.0.0\\Oracle\\Middleware\\jdeveloper
oracle.jdeveloper.workspace.path=Q\:\\JavaDevCloud\\DOAGDEVCAMP2016\\AppsCloudUIKit\\AppsCloudUIKit.jws
oracle.jdeveloper.deploy.profile.name=*
oracle.jdeveloper.deploy.dir=Q\:\\JavaDevCloud\\DOAGDEVCAMP2016\\AppsCloudUIKit\\deploy
oracle.jdeveloper.ojdeploy.path=R\:\\Java\\12.1.3.0.0\\Oracle\\Middleware\\jdeveloper\\jdev\\bin\\ojdeploy.exe
oracle.jdeveloper.deploy.outputfile=Q\:\\JavaDevCloud\\DOAGDEVCAMP2016\\AppsCloudUIKit\\deploy\\${profile.name}

We see that the generated properties are holding absolute path variables to programs like ojdeploy or the installation path of your local JDeveloper. We can use these two files to build the application locally without a problem. Working with the same properties, the absolute path variables, in the DCS will not work. The path from the local machine simply does not exist on the server. We need to make some changes to the properties file.

The goal is to use the ant build.xml and build.properties file in both environments with minimal changes. The less we lees to change the better. JDeveloper did some good ground work for us. The build.xml file have no dependency to the environment it’s running at. The save build.xml file can be used to run on the local environment and any server. All locations are either relative or are addressed with properties from the build.properties file.

The DCS offers two different environments (today), one for version 11.1.1.7.0 and one for version 12.1.3.0.0. The environments can be used by using environment variables which are preset for the server which is running the DCS. There are two ORACLE_HOME variables predefines env.ORACE_HOME_11G7 and env.ORACLE_HOME_12C3. Depending on which JDeveloper version we use to develop an application and which runs on the server we substitute the absolute path by one of the preset environment variables:

oracle.commons=R\:\\Java\\12.1.3.0.0\\Oracle\\Middleware\\oracle_common

changed to

oracle.commons=${env.ORACLE_HOME_12C3}\oracle_common =${env.ORACLE_HOME_12C3}

This we have to do with all absolute path variables we find in the build.properties file. We don’t even have to know the real path of the installation on the DCS, all we do is to use the predefined environment variables. Another thing to take care of is that the Hudson server which uses the build files run on a Linux machine whereas we normally use a Windows machine. In case that you run rue local development on a Linux machine too, you can skip the next paragraph.

Use the same build.xml and build.properties on Windows and Linux machines

There are some small but vital differences when running the development on Windows against running it on Linux.

  1. The path separator is different: ‘/’ in Linus, ‘\’ in windows
  2. Executables in windows have a suffix ‘.exe’

It would make sense to use the same build files on both machines. The path separator isn’t much of a problem as the ant tool manages reading Windows and/or Linux without a problem. To make the path separator work on both machines we use the Linux version in the build.properties. This can be done by a simple search and replace job.

The build properties contain one call to an executable ojdeploy. This is the packaging task JDeveolper uses to build jar, war and ear files. The name suggests that its use is to deploy something to a server, but that’s not what’s ojdeploy is doing. The problem is that Windows uses a suffix ‘.exe’ for executables, whereas Linux does not. Here an executable just has a flag set on the file properties. One solution would be to rename the ojdeploy on the Linux side to ‘ojdeploy.exe’, but for this we have to have access to the servers file system and the right to change this setting. We use a property which we define for the ant build job, ‘${env.EXEC_SUFFIX}’. The trick is to set the ‘${env.EXEC_SUFFIX}’ property to ‘.exe’ on a windows system and to ” (empty) on a Linux system.

On a Windows machine we define a system property for this

041516_1236_DOAGDevCamp1.png

On a Linux local system we can use an export command. For the Hudson build we use an ant property

Optimizing the build.properties for reuse

A close inspection of the original build.properties file shows, that we only need five properties to make the build.properties easy to handle for every project which we want to develop in the cloud and on a local environment.

  • workspace.name: holds the name of the workspace, in our case AppsCloudUIKit
  • project.viewcontroller.name: holds the name of the view controller project which is used to build the WAR file. The sample application uses the ‘DemoMaster’ project to create the WAR file.
  • project.deploy.folder: holds the folder where all artefacts are stored. This folder holds the final artefact, the EAR file.
  • oracle.jdeveloper.deploy.profile.name: The name of the application profile which builds the EAR file.
  • output.dir: holds the directory the build process uses to put the class files to.

The remaining properties don’t change as they use environment variables which will be set by the machine the build system is running on. In the cloud we have two environments (at the time of writing), one for 11g (11.1.1.7.1) and one for 12c (12.1.3). We use the 12.1.3 environment as our JCS uses 12.1.3 too.

The main environment variables are ‘${env.ORACLE_HOME_12C3}’, ‘${env.MIDDLEWARE_HOME_12C3}’, ‘${env.WORKSPACE}’ and finally ‘${env.EXEC_SUFFIX}’. All of them start with ‘env.’ which shows that they are read from the environment. To make ant aware of the environment variables we have to add one line to the generated build.xml at the beginning of build.xml

<property environment=”env” />

The final version can be seen below or downloaded at Ant build.properties

#Change the next properties to match your projects names
workspace.name=AppsCloudUIKit
project.viewcontroller.name=DemoMster
project.deploy.folder=deploy
oracle.jdeveloper.deploy.profile.name=AppsCloudUIKit
output.dir=classes

# 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}

#Flags
javac.deprecation=off
javac.nowarn=off
java.debug=on
project.workspace.file=${workspace.name}.jws
oracle.jdeveloper.ant.library=${oracle.home}/jdev/lib/ant-jdeveloper.jar
oracle.jdeveloper.workspace.path=${env.WORKSPACE}/${workspace.name}.jws
oracle.jdeveloper.project.name=${project.viewcontroller.name}
oracle.jdeveloper.deploy.dir=${env.WORKSPACE}/${project.deploy.folder}
oracle.jdeveloper.ojdeploy.path=${env.ORACLE_HOME_12C3}/jdev/bin/ojdeploy${env.EXEC_SUFFIX}
oracle.jdeveloper.deploy.outputfile=${env.WORKSPACE}/${project.deploy.folder}/${oracle.jdeveloper.deploy.profile.name} 

Setting up the Build Job in the DCS

The next task it to set up the build job in the DCS. For this we create a new job

Give the job a name and can now select to create a new job or to copy an existing one. We select to create a new one

Now we configure the build job by filling in the needed information. On the main tab we can describe the job, decide which JDK to use and how many build job executions are saved. If you use a high number the space on your virtual storage is filling up quickly as all output and all artefacts are stored. We set this to 10.

We skip the next tab ‘Build Parameters’ and move to the ‘Source Control’ tab

As we use Git, we set the radio button to Git and select the repository of the project we want to build. The ‘Advanced Repository Settings’ are set automatically. In the ‘Branch Specifier’ field we can tell which branch we want to check out. Next we tell the build system when to start working

Here we select that we want to poll the source control system every minute for changes. The schedule uses the Linux ‘cron’ syntax. We skip the ‘Environment’ tab and define one build step on the ‘Build Steps’ tab

All we need to do is to execute the Appbuild.xml target ‘deploy’. This will compile all other needed projects and create the needed jars before finally creating the applications ear file. The remaining tab we leave unchanged and save the job configuration. In the ‘Properties’ field we see the definition of the ${env.EXEC_SUFFIX} variable mentioned before.

The ‘Post Build’ tab defines what to do with the outcome of the build. Here we define that the generated artifacts which end up in the ‘deploy’ folder should be archived in GZIP format. If we don’t do this the build runs but as nothing is saved, we later can’t deploy the ear file. The remaining tab ‘Advanced we skip and save the created job.

Now we can run the build job by clicking the ‘Build’ button. The job doesn’t start immediately but is queued first, then starts running.

… when the build starts we see the change in status.

We can look at the console output of the job by clicking the console icon of the running job. If you click on the console icon of a finished job you see the complete output.

Once the job has finished successfully the artifacts are shown with the build.

In the next and final part we see how to setup the ‘Continuous Integration’ part by deploying the application to the JCS.

DOAG DevCamp2016: Oracle Development Cloud Service Hands On (Part 2)

In part 1 of this series we talked about the Oracle Development Cloud Service (DCS) in general terms and what we plan to do. This part describes the migration of an application developed for an earlier version of JDeveloper to version 12.1.3 and how to move it into the cloud.

As a test case we use the sample application provided by the Rapid Development Kit which shows a sample on how to easily develop modern, scalable applications using the Alta UI. The image below shows the landing page of the application with the splash screen. The running application can be seen at http://140.86.8.75/AppsCloudUIKit/faces/Welcome

In Part 1 we already downloaded the source of the application, created the DCS project, assigned users to the project and initialized the GIT repository for the application in the DCS. The next step is to migrate the application which was designed using JDeveloper 11.1.1.9.0 to JDeveloper version 12.1.3 which we use in the DCS.

Before we start we checkout a new branch named ‘develop’ from the GTI repository. This allows us to work outside the ‘master’ branch. When we finished the migration we can merge the changes back to the master. This resembles the GIT Flow pattern (see ‘The Git Experience (Part 4)‘).

Migrating is as simple as to open the project in your local JDeveloper 12.1.3 and let JDeveloper do an automatic migration. There are some things which have to be changed in the sources as JDeveloper can’t do them automatically.

  1. We check the libraries used in each of the projects of the AppsCloudUIKit workspace. Make sure that there are no red marked libraries as this would mean that the library is not available in the current defined libraries. If we see one of those (e.g. JSF1.2 which is JSF2.1 in 12.1.3) we need to find an equivalent library for 12.1.3 and choose this instead.
  2. We compile each project and correct any errors we find in the compile window. There are some warnings which we let go for the moment. They tell us that the UI uses some tags or components which have been deprecated in JDeveloper 12.1.3. The components are still available but we should exchange them with the new components in the future. When we compile the projects we have to follow a specific order, the dependency of the project. There is a common project ‘UIKitCommon’ which is used in all other projects. This project holds the foundation of the application. Once the project compiles we have to create an adfLibrary from it which is used in the other projects. For this we right click on the project and select ‘Deploy’->’adflibUIKitCommon…’ and follow the instructions.
  3. We need to setup the data used for the application. The application doesn’t use a DB in this version. All data is created and served via POJO Java classes. All of them reside in the ‘DemoData’ project. We compile this project and create an ADF library from it like we did for the ‘UIKitCommon’ project.
  4. We compile and deploy (to adfLibrary) the other projects in this order: ‘DemoCRM’, ‘DemoHCM’, ‘DemoFIN’ and finally ‘DemoMaster’. The ‘DemoMaster’ project create an EAR File which can be deployed to a standalone server.

After this we can run the application in our local server integrated in JDeveloper and see if it works (see the image above). Once this is verified we save all changes in the GIT repository and push them to the cloud based remote GIT Repository. This is like working with any other remote GIT repository, no difference in usage. After this the landing page of the DCS project shows the trail of work as in the image below.

Using the collaboration features

One really nice thing about the DCS is the integrated collaboration features like a wiki page, an issue tracker like Jira and an agile board where we can plan sprints to track the progress of the project.

We create a wiki page to collect all decisions made during development and generating documentation this way. This will help members to understand the project and how they are supposed to work with the project. New members added to the project at a later point in time can use this wiki to understand the project and how to work with the team.

The image below show the start wiki page of the project

and add some basic information about the project. Later we add more info about who we changed the project and how to setup the build system.

The wiki supports cascading pages too. We add a page describing the build system to the project. This allows other team members to efficiently use the build system on the DCS. We talk about details of the build system and how to use it in the next part.

Agile Development

The DCS supports agile development. The tab ‘Agile’ opens a sprint planning view to the project. This is a very neat feature. Teams can use this to plan their tasks and track their progress. Here we can create issues (tasks, feature or issues) which first end up in the bag log. We can create sprints and assign the issues to sprints.

We can work like in e.g. Jira, we drag issues from the backlog to the sprint

to add the issue to the sprint

If you like you can change the agile board, e.g. add progress states

Finally we can start the sprint by defining the start and end date. Once a sprint is started we can look at the active sprint to see the tasks in their different states. This view allows drag & drop to make it easy to change the status of a task.

Once all tasks are finished we can complete the sprint.

A look at the ‘Issues’ tab shows the finished work.

All this works out of the box. As a teaser I added a couple of images from the DCS team feature when they are integrated in JDeveloper 12.2.1

When the DCS supports JDeveloper 12.2.1 the integration to the agile board and issue tracker is as simple as logging into the DCS. No hassle setting up a team server and all other needed software and their adapters.

This concludes the second part of the series. The next part reveals details about the build system.

DOAG DevCamp2016: Oracle Development Cloud Service Hands On (Part 1)

End of February the DOAG held its annual DevCamp in Bonn, Germany. One big part of the DevCamp was a session or better a couple of session about the Oracle Developer Cloud Service and how to use it.

This part shows some general information about the Oracle Cloud. In the next part we show how to migrate an existing application to the cloud and how to use some of the available tools of the Development cloud.

The Developer Cloud Service (DCS) was introduced last year and became available to the public around the OOW2015. It offers a whole toolset to allow development of applications in the cloud. The DCS is bundled with the Java Cloud Service (JCS) which is bundled with the Database Cloud Service (DBCS). There are a couple of other services like Storage Cloud Service , responsible for managing the disk storage needed, and Compute Cloud Service responsible for the security and firewall of all services used by a company. For more information see Fasten your seat belts: Flying the Oracle Development Cloud Service (1- Boarding).

All these services are working together. If you ever have setup a working Oracle environment consisting of a DB, a WebLogic Server, load balancer, ADF Runtime you know that this isn’t an easy task to accomplish. The good news is that this work is done automatically by Oracle provisioning the different services. You as a user or company have to make some decisions like which version of the DB you want to use, or which version of WebLogic Server to install and how many CPUs to use for each service. You can later upscale the number of CPUs or managed server you want to use in total for your system. All this is very flexible.

Why to use the DCS?

Well, as mentions before, setting up a development environment does take some time and hardware. Sometimes it hard to get the time from your admins to get the hardware and setup the software to get the full environment four your development. This is one reason I see at my customers for not upgrading to newer software versions. The department has to buy the hardware and software licenses, without knowing exactly which hardware parameters they later need. Once the evaluation is finished you have the hardware and software on stock without knowing if you really need them. After all it was an evaluation only.

Oracle Cloud Services (Platform as a Service or PaaS in short) allows you to buy or lease the needed hard and software to setup an evaluation stack. You can use the stack as long and you pay for it. You can up/down scale it to your needs. As a sample you can start with a small scale development environment (DB, WeblogicServer with one admin and one managed server) and later scale it up with a load balancer and multiple managed servers in a cluster.

Right now there are two different environments for development available to configure: 11g as JDev 11.1.1.7.0 and 12c as JDev 12.1.3. In a couple of weeks JDev 12.2.1 should be available too.

Depending on the size (RAM, storage or number of OCPUs) you can select ‘metered’ or ‘none metered’ services. For pricing information see https://cloud.oracle.com/en_US/java?tabID=1385147650676 for a sample for the JCS.

Installation or configuration of the DCS is not part of this document. Oracle Developer Cloud Service smoothly and invisibly integrates your development environment with the latest versions of other services in Oracle Cloud, such as Oracle Java Cloud Service and Oracle Database Cloud Service.

Another big plus is the fully integrated development life cycle which allows to create and administer the configurations for code repositories, continuous integration, testing, building, and deployment for all stages of the development.

Developer Cloud Hands On

The remainder of this document talks about the practical work with the DCS. We show which tools are provided and how to use them to setup a CI (Continuous Integration) environment. As a test case we use the sample application provided by the Rapid Development Kit which shows a sample on how to easily develop modern, scalable applications using the Alta UI. The sample was developed by Oracle Applications User Experience team to give developers a foundation to enhance the sample or use the code they like in their own application. The image below shows the landing page of the application with the splash screen. The running application can be seen at http://140.86.8.75/AppsCloudUIKit/faces/Welcome

The application comes with design guide as an e-book and hints on how to use and extend the sample. We start with downloading the source from the web page. The application was developed using JDev 11.1.1.9.0. In the DCS we use JDev version 12.1.3.

Before we start to use the DCS we copy the sources from the zip into a new empty directory. From this directory we start by first logging into the DCS and creating a new project, DevCamp16 in the image below.

The identity domain holds the service (multiple projects) and members who can access the DCS using different roles. Once we work with one of the project we can add members to the project, but first have to add them to the identity domain as users. For this document we are only using one administrator and multiple development users. The DCS administrator assigns new users to the DCS, the project administrator the members of the DCS to the project. A DCS member can be member in zero or many projects in different roles. This way one DCS can be used for different projects. Members of one project can be excluded from others. A member of the identity domain only sees projects he is a member of. This allows a fine grained project landscape.

The project is the development environment we or the team uses to develop an application. A project holds one or more GIT repositories to manage code, a Husdon build server to manage the builds of the software, an issue tracker (kind of Jira), a wiki which we user to document decisions we made during the development, a deployment section which we use to implement a CI environment and finally we get an agile board where we can plan the development (add issues, backlog and sprints).

The last tab we see is the ‘Administration’ tab which allows one or more members to act as the administrators of the project. An administrator can add other members to the project, manage their rights and even remove the project with all its artifacts. The UI is modern and build using JET with Alta UI Design. The image below shows the administration page of the project.

The image below shows the GIT (or more than one if we add more) and the one Maven repository.

In the next tab we get an overview about the project. This is more or less empty as there has not been much work done.

The final tab hold the information about the members of the project.

This concludes part 1. In part 2 we talk about how to migrate the application from the RDK to the DCS. We learn how to setup the build system and integrate with continuous integration service.

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

DOAG DevCamp 2015

Upcycling Software!

The DOAG (Deutsche ORACLE-Anwendergruppe e.V.) meets for the DevCamp 2015 in Frankfurt a.M., 29th & 30th of April 2015. This event is a great opportunity to meet German Oracle users, Oracle ACE and Oracle ACE Directors as well as Oracle Product Management to discuss your matters.

The event will be held as a bar camp where everybody can suggest topics at the start of the event which are then evaluated and scheduled for discussion during the event. There is no better chance to discuss your problems, hopefully get some answers or pointers and meet your peers.

I’m looking forward meeting customers, colleagues and friends for interesting discussions and some hacking. This years main topic is ‘Upcycling Software’. Two big Oracle customers (Bundesagentur für Arbeit and IKB) tell us about their challenge in upcycline software.

If you are not already registered take the opportunity and visit [DevCamp 2015|http://barcamp.doag.org/] now!