Skip to Content

Introduction

After playing around with the available SCP Cloud Foundry demos based on Java (SAP Content Platform Tutorials) I was interested how to use Node.js and especially how to connect to a MongoDB Service instance with Node.js. For testing reasons I put a simple OpenUI5 application on top which consumes the data from the MongoDB using an API exposed via Express. So because of the usage of OpenUI5 it is not a classical MEAN stack application, but the principles are the same. An inoffical name used for such a scenario is NEMO (Node.js – Express – MongoDB – OpenUI5). Disclaimer: The following described points are not “high sophisticated” implementations, especially the API and UI5 part. They are just for testing reasons created. The main goal was to find out how the information about the MongoDB service instance(s) can be accessed and used within a Node.js application and how the connection to the MongoDB service instance can be established.

Prerequisites

To be able to do the implementation steps some prerequisites have to be fullfilled.

First of all a SCP Cloud Foundry trial instance has to be created like described here.

To inteact with the Cloud Foundry instance via command line the Cloud Foundry CLI has to be installed on the local machine and the connection to the instance has to be established using the commands “cf api” and “cf logon”. All details are described here and here. The result should look like following:

01_prereq_cf_api_cf_login.JPG

On the local machine Node.js including the Node Package Manager needs to be installed. Follow the instructions on https://nodejs.org for that. If you are in a corporate network please consider to set the proxy settings for npm (https://docs.npmjs.com/misc/config).

