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.


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 page in preparation of the session I planned for the DevCamp.


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


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.


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


We clicked on the ‘Buy Now’ and Eureka!


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


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!

Summary of Day 3 at Oracle Open World 2016

Started with the (early) morning keynote ‘Oracle OpenWorld Tuesday Morning Keynote‘ hosted by Bhanu Murthy B. M., Safra Catz, Hon. Chief Minister Shri. Devendra Fadnavis and Thomas Kurian.

As the keynote and it’s content is covered all over the media already I won’t add to this. Oh, one thing I like to say is that the ‘live’ demos did not really look live to me. Would you risk that your ‘live’ demo is going to hell because of some technical problem with Thomas Kurian on stage?

Next on my list for today was ‘Agile Development and DevOps Done Even Faster with Oracle IaaS and PaaS‘ by Michael Lehmann, Suhas Uliyar and  Siddhartha Agarwal. This session talked about agile development in the cloud using IaaS, PaaS and Microservices together with DevOps tools like Docker.

First a Cloud Navtive Architecture was introduced:


Cloud Native Architecture

 Multiple services working together to build the cloud native architecture

Services for the Cloud Native Architecture

The practical part was a sample which showed how to build, deploy, or manage mobile-fronted, API-first autoscaling application, a microservice build on Node.js here, live on stage. New here is htat you can use the Management Cloud Service to introspect the microservice to see how it runs on your environment. The just build service then is consumned by anohter app (mobile using MAX) to visualize the data.

The final dashboard build for the mobile app, it took only about 20 minutes to build and deploy:


Dashboard for the Mobile Application

and the final detailed architecture of the application:

Detailed Architecture

Detailed Architecture

Next on my Cloud program was ‘Development Operations in the Cloud: A Use Case and Best Practices‘ by Greg Stachnick and Jeff Stephenson. They talked about best practices using the Cloud Services to develop applications from the modern DevOps point of view.


Modern DevOps

The case study was about the development of the Developers Cloud Service itself, neat!


Developers Cloud Service Outline

This is a big project which is running completely in the cloud. Here is an image that shows a code review screen (sorry for the poor quality)


Code Review

After accepting the changes the changes are pushed back to the mail line, triggering the next integration cycle in the continuous integration system. The typical cloud developers life is


Day  in the Life of a Devloper

and the day of a manager

to summarize these points



This summary hit the nail on the head. I’ve bin a contractor in many projects, always asking for more machines or more power. I would be happy if I could spin up another machine to do some testing instead of waiting for some other things to finish using the machine I wait for.

Before my day is over there are two sessions about ADF and JDeveloper to attend. First was Shay Schmeltzer with ‘Oracle Application Development Framework and Oracle JDeveloper: What’s New‘ which reveals what’s coming up in the world of ADF and JDeveloper. Shay started with the short history of ADF and JDev


which is even longer if you count JBO to it too, which started 1999. Impressive. The session was more about features which are new in JDev 12.2.1 and JDev, both versions are out quite some time.  So, nothing new for seasoned ADF developers at the beginning.

Not so well known are ADF Business Components Triggers which are more known by Forms developers. They allow to do things right before or after some DB events fires.


ADF BC REST Services and REST DataControl are better known if you work in the cloud or with mobile applications:

