Thursday Feb 18, 2016

Oracle Mobile Cloud Service Reuse: importing and exporting MCS artifacts

Reuse, Reuse, Reuse its the Developer’s mantra.

You go through all the effort to define in Oracle Mobile Cloud Service a Mobile Backend, specify all the endpoints and methods of your APIs, test all the Connectors and Storage collections to support a mobile application. Then you find out that some of those definitions and components can used in other mobile applications.

Being the good developer you are, you’re more than willing to share those definitions with other service developers to make their job easier. Wouldn’t it be nice to have a way to extract a set of definitions and all the dependent artifacts from one MCS instance and deposit those definitions into another MCS instance?

Well it’s very easy and straightforward if you use the new Export/Import features in MCS. You can export almost any MCS artifact like a Mobile Backend, an API or a Collection.

Let’s say you’re interested in reusing a Mobile Backend and all its components in another mobile application; the export process creates a packaged zip file which would contain a single mobile backend and all its dependent components, including any APIs the backend uses, any implementations the API uses along with any connectors and storage collections the MBE uses. You invoke the Export wizard, from the More menu on main page of the component you wish to archive.

In the Export page, you see all the dependent components that will be archived, including the state they are in, either Draft or Published.

You may then change any of the Policies the exported environment uses, for example the end points of your connectors. When the export process is complete you have a zip comprised of four files: the export, a package.json with the roles that need to be manually created in the target MCS instance, and policies.json containing all the exported policies and a Readme.txt listing all the exported artifacts.

Importing the packaged archive is even simpler than creating an export. In your target MCS instance, invoke the DEVELOPEMENT menu, expand the Applications menu and select the Import option.

This three step wizard steps you through the process of importing an archived package, viewing the contents of the import and making any last minute policy changes. Once the import completes, the top level components and all its dependent components will be added to the MCS instance.

One important point to make about the import process: you must manually pre-create, in the target MCS environment, any roles used by the artifacts found in the packaged archive.

Image courtesy of potowizard at

Wednesday Feb 17, 2016

Making promises: Oracle Mobile Cloud Service revamps Custom API SDK and Node.js support

I'm going to talk about 'promises' and for once as an Oracle employee not include a safe harbor slide ;-)

The February 2016 Oracle Mobile Cloud Service (MCS) release has two handy updates to the server side SDK exposed to custom API service developers in Node.js.

As an existing MCS customer you'd be familiar that within your custom API Node code, you used a generic server side SDK rest call for consuming the other parts of your MCS implementation through a call to the req.oracleMobile object and its methods get, put, post, delete and so on. For example in the following Node example we can see a call to a MCS connector AussieWeatherConn using the generic REST call to get data from an external service and return it to the mobile client:

