SAP HANA 2.0 SPS 01: New Developer Features

Wednesday, April 12th SAP has begun to ship SAP HANA 2.0 SPS 01.  If you would like to learn more about all the new features in SAP HANA 2.0 broadly, you can refer to the following blog post:

https://blogs.saphana.com/2017/04/12/whats-new-sap-hana-2-0-sps-01/

In this blog, we would like to point out some of the highlights of the new features for developers who use the SAP HANA native application development capabilities. It should be noted that most of the major architectural changes in the development topic area were recently introduced in SAP HANA 1.0 SPS 11.  This is when we first shipped the SAP HANA extended application services, advanced model (XSA), SAP HANA deployment infrastructure (HDI), and the SAP Web IDE for SAP HANA.  If you are new to these topics in general, you might first want to review the what’s new details from SPS 11, SPS 12, HANA 2.0 SPS 0 and the openSAP course on this topic.

SAP HANA SPS 11: New Developer Features

SAP HANA SPS 12: New Developer Features

SAP HANA 2.0 SPS 0: New Developer Features

https://open.sap.com/courses/hana5/

We will also be hosting a webinar for the What’s New Developer topic:

We have also updated the exercises from the latest openSAP course to include a version that showcases how to build the same using HANA 2.0 SPS 01:

https://github.com/SAP/com.sap.openSAP.hana5.example/tree/hana2_sps01

Also the HANA Express version has now been updated to HANA 2.0 SPS 01 as well: https://blogs.sap.com/2017/04/20/sap-hana-express-edition-2.0-sps-01-now-available-to-download./

Database Development

In order to keep this blog from being too large, Rich Heilman posted about the database development features in a separate blog here: https://blogs.sap.com/2017/04/18/sap-hana-2.0-sps-01-new-developer-features-database-development/

SAP HANA Extended Application Services, Advanced Model

One of the biggest changes to the SAP HANA architecture was the introduction of XS advanced in SPS 11. SAP HANA extended application services in SPS 11 represents an evolution of the application server architecture building upon the previous strengths while expanding the technical scope. While I don’t want to repeat all the architectural features which came with XS advanced in SPS 11, you can review them in this blog: SAP HANA SPS 11: New Developer Features; XS Advanced

With HANA 2.0 SPS 01 we continue to round out the general feature set of XS Advanced; filling in one of the major remaining features from the XS Classic environment while also improving support for audit logging and multi-tenancy.

A few of the various new and enhanced features are:

Java Spring Boot Support

Spring is a popular open source application framework for Java. In particular it is focused on web applications in the Java EE space.  This addition ensures that Spring Boot is usable from both the Java runtime in XSA but also is added as an option in the Java module wizard in the SAP Web IDE for SAP HANA.

This addition broadens the offering of Java EE applications and makes it easier to port existing Spring based Java applications to XSA.

Parallel Deployment of Apps

As a performance feature we will now support parallel deployment of applications within the deploy service.

This will improve performance in situations which rely upon a large number of deployments: for example new system installation or system upgrade times.

Fiori Launchpad

One of the few remaining feature gaps to XS classic, was the absence of ability to easily create Fiori Launchpad applications in XSA.  With HANA 2.0 SPS 01, SAP fills this gaps with a full featured implementation of the Fiori Launchpad based in XSA’s micro-service approach and integrated with the SAP Web IDE for SAP HANA.  For more details on this XSA specific implementation of the Fiori Launchpad please refer to this separate blog post here: https://blogs.sap.com/2017/04/24/fiori-launchpad-in-sap-hana-2.0-sp01/

Instance Manager

Service instances, for example HDI containers, are statically bound to an application at deployment time. But multi-tenancy capable applications that leverage service instances for tenant separation (e.g. each tenant stores its data in a separate HDI container) need to create additional instances at runtime whenever a new tenant is added and they also need to connect to any one of these instances when processing a request for a specific tenant. To support this requirement, Application Managed Service Instances are made available by the new Instance Manager (Instance Broker) In HANA 2.0 SPS 01.

This is a key technology for building and delivering multi-tenant applications.  This functionality supports the automated on-boarding and upgrade capabilities required in a true multi-tenant environment.  This capability is delivered on premise in the XSA Runtime, but will also soon be available in the SAP Cloud Platform as well.

So normally you would create an HDI service instance and bind it your application with the following commands (or this happens automatically upon MTAR deployment/installation).

xs create-service hdi hdi-shared tenant-hdi-container
xs bind-service <app-name> tenant-hdi-container

This works perfectly fine when you have a static, single container instance, but if start to use HDI container instances as tenants then the application needs to be restaged and restarted for each new service instance binding.  This is prohibitively disruptive in a productive environment when you could be on-boarding new tenants at any time.  It also requires that the application user have SpaceDeveloepr authorization if your application does the dynamic on-borading at runtime.

But with HANA 2.0 SPS 01 we now have a special Instance Manager that can perform the provisioning and dynamic binding to your application for you.

Your application, at installation type, now creates a special type of HDI service called managed-hana and bind this centrally to your application.  This really gives you a connection to the Instance Manager instead.

