SAP HANA SPS 12 was released last week and of course we have improvements and additions targeted for developers in this new release. With SPS 11 we saw major architectural changes and additions with the introduction of XS advanced and HANA Deployment Infrastructure (HDI). Naturally the first release after such a major change primarily involves left over minor features, infrastructure improvements and other incremental changes. That is certainly the case with SPS 12 when it comes to developer features; although as SPS 11 as so major and still quite new to people we will review some of those major changes here as well.
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
Most of the additions to XS advanced architecture in SPS 12 are infrastructure related and designed to increase scale and performance options. Most notable among these features is the new concept of partial runtime download. Previously, a buildpack’s only option to create a droplet for an application was downloading the appropriate runtime (for example a Node.js runtime for node apps or jvm/tomcat for Java apps), materializing all files into the file system and sending the whole droplet back to the XSA Controller. As runtimes might be fairly large in size and consist of thousands of files, this requires a lot of file system and network operations and slows down the staging process significantly.
As an optimization of the classic runtime download, the XS Controller in SPS 12 provides an enhanced runtime download interface for buildpacks: It enables buildpacks to download only those files to be analyzed or modified by the buildpack and omit the rest of the files. The omitted files will be added by the XS controller in a low cost operation (no file system and network access) after the buildpack has finished and merged with the files added / modified by the buildpack. This speeds up the staging process significantly.
Already in SPS 11 the Node.js runtime of XSA contained an implementation of XSOdata to allow for easy migration of existing services in XS Classic as well as reuse of the existing developers knowledge of how to create OData services. In SPS 11 we supported these major features of OData in the XSOdata runtime of XSA:
• Service Document = scheme serviceRoot
• EntitySet = scheme serviceRoot “/” entitySet
• Entity = scheme serviceRoot “/” entitySet “(” keyPredicate “)”
• Navigation = scheme serviceRoot “/” entitySet “(” keyPredicate “)/” entityNavProperty
• Metadata = scheme serviceRoot “/” $metadata
• Batch handling = scheme serviceRoot “/” $batch
• System Query Options: $top, $skip, $select, $expand, $filter,$orderby,$inlinecount,$format
• CUD Entity
• Definition of OData schema namespace
• Exposure of HANA tables and views as EntitySet
• Create/update/delete restrictions on EntitySet level
• Property Projection: Expose a subset of the table columns as properties of an OData EntityType
• Automatic OData key generation, e.g. required for aggregated views
• Simple and complex associations
• Data aggregation
• Calculation views
• Parameter EntitySets for calculation views
• Nullable properties
• Cache Control via cache header of $metadata requests
(Only Entity requests)
• Custom exits in batch requests (Only entity request)
This was a considerable list of features but did not yet match 100% of the features of XSOdata in XS Classic. With SPS 12 we continue to close the feature gaps by introducing these additional OData features into the Node.js based version of XSOdata:
• $links requests, e.g. EntitySet/$links/NavigationProperty
• $links requests inside batch requests
• $links modification requests with custom exits (also as part of batch requests)
• ETAG handling for conditional requests to support caching and optimistic concurrency control
Beyond SPS 12, we still have just a few features still to cover. We have the following planned features for the future:
• Finalize feature parity to XS Classic, e.g. SAP annotations in metadata
• Additional authorization checks via scopes on Service level and EntitySet level
• We soon switch XSOData V2.0 into maintenance mode as we will have a strong focus on OData V4 development (OASIS OData standard)
• No new major features planned to be provided with V2.0 and only very limited/important further features, based on customer requirements, will be implemented.
In the Node.js modules delivered by SAP we also see several new features. For example the XSJS compatibility module now supports $.utils.createUuid(), $.utils.stringify(arrayBuffer) and all the functions under $.util.codec.*. We also see that the sap-hdb-connect module has been deprecated in favor of the largely very similar Node.js module sap-hdbext.
The final piece of the new developer experience in SAP HANA SPS 11 shipped in late March 2016. The SAP Web IDE for SAP HANA was made available for download from the Service Marketplace and installation onto HANA SPS 11 systems. 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
However as the SAP Web IDE for SAP HANA shipped later than the initial release of SPS 11, for many people SPS 12 will represent their first exposure to the new developer tooling. Therefore you might want to first review the launch materials which were created for the SAP Web IDE for SAP HANA.
Although the delivery of the first version of the SAP Web IDE for SAP HANA was just two months ago, we will still find some nice usability improvements in the SPS 12 version. First the HANA Runtime Tools (HRTT) visual design has been adjusted to adopt the Web IDE design. This is the first step toward the planned deeper integration between HRTT and SAP Web IDE for SAP HANA which we are working towards.
The HRTT has also been enhanced to be both multi-space and multi-org aware. This allows you to connect to any container in a HANA system.
One of the major feedback items we’ve had from early adopters of the XSA-based development is that working with the log files can be overwhelming. This is a point we will continue to work on inthe future, but for SPS 12 we’ve made a first important improvement. The logs for a running service now stream as a live view in the SAP Web IDE for SAP HANA. No longer do you have to open a separate browser window to view the logs and then continually refresh that window. Updates to the log are pushed into the run console as you test your application.
Another pain point we tried to address in SPS 12 was around the editing of the mta.yaml file. YAML has a rather strict syntax when it comes to indentation and also doesn’t allow the usage of tabs. In SPS 11, any technical problems with the mta.yaml file wouldn’t produce an error until build/run time and often resulted in a crashed service. With SPS 12 we introduce a client side validator to the mta.yaml editor, so that most technical errors are displayed immediately. This way you can avoid costly failed builds/runs and more easily find and correct such errors.
The Application Lifecycle story for XSA based development in SPS 11 was largely a manual process using command line tools to deploy MTAR archives. At most we did deliver basic Git integration with the SAP Web IDE for SAP HANA. For SPS 12 we expand this area while still sticking close to standard Git. First we deliver an installation of Git for those customers that which to receive a complete installation from SAP. In addition we also deliver two additional pieces – a Gerrit server and a Git Service Broker.
The Git server installation we deliver is based upon JGit. Alongside this Git server we also deliver Gerrit – and open source project led by Google which provide a code review workflow. To tie these open source pieces together with XSA development overall, we also deliver a Git service broker. This service broker integrates Git/Gerrit with XSA. It allows for access control and OAuth authentication for Git/Gerrit using the XSA UAA service. It also enables XSA services and applications to bind to the Git service; allowing dynamic create/delete of repositories and ability to bind to a repository.
Beyond SPS 12 we plan to continue to build out this Git/Gerrit integration further. We want to provide a REST API for runtime authoring of development objects. We also plan to introduce a special Developer OAuth Scope to further control developer level access. We also plan to support OAuth authentication of the Git service broker against multiple HANA systems. We want to introduce versioning support for large binary files via the Large File Extension of Git (git-lfs). Finally we plan to integrate the Gerrit code review workflow into the SAP Web IDE for SAP HANA as well as extend the Git Service Broker OAuth Single Sign On into the SAP Web IDE for SAP HANA.
For all database level development topics, including SQLScript, HANA Deployment Infrastructure (HDI), and Core Data Services (CDS) for SAP HANA.
In this section we would like to summarize the availability of many of these features and some things to consider when first starting development with these new capabilities. Some of these recommendations have changed from what we originally suggested with SPS 11.
First when will everyone receive the functionality described in this blog series. The new XS Advanced runtimes – Java and Node.js based – and infrastructure is all delivered generally available in SAP HANA SPS 11. Also the HANA Deployment Infrastructure (HDI) and the new database development artifacts delivered with it are also generally available. As you see in this blog we continue to enhance these new features in SPS 12 and beyond.
SAP HANA SPS 11 is delivered for on premise systems already (as of the end of November 2015). Similar capabilities are planned to come as a part of SAP HANA Cloud Platform at some later date.
The original XS runtime (now named XS Classic) and HANA Repository remain a part of SAP HANA SPS11 and beyond to provide 100% backwards compatibility. This continues to be true in SPS 12. Therefore customers can upgrade with confidence to SPS 11 or SPS 12 without fear that the new innovations will somehow disrupt their existing applications. Customers can decide how and when they want to begin to move applications to the capabilities and only do so once they are comfortable with everything involved. In the mean time everything they have continues to run exactly as it does today.
The new runtimes and HDI will NOT be feature compatible with the old XS and repository runtime at the first release of SPS 11 or even SPS 12. There are missing features particularly in the area of Calculation Views as well a few lesser used aspects of XSODATA. SAP fully intends to fill these gaps in future Revisions and/or Support Package Stacks. Already with SPS 12 we have closed a great many of these gaps, but we still haven’t yet achieved 100% feature compatibility with XS Classic or the old Repository based development objects.
The development tools for the new runtimes and infrastructure (SAP Web IDE for SAP HANA and HANA Runtime Tools) where shipped for SPS 11 in March 2016 via the Service Marketplace and could be added to an existing SPS 11 system. With SPS 12 these new tools ship in standard and can be installed into system via the hdblcm tool during system installation or upgrade.
Migration tools are planned to be delivered after the initial shipment of SPS 12 to help move your applications from XS Classic and the HANA Repository to XS Advanced and HDI.
SAP recommends that customers and partners begin to evaluate the new capabilities delivered with SPS 11.
SAP recommends that customers and partners who want to develop new applications use SAP HANA XS advanced model as of SPS 12.
The planned scope of available technologies for development with XS Advanced as of the initial delivery of SPS 11 is as follows:
– Core Data Services (the new HDBCDS artifact)
– SQLScript procedures and UDFs
– DDL for the development of database artifacts using text-based editors. See help for full list of supported database artifacts.
– XSJS via the compatibility module of Node.js
– XSODATA via the compatibility module of Node.js or the new implementation in Java
– Node.js based development
– SAPUI5 for application development (using 3rd party text based editors)
If you want to migrate existing XS classic applications to run in the new XS advanced run-time environment, SAP recommends that you first check the features available with the installed version of XS advanced; if the XS advanced features match the requirements of the XS classic application you want to migrate, then you can start the migration process.