service.get("/mobile/custom/AussieWeather/Perth", function(req, res) {

  var payload = {};
  payload.uri = "/mobile/connector/AussieWeatherConn/Perth";, function(err1, res1, body1) {
    if (err1) {
      res.send(res1.statusCode, err1.message);
    } else {
      res.send(200, body1);

This generic mechanism can be used to call all sorts of APIs inside MCS, including connectors, analytics, the storage API, or even other custom APIs. However as we're treating everything as a REST endpoint, as you can see it's a bit clunky. We have to pass a payload containing the REST URI as a string and other parameters to the method, there is no direct support for the MCS connector API I'm calling. Couldn't MCS provide dedicated SDK methods to call all the different REST APIs which can protect us from silly programming mistakes?

While this generic SDK mechanism continues to be supported in the February 2016 MCS release, MCS has introduced in the server side SDK methods dedicated methods to all the server side APIs (with the exception of the database API which is planned for a later release). Taking the connector example from above, in the following code you can see the new call supported for connectors:

service.get("/mobile/custom/AussieWeather/Perth", function(req, res) {

    function(success) {
      res.send(200, success.result);
    function(failure) {
      res.send(500, failure.error);

Compared to the previous example first note the SDK call to req.oracleMobile now includes a connectors object (as well as analytics, notifications and more to support the other APIs). Then also note the inline syntax support for referring to the AussieWeatherConn object that previously we had to name in a string.

The other major change you may note is the callback handler via the connector call being replaced by a then() call with separate functions to handle the success or failure. This new syntax is the support for Promises.

Promises originated from functional programming languages to make working with asynchronous functions easier, and have surfaced in many modern languages like Javascript and Node. To date I haven't personally found a simple definition of promises that I think conveys succinctly to beginners what they mean to your programming. For example take the following Wikipedia definition:

Futures and promises originated in functional programming and related paradigms (such as logic programming) to decouple a value (a future) from how it was computed (a promise), allowing the computation to be done more flexibly, notably by parallelizing it.


Possibly the better approach to explaining Promises is to show you the change between SDK calls in the different MCS releases.

In the original example the method accepts as a parameter a callback handler function to support the asynchronous callback when the connector returned a result.

The classic problem with callback handlers is that if you then need to call another connector as a result of the first, and another as result of the second and so on, you end up with a nesting hell, something like the following:

var payload1 = {};
payload1.uri = "/mobile/connector/Conn1/Resource1";, function (err1, res1, body1) {
   if (err1) {
      // handle error
   } else {
      // handle success
      var payload2 = {};
      payload2.uri = "/mobile/connector/Conn2/Resource2";, function(err2, res2, body2) {
         if (err2) {
            // handle error
         } else {
            // handle success
            var payload3 = {};
            payload3.uri = "/mobile/connector/Conn3/Resource3";
  , function(err3, res3, body3) {
               // Argh! Are we done yet?

While the above example is fairly simplistic and nicely condensed for this blog, imagine sprinkling those nested calls with the additional logic you need beyond just the req.oracleMobile calls, to deal with the payloads. It's going to get pretty messy, hard to maintain and just hard to read in general, especially for the next coder who has to understand this nesting logic.

With the introduction of Promises and the February 2016 SDK enhancement we can instead do the following:

  function(success1) {
    // handle success
  function(error1) {
    // handle error
  function(result2) {
      function(success2) {
        // handle success
      function(error2) {
        // handle error
  function(result3) {
      function(success3) {
        // handle success
      function(error3) {
        // handle error
  function(result4) {
    // and so on

As you can see the nesting hell is removed, and now each connector call within the then() has a success or error handler, where you can pass results to the next then() function and so on.

The then() function isn't where the Promise supports ends, the server side SDKs also include:

  • all: Wait for an array of promises to all complete and return a result that has all results.
  • join: Run a fixed set of promises and callback a function with their results as arguments.
  • settle: Same as all, except that it doesn’t stop on the first rejection.

As noted in the documentation these are modeled on the 3rd party Bluebird Promises implementation. Indeed you are free to import Bluebird as a 3rd party module into your MCS server side custom API node code and make use of its extensive Promise support.

Overall with the latest release of Oracle Mobile Cloud Service we continue to strive to simplify the coding experience and empower developers to use the latest programming paradigms, all with the goal of building mobile applications faster. I promise ;-)


Image courtesy of artur84 at

Tuesday Feb 16, 2016

Surviving the mobile offline blues with Oracle Mobile Cloud Service

Sick of your mobile apps hanging or being totally unusable when they don't have a connection? Tired of waiting for an app to download data and then having to constantly refresh it? Got a mission critical app which would be ideal for mobile but not sure how you're going to deal with update errors when two people attempt to sync the same updated record back to HQ systems?

These are problems that Oracle Mobile Cloud Service (MCS) Data Offline and Synchronization API is designed to solve.

With the February 2016 update to MCS we've revamped the API so the actual programming effort mobile developers need to put into this problem isn't a depressing complex mess of code you have to write yourself, rather it is, well, a doddle. Let's investigate.

Having created a server side custom or storage API, the mobile developer has to do only 3 things: install the MCS mobile client SDK for Android, iOS or Windows, configure the sync policies to state their preferences around fetching data from the device's local cache or remote server side APIs, and then write the client side code using the SDK to initialize the sync engine and fetch the data in just a few lines of code.

The sync policies are the magic of the MCS data offline & sync capabilities.  These options save the mobile developer from a complex programming problem and considering numerous offline use cases & sync edge cases. Rather it is replaced with a list of simple but powerful policy options to choose from, which along with the SDK provided by Oracle takes care of the grunt work of data sync between the mobile client and server.

As example imagine a MCS server side custom API for working with incident reports. In building support into your mobile app to synchronize data with the remote incidents API published via MCS, you make decisions like the following:

  • Fetch the data from the mobile device's local cache if the data is available, but if a cache miss occurs or the data has expired, then fetch the data from the remote MCS custom or storage API instead
  • Expire the local mobile cached data after 300 seconds
  • Periodically refresh any expired locally cached mobile data every 60 seconds to keep the local device's data up to date
  • If the user updates the device's locally cached data and the device is offline, queue those updates to be written to the remote API when the device returns online
  • On writing an update to the remote API service, if the service's copy of the data has already been updated by somebody else before us, define a rule to overwrite the server side change with your mobile client update

The following example demonstrates the choices from above using the sync policy settings of the MCS SDK data offline & sync API in an iOS application:

    <string>CLIENT_WINS</string >

Having set these options, here's an example in iOS Swift app working with the data offline & sync client side functions to fetch the above policies:

let mcsMbe: OMCMobileBackend =
let mcsSync: OMCSynchronization = mcsMbe.synchronization()

let mcsEndpoint: OMCMobileEndpoint =
  mcsSync.openEndpoint(OMCMobileObject.self, apiName: "IncidentsAPI",
    endpointPath: "incidents")
let mcsBuilder: OMCFetchObjectCollectionBuilder =
  { (objectCollection) -> Void in
    // Do something with objectCollection.getMobileObjects()
  { (error) -> Void in
    // Handle error

It's no more complex than that. No raw REST API calls to MCS to extract the data, no creating timers or threads to periodically refresh expired data with MCS, no dealing with data update collisions and HTTP headers like If-Modified-Since, or when the device goes online and offline which data to use, this is all handled by the SDK, driven by the sync policy options you choose.

Overall writing data offline & sync capabilities as well as fast caching into your mobile apps can be a challenging exercise for day-to-day mobile developers to solve, but are a feature that mobile users are demanding more and more. As we've seen the requirement is massively simplified with Oracle Mobile Cloud Service, leaving your developers more time on building out other compelling features of your mobile app, and not wasting time reinventing the wheel when Oracle has a solution for you which it excels at: managing data.

Image courtesy of stockphotos at

Monday Feb 15, 2016

New Update for Oracle Mobile Cloud Service

The cloud moves at a quick cadence and Oracle Mobile Cloud Service (MCS) has some new enhancements that MCS customers will get right away. 

  • Want to build apps that connect via Oracle Integration Cloud Service (ICS)?  You got it. Now the world is your oyster.
  • New updated, cleaner, crisper - more focused interface to get the job done.  Que bella!
  • Client SDKs for Windows .NET and JavaScript - Ok, done. You're welcome Mr. Gates, Mr. Ballmer, Mr. Nadella. 
  • Improved support for offline mode and data sync between the client and the backend? Yes - we shall persist.... 
  • OAuth 2.0 - security, security, security.
  • Improved policy management - no recompile needed
  • Improved analytical queries and custom saved reporting. Know everything about everything. Repeat.
  • Better asset sharing, import/export packages.  Because sharing is caring.
  • Continued improvements and easier use of platform APIs, connectors and custom APIs. API First!

We've also published an Oracle MCS February new features update video which gives you a rundown of all the new features. And over the next few days we'll be publishing blog entries that dive into some of the details of each of these new features. So keep watching!

I probably missed something so go here to see more details or feel free ask a question on the MCS forum.  

Self service learning you ask? Watch the in-depth videos on Oracle Mobile Platform YouTube channel.

Follow @OracleMobile

Monday Feb 08, 2016

Mobile Solutions for Oracle Applications

Enterprises building a portfolio of mobile applications often face significant challenges. These challenges are magnified when dealing with older versions of E-Business Suite or JD Edwards which may not have included an out-of-the-box mobile option from Oracle and while newer versions may include out-of-the box mobile apps, but they may not meet your customer needs or be easily customized. To address these challenges, check out this webinar which introduces new mobile solutions for E-Business Suite and JD Edwards. 

Follow @OracleMobile 

Thursday Feb 04, 2016

MAF 2.2.2 release available now

Approximately 6 weeks after the release of MAF 2.2.1 we have the next patch MAF 2.2.2 available. This release contains several important bug fixes and a new JVM optimized for 64 bit devices on iOS. The new JVM should provide a nice performance boost to your apps on most iOS devices. So we strongly encourage everyone to upgrade to this patch. Some key notes about the release:

  1. If you are already using MAF 2.2.1 picking up this patch should be a breeze. There is no migration needed if you are moving from 2.2.1 so you should be able to re-build your apps with the new release and good to go
  2. If you are moving from 2.2.0 or earlier release please be sure to follow the migration instructions provided here
  3. Bugs fixed in this release and other important release notes are available here



This blog is is dedicated to announcements,tips and tricks and other items related to developing, integrating, securing, and managing mobile applications using Oracle's Mobile Platform. It is created and maintained by the Oracle Mobile product development team.

Archive of past entries

Even More Mobile Development Blogs

Oracle A-Team Site - Mobile Related Entries

Code samples from the Community

Fusion Middleware Blogs


« May 2016