Soaring Through the Clouds – Part 8: Oracle JET Application on top of MCS and ACC

Version 10

    The final installment in the Soaring Through the Clouds series, this article examines the last link in the chain of ten cloud services: a rich user interface in a desktop browser or on a mobile device, implemented using the Oracle JET rich client web development toolkit.


     

    By Lucas Jellema ACED.gif

     

    Table of Contents
    1. Introduction: How to Integrate Ten Different Oracle Public PaaS Services
    2. Internet of Things Cloud Service
    3. Building the Authorization Process and Microsite
    4. Integration Cloud Service to Connect the Dots
    5. Orchestration, Enrichment and Persistence with SOA CS and DBaaS
    6. Lightweight Application Container Cloud Service for Rich API implementation with Node.js
    7. Mobile Cloud Service
    8. Oracle JET application on top of MCS and ACC

     

    In this article, we reach the end of the chain—the apex of the integrated flow across ten cloud services. A rich user interface in a desktop browser or on a mobile device, implemented using the Oracle JET rich client web development toolkit. This application runs on the Application Container Cloud as a Node.js application and makes use of the developer-friendly APIs exposed from MCS, as discussed in the previous installment in this series.

    image001.png

    Figure 1

     

    The JET application provides insight into the artist proposals that have been recorded after being initiated on Twitter, approved on PCS and enriched on SOA CS. The screenshot below shows the overview page in the application.

    image002.png

    Figure 2

     

    The list of approved artist proposals retrieved from MCS can be sorted by number of votes or registration date. Multiple visualizations are available for the number of votes per artist; using the buttons at the bottom, we can toggle between horizontal and vertical (and stacked or unstacked) bar charts as well as a pie chart.

     

    A user can drill down to learn about a particular artist’s details, such as biography and discography:

    image003.png

    Figure 3

     

    All data shown on the details page are retrieved from MCS (and indirectly from SOA CS and DBaaS). The image shown for the artist has been selected by the human approver in the PCS workflow. The tweet button allows the user to add his or her vote for the proposed artist by tweeting in the required format, as shown in Figure 4:

    image004.png

    Figure 4

     

    The Backend Node.js Application

     

    The Oracle JET web application is a rich client application that runs in the browser. When the application is accessed from a browser, all required (static) files – HTML, CSS, JavaScript – are retrieved by the browser from a web server and executed in the browser. We use a simple Node.js application to serve the client side JET application sources to the browser.

     

    Additionally, the Node.js application is a simple proxy between the client application in the browser and the remote MCS APIs, as shown in the next figure. In order to smoothly deal with the CORS headers (Cross-Origin Resource Sharing) and handle the mobile backend identification and the authorization for the MCS APIs, it is convenient to use the server side Node.js application for the interaction with MCS on behalf of the rich client JET application.

      image005.png

    Figure 5

     

    The first step in creating the rich web application is the use of the npm module express generator to generate the application scaffold. The index.js file is configured next to handle HTTP requests for static files in the public directory (where the rich client application’s resources reside) and API requests for the REST APIs on MCS. The entire index.js application is shown in the code snippet below:

     

    var express = require('express');
    var app = express();
    var request = require('request');
    app.use(express.static('public'));
    app.use('/mobile/*', function (req, res) {
    
        var url = process.env.MCS_URL + req.originalUrl;
        req.pipe(request({
            url: url,
            headers: { 'oracle-mobile-backend-id': process.env.MCS_BACKEND_ID },
            auth: { user: process.env.MCS_USER, pass: process.env.MCS_PWD }
        })).pipe(res);
    });
    
    var PORT = process.env.PORT || 3000;
    app.listen(PORT);
    
    

     

    The Express framework is used for specifying the URLs to be served by this simple application. The contents of the directory public are exposed through app.use(express.static('public'));. This directory contains the JET application resources that are to be downloaded to the browser.

     

    The line starting with app.use('/mobile/*' handles all requests from the JET application to the MCS APIs: each request is forwarded to MCS with the required mobile backend identification and authentication details, and each response from MCS is returned to the browser unchanged, by the command pipe(res).

     

    Development of the Oracle JET application

     

    The Oracle JET application consists of a number of custom HTML, CSS and JavaScript resources, supported by the Oracle JET libraries and frameworks such as jQuery, Knockout and RequireJS. The JET application resides in the /public directory. All resources under that directory are served by Node.js upon browser requests. You can inspect and download these sources at  https://github.com/lucasjellema/aced-cloud-demo-ofmw2016-valencia/tree/master/ACC/frontend/public         .

     

    The file index.html is the bootstrap resource in what is basically a single page application. This file includes the custom JET module drill – implemented through drill.html (the view) and drill.js (the supporting viewModel). This module largely consists of a single JET component—moj.ModuleAnimations.switcher  (see documentation: http://www.oracle.com/webfolder/technetwork/jet/uiComponents-ojModule-platformAnimation.html ) -- that implements a simple pattern of switching between an overview page and a details page. The next figure shows the first half of the structure of the application.

    image006.png

    Figure 6

     

    The overview is implemented with the custom acts module in files acts.html and acts.js. Acts.html uses the listview component ( http://www.oracle.com/webfolder/technetwork/jet/uiComponents-listView-collectionListView.html ) to present all proposed acts that are returned from the backend REST API in a JSON data structure.

     

    The acts module is extended with the charts module. This module shows a bar chart (horizontal or vertical, stacked or unstacked) or a pie chart based on the number of votes for each of the artists. These charts are created using the Data Visualization components Bar Chart ( http://www.oracle.com/webfolder/technetwork/jet/uiComponents-barChart-default.html ) and Pie Chart ( http://www.oracle.com/webfolder/technetwork/jet/uiComponents-pieChart-default.html ). This chart module is defined in chart.html supported by the viewModel in chart.js. The data underlying the chart is the sortedActs collection in the acts viewModel that is passed to the chart viewModel in acts.html.

     

    Figure 7 also shows the details state of the drill module, based on the details module that is implemented by details.html and details.js.

      image007.png

    Figure 7

     

    The details module uses a number of JET components to present content in an appealing way: Button, Panel ( http://www.oracle.com/webfolder/technetwork/jet/uiComponents-panel-panelcolors.html ) and Filmstrip ( http://www.oracle.com/webfolder/technetwork/jet/uiComponents-filmStrip-filmStripNavArrows.html ).

     

    Both acts.js and details.js call out to the Node.js backend to fetch JSON data sets at the /mobile/… URL. Requests at this URL are routed to MCS as visualized in the next image. These MCS APIs return JSON documents with summary information about all proposed acts or all details about a single act. These APIs have been introduced in the previous installment in this series.

    image008.png

    Figure 8

     

    This picture also shows how acts.html embeds a UI widget from Twitter, using the URL  https://twitter.com/hashtag/ofmaces, to show the most recent tweets with hashtag #ofmaces.

    Deploying and running the JET application on ACC

     

    Deploying the application can be done through the ACC Cloud Service Console, as described in installment five of this series. Another option is deployment through the API that ACC exposes for that. By making an HTTP POST call to the ACC REST API, which submits a form that contains the contents of the zipped application archive, the JET application can be rolled out in a fully automated fashion.

     

    The sources for the JET application are available in GitHub: https://github.com/lucasjellema/aced-cloud-demo-ofmw2016-valencia/tree/master/ACC/frontend . The gulpfile.js file contains the Node.js program code that makes the HTTP calls to the ACC API to create the application and programmatically deploy the zip file:

     

    var form = new FormData();
    form.append('name', name);
    form.append('runtime', 'node');
    form.append('subscription', 'Hourly');
    form.append('manifest', fs.createReadStream('manifest.json'));
    form.append('deployment', fs.createReadStream('deployment.json'));
    form.append('archive', fs.createReadStream('frontend.zip'));
    formData.submit({
    
        method: method,
        protocol: 'https:',
        host: 'apaas.us2.oraclecloud.com',
        path: '/paas/service/apaas/api/v1.1/apps/myDomain',
        auth: 'admin:password',
        headers: { 'X-ID-TENANT-NAME': 'myDomain'}
    });
      

    Note how the function _rjs() in gulp.js packages the JavaScript sources in the application into one compact and obfuscated file (optimized.js) that can far more efficiently be downloaded by the client than all the individual JavaScript files.

     

    When the deployment is complete, a number of environment variables need to be set, in order to configure the application for the MCS instance with which it interacts. These values are passed to the Node.js application context by the Application Container Cloud framework and can be accessed from within the application. This means that we do not need to hard code references to end points and other configuration properties into our applications. Figure 9 shows the Service Console’s Deployments page with details for the application deployment, including these environment variables.

      image009.png

    Figure 9

     

    More details on how to get started with Oracle JET applications on the Application Container Cloud service for Node.js are in this article:  https://technology.amis.nl/2016/02/07/deploying-an-oracle-jet-application-to-application-container-cloud-and-running-on-node-js/         .

     

    Conclusion

     

    Even a rich-client web application like Oracle JET that runs as a single page application in the browser needs to be served to the browser. A lightweight  and very scalable option to serve these applications is use of the Node.js platform (e.g., in the Oracle Application Container Cloud (ACC)). In addition to simply serving all static resources, this Node.js backend application can provide some useful facilities, such as proxying requests to external services and handling identification and authorization details as well as HTTP headers like the ones to deal with CORS. This article showed how a JET application can be packaged and deployed as a Node.js application on ACC. This application can easily access the APIs that have been exposed on Mobile Cloud Service for consumption in mobile and web apps—in this case, to access artist [proposal] data.

     

    The JET application itself provides a rich UI to end users, with a number of attractive features. Using the JET UI components, it is quite straightforward to create these rich UI elements. Once the application structure is created – using modules, views and viewModels and with the appropriate data structures and API calls – further refining and embellishing the application is fairly easy and productive. Development and testing can be done locally in quick development iterations, and automated deployment to ACC makes the next incarnation of the application available to the world.

     

    About the Author

     

    Oracle ACE Director Lucas Jellema is solution architect and CTO at AMIS, based in the Netherlands. An Oracle, Java, and SOA specialist, he works as a consultant, architect, and instructor in diverse areas such as Database & SQL, Java/Java EE, SOA/BPM and PaaS and SaaS Cloud Solutions. The running theme through most of his activities is the transfer of knowledge and enthusiasm (and live demos). Lucas is a well-known speaker at Oracle OpenWorld, JavaOne and various Oracle User Group conferences around the world. His articles have appeared in OTN, OTech and the AMIS Technology Weblog, and he is the author of Oracle SOA Suite 11g Handbook (2014, McGraw Hill) and the Oracle SOA Suite 12c Handbook (2015, McGraw Hill).

     


    NOTE: This article represents the expertise, findings, and opinion of the author.  It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.