This blog is part of the larger series on all new developer features in SAP HANA SPS 11: SAP HANA SPS 11: New Developer Features

With the introduction of XS Advanced and HDI within SAP HANA SPS 11, developers are faced with many new tools and options to work with. There is so much new content, that it might very well feel overwhelming at first.  In this blog I’d like to present some tips and tricks for getting started. I’ll share links and suggestions for some tools that will as well as describe some things we’ve learned internally having built applications in this new environment over the last few months.

Gathering Tools Before You Begin

For the purposes of this blog, I’m going to assume you already have access to an SAP HANA SPS 11 system with XSA installed and configured. You can always refer to the official help documentation for installation, configuration and even the developer guide: SAP HANA Platform (Core) – SAP Help Portal Page

What I want to talk about here is what you as a developer will need to setup on your local machine in order to get started doing XS Advanced and HDI based development as of the initial shipment of SPS 11. To start off you are going to want to get some code development tools.  The initial release of SPS 11 includes the runtimes and command line tools but not actual development editors for XSA/HDI based development.  SAP did release the SAP Web IDE for SAP HANA in March, 2016.  If you want to learn more about the SAP Web IDE for SAP HANA please see this blog: SAP HANA SPS 11: New Developer Features; SAP Web IDE for SAP HANA.  But before you have the SAP Web IDE for HANA, customers and partners will need to use 3rd party editors/tools in combination with the command line interface for deploying their code as described in the remainder of this blog.

Of course any basic text editor will work. I’d imagine that most developers want something slightly more sophisticated than notepad, however. You want a tool with at least basic code collapse and syntax highlighting for a variety of the development artifacts we work with. That means at least JavaScript, JSON, XML, and HTML editing support would be nice. Its even better if the tool supports some SQL/DDL syntax features as they can be applied to Stored Procedures and other DDL based catalog artifacts. Inside SAP we tend to use one of the following three tools:

• WebStorm: The Smartest JavaScript IDE
• Sublime Text: The text editor you’ll fall in love with
• https://code.visualstudio.com/

So here are my personal experiences and opinions about these three choices.  All three are cross-platform; even surprisingly the Microsoft Visual Studio Code option. I was shocked the first time I saw a developer with a Mac using the Microsoft Visual Studio Code tool. It was like watching a Jackalope riding a Unicorn. All three tools support not just basic JavaScript but also Node.js to some extent. Here is what stood out about each tool.

WebStorm – One word: debugging! I think this is what first draws most people to WebStorm is the integrated Node.js debugging experience. It also has built-in integration to Git and other external source control repositories. It all sounded good, so this was the first tool I tried out when I started XSA development. Then I quickly hit the downside; cost. Its commercial software. Ironic since I work for a commercial software company and the price of the tool isn’t exactly bank breaking. However if you are like me and work at a large corporation you know it isn’t often easy to purchase software that isn’t already in the “approved” catalog. There is a nice 30 day trial mode, but I rather quickly put this tool aside knowing that it wouldn’t be fun going through the approval process to get a license.

Microsoft Visual Studio Code – This was the wild card in the pack. I went in with the same assumptions about a Microsoft tool that I think most people have. I expected a .Net centric experience that only payed lip service to Node.js. I was very pleasantly surprised to find something completely different. Its a very rich environment with support for a variety of languages, node.js debugging, and Git integration. It even does a pretty good job with HANA database artifacts when you manually configure them to use SQL for the editor.

The downside: technically its still pre-release, beta software. It still has a few rough edges, but its is quickly winning me over. Here are a few links to using this tool for Node.js development and debugging.

https://code.visualstudio.com/Docs/runtimes/nodejs

https://code.visualstudio.com/docs/editor/debugging

Sublime – This is the tool that currently dominates by personal usage. I’ve got all my laptop defaults set to open this editor for nearly all file types. It does a great job of one thing – speedy editing of source code.  Therefore it forgoes some of the source control and debugging experiences of other tools. It also isn’t a free tool. It requires a purchase, but only reminds you to purchase every 50 saves.

Git/GitHub

With SPS 11 and XSA/HDI based development we no longer use the built-in HANA Repository. Instead all source code versioning and management is done externally in Git/GitHub.  We don’t initially ship a copy of GitHub, so your company will either have to setup its own copy or use an existing one. Everything is designed to depend upon standard GitHub, so there is no reason not to share an existing installation.

I usually start my development process from GitHub Enterprise in the web-based interface. For new development I create a new repository here first and initialize the readme and gitinore for node.js. I find the gitignore for node.js is important as this keeps your node_modules folders from uploading to the GitHub repository and keeps your actual project size smaller and more manageable.

Assuming that you aren’t using an editor/IDE that has Git integration built in, you will then need some standalone Git tools at this point.  Personally I use GitHub for Windows. Its a nice tool that makes cloning and committing with GitHub Enterprise very simple. I also like the fact that it lets me manage my SAP internal GitHub Enterprise repositories and my public GitHub.com ones within one tool.

Testing Locally

I’ve now got my project/repository and an editor to work with it. I’m ready to write code. However I like to test my code as I go. I could deploy all my development onto the HANA XSA server and test after each little change, but that’s a bit time consuming for each change. If you are like me, I have 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. Just be sure to match the same node.js version you run locally with the build pack version on XSA.  The main download page of nodejs.org has the newest builds which came out too late in our development cycle to include with the initial SPS 11 version. Therefore you’ll have to dip back into the nodejs.org download archive and grab a 0.12.x version:

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

You then do your iterative development testing locally. 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 project 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.

Deploying to XSA on the HANA Server

We will use the XSA Command Line tool for most of the interaction with the server. We can use this tool to deploy and manage applications, services, products, etc. However I’d imagine that most developers probably won’t get OS level access to the HANA host machine in order to run this command line tool. This is why we also deliver an XSA client for a variety of operating systems.

You will find the client installers the HANA SPS 11 installation media:

You can then run this XSA Client from the command line of your local desktop/laptop and remotely connect to HANA XSA servers.  This removes the need for OS level access but also means you don’t have to transfer your development artifact files to the file system of the HANA server before deploy.  You can use the client to deploy code from your local development machine. The client even differences the files and only sends changed files upon delta deploys.

While we are looking at the installation media, inside the XS Client folder you will also find a very important file named xs_javacript*. Since the SAP specific node modules aren’t available in a public NPM repository; this zip file is the only way they are currently delivered. You will need to download and manually place these modules into your node_modules folder of your project as npm will not be able to install them automatically.

Admin and Security Tools

After deploying your application, you are going to need some tools to administer and setup the security for them.  First and foremost is the same XS Client tool that you used to perform the deploy.  Running xs apps, will list all applications and most importantly the ports they are running on.  When testing I find myself running xs apps often to remember what port everything is running on.

Next up is the XSA Admin web tools. Using the xs apps command from the previous step, find the the port/url for the xs-admin service.  Running this from a browser should provide you with a launch pad of various XSA administrative tools. The Application Role Builder is probably the tool that will be of most interest to developers.

It is with this tool that you can take the role templates and scopes you defined in your xs-security.json file in your project and configured them into role collections.

The final tool is one that you are already familiar with – the SAP Web-based Development Workbench – Security. If you are using HANA database users as your user store for XSA applications, the existing security tool has been extended to allow the assignment of XSA Role Collections to the user accounts.

Closing

Are there other getting started tips and tricks that you’ve discovered for SPS 11 XSA/HDI development? If so feel free to shared in the comments of this blog.