xs create-service managed-hana hdi-shared tenant-hdi-container
xs bind-service <app-name> tenant-hdi-container

Your application now makes HTTP requests to the Instance Manager to create, delete, or get access to specific HDI container instances for a particular tenant.  The following is an example written in Node.js for creating a tenant instance named my-tenant, getting access to the instance, and then deleting it.

/*eslint no-console: 0, no-shadow: 0*/
"use strict";

var http = require("http");
var port = process.env.PORT || 3000;

http.createServer(function(req, res) {
	var xsenv = require("@sap/xsenv");
	var createInstanceManager = require("@sap/instance-manager").create;

	var options = xsenv.getServices({
		hana: {
			tag: "managed-hana"
		}
	});
	console.log(JSON.stringify(options.hana)        );
	createInstanceManager(options.hana, function(err, instanceManager) {
		if (err) {
			return console.log("Create instance manager error: ", err.message);
		}

		instanceManager.create("my-tenant", function(err, instance) {
			if (err) {
				return console.log("Create error: ", err.message);
			}

			// consume instance.credentials
			console.log(instance);

			instanceManager.get("my-tenant", function(err, instance) {
				if (err) {
					return console.log("Get error: ", err.message);
				}

				// same instance
				console.log(instance);

				instanceManager.delete("my-tenant", function(err) {
					if (err) {
						return console.log("Delete error: ", err.message);
					}

					console.log("Instance deleted");
				});
			});
		});
	});

	res.writeHead(200, {
		"Content-Type": "text/plain"
	});
	res.end("Instance Test\n");
}).listen(port);

console.log("Server listening on port %d", port);

Limitations:

Using Instance Manager also has some drawbacks:

-Apps have to trigger service instance creation on their own (there are APIs to assist)

-Managed service instances are not visible for the cloud/xsa controller yet for direct administration (but only the shared underlying service instance)

Audit Log

Central Audit logging for XSA was added in HANA 2.0 SPS 0 but the APIs for writing to the log were only available in Java modules. This addition extends the audit logging APIs to Node.js based modules as well.

Customers expect centralized audit logging capabilities for their applications and we can now provide this feature for both Java and Node.js based applications in XSA.

XSA provides both centralized Audit logging APIs but also central storage of the audit entries in the HANA database, an OData service for reading the Audit Log, and an interactive user interface for querying and displaying Audit Log entries.

The Audit Log is provided by an XSA service broker much like the UAA or HDI services.

xs create-service auditlog free <my-service-instance>

Then this audit log service instance needs to be added as a resource in your project’s mta.yaml file:

Finally the resource must be bound to your application (Java or Node.js) that wishes to write Audit Log entries:

For Java modules, you would use the following steps to use the Audit Log:

1. Include the Audit Log API in your Maven Project

   <dependency> <groupId>com.sap.xs.auditlog</groupId> 
     <artifactId>audit-java-client-api</artifactId> 
     <version>0.2.0</version> 
     <scope>provided</scope> 
   </dependency>
   

2. Declare the resource
   1. If you are using Tomcat as your runtime, add a new resource in META-INF/context.xml

      <?xml version='1.0' encoding='utf-8'?> 
      <Context> 
        <Resource name="audit" auth="Container" type="com.sap.xs.audit.api.AuditLogMessageFactory" factory="com.sap.xs.XSObjectFactory" singleton="true" /> 
      </Context>
      

   2. If you are using TomEE, then add a new resource in WEB-INF/resources.xml

      <?xml version='1.0' encoding='utf-8'?> 
      <resources> 
        <Resource id="audit" type="com.sap.xs.audit.api.AuditLogMessageFactory" provider="xs.openejb:XS Audit Log Message Factory Provider"/> 
      </resources>
      

3. Access the AuditLogMessageFactory. This could be done in one of two ways:
   1. Via JNDI lookup

      Context ctx = new InitialContext(); 
      AuditLogMessageFactory auditlogMesageFactory = (AuditLogMessageFactory); ctx.lookup("java:comp/env/audit");

   2. Via Resource Injection

      @Resource(name="audit") private AuditLogMessageFactory mesageFactoryInj;

4. Finally, the Java coding itself

   ConfigurationChangeAuditMessage message = mesageFactory.createConfigurationChangeAuditMessage();
   message.setUser("<user>"); 
   message.setObjectId("logger.com.sap.xs.test"); 
   message.addValue("severity", "error", "warn"); 
   message.logSuccess(); 

Or for Node.js this example shows loading the Audit Log instance resource via the @sap/xsenv module and then using the APIs to write a log entry from within an Express handler.

/*eslint no-console: 0, no-unused-vars: 0, no-shadow: 0, quotes: 0, no-use-before-define: 0, new-cap:0 */
"use strict";
var express = require("express");

