Location Viewer

Towards the end of my internship, I started working on a more complicated project utilizing everything David and I had done. This project solved a problem that one of Progress’ customers had where they had switched a portion of an application from using Rollbase to PHP and MySQL. The application had been processing data that was rapidly coming in from GPS sources and the data was not being processed fast enough. Switching away from Rollbase, however, caused a whole set of problems, for example they could not integrate with other Rollbase apps. Thus, our project was to convert their setup, from using MySQL and PHP to using Node and Rollbase.

The first step was converting the database from SQL to a database that would work well with Rollbase and the rest of our setup. We decided to use MongoDB, a database that can be hosted on Modulus, and has a wide variety of applications with Node. For example, the MEAN stack is a way of using MongoDB, Express, Angular, and Node, all tools that I used for a variety of projects. To convert the database from SQL to MongoDB, we exported the database to JSON and then imported the JSON-array into MongoDB. This method works for relatively simple applications where most data types are strings or numbers.

After setting up the data in MongoDB, the next part was connecting the MongoDB to Rollbase. To do this, we used JSDO, a way of interacting with data that has a bunch of advantages. You can read more about JSDO in David’s and my post, and our code for exporting the MongoDB as JSDO is extremely similar to the jsdo-node GitHub project. With the JSDO, object implemented, we now had a way of exporting the data to Rollbase.

To import the data on Rollbase, we created a new application using JSDO data (first couple steps shown below). It was extremely straightforward as we just needed the ServiceURI and a copy of the catalog.json file from the CatalogURI. We then just labeled the fields correctly and had a complete Rollbase application.



Once we had a complete Rollbase application, the next part of the project was displaying the data using AngularJS, in addition to the views already in Rollbase. I had done this for a few earlier projects, for example my blog, and thus once the data was at the Rollbase level, it was easy to make an Angular app. Having the data on Rollbase had the other important advantage that I could combine the data from this application with other Rollbase applications. In this case, I combined the location data from the customer’s database with sets of faked data of citizens and fallen trees, so that from the Angular view, you could view the affected users for a given event and add affected users. An image of the overall architecture is shown below.


As a final addition to the project, I added some calls directly to the MongoDB so that users could view historical data using queries at the AngularJS level to show that with this setup, we could access the combined set of features from both MongoDB and Rollbase. You can view the code at https://github.com/progress/locations-viewer.



Corticon Healthcare App

I had previously worked on an app that combined AngularJS, NodeJS, and Corticon, but the app, a simple counter, was mainly a proof of concept. Corticon’s ability to quickly automate decisions makes it extremely useful for creating individualized pages in complex areas such as healthcare and taxes. With this in mind, I decided to work on making a simple healthcare website where each page could be customized based on previously entered responses.

AngularJS is very useful for building dynamic webpages, and through the use of ng-show, (I could have also used ng-switch) I was able to build a simple frontend where users could navigate between screens and answer some basic questions. This application, however, wasn’t being customized based on user responses, however, and to achieve this, I decided to call the backend. As a way of keeping the app relatively simple, I decided that the only customizations I would do would be based on the user’s gender and number of family members.  For the user’s gender, I changed the selection of magazines presented, and for the number of family members, I changed the number of family members shown using ng-repeat. Before writing the final app, I also added some basic animations for screen transitions and some form validation so that the user experience would be better.


An image of the application

After setting up the frontend, I just needed to connect the app to Corticon. To do this, I started by reusing my code from the previous app. I then used the JSON documentation to try to make REST calls to Corticon. I had a bit of difficulty, till I was told that the location to run REST calls was http://{hostname}/axis/corticon/execute. With this information, I was able to make JSON calls into Corticon. As of this post, I did not finish completely connecting the app to Corticon as it was my last week, but the project is being taken over by someone else who will finish it up.

Working with Corticon was very interesting and it turned out to be a very powerful tool. You can view the final project on GitHub at https://github.com/progress/corticon-angular-insurance and the sample app at http://health-insurance-22573.onmodulus.net/. Keep in mind that you might need to set up Corticon to be able to create your own copy of the app.


My next project was working with JSDO (JavaScript Data Objects), a way of interacting with data that has many advantages, including for example support for Mobile applications. To begin the project, I started with code and ideas from David’s JSDO and AngularJS web app. Because of this, I did not write most of the code for setting up JSDO. Instead, I used the JSDO objects provided by his code at his ServiceURI and CatalogURI. You can view the final project on GitHub at https://github.com/progress/jsdo-node, where most of my work was done in the JSDO-Tester component.

