Skip to Content

Liberating HANA – How River will democratize SAP’s In-Memory technology

At the recent Influencer event in Boston that took place as part of SAP’s Run Better Tour, the main focus was on HANA and the announcement of the release dates of applications enhanced with this new In-Memory technology. Exciting stuff and you could almost feel the physical sensation of the increasing tempo of SAP’s releases in this area. The majority of the attention was placed on the use of this technology in the OnPremise product line. There was some notice paid to the planned use of this technology in the Core OnDemand products (for example, BusinessByDesign 3.0). During his Keynote to Influencers, Vishal Sikka mentioned in passing the fact that this technology will be used in SAP “Project River” – how does it compare to xyz?(Basic Edge) at some point.  No one really noticed his comment and my tweet regarding this change attracted little notice.   At the time, I realized the implicit importance of this revelation but I didn’t really know why. I mentioned this fact in my interview with Dennis Howlett and Jon Reed  but I was a little vague on why it was so important. 
I’ve now had some time to think about this revelation. This blog contains my thoughts on this topic.

Note: Besides the fact that I’m a alpha user of River and have seen the various slides about In-Memory technology in Boston, I don’t have any further details about the future planned architecture or details about the use of this new In-Memory technology in River.

I already Aggregation Patterns in OnDemand Edge Platforms: River vs. StreamWorkabout the difference between the consumption patterns of River and StreamWork . This blog continues along these lines of analysis.

Thanks also to Dennis Howlett who showed me a sketch of a River architecture including In-Memory technology during our session with Sam Yen in Boston.  This blog is an elaboration of his sketch.


For the developer using River, the data layer that is the foundation of applications is hidden. Via the WYSIWYG User Interface of River, the developer creates forms / views and the underlying data structure / queries are created automatically via a Data Services layer.  You need not know whether the database is based on Oracle, MySQL or DB2.  This is dealt with in River’s Collection / Record implementation.

River – remember, raising the level of abstraction – has made a lot of the choices for you. You don’t program against a database abstraction API, you just define what you want to persist. River will take care of it. In the last two years we have actually replaced the database technology three times (with the next change already happening), without any impact to the applications.  [SAP “Project River” – how does it compare to xyz?]

My assumption is that the underlying database will be replaced by the In-Memory technology.

What are the implications of this change?

In-Memory Technology for the Masses

If you look at the usage patterns for In-Memory technology in SAP’s products, you see that the usage is largely restricted to existing product lines.  Of course, you have a distinction between applications (as evidenced by the announcement in Boston), OnPremise products (such as BW) and OnDemand products (such as BusinessByDesign). All these environments, however, have a business focus and are restricted by the character of the platforms themselves.  These restrictions (technical, legal – ie, licensing- , etc) limit the number of individuals who can use this technology.   For example, access to BusinessByDesign as a development platform isn’t open to all – yes, the hurdle may be lower than in other SAP product lines but it still exists. Furthermore, the presence of an SAP AppStore should include certain quality gates (although I have no idea what they may be) that should also restrict the type of applications available.

The use of In-Memory technology in River as a PAAS, however, should allow this technology to be available to the ‘Masses’ . On River, I could develop a game or a shopping application or an application dealing with social networks – I can focus on the consumer market rather than the business user.

In some ways, the distinction between River and the other environments is similar to the difference between Apple / Android and their respective philosophies regarding the rights / openness of the ecosystem.

Now some may be asking why I would want to create a River application with a non-business focus. River has a variety of other advantages over other OnDemand development platforms.   One of the most intriguing will be the ability to pull in data (purchasing history, travel history, etc) from back-end environments (for example, via Gateway). This data then could be stored using In-Memory technology and the user could then use the potential of In-Memory technology to examine various simulations. Of course, this information might be enhanced when the user is accessing the data via mobile client and his/her current location is pulled into the equation.

Other potential use cases might exploit this In-Memory technology to perform semantic analysis of data originating from social media / commercial sites and linking this data to other information.  

Run Simpler

As described above, the River implementation hides all the deep / complicated database-related code. The switch to In-Memory in River should allow developers to manipulate In-Memory data sources without having to write any additional code. Currently, HANA supports accessing the data via SQL and MDX and other means. With River, developers can now access such data sources without having to use these query languages – they can work graphically.

