Skip to Content
Author's profile photo Thomas Jung
Thomas Jung
May 9, 2016 Less than a 1 minute read

What’s New in SAP HANA Extended Application Services – SAP TechEd 2015 Lecture of the Week

With Support Package Stack 11 for the SAP HANA platform, some major additions to SAP HANA extended application services were delivered. For example on the JavaScript side, we switched to Google V8 and added full support for Node.js. We also added a standard Apache Java runtime (Tomcat and TomEE). We introduced the concept of HANA Deployment Infrastructure for container abstraction of Schema-based database objects.  We also introduced a whole new development environment in the form of the SAP Web IDE for SAP HANA. These are just some of the new features which we detail in this SAP TechEd 2015 lecture of the week.


If you find this topic interesting, you can continue your educational journey with some of these other materials which expand on this same topic:

ℹ Sign up to receive SAP TechEd event updates, special promotions, registration, session and speakers information

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Cameron HUNT
      Cameron HUNT
      Hello Thomas,
      1) you state in this video that ‘HANA Native Development’ is about “doing as much as you can inside of HANA”, and that “it’s no magical thing” to “build 80-90% of the application in the DB itself”. This being the case, I can only hope that SAP is planning — in a next-generation ERP — to move ALL standard ‘business logic’ (as well as Enhancement-hooks) to the DB-level (i.e. as procedures, triggers, etc) ? This would of course means that SAP could remove the business logic that is currently coded at application-level — across your entire, very-often-overlapping application suite — and to strip all of these apps back to little more than thin clients (without redundant business logic).
      2) In the context of XSA apps, you went on to say “we made sure that … all the interaction you do with the [app-] server is … [with] RESTful services”, and you also claim SAP is making a move towards Node.js, in part, owing to its asynchronous (/stateless) nature. But why are asynchronous/RESTful services only considered useful in the world of apps? Given the ever-growing need to support offline mobile devices, doesn’t SAP also need to provide a RESTful DB layer? This seems to require no more than the evolution of your current ILOData framework, with HANA acting as the only backend OData Server (rather than SAP Gateway, SAP PO, SAP Mobile Platform, etc), and all local devices -- fixed or mobile -- running the ILOData front-end on a local (distributed) Node.js Web-App server, whose job would be to cache in-memory (which is said to be the future for performance reasons) all data that would typically be required given the device user's Role (e.g. by Purchasing Group, Company Code/Financial Year). Why plan for a future where mobile devices will have no more memory and will be no more powerful than today's devices, when the opposite is clearly true ?
      3) Doesn’t this all point to a future world where APIs (DPIs?) are no more than exposed HDI Containers via which clients can perform reads and writes on the underlying physical DB — including standard SAP tables — via OData services, without the slightest regard for any application layer or business logic? Couldn’t Fiori Apps even be generated directly off these Containers (business logic being managed by the DB) ? 
      4) Likewise, will IoT devices need to be routed through application-layer-EXITs to enforce coded (application) business logic, or should they cut out the middle-man and head straight to the DB (where all business logic is best enforced to ensure a single-source-of-truth) via simple message-passing, in which case they wouldn't even have any need for the ILOData framework, as they would not be able to manage write/insert failures (but would still require a RESTful DB layer for asynchronous inserts) ?
      Regards,
      Cameron HUNT