Skip to Content

hello readers, this is the 3rd post in my series of experiences while working with HXE2SP3. If you have read the other 2, thank you… if you have not, please check them out.

In this section, I will explain how adding a nodejs module goes and some interesting learning I had while doing this. Thank you again for reading this far.

 

My steps:

  • Add a new module to the existing project.

 

Let’s also enable XSJS for backwards compatibility in case we had an xsjs service before

And Yes you are right.. the new reference is automatically added to the mta.yaml file.

 

The package.json file contains the configuration for this nodejs module. Where is the entry point, and what other properties will be used in this module, such as scripts, versions, engines, etc.

 

 

The server.js file – is the entry point of our nodejs module.

From this file, we can create REST APIs that perform tasks in response to a request. Notice in our server.js file.. it redirects to the index.xsjs file… let’s examine what happens there… so let’s first build and then run our nodejs module

 

 

It was successfully built

 

 

Btw… while the nodejs module is starting.. we can go back to the cockpit and look in our development space.

 

 

After a few minutes… then the new service starts

 

 

We can also see the output in the webide console…

 

 

And then run the service to get the output from the xsjs service.

Woooooaaaaaahhhhh!!!

 

 

 

You may be wondering.. where is nodejs, where is xsjs.. what is all of the other code..

The best way to differentiate and know what code is being run, we can look into the file extensions..

xsjs – XSJS legacy XS services

js – this is the nodejs code.. you can also look into the different code function calls etc.

 

now that we have the example working, let’s add the UAA-service to make it more robust, also add the dbm module as a dependency to be able to call the db and extract data.

In your mta.yaml file, reopen the Requires section and add the following:

 

 

Now, in the app module… let’s add a reference to the nodejs module so that we can make calls from our UI app to the server side and even navigate from the browser (nodejs module). In the mta.yaml file, under the Requires section add the nodejs_api provider. * notice the provider and the resource types.

 

 

Then add the routes to the xs-app.json file.

Let me take a moment here and explain these routes…. As part of any SPA (client side) or even on the server side, there is route navigation… so we can easily get to our destination with a route. This is similar how REST APIs defines the entity we need to get to or a specific object within a collection, such as:

host:port/destination –> mainly seen on a SPA

host:port/destination/id –> seen at SPA to navigate to a specific object

 

host:port/entityCollection  –>mainly seen on REST APIs

host:port/entityCollection/objectId –> mainly seen on REST APIs

 

 

*if you copied the code from the great tutorial from SAP… make sure modify the name of your nodejs module, in my case it is called nodejs

 

Further, in the server.js file… (entry point to our back end service, comment out the anonymous authentication) so we can test out the integration with that service

 

 

Re-build and re-run your web app module since that will now be our entry point.

If you do what I did….

  • and ran the index.xsjs you will get unauthorized since we had modified the routes
  • and ran the web app module and nav to the nodejs/index.xsjs file path you will get 404 not found… since the path will not match…. Finally you will realize that the route does make sense –

 

 

 

Hopefully you get it to run… and share the same feeling as me

Then try your other routes such as:

 

 

 

Or your odata service, however, if you didn’t specify a key on your view you may see an error like:

 

so then, I specified a key and re-built the project

 

And now

fine then XSA… … let’s add the $format flag

 

 

And the entity collections

 

From here on wards it should be simple for anyone already knowing odata… but if you do not.. here are some good rules

 

My next finding was that this is still odata v2 (nodejs and javascript) and apparently Java is the only runtime that supports odata v4.. so I will investigate further.

https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.03/en-US/78606fc13a6b41e5b654ca5f289351ca.html

 

I went back to my hdbcds file… added the odata annotation, re-build the db module… re-run and looks like v2 still 😊 so let’s go build a Java module, why not.

 

by this point, I have created a new project, a ui5 module, a db module and a nodejs (xsjs compatibility mode) module. All the moving pieces feel like what’s happening on the east coast – jk – hope every one is doing ok in those areas.

 

Thank you again for reading this blog, please share your findings, experiences, and issues.

 

To report this post you need to login first.

3 Comments

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

  1. Annie Thornton

    Hi Sergio,

    These are interesting blogs and great to see your take on how your development experience went with SAP HANA, express edition SPS03.

    Aside from the ones you mentioned in this blog series when creating each of these modules, were there any other significant things you experienced during development that you think could have been a better user experience?

    Also, have you tried this on another environment besides a VM on your laptop, something like a cloud instance or container?

    Excited to hear back.

    Thanks,
    -Annie

    (1) 
    1. Sergio Guerrero Post author

      Hi Annie,

      thank you for the comment. I have not tried the cloud or container instances but I will probably do that next to see and compare myself other alternatives.

      As far as sgnificant changes are the tools primarily such as the mta graphical editor, the CDS graphical view… and the web Ide – this is in comparison with my experience on HANA 1 SP12. As far as UX improvements … I am not sure if this would count as an improvement but having the cockpit and cockpit manager seems somewhat confusing on the naming of 2 tools… I think this would have been ok to keep on the same tool with a different set of permissions or roles, just from my personal opinion. I’ll think of others and let you know once I do a few more examples.

       

      thank you again for your question and comment

       

      (1) 
      1. Annie Thornton

        Hi Sergio,

        Thanks for your feedback here about your own user experience with the new version, and your take on the Cockpit tools.

        Would be great to hear more about the other environments as well. Keep ’em coming…we’re here to listen! 🙂

        Cheers,

        Annie

        (1) 

Leave a Reply