Screen Shot 2015-12-09 at 9.12.45 PM.png

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.

Screen Shot 2015-12-09 at 9.26.29 PM.png

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?

To report this post you need to login first.

15 Comments

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

  1. Thomas Jung

    >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

    I too had the same impression at first.  A little tip that many of us working on XSA have been doing: we use a local installation of pure node.js on our laptops.

    https://nodejs.org/dist/v0.12.7/

    You do your iterative development testing there. You can deploy the same SAP specific node modules locally. You can even access a HANA backend remotely with many of them. You won’t obviously have an HDI service broker or the uaa; but you can substitute connection parameters via a  default-services.json file in the same directory as the node.js services themselves (not the root).

    {

           “hana”: {

            “host”            : “<HANA DB HOST>”,

            “port”            : “3<HANA Instance Number>15”,

            “user”            : “<DB USER>”,

            “password”        : “<PASSWORD>”,

            “schema”          : “<DEFAULT SCHEMA>”

        }

    }

    It works pretty nice for getting 90%+ of the logic and design built locally. You can then deploy to the server and test with the real security and connectivity.

    (0) 
    1. Paul Aschmann Post author

      Thanks for the feedback and yes, great idea. I think this is one real benefit over using traditional XS, since each developer can develop locally and consolidate to their central source.

      I noticed in the Install Media that there are XS Client CLI’s available for each OS (Windows, Linux and Mac) – and doing some digging it seems like the XS CLI does run on OSX. I sifted through the documentation but didn’t find any details for installing/running it this way … is this a “coming soon” feature?

      (0) 
      1. Thomas Jung

        Not coming soon as its on the installation media. I’m actually writing a blog on this right now.  A kind of what you need to get started where I’m collecting such tips and tricks. The XS Client on your local machine means you don’t need telnet access to the HANA host machine (which I’d imagine most developers won’t get anyway). It also makes it easier/faster to develop locally and then deploy using the local client. No need to copy/ftp files over to the HANA host machine.

        (0) 
  2. John Astill

    I am running on SLES12 and the upgrade from SPS10 to SPS11 had a little quirk but there is a note available:


    “The libopenssl version 0.9.8 is required for SAP HANA. If the libopenssl version on your linux server is newer than 0.9.8, you need to downgrade it.”.

    https://websmp230.sap-ag.de/sap/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361706E6F7465735F6E756D6265723D3232343039363126

    Another gotcha for me, I should have paid more attention during the SLES12 install, was that it only allocated 40GB of 1TB for / by default. Snapper quickly consumed this space. Removing the snapshots and then adding another volume to / (I have started to like btrfs) and it was good to go again.

    Thanks for the recap for your journey, I will put it to good use.

    (0) 
    1. Paul Aschmann Post author

      Thanks for sharing and also good to know about the libopenssl library needing to be upgraded. Did you use the SAP version of SLES12?

      Re: Disk space, thats also caught me off a couple of times 🙂

      (0) 
  3. Martin Chambers

    Normally, each HANA SPS contains new functionality. Now, as I understand it, new functions will be delivered with different revsions within SPS11!? This goes in particular for XS Advanced. Is there any indication when for example the new web IDE will be available?

    We are considering an upgrade for our development system end of January. Does this make sense, so that the developers can play around, or is it too risky.

    What do you think?

    Cheers,

    Martin

    (0) 
    1. Thomas Jung

      >Normally, each HANA SPS contains new functionality. Now, as I understand it, new functions will be delivered with different revsions within SPS11!?

      Nothing has really changed here. HANA itself primarily receives new functionality in new SPSs. The difference here is that SAP Web IDE was being considered an application that runs on HANA and not a part of HANA itself. Separate applications can their own delivery timelines. The decoupling of XS Advanced itself would also make such individual delivery possible, although in near future at least we still plan to delivery its updates within the HANA delivery rules.

      >Is there any indication when for example the new web IDE will be available?

      We originally thought we would deliver the new Web IDE as its own application alongside one of the first revisions to SPS 11 in early 2016. However it does now look like work might be delayed enough that we will instead hold out until the SPS 12 delivery.

      >We are considering an upgrade for our development system end of January. Does this make sense, so that the developers can play around, or is it too risky.

      There is very little risk to the upgrade. The current Repository and XS runtime remain in place and none of your existing content is migrated automatically. XS Advanced itself is an optional, additional installation step.

      (0) 
      1. Martin Chambers

        Thanks Thomas,

        That was very helpful.

        I’ll pass on your information to our developers and see how this influences their opinion. Usually, they want anything new to be installed yesterday.

        Merry Christmas,

        Martin

        (0) 
  4. Stefan Ressing

    Hi Paul,

    what is your hardware and memory you use for the SPS 11.

    I use SLES 12 and I see a lot of threads busy with the new statistics server updates.

    Anyone seen threads stuck like this?

    /wp-content/uploads/2016/01/2016_01_06_18_04_56_863123.jpg

    Thanks

    Stefan

    (0) 
  5. Frank Schuler

    Hello Paul,

    where did your XSA installation fail? I am asking, because I can install the HANA XS Advanced Runtime no problem, but the installation of the XS Advanced Components fails while trying to bind application “jobscheduler-db” to service “jobscheduler-db-container”.

    I also retried the installation as user SIDadm, but unfortunately with the same result.

    Is that the same issue you had?

    Best regards

    Frank

    (0) 

Leave a Reply