Remote Regions where introduced with JDev 12.2.1 but needed a patch to make them run (fixed in


Remote Task Flows:


UI stuff like responsive support through templates (Tablet First), Massonry Layout and matchmediaqueries:


Lots of new and changed data visualization components:

and finally to sum things up, other enhancements behind the scenes:


For the future we can expect more and easier support for REST services and writing Groovy code. The biggest change will be the integration of JET Composite Components into ADF pages. JET Composite Components are an equivalent to ADF Declarative Components. You can build components from using other components, add properties to them to influence their behavior. Composite Components fire events which you can use to interact. Not sure how this will work, other that in the end you have HTML. Bad thing is that there is not even a time frame for this. More details in hte next section.

Anyway, ADF is not dead! There will be future development and enhancements in JDeveloper and ADF.

Final session for this long day ‘Oracle Development Tools and Frameworks: Which One Is Right for You?‘ by Shay Shmeltzer (again) and Denis Tyrell. As some of the features are not available at the moment the ‘Safe Harbor’ statement comes to play. So if you see something which you don’t find in the available version, you have to patiantly wait for it. No time frame given 😦

Shay summarized the different frameworks ADF, MAF, JET and ABCS and pointed out their key features. As the frameworks are well known I spare most details. As promised I give more detail about the Oracle JET Composite Components.

Sample JET Composite Components

Sample JET Composite Components

Key features of JET Composite Components and there basic structure is shown below

(Coming soon!) The composite components end up together in a Tenant Component Catalog where the components can be filtered by their characteristics


Which late will be extended so that components are available from different channels


In the end there will be Project Visual Code provides a low code environment

Project Visual Code

Project Visual Code

After this deep dive into JET Composite Components I present the summary of the session which shows which development framework is used for which development

At the end of the session Shay and Denis answered some question which are noteworthy. I Cant remember all question but tried to summarize the key points from the answers:

  1. Oracle focuses on JET as the future development environment Future focus on jet. Why? ADF is already feature rich and the developer don’t ask for much more.
  2. Developers want more client side development. Demand on server generated UI is going to decline.
  3. JET will get offline capabilities! This can’t be done easily with ADF.
  4. JET allows faster exchange of libraries. JavaScript developers tend to rewrite their UI faster then ADF developers (see yesterdays summary where Geertjan Wielenga made the same point).
  5.  Public Component Catalog is only public to a point. You have to submit components which then will be vetted by someone before other users can use them.
  6. Cloud IDE (writing code in the cloud) will have JavaScript capabilities
  7. ABCS (Application Builder Cloud Service) is not available on premise right now
  8. For declarative JET development look at ABCS. ABCS allows to get the underlying JET code (save as) so you can look at the code and change it, e.g. to use it elsewhere.

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 (

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 The build.xml file is the ANT build file and is not dependent on the environment. All environment dependent variables are put in the file. A sample of the created build properties look like

#Mon Feb 15 21:29:41 CET 2016

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 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 file.

The DCS offers two different environments (today), one for version and one for version 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:


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


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

Optimizing the for reuse

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

  • holds the name of the workspace, in our case AppsCloudUIKit
  • 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.
  • 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 ( 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

#Change the next properties to match your projects names

# Don't change anything below!


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

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

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 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 with JDeveloper 12.2.1 available

I almost missed that Developer Cloud Service has been updated to 12.2.1. Great news as we now can use JDeveloper 12.2.1 to access the agile capabilities like

  • Interact with Tasks/Issues in JDeveloper
  • Leverage the Team view in JDeveloper (tasks, builds, and code repositories)
  • Connect to DevCS and its projects from inside JDeveloper
  • Create Agile boards and manage sprints in Developer Cloud Service
  • Associate code commits with specific tasks
  • Monitor team activity in the Team Dashboard
  • Handle Git transactions

For more information about how JDeveloper and the DCS are integrated watch this video ‘Agile development with Oracle JDeveloper and Oracle Developer Cloud Service’.

This was possible since last year. So, what’s new?

New is that the JCS is also available in 12.2.1 and that we can use the whole continuous integration scenario. For this we have to configure a 12.2.1 JCS instance which then can be used for deployment. When we select to create a new instance of a JCS we see the new wizard which allows us to select a WebLogic Server 12c in version 12.2.1

On the ‘Edition’ page we don’t find anything new so we skip it and go to the Details page where we specify the needed information for the service, database configuration, backup and the WebLogic user

After getting the confirmation page we create the new service and finally after a short time we see the new service

A look at the Enterprise Manager of the new service shows the new login page

and after logging in the new 12.2.1 Enterprise Manager

It look modern and fresh. However, this is not what this blog is about. I installed my ADF Version Web Service BlogAdfVersionWS to check which ADF version is running in this instance. Selection the modules we find the test point on the right side of the Web Service

After selecting the test point we select to run the ‘GetVersion’ service

and get

That’s right what we expect when running ADF 12.2.1!

Next time we see how to change the build and deployment part of the DCS to work with the JCS 12.2.1.

Fasten your seat belts: Flying the Oracle Development Cloud Service (2 – Safety)

In this second part of the series we take a look at the safety features on board of our aircraft, named Oracle Developer Could Service.
As in a real aircraft we don’t see all safety features available, as some are hard to show without blacking most of the screen. We cover how the Developer Cloud looks for a new member of a project. Remember that a project in the cloud is not the same as a project in JDeveloper. For more info on this refer to Part 1 – Boarding.

We start with an administrative task of creating a new member for our Identity Domain in the Oracle Developer Cloud Service. This is necessary as only members to the Identity Domain can be members of a project in the Developer Cloud. The Identity Domain is the sandbox which holds all available (or licensed) cloud services. In our installation it contains the services we saw in the first part of the series.

Logged in as an administrator of the identity domain we can add a new user

Add a new member

Add a new member

Clicking on one of the marked links will open a couple of dialogs to fill in the new users data

In the first image we fill in the basic user data like name and e-mail address and the roles the user is assigned to. The e-mail address is significant as the new member gets a nice mail with credentials he/she must use to verify the e-mail address and finish the account building by changing the initial system assigned password.
The possible roles a user can be assigned to can be seen on the left. We only assign the new member the ‘Java Developer’ the role ‘Developers Service User Role’. This is sufficient to work with the Oracle Developer Cloud Service as part of a development team. The other roles allow a user access more administrative tasks and the other parts of the Oracle Development Cloud Service (DB, storage…).
Once the dialog is filled out an e-mail is send to the new member as well as to the manager of the user if this field is filled.
New member e-mail

New member e-mail

When the new member follows the link in the e-mail and logs in the first time he has to change her/his password. This isn’t just changing the password but you also have to answer three questions which are used if you forget you password and need to reset it later. You should note down the answers carefully! The next step is to configure the user interface language and timezone.

Finally you get transferred to the landing page showing all available services from all identity domains the e-mail address is or was registered to.
As I used the e-mail address before to get a trial account the landing page shows multiple identity domains. The one we are using in this post is marked with a red border. You can user the drop down to select to only show one identity domain which makes it less confusing.

Clicking on the Oracle Developer Cloud Service you are transferred to the ‘Welcome Page’ (last image of the gallery). At the moment you can only create a new project, but don’t see any available project. The reason for this is that the new member is not attached to an existing project. This has to be done by an ‘owner’ of the project. Only after this a member can access the project.
To add the new member to an existing project, we log into the Oracle Development Could Service as an owner of the project and add the new member to the project.

Administrator adds new member

Administrator adds new member

The next time the user updates the ‘Welcome Page’ or logs in again he’ll see the project.

Clicking on the project shows the project’s home page with the project’s timeline and information about the git and maven repositories.
Project's landing page

Project’s landing page

Now the new member can access the git repository information by clicking the menu button
Copy git repository address

Copy git repository address

With this information the member can clone the repository using JDeveloper 12.1.3

The member can now work locally with the project and make changes needed or assigned to him/her.

This concludes the 2nd part about safety and setting up members in the Oracle Developer Cloud Service.

In the next part we will introduce how to work with projects and how to setup projects for continuous integration (CI).