I have no idea what administrative tools (create datasource, change data structure, etc) will be available for the In-Memory technology but in River, the developer will never need to see such tools.

Access In-Memory Data via REST APIs

Adding In-Memory technology to River would allow access to In-Memory data via REST API – even better is that this functionality would be available out-of-the-box. Because River creates REST APIs automatically based on the underlying data structures, In-Memory technology could be made quickly accessible.

Of course, modern tools / code generators can create all the code necessary for REST APIs but the River developer doesn’t have to worry about generating new stubs every time he changes his UI – this is done automatically.

Will direct access to the In-Memory Business Logic Layer be necessary in River?

Note: This section is rather superficial and I don’t really go into great detail about how this might map to the actual In-Memory architecture. For more details on this architecture, I suggest looking at this presentation.

As was discussed in the Influencer Keynote in Boston, there will be a number of built-in functions (with typical database functions – rounding, etc – as well as other functions with a more specific business focus) in the In-Memory core.   Developers can also add functionality / logic to this core via “stored procedures” that are close to the data storage and are perfectly suited for the high performance needs demanded by the In-Memory technology.

As mentioned above, River developers usually won’t have to deal with the In-Memory functionality. How can River applications take advantage of these built-in in functions? In all likelihood, the Data Services Layer in River will have to be adjusted to deal with the potential of these built-in libraries.  This layer might use standard SQL to access In-Memory-based data but this probably isn’t the best choice to exploit the potential of this technology.

In River, developers have the ability to write their own code – via the CodeBox- if they want functionality that can’t be generated automatically.  What happens if a developer has functionality / business logic that should optimally be an In-Memory stored procedure – for example, to assure the highest performance. My suggestion would be additional CodeBox functions / syntax that are then stored in In-Memory.

Is In-Memory technology even needed in OnDemand Edge products?

Some might thinking – “Great that In-Memory technology is present in OnDemand Edge products.  Are the business requirements there to necessitate its usage? I really don’t think you will have a River application with 3 TB of information.”

First of all, the SAP OnDemand Edge Product line includes BIOnDemand and StreamWork as well. These environments (especially BIOnDemand) are an excellent fit for the analytic functionality made possible by this technology. There are possible use cases (for example, simulation) which would also be possible.


SAP’s new In-Memory technology provides amazing potential to end users – regardless of whether they are sitting at home or in the office – for example, improved access to information faster and more efficiently than was previously possible.  Combined with River, developers now have the ability to exploit this technology in a rapid / agile manner.

It is always been known that River isn’t the ideal platform for complicated applications that use Core business functionality. For Edge applications, however, River is perfect. The fact that developers will be able to exploit In-Memory technology just increases its attraction for such scenarios.

With its ability to provide developers easy access to the In-Memory technology via its WYSIWYG User Interface and its ability to present the resulting data automatically via REST APIs, River opens up InMemory technology to a wide range of developers with varying levels of expertise; it is the resulting expansion of the potential developer community and possible innovative use cases that makes the combination of River + InMemory technology so exciting. 
You must be Logged on to comment or reply to a post.
  • Richard,
      It took a couple of reads to fully understand the implications here; Just using your own data would make a poor business case for In Memory On Demand, once you factored in the cost of paying for your share of a cloud of HANA’s, AND the cost of transferring sufficient of your own data to make In Memory worthwhile.  However, the simulation idea made me wonder about using publicly available data (i.e. REST or RSS input…) to calculate something of value to yourself or other people.

    A very rough analogy is how, in the early series for American Idol, before SMS voting and when evry contestant had their own phone number, bookmakers would autodial the voting number for each contestatnt and use the ratio of engaged to answered calls to estimate the voting percentages. 

    So, what publicly available data would I need to guestimate airline seat availability ?  I could provide that to you, or use it myself to generate a virtual airline by arbitraging the price difference between what you would pay and what I could get the seat for.

    1. River
    2. HANA
    3. ?
    4. PROFIT !!!!

    • Martin,

      “publicly available data (i.e. REST or RSS input…) to calculate something of value to yourself or other people”

      That is the perfect use case – use In-Memory technology on River to easily / quickly provide simulations for other OnDemand services  – regardless of whether they are from SAP or not – via the REST APIs.   Since River also has Billing Services built into the architecture, this combination could be profitable for SAP as well as the application developers.