module.exports = function() {
	var app = express.Router();

	var xsenv = require("@sap/xsenv");
	xsenv.loadEnv();
	var credentials = xsenv.getServices({
		auditlog: 'openSAP5-ex-log'
	}).auditlog;
	var auditLog = require('@sap/audit-logging')(credentials);

	//Simple AuditLog Example
	app.get("/example1", function(req, res) {
		var ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress;
		if (req.headers['x-forwarded-for']) {
			ip = req.headers['x-forwarded-for'].split(",")[0];
		} else if (req.connection && req.connection.remoteAddress) {
			ip = req.connection.remoteAddress;
		} else {
			ip = req.ip;
		}
		auditLog.securityMessage('%d unsuccessful login attempts', 3).by(req.user.id).externalIP(ip).log(function(err, id) {
			// Place all of the remaining logic here
			if (err) {
				res.type("text/plain").status(500).send("ERROR: " + err.toString());
				return;
			}
			res.type("application/json").status(200).send(JSON.stringify('Log Entry Saved as: ' + id));
		});
	});

	return app;
};

Finally there is the central Audit Log UI provided by the XSA runtime itself that can be used to search and display the entries:

Scoped NPM Packages

Before HANA 2.0 SPS 01, the SAP provided Node.js modules were simply separated out by the fact that their names generally began with the text “SAP”.  This could potentially cause conflicts with customer or other public NPM modules.  This will especially become a problem once SAP launches the planned public NPM repository for SAP modules. Scoping provides a safe, enforceable namespace for NPM modules/packages.

The use of scoped packages better identifies SAP provided Node.js modules but most importantly allows for the integration of SAP modules with customer or open source specific modules. It is a key feature necessarily for the launch of the SAP owned public NPM repository.

With HANA 2.0 SPS 01, customers should switch all the references in their package.json files in their projects to the new scoped module names. Only the scoped modules will continue to be updated.

Development Tools

SAP Web IDE for SAP HANA provides a comprehensive web-based end-to-end development experience for creating SAP HANA native applications:

• Development of SAP HANA content and models
• UI development with SAPUI5
• Node.js or XSJS business code
• Git integration

Therefore it provides a complete workflow for all of your new HANA Deployment Infrastructure (HDI) and XS advanced model (XSA) based development.

SAP Web IDE for SAP HANA comprises capabilities of SAP HANA Studio and SAP HANA Web-based Development Workbench. It represents the long term replacement tool for both of these previous offerings. It consolidates technologies, follows industry trends, and leverages industry standards where possible, while retaining a competitive innovation focus of SAP’s current offering.

With SAP HANA 2.0 SPS 1, we continue to enhance and expand the capabilities of the SAP Web IDE for SAP HANA and close the few remain feature gaps compared to the old HANA studio.

Backwards Compatibility

Previously the version of the SAP Web IDE for SAP HANA had to match exactly the version of the underlying HANA database. With the HANA 2.0 SPS 01 version of SAP Web IDE for SAP HANA, we introduce the ability to target older releases of HANA for HDB modules. Upon module creation, the developer choose the lowest HANA release they want to target. Then all source code editors adjust their syntax checks and other features to enforce the development at the target older release.

This means that customers running HANA databases at 1.0 SPS 12, can now upgrade both their XSA Runtime and the SAP Web IDE for SAP HANA to HANA 2.0 SPS 01 (and later) versions and gain new features that previously were only available with a full HANA DB upgrade.

Fiori Template Enhancements

We’ve enhanced the Data Connection step of the Master/Detail  modules.  In SPS 01, it now allow you to connect to OData services in the current project and allows you to see all endpoints in multiple modules of your project.

mta.yaml Editor

The mta.yaml file is the core project configuration file in the SAP Web IDE for SAP HANA.  Although it is based upon the open standard of YAML; we’ve received feedback from customers that both the YAML specification and the technical complexity of the mta file are difficult to understand and edit. This leads to a higher learning curve and more development errors. With SPS 01 we introduce a new form based editor in addition to the existing source code based editor for the mta.yaml file.

This new error reduces the overwhelming initial complexity of project creation and maintenance experience in SAP Web IDE for SAP HANA.  It structures the flow that developers need to follow and enforces checks upon the values they provide. It also provides better overall navigation than a traditional source code based editor can provide.  Overall this new editor should work to greatly reduce the barier to entry that many developers face when first working with the SAP Web IDE for SAP HANA.

Application Lifecycle Management

Product installation for XSA in SAP HANA 2.0 SPS 0 and lower is only possible via the XS command line tool. With HANA 2.0 SPS 01 we introduce a web-based user interface alternative for installing XSA products and customer owned application MTA archives.

This new UI offers more options for installation tooling as well as better administrative user experience. This also better unifies the administrative and devops user experience around web-based tooling.

Closing

With SAP HANA 1.0 SPS 11, SAP introduced a considerable change in the architecture of application development. Much of the development for the past few years has been focused on just delivering the first version of that new architecture and then only closing gaps between the old and new architecture.  With SAP HANA 2.0 SPS 1, you are beginning to see that we can finally innovate based upon this new architecture.  The general improvements combined with tools and programming model changes you see here are laying the foundation to allow you to build new kinds of applications easier and faster than you ever have before.