To start working with the JSDO object, I first needed to make sure that the JSDO objects were set up correctly. Conveniently, David’s code had a simple test method that would open a new JSDO data session and print out some data. With JSDO, this only involved logging in to the ServiceURI, adding the catalog, and calling the fill method. The JSDO fill method would get information from the catalog, which in his case would be returned to the user.

By calling this test method from AngularJS with an http GET request, it was possible to get the JSDO data in a format that AngularJS could easily work with. In other words, through JSDO, I was able to easily send data from MongoDB all the way to AngularJS on a NodeJS server as illustrated (the MongoDB to NodeJS part was handled by David’s code).


Once the data was at the AngularJS level, it could easily be displayed. I decided to just show it in table form using Jade. (David had used a slightly different method, using Serverify, to display his results, but the end result is similar to mine.) You can view the final AngularJS app at http://jsdo-node-angular-22603.onmodulus.net/.


If you are interested in more projects showing what you can do using JSDO, you can see a couple mobile web apps at http://oemobiledemo.progress.com/jsdo/example005/Screen1.html and http://oemobiledemo.progress.com/jsdo/example003/MyPhoneApp.html.

Corticon Counter

My next project was making an app using Corticon, a decision making tool by Progress. For the project, I started by using the tools I was familiar with NodeJS for the server and AngularJS with Jade for the frontend. To work with Corticon, I needed to communicate using JSON, which was relatively straightforward once I learned the format used by Corticon. For the first version of the app, I simulated the Corticon server with a NodeJS server. My server had a simple rule where given a number, it returned its negative. I soon had a working app that had a counter, which a user could reset. To make the app slightly more interesting, I wrote the app so that when reset, the counter would decrease till it reached zero, then increase again. In addition, I had the client display the counter squared in changing colors. However, this app allowed the server to send information to the client only when the client requested it (shown below).


To allow the server to send information to the client, without it being requested, I turned to Socket.io. This allows bidirectional communication between the client and server. A common example of an app that can be made using Socket.io is a chat client. For my project, however, I decided that I would continue building something similar to my previous app. To allow Socket.io to work easily with Angular, I decided to use the Angular Socket.io Seed as a starting point for my app. One thing to note about using this as a starting point is that it does not use the most up to date versions of Socket and Express. (Also, when building of the seed, instead of having a separate socket.js file, I moved my Socket.io code to the app.js file with the rest of the server code.)

Using Socket.io, I was able to send messages between the server and client, and using JSON requests, I was able to communicate with my simulated Corticon server. I now had an app where information could be passed both ways. However, my app continued to only have the server communicate with one client at a time. If I reset the count from one instance, it would not affect the rest. To address this issue, I changed my code slightly so that whenever a reset message was received by the server, it would broadcast the response to all clients. This allowed one client to easily change the rest, something that would have been much more difficult without Socket.io. I thus had a bidirectional app using Corticon calls for making decisions (design shown below).


The app can be viewed on http://counter-22161.onmodulus.net and the code can be found at https://github.com/progress/corticon-angular-app.

Importing an Existing Rollbase Project

To import a Rollbase project, the first step is creating a test account on Rollbase. You should be greeted with a screen similar to the one shown below.

RegisterAfter creating a Rollbase account, navigate to the Applications tab, followed by import from and then select xml (shown below). You can also directly navigate to importing xml files at: https://www.rollbase.com/prod1/setup/appFromXML.jsp  instead. 

ApplicationsImportPageImportProjectAfter choosing the file to upload, just keep pressing next, and your project should be automatically created or updated and will be ready to use. 



Angular Rollbase Blog V2

I had previously made a simple blogging app using Rollbase. The app worked well, if you were fine with anyone adding, editing, and deleting posts. However, for most blogs, while you want your posts to be publicly accessible, you only want trusted authors writing posts. I thus decided to modify my blogging app so that only logged in users would be able to submit content. At the same time, with known authors, I was able to show each post’s author. With these changes in mind, I started adding features to my previous app. (The rest of the post assumes you have worked with the previous blogging app.) To follow along, you can view the GitHub project at https://github.com/progress/angular-rollbase-blog/tree/login (the login branch of angular-rollbase-blog).

The first thing I needed to do was add a login page. This involved writing the AngularJS and Jade code so that a simple login page would be displayed. To actually verify users, I decided that I would pass the login credentials back to the NodeJS layer. This layer would call the Rollbase API to check if a user was actually valid. If the user was valid, Rollbase would return a temporary sessionId, which I would then be able to use in other parts of the application. I decided to store the returned sessionId at the Angular layer. One disadvantage with this approach is that every time the user refreshes the page, the user has to log on again. There are ways of getting over this limitation, for example by using cookies, but since my focus was on writing a simple app, I decided to ignore this issue for now. Most importantly, by having the backend, as opposed to the AngularJS layer, deal with logging in, I prevented the user from easily bypassing login and made the login much more secure.

With a login page in place, I next decided that I would have the app appear differently for logged in and regular users. To do this, I just checked if there was a sessionId stored in the AngularJS layer. Depending on its existence, different options would be presented to users. For example a logged in vs not logged in user has been shown below.


With this, I had a basic app, where only logged in users could post. However, if someone decided to modify the client facing code, which users can do, they would be able to still edit the blog. Because of this, I had to modify my edit, delete, and add post functions so that they would be called with a sessionId. This meant that only if the user passed in a valid sessionId, which would only be the case if they had logged on, would they be able to actually modify the blog.

Now that I had users associated with posts, I was also able to add an author section to each post. Because each sessionId is associated with a  user, when I was posting with a sessionId, the user was automatically being stored. When I went to the Rollbase fields page (shown below), I decided that the author I would use would be the updatedBy author (the last person to update the post), not the createdBy one; however, either author could have been chosen. This data was already associated with each post, and I just had to display it in my final webpage.


With this, I had a blog which had authors associated with each post, and my blog was no longer free for anyone to edit. The updated blog can be found on: http://angularrollbaseblog2-21893.onmodulus.net.

Angular Rollbase Blog

For my next project, I tried to gain more experience with Node and Rollbase by creating a simple blogging app. I based my project on the angular-express-blog, which took care of the Angular aspects of the application. Because of this, I primarily worked on the api.js part of the project to change it from storing data locally to storing data using the Rollbase REST api. To follow along, you can view the GitHub project at https://github.com/progress/angular-rollbase-blog.

The first part of the project was setting everything up on Rollbase. I created a test account on Rollbase so that I would be able to store my data easily.


I then made a new project and then created a new object to represent posts. My post object contained two important fields, the Post field (the title/name of the post, which was automatically created) and the text field (the contents of the post, a field that had to be added). If you don’t want to go through the process of making your own project, you can instead just import the existing project onto Rollbase. To do so, follow these instructions:  https://mendoncakeegan.wordpress.com/2014/08/28/importing-an-existing-rollbase-project/ using the XML file in the GitHub repo.Make AppMake ObjectAdd Fields

After creating the post object, it was given the integration name (accessed at (Application Setup > Objects > Post), ‘post2’ which is what I would use for referencing posts during API calls.

Integration Name

I also edited the permissions, so that both the Administrator and Query API would be able to View, Create, Edit, and Delete objects.

View Edit PermissionsEdit Perimissions

I also accessed the posts view (Application Setup > Objects > Post > All Posts) to get the unique viewId, which I would use in API calls to see all my current posts.

View viewView viewId

By default this view of all the posts is sorted by age, which worked perfectly for the blog application I was planning on making.

After setting everything up on Rollbase, I then proceeded to change the api.js file, which had been storing all the data in the angular-express-blog I was basing my project on. To access all the information stored in the Rollbase database, I needed to first login and receive a sessionId, which would allow me to make the rest of the API calls. The process for logging in was relatively simple, as I was just accessing a URL and receiving a JSON object in return. (For most of the API calls, I had the option to get results in XML or JSON form, and I generally preferred JSON.) After getting the sessionId, I was able to populate my local database using the data from Rollbase through a getPage call with my viewId and sessionId. Most of the rest of the API calls were similar and relatively straightforward, and soon I had a working blog app being hosted on my computer.

The final part of the project was deploying the project so that it would be publicly accessible. To do this, I had to modify the app.js file so it would use the appropriate port, instead of just defaulting to 3000, when deployed on Modulus. I then deployed the project by uploading the zipped project to Modulus. Instead of uploading the zipped file, I could have also used Modulus’ command line tool to create the project. If you are unfamiliar with Modulus, you can read up on getting started at https://modulus.io/codex/getting_started.

The simple blog application can be viewed at: http://angularrollbase-21755.onmodulus.net/.