To be able to test against a MongoDB instance on the local machine, MongoDB needs to be installed (https://www.mongodb.com/download-center?jmp=nav#community).

Create the Cloud Foundry based Node.js application structure

The package.json file

In the obligatory “package.json” file the name of the application, the required dependencies to npm packages and the node engine to be used are configured.

As node engine 6.2.1 is used which is supported by the Node.js Cloud Foundry buildpack in version 1.5.15 (Release v1.5.15 · cloudfoundry/nodejs-buildpack · GitHub). What version of the buildpack is available on the Cloud Foundry instance can be determined using command

cf buildpacks

The output of the command displays all available buildpacks including the version information in the file name.

/wp-content/uploads/2016/09/03_cf_buildpack_1029413.jpg

The npm packages which are used as dependencies in this demo are:

  • express
  • body-parser
  • mongoose
  • cfenv
  • path

They can be installed using command

npm install –save dev express body-parser mongoose cfenv path

Details, why they are necessary and how they are used, are described in the following paragraphs.

Finally the package.json file looks like following (version numbers of dependencies can be different depending on the point of time installing them):

02_package_json.JPG

The application manifest

In the application manifest file “manifest.yml”, information about the Node.js application and Cloud Foundry are described. The information is used by the “cf push” command for setting up the environment when the application is deployed to the Cloud Foundry instance. Later information will be added for the MongoDB service consumption.

04_manifest_yml.JPG

Following information is provided in the file:

  • name: The name of the application.
  • buildpack: The name of the Node.js buildpack determined before with command “cf buildpacks”. It is also possible to reference the buildpack sources on GitHub. By default an auto determination of the buildpack is done if the buildpack information is missing in the application manifest. But from my point of view it is clearer to specify it in the application manifest.
  • command: Node.js applications needs a start command to start the application. In the example “node app.js” is called which executes the JS code in a file “app.js” which is described later. The command is executed automatically after the application is successfully deployed to the Cloud Foundry instance.
  • memory: Definition of the RAM available for the application. For the demo 128 MB are used.
  • disk_quota: Definition of the disk space available for the application. For the demo 128 MB are used.
  • host: Host information for the application which is used in the URL which makes the application accessible.

Application structure

In the application root folder the folders “server” and “client” are created to separate the server/client logic from the beginning. Additionally a “.cfignore” file is created which contains all folders/files which have to be ignored by the “cf push” command. That means all files/folders listed in that file are not uploaded to the Cloud Foundry instance. For instance the “node_modules” folder can be excluded from the upload because the step to prepare the environment downloads the npm packages defined in the package.json file. For the demo case the sources are stored in a Git repository, therefore also a classic “.gitignore” file exists. Following you can see the initial application structure and the content of file “app.js” which contains the JS code executed after the successful upload/build of the application to the Cloud Foundry instance. At the moment the coding in the file just creates an Express instance, adds the body-parser middleware to process URL parameters and JSON bodies (for the later defined API) and starts a web server.

05_app_js.JPG

Create a MongoDB service instance and connect to it

Create a MongoDB service instance

MongoDB is available as service in the SCP CF environment. To display the available services the command

cf marketplace

has to be executed. This produces following result.

06_cf_marketplace.JPG

To create an instance of the MongoDB service the command

cf create-service mongodb v3.0-container mongodb-nemo-t01-service

needs to be executed. “mongodb-nemo-t01-service” is the service instance name which is used to bind the service instance to the application.

07_cf_create_service.JPG

Executing command

cf services

shows the created service instance. The service instance can also be seen in the SCP CF cockpit “Service Instances” area.

08_cf_services.JPG

To bind the service instance to the application, following “services” property using the name of the MongoDB service instance has to be added to the application manifest.

09_application_manifest.JPG

cfenv npm package – determine Cloud Foundry environment variables

The Cloud Foundry environment provides several environment variables which can be used in Node.js. For instance there is the environment variable VCAP_SERVICES which provides in that demo case information about the bound MongoDB service instance, e.g. the connection URI. The npm package cfenv (which was already added as dependency at the beginning) provides functionality which parses the information out of the environment variables, so that a developer has not to do it by himself. In addition the object created by the package provides also information if the application is running in a Cloud Foundry environment or locally. Depending on that, information is provided, like the PORT information, set to useful values (also in a local environment).

In the “app.js” file the functionality of the cfenv package is added.

/wp-content/uploads/2016/09/10_app_js_1029567.jpg

Connection to the MongoDB service instance using mongoose

The connection to the MongoDB is done using mongoose which allows an easy object modeling in JS.

First a file “/server/db/mongo-connect.js” is created which coding establishes the connection to the MongoDB using the information provided by the cfenv object. As it can be seen in the coding it is checked if the application is running in a “local” mode. In that case the connection is done to a local running MongoDB “test”. So the application can also be tested locally with MongoDB.

11_mongo_connect.JPG

In the “app.js” file the function exported by the “mongo-connect.js” file is called, passing the object created by the cfenv functionality. With that the connection to the MongoDB is established, but so far really nothing more is done.

12_app_js.JPG

Create an API layer

In that step a little User API is created which enables to create/read/update/delete users. Of course there exists API frameworks for Node.js (for instance loopback), but for demo purpuses this is done in a simple way from scratch.

First the moongoose schema and model are created in a file “/server/db/models/user.js”. The schema definition defines the fields the resulting MongoDB collection will get. The Node.js application interacts via the exported model with the collection.

13_user_js.JPG

In a file “/server/api/users/users.js” the previous created mongoose model is imported and the Express routes are defined. “oApp.get(‘/api/user’, …” for instance defines that via the URL “/api/user” all users can be determined. The coding for the create/update/delete functionalities can be found in the Git repository which is linked in the “Resources” paragraph.

14_user_js.JPG

That the routes are evaluated by the Express application, the function exported by the file has to be called in the “app.js” file passing the Express application object.

15_app_js.JPG

Starting the application with command “node app.js” allows to test the API locally. Two data records inserted with Postman using the API will return following by calling the URL “http://<host>:<port>/api/user”.

16_localhost_api_user.JPG

Add a presentation layer using OpenUI5

To be able to test the API also with a “real” frontend and not just via Postman or some other tool a simple OpenUI5 application is created. I don’t describe the details of the application here (it can be seen in the Git repository), but just the necessary steps to integrate it in the Express application. At time of writing this the beta version of OpenUI5 1.40 is used for that demo. The application provides a view which allows to display all users, to delete them and to add new ones. In addition an additional view is integrated which displays some information about the application (e.g. the values of the environment variable VCAP_SERVICES described above). The API for that can be found in the Git repository too. The access to the API layer defined previously is done using a UI5 JSONModel to read the data and jQuery AJAX requests to create and delete data.

In the folder “/client/public/webapp” the sources of the OpenUI5 application are stored. An “index.html” file is available which instantiates the OpenUI5 component and displays it in a component container.

19_webapp_structure.JPG

File “/client/routes/routes.js” exports a function which adds a route to the Express application. Calling “http(s)://<host>:<port>/” will send the index.html file to the caller.

18_routes.JPG

In the “app.js” file the function exported by “routes.js” file has to be called to register the route. In addition the “express.static” middleware is added to the express application which defines the OpenUI5 webapp folder as folder for static resources. So each file of the single page application can be loaded.

17_app_js.JPG

Testing the application locally produces following result.

20_app_info.JPG

21_app_users.JPG

Checking the MongoDB collection records on the console shows that the data is really available in the local MongoDB.

22_mongo_user_collection.JPG

Deploy the application to the Cloud Foundry instance

So far the application was only tested on the local machine. Now it is time to deploy the application to the Cloud Foundry instance using command

cf push

executed in the application root folder where the application manifest file is available.

The log shows different information regarding the deployment steps and finally reports that the application is successfully started and running.

23_cf_push.JPG

 

Afterwards the application information can also be found in the SCP CF cockpit.

24_app_in_cockpit.JPG

Executing the application route URL displayed on the page opens the application.

25_app_info.JPG

26_app_users.JPG

Resources

The sources used above (and a little bit more) can be found at GitHub – pfefferf/hcp-cf-nemo-t01. If you wanna deploy the app to your on SCP CF instance, just change the host information in the application manifest to something unique.

Conclusion

With the above described steps I hope I could explain a little bit how easy it is to create a Node.js application connected to a MongoDB service instance and putting a simple OpenUI5 app on top. The options what to use from the Node.js universe and how to use it a nearly limitless within that Cloud Foundry based environment.

To report this post you need to login first.

17 Comments

You must be Logged on to comment or reply to a post.

  1. Ivan Mirisola

    Hi Florian,

    I have followed the procedure to enable my HCP account access to Cloud Foundry Beta, but I am currently unable to see the organization I have created on YaaS. When I issue the following command I get:

    # cf orgs

    Getting orgs as xxxx@xxx.com

    name

    No orgs found

    I have an Org created with a Project and HCP Starter Edition Cloud Foundry (beta) assigned to it. Funny is when I open Builder@YaaS –> Org  –> Prj –> HCP the organization shows as “In Process”.

    Do you know if it takes some time to actually display the organization name here? Or should “in process” means something like “active for the trial period”.

    Regards,

    Ivan

    (0) 
    1. Florian Pfeffer Post author

      Hi Ivan,

      seems like the preparation is still “In Process”. After the preparation is done, the status switches to an information about days left for the trial period.

      Regards,

      Florian

      (0) 
      1. Ivan Mirisola

        Thanks Florian!

        Great blog BTW! Congrats!

        Do you remember how much time it took for you? I created the org and project yesterday, so it’s been arround 18hrs already.

        Regards,

        Ivan

        (0) 
          1. Ivan Mirisola

            Hi Paul,

            It was a glitch in the system. Try to delete de org you created and create it again.
            Once you add the Cloud Foundry BETA it is added to your space almost instantly.

            Good luck!

            Regards,
            Ivan

            (0) 
  2. Alexander Gahr

    Great Tutorial,

    is there a change that you can also show us how to make this API and UI secure using the UAA in sap cloud foundry?

    Best regards

    Alex

     

     

    (0) 
  3. Kuldeep Poonia

    Hi everyone,

    Can any one tell me where to see all table records of MongoDB on  HCP cloud foundry gui interface? I didn’t found any link or blog. Currently I am able to see all records through programming only.

    (0) 
    1. Florian Pfeffer Post author

      Hi MG,

      at time of writing the code I used the OpenUI5 beta version to be able to use some features which were not in the final release. The beta channel is no longer supported. The error occurs because the UI5 core cannot be loaded.

      If have fixed that in the repo. It points to the released UI5 version now.

      Regards,
      Florian

      (0) 

Leave a Reply