For anyone interested in HANA as a Service and the Web IDE Full-Stack, I have recently explored the Web IDE Full-Stack and Cloud Foundry environment with the goal of recreating a Node.js application. An application that I previously made using an on-premise version of HANA and Web IDE for SAP HANA (HANA 2.0 SPS 03). Along the way I encountered a few subtle differences and I am writing this blog to highlight these differences. I also included steps in the process that I found hard to figure out without foraging the internet for and piecing together multiple sources of information.
If you’re wondering if you should keep reading, here are the key Take-Aways:
Let us start at the beginning, specifically on a brand spanking new SAP Cloud Platform account and a world of opportunity. SAP Cloud Platform breaks things down into Global Accounts and Subaccounts. My account was initialized with two Subaccounts that looked like this:
As seen above, I had a Cloud Foundry environment and a Neo environment. At first, to me at least, this was confusing. I’m wanting to make a Cloud Foundry application, why do I need the Neo environment? The short answer is that Neo doesn’t have anything to do with my application. It’s simply the environment that runs the SAP Web IDE Full-Stack which has all the tools I need to develop my app. All the services and modules I create for my app will exist inside of Cloud Foundry.
After figuring that out, I began my project by traversing into the Cloud Foundry environment and creating a Space. Once inside the space, I navigated to the Service Marketplace in search for an SAP HANA Service. I quickly found the service, opened it up and used the wizard to create a new service instance. Nothing complicated here.
It was now time to find and enable the SAP Web IDE Full-Stack. In the Neo environment’s Service Marketplace, I searched for the Web IDE and found what I needed. However, there were a few unexpected extra steps I needed to complete before being able to use it. Inside of the Web IDE Full-Stack service overview, there is a Take Action tile where I found a Configure Service option.
I had to go inside of the Configure Service to grant myself Developer and Administrator permissions before being able to use the Web IDE Full-Stack. For both roles, DiDeveloper and DiAdministrator I added my SAP Cloud Platform User ID which granted my account the permissions I needed.
With the proper permissions I had one last task to do. Under the Security > Trust settings of my subaccount I needed to enable Principle Propagation.
With that out of the way, I was ready to develop my application using the Web IDE Full-Stack. Upon opening the Web IDE Full-Stack, I needed to set up my Workspace Preferences. The first thing I had to do was go to the preference menu and configure my default Cloud Foundry space so that the Web IDE deploys and creates services in the right place.
As you see, I needed my Cloud Foundry API endpoint. This was found on the Overview page of my Cloud Foundry sub account. I simply copied my API endpoint into the input field and selected my organization and space. Bam! That easy.
Next, I needed to enable a few Web IDE extensions. Under Workspace Preferences there is an “Extensions” menu item and inside I found a list of extensions for the Web IDE. For my project I enabled the following: SAP Cloud Platform Business Application Development Tools, SAP HANA Database Development Tools, and Tools for Node.js Development. There is more information about these extensions available on the SAP Help Portal. Enabling those extensions concluded the project setup and now I was ready to create my application.
Using the project creation wizard, I created an SAP Cloud Platform Business Application where I found two key steps to look out for when creating the project. First, on the Template Customization step I had to check the Use HTML5 Application Repository box.
This important step creates two application modules and a service that “enables the consuming application, typically the application router, to access HTML5 application sta....” I emphasize this because application routing was handled a bit differently compared to my on-premise application. Second, on the Project Details step, there is currently no option to initialize a project with a Node.js service module. I selected not included in the Service Module input field and then created a Node.js service module manually.
Woo! My project was set up and I was ready to begin developing. First task, creating my service module. Using Web IDE tooling I created a new Node.js Module. Using the Node.js Module wizard, I simply named the module srv then clicked next and finish. After that, I needed to add a bit of code to the applications package.json file to recognize my service module.
With my service module created, I went ahead and created an HTML5 module for the UI. After right clicking on the project folder and following New > HTML5 Module, I used the wizard to create an SAPUI5 Application. The wizard generated the module and I began looking through the files it had created. Taking a look into the xs-app.json, I noticed a small difference in the way the routing is handled compared to on-premise versions of the Web IDE. I notice that the @Sap/approuter.js module wasn’t a dependency in the web module’s package.json and routes looked to be handled by the html5-apps-repo service that was generated by the project creation wizard. With this knowledge, I investigated the appRouter module that was generated during project creation and found that it contains the @Sap/approuter.js module. Here was the xs-app.json file that I needed to add my routes to.
Fast forward, I have created a data model, set up my srv module, and built my UI. Everything was done simply by copying over the necessary files from my previously built on-premise application to my cloud application. However, upon running my srv module I encountered an error. Conveniently, I can no longer reproduce this error however, the error message looked something like this “the predefined session variable cannot be set via SET command: XS_APPLICATIONUSER.” After some research I stumbled across someone with the same error and used their solution. It was a simple switch in the order of two lines of code that fixed the error.
Lastly, it was time to test my application’s UI. The only difference here was the file directory and URL used to navigate to my app. In the on-premise Web IDE the HTML5 file directory comes with an xs-app.json, package.json, and a resources folder.
Pretty straight forward stuff. The cloud generated HTML5 modules have a few additional files (neo-app.json and gruntfile.js) and come with the skeleton of an MVC web application (webapp folder).
In the on-premise version, I developed my UI, stuck it in the resources folder, then set up the necessary routing in the xs-app.json. For the cloud version, I found it was easiest just to create a resources folder inside of the webapp folder that was generated and simply cut and paste the UI files from the on-premise application into it. I ran the srv and web modules, logged into the app using my cloud platform credentials, and appended the URL with the location of my UI’s index.html file (resources/<file name>/index.html). After testing the functionality of my application, it was safe to conclude everything works as expected.
In conclusion, development in the Web IDE Full-Stack compared to the on-premise Web IDE remained mostly unchanged, except for the few distinctions of needing to enable the appropriate Web IDE extensions, manually creating your Node.js service module, and using the html-app-repo service instead of the xs-app.json in the web module.
If you’re wondering if you should keep reading, here are the key Take-Aways:
- Creating an SAP Hana Service in the Cloud Foundry environment
- Setting up the Web IDE Full-Stack for Node.js development
- Difference in HTML5 routing
- Slightly different HTML5 Module directory
- A tiny code error I encountered along the way
Let us start at the beginning, specifically on a brand spanking new SAP Cloud Platform account and a world of opportunity. SAP Cloud Platform breaks things down into Global Accounts and Subaccounts. My account was initialized with two Subaccounts that looked like this:
As seen above, I had a Cloud Foundry environment and a Neo environment. At first, to me at least, this was confusing. I’m wanting to make a Cloud Foundry application, why do I need the Neo environment? The short answer is that Neo doesn’t have anything to do with my application. It’s simply the environment that runs the SAP Web IDE Full-Stack which has all the tools I need to develop my app. All the services and modules I create for my app will exist inside of Cloud Foundry.
After figuring that out, I began my project by traversing into the Cloud Foundry environment and creating a Space. Once inside the space, I navigated to the Service Marketplace in search for an SAP HANA Service. I quickly found the service, opened it up and used the wizard to create a new service instance. Nothing complicated here.
It was now time to find and enable the SAP Web IDE Full-Stack. In the Neo environment’s Service Marketplace, I searched for the Web IDE and found what I needed. However, there were a few unexpected extra steps I needed to complete before being able to use it. Inside of the Web IDE Full-Stack service overview, there is a Take Action tile where I found a Configure Service option.
I had to go inside of the Configure Service to grant myself Developer and Administrator permissions before being able to use the Web IDE Full-Stack. For both roles, DiDeveloper and DiAdministrator I added my SAP Cloud Platform User ID which granted my account the permissions I needed.
With the proper permissions I had one last task to do. Under the Security > Trust settings of my subaccount I needed to enable Principle Propagation.
With that out of the way, I was ready to develop my application using the Web IDE Full-Stack. Upon opening the Web IDE Full-Stack, I needed to set up my Workspace Preferences. The first thing I had to do was go to the preference menu and configure my default Cloud Foundry space so that the Web IDE deploys and creates services in the right place.
As you see, I needed my Cloud Foundry API endpoint. This was found on the Overview page of my Cloud Foundry sub account. I simply copied my API endpoint into the input field and selected my organization and space. Bam! That easy.
Next, I needed to enable a few Web IDE extensions. Under Workspace Preferences there is an “Extensions” menu item and inside I found a list of extensions for the Web IDE. For my project I enabled the following: SAP Cloud Platform Business Application Development Tools, SAP HANA Database Development Tools, and Tools for Node.js Development. There is more information about these extensions available on the SAP Help Portal. Enabling those extensions concluded the project setup and now I was ready to create my application.
Using the project creation wizard, I created an SAP Cloud Platform Business Application where I found two key steps to look out for when creating the project. First, on the Template Customization step I had to check the Use HTML5 Application Repository box.
This important step creates two application modules and a service that “enables the consuming application, typically the application router, to access HTML5 application sta....” I emphasize this because application routing was handled a bit differently compared to my on-premise application. Second, on the Project Details step, there is currently no option to initialize a project with a Node.js service module. I selected not included in the Service Module input field and then created a Node.js service module manually.
Woo! My project was set up and I was ready to begin developing. First task, creating my service module. Using Web IDE tooling I created a new Node.js Module. Using the Node.js Module wizard, I simply named the module srv then clicked next and finish. After that, I needed to add a bit of code to the applications package.json file to recognize my service module.
With my service module created, I went ahead and created an HTML5 module for the UI. After right clicking on the project folder and following New > HTML5 Module, I used the wizard to create an SAPUI5 Application. The wizard generated the module and I began looking through the files it had created. Taking a look into the xs-app.json, I noticed a small difference in the way the routing is handled compared to on-premise versions of the Web IDE. I notice that the @Sap/approuter.js module wasn’t a dependency in the web module’s package.json and routes looked to be handled by the html5-apps-repo service that was generated by the project creation wizard. With this knowledge, I investigated the appRouter module that was generated during project creation and found that it contains the @Sap/approuter.js module. Here was the xs-app.json file that I needed to add my routes to.
Fast forward, I have created a data model, set up my srv module, and built my UI. Everything was done simply by copying over the necessary files from my previously built on-premise application to my cloud application. However, upon running my srv module I encountered an error. Conveniently, I can no longer reproduce this error however, the error message looked something like this “the predefined session variable cannot be set via SET command: XS_APPLICATIONUSER.” After some research I stumbled across someone with the same error and used their solution. It was a simple switch in the order of two lines of code that fixed the error.
Lastly, it was time to test my application’s UI. The only difference here was the file directory and URL used to navigate to my app. In the on-premise Web IDE the HTML5 file directory comes with an xs-app.json, package.json, and a resources folder.
Pretty straight forward stuff. The cloud generated HTML5 modules have a few additional files (neo-app.json and gruntfile.js) and come with the skeleton of an MVC web application (webapp folder).
In the on-premise version, I developed my UI, stuck it in the resources folder, then set up the necessary routing in the xs-app.json. For the cloud version, I found it was easiest just to create a resources folder inside of the webapp folder that was generated and simply cut and paste the UI files from the on-premise application into it. I ran the srv and web modules, logged into the app using my cloud platform credentials, and appended the URL with the location of my UI’s index.html file (resources/<file name>/index.html). After testing the functionality of my application, it was safe to conclude everything works as expected.
In conclusion, development in the Web IDE Full-Stack compared to the on-premise Web IDE remained mostly unchanged, except for the few distinctions of needing to enable the appropriate Web IDE extensions, manually creating your Node.js service module, and using the html-app-repo service instead of the xs-app.json in the web module.
- SAP Managed Tags:
2 Comments
