Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
paschmann
Advisor
Advisor

Having been a long time follower and developer on the last 5 releases of HANA, I don’t believe I have ever been more excited to get my hands on a HANA release than SPS11. The inclusion of an entirely new XS runtime (XSA) and the ability to use Node.js and Java were just some of the features I was looking forward to. After figuring out that the SPS11 download was in the support/download portal on the 23rd November, I set out to get my machine up and running as quickly as I could …

After getting my SLES 11 SP4 machine installed/configured (I used the SAP SLES 11 SP4 Image from Suse), I downloaded the HANA SPS11 files, but after multiple failed attempts (even using the SAP Download Tool) the archives did not correctly uncompress and subsequently resulted in installation errors. After re-downloading the files no less than 5 times, I had a clean uncompress and the install was simple and straightforward, and worked like it should. I initially installed just a basic HANA instance, but struggled to subsequently install XSA. I ended up logging out of the root user account, logged in as my *adm account which seemed to get the install to successfully complete. While its been mentioned before, I will still reference the below statement from the documentation, since it will effect many admins wanting to install SPS11 on a SLES SP3 or lower:

In order to run revision 110 (or higher) of SAP HANA, an additional runtime environment for GCC 4.8 needs to be installed before running such a database revision. Please consult SAP note 2228351 for more details.

Once I had everything installed, I was a little lost as to where to get started with XSA, I sifted through the install logs and I deferred to the documentation included on XSA Development. I created a couple of basic test files and deployed them, but keep in mind that XSA does have quite a different development lifecycle compared to our existing XS projects (even though the code is reusable!). It does take a little getting used to, and I would suspect that Node.js developers would not have any little trouble wrapping their heads some of the SAP centric CLI tools or modules.

In order to get some more practical experience I went through the Shine XSA application/content which is included. (You can find it by executing "xs a" in your console and checking its URL.) It was a great reference and ultimately helped me get through the majority of my initial “Hello World” application I threw together. You can find the compressed files in XSA_CONTENT Folder of the install media. After getting the content in place and running, the first thing that hit me was how much I was using the command line, I was constantly using the XS CLI to deploy, push, restart, create-services and delete the things which I had not set up correctly. Something else which made things a little slow, was that as a “traditional” web developer, I am used to a more iterative approach to development, make minor changes, see how they look, rinse and repeat … but with XSA, changes are not displayed until they are deployed. (Due to the code base and the deployed code being separate by design).

A couple of things I appreciated: The new built-in UAA (Broker for Authentication and Authorization) is great, I was a big proponent (and still am) of using a Technical user with XS projects, this handles all setup/management of that user for you.  I can’t wait to integrate the build/deploy CLI with my DevOps tool (Bamboo) and automate all of these steps. The CLI tools are fast and easy to use, and show you what you need to know via the console, e.g: "xs a" = list of running applications.

Running "xs a" will display a list of running apps.


I decided I was going to build a small template, or boilerplate, which I could reuse as a starting point for any of my future applications, this has the majority of files needed to get started, and this project could be downloaded, pushed and within a few minutes get you up and running. Since it seems to be working quite well, I decided to put it on Github (here). Thanks to the Shine content, and Thomas Jung's content on Youtube (here) for being the original content I used as a reference.

I also listed the XS CLI commands here just as a quick lookup (versus having to find them in the documentation, or it is listed in the references?).

If you are going to roll up your sleeves and do some testing in this initial release, here are a couple things to keep in mind:

  • Folder structure is really important. There are multiple required files, dependent on which the of code you are writing!
  • Temp files can cause havoc. Some editors create ~ versions of the files and the deployment will try to process them!
  • If your deployments are failing use the "xs logs myapp-ui -recent" command to find the issue.
  • DB artifacts can still be check in HANA Studio or the Web IDE Catalog, the logs from the DB during creation will show the unique schema ID.

Overall I am impressed with what I have developed so far, even though this is the initial release of the product. I am curious to know how many of you have installed SPS11 and tested the new platform out?

15 Comments
Labels in this area