SAP HANA SPS 12: New Developer Features
Overview
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.
XS Advanced
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.
Node.js
Node.js support for the JavaScript runtime in XSA as a major new features as well in SPS 11. For the basics of what was introduced and supported as of SPS 11, please see this blog: SAP HANA SPS 11: New Developer Features; Node.js
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
•Calculation views
•Parameter EntitySets for calculation views
•Nullable properties
•Cache Control via cache header of $metadata requests
•Custom exits (JavaScript and SQL Script) for modification and validation 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.
Development Tools
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 here:
SAP HANA SPS 11: New Developer Features; 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.
Application Lifecycle
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.
Database Development
For all database level development topics, including SQLScript, HANA Deployment Infrastructure (HDI), and Core Data Services (CDS) for SAP HANA, my colleague Rich Heilman has written a separate blog. You can read about that content here:
SAP HANA SPS 12: New Developer Features; Database Development
Closing
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.
When?
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.
Recommend Usage
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.
Thanks for this Thomas.
Thank you Thomas - very informative as always
Thank you Thomas, a really nice and useful post.
thanks you Thomas, very useful
Thanks Thomas. Any news regarding the use of additional CloudFoundry buildpacks with XS Advanced? You made mention of this in one of your SPS11 articles late last year - thinking golang etc. here...
Technically using other buildbacks works already, but we didn't release this feature yet because of lack of documentation and example. Bring Your Own Language/Runtime via CloudFoundry buildpacks is a still a feature we plan to support in the near future once we've filled this mostly documentation gap.
Hi Thomas,
thank you for the very interesting post. However what I am missing is a post about how to develop and deploy java applications to XSA engine. I know node,js is the preferred way to develop xsa applications, but for more complex apps the java ee container is much more powerful than node.js plugins. Do you know posts or tutorials in how to develop java services in XSA? Of course, I saw the tutorial "Setting Up the Java Run-Time Environment in XS Advanced" in the xsa developers guide and yes my webapp containing a simple servlet is running. But authentication and authorisation is not working. I did all the steps described in the tutorial about these topics. But I get always "404 Unauthorized". I think the basic problem is that the request is not forwarded to the uua service login page. But how to configure this? I added my uaa service in the manifest,yml. I added XSUAA as login method in web.xml ... What's misssing? Any idea? It would also be very useful if there would be a complete java example somewhere.
I would be very glad for any help.
Christian
>However what I am missing is a post about how to develop and deploy java applications to XSA engine
Our focus is for Node.js development and therefore there is less documentation on Java. However part of the theory is that Java development is already well known and the XSA specific parts are only a very small percentage of the development process. There is Java on XSA development tutorial in the online help. That's the main resource we provide.
Tutorials: Setting Up the Java Run-Time Environment in XS Advanced - Introduction to Application Development and Deploym…
> I think the basic problem is that the request is not forwarded to the uua service login page.
Just like with Node.js applications, you should configure a Web/App Router service to run in front of your Java service. This is what does the redirect to the UAA.
As far as more Java examples, we are planning to add a Java service to SHINE for the next release. I can pass along your comment to the documentation colleagues that you would like to see more extensive Java example in the documentation.
Hi Thomas,
thank you very much for the helpful hint! I created an additional "starter" node.js service containing the welcome page and the approuter configuration. Then I configured a route to my java app as usual. And now it works! The login page appears and the login token is forwarded to the java app.
Christian
Very Informative - Thanks Thomas 🙂
Hello Thomas,
i just wanted to install the gerrit server. I downloaded the XS_GERRIT...SAR file from the download center. Is there any documentation how to install it? I tried with:
- "hdblcm"
- "xs install" (error: ERR java.lang.IllegalArgumentException: Not valid file)
and "xs deploy" (error: Cannot find archive entry "META-INF/mtad.yaml")
already, but without success!
The corresponding sap release note (2287418) doesn't provide any instructions how to install it.
Thanks for any advice!
Greetings
Johannes
GERRIT doesn't use the hdblcm installer nor is it XSA content (and therefore not installed via the xs command).
If you open that SAR file with sapcar, you will see that it has one real file in there named release.war. From that point you can follow the installation instructions on Gerrit's site:
Gerrit Code Review - Standalone Daemon Installation Guide
Just instead of gerrit.war in the documentation use the release.war from the SAR file you downloaded.
Ah ok, thanks for the help!
Hi Thomas,
We have a procedure in HANA Modeler (SP09) and an XS job that triggers Procedure on every Monday.
Currently we are manually checking the JOB_LOG table whether the job ran fine or not.
Need your help to check whether there is any Alert mechanism I.e. sending an email when the job fails.
Any setting in XS application or any procedure that checks the JOB_LOG table and send an email when it finds a failure status for the job.
Thank you in Advance.
I don't know of any such functionality. However if there were it might be in the admin/altering framework which is a topic I don't cover and therefore might not be aware of. You should really ask your question in the Q&A forum as its not really directly related to this blog.
Thank you Thomas.
I am unable to find any documentation related to SPS12 that provides example of creating remote source privileges within SAP HANA repository based roles. I tried using the Web Based IDE but it would not list the remote source under object privileges. The Web-based IDE will list virtual tables from remote sources but not the remote source node itself. SAP HANA Studio lists the remote source node and its privileges but I want to use repository roles not standard catalog based roles. Do you know if remote source privileges are supported within repository based roles?
Hi Thomas,
Looks like that the "support" for JS exit functions have some issues. Here my problem description:
https://answers.sap.com/questions/172495/java-script-exit-method-on-xsa-using-batch-request.html
Maybe you can help me... 🙂
Make sure you are using the latest version of the XSJS module available on your system. If problem continues, then please enter a support ticket.
Hi all, i cannot find any information in internet on this question:
How can we consume views, procedures and etc created using SAP WebIDE4HANA in ABAP systems without Eclipse ADT? I mean i know that we can register external view or call from AMDP using Eclipse, but if i remember correctly Thomas and Rich in open course told that SAP will move away all development from Eclipse to WebIDE, and SAP currently have WebIDE for SAPUI5 and for HANA, and MAYBE later SAP will merge those IDEs in one IDE. I haven't seen S/4HANA, but i know that it is fully web based, but ABAP is still at the backend with improvements in consideration of HANA. Maybe SAP will sometimes get rid of ABAP ?
>Thomas and Rich in open course told that SAP will move away all development from Eclipse to WebIDE
No we didn't say that. We said that HANA Studio was being replaced by the SAP Web IDE for SAP HANA. However ABAP Development tools are staying in Eclipse.
Thanks Thomas. I see there is no other way besides using Eclipse for that pusposes. I have computer with only 4gb or RAM and old hard drive at work, so it is uncomfortable to use Eclipse, because it eats a lot of RAM and becomes laggy.
Hi Thomas,
Trying to deploy Fiori application (xsodata based) from Webide to on prem Hana Sps12
Fiori template minimum UI5 runtime version requirement is 1.30 but my hana on prem ui5 runtime version is 1.28. Is there a way I can update my UI5 runtime version of Hana xs ?
Thanks,
Tanveer
If you switch to XS Advanced you can run more than one version of the SAPUI5 runtime and can update it to later versions. XS Classic doesn't have this capability.
Hi Thomas -
In XSC we can expose HANA calculation views as is from Hana repository using .xsodata service and can still use analytic privileges for data level security. I understand that XS classic style xsodata is compatible with node.js module in XSA. But, compared to XSC, how different it is to use a Hana repository calculation view into xsodata service in node.js using SAP webide for Hana (1.0 SPS12)? Is it the same or changes with XSA ? Are eclipse built Analytic privileges (SQL or DB procedure based) are still compatible with node.js - xsodata ? Trying to understand whether just mentioning the calculation view name in Service{ } in .xsodata file will do that job or will have to build artifacts in hdb module first and then use in xsodata ?
Thanks,
Tanveer
> I understand that XS classic style xsodata is compatible with node.js module in XSA.
Yes the XSODATA works exactly the same in XSA as XSC - syntax-wise.
Is it the same or changes with XSA ?
No it doesn't change.
Are eclipse built Analytic privileges (SQL or DB procedure based) are still compatible with node.js – xsodata ?
No repository privileges have to be migrated to HDI the same as all database artifacts.
Trying to understand whether just mentioning the calculation view name in Service{ } in .xsodata file will do that job or will have to build artifacts in hdb module first and then use in xsodata ?
You reference the name as before, but the calculation views do have to be migrated to HDI. Also the privileges might have to be adjusted to check for XS attributes in the session context now.
Hi Thomas,
Tried to search blogs/ KBAs/SAP references but did not find anything that shows steps to migrate calculation views to HDI on HANA 1.0 SPS12. All documents talk about XSA Migration assistant that comes with HANA 2.0.
Any hint on steps to migrate calculation views in HDI in Hana 1.0 SPS12 ? Is there any document available to refer to ?
Thank you !
Tanveer
That's true that the migration assistant was delivered with HANA 2.0. Although migration assistant only is a time saver/helper. It creates an SAP Web IDE for SAP HANA project from a DU. Anything it does could also be done by hand. And the HDI calculation view does lack a few features in HANA 1.0 SPS 12. However most Calculation Views can be migrated (unless they use one of a few of the missing features - such as hierarchies). Of course if this is a big concern for you on 1.0 SPS 12, why not just stay with XSODATA in XSC until you can update?
Well, It all started with XSC has limitation of UI5 runtime version till 1.28 no further. I am trying to build UI5 application using Fiori template that requires runtime version of at least 1.40 which brings me to XSA , node.js – XSODATA , calculation view migration and all that good stuff.
I doubt on its possibility but let me ask anyways – Is it possible to build UI5 Fiori applications with higher runtime version of XSA ans still stay with XSC for XSODATA until I can update ?
Thanks,
Tanveer
Yes UI5 from XSA can consume an XSC XSODATA. Two things to consider however. First: authentication. They won't be running from the same application server and won't share authentication. Two: CORS. The browser will see the call to the OData service as a foreign server and trigger CORS restrictions. You'll just have to use the XS Admin tool to configure CORS for that service.
Thank you Thomas ! This helps a lot.
Haven't got my hands onto HANA 2.0 yet..But wondering will this 'migration' approach change with introduction of Database explorer in HANA 2.0? if Yes, will it be wiser to go on HANA 2.0 rather than putting in effort to migrate views to HDI ?
Thank you Again !
Tanveer
I'm not sure I understand the question. You have to migrate to HDI to use the views in XSA regardless of if you on HANA 2.0 or 1.0. I'm also not sure what role Database Explorer has in your question. Database explorer is delivered with both the SAP Web IDE for SAP HANA and the HANA Cockpit 2.0. Both of these tools are backwards compatible with HANA 1.0 SPS 12. So you can use the latest version of the Database Explorer even without upgrading your HANA DB to 2.0.
Hi Thomas,
We are on Hana 1.0 SPS 12. Most of our tables are in XS Classic. Through synonyms we are consuming these tables in XSA. We have found that the XSODATA created in XS Classic is much faster when compared to the XSODATA created for the Calculation views using the synonyms in XSA. We tried using the settings for cache-control in XSODATA, but it doesn't seem to help. Is there any way that we can improve the performance of the XSODATA in XSA?
Regards,
Mahesh
You should enter a support ticket for this.
Hi Thomas,
We want to migrate an existing web application running in Tomcat from using SQL Server to using HANA as the database engine. As XSA Java support is based on an embedded Tomcat server, could we just deploy our existing war file (probably after some adaptations of SQL dialect)?
Regards
Frank
Yes you can do an xs push directly against a WAR file or specify the WAR file as the target in a manifest.yml or mta.yaml module definition.