The #SAPRiver Of Dreams
Eindhoven, March 7, SAP CodeJam on SAP River
SAP specialists Inbal Zilberman and Yoram Hod travelled to Eindhoven to share the passion and enthusiasm in a CodeJam on SAP River with us. Inbal already wrote about her experiences in a summary blog.
Is SAP River the new ABAP? Join a local CodeJam or apply for a free account on sap-river.com and follow the tutorials to find out yourself. Initially it might be a bit scary, but the tutorials will lead the way, no need to have hydrophobia. Let’s recall a song by Billy Joel – The River Of Dreams:
To the river so deep
I must be lookin’ for something
The SAP River might look deep or filled with wild water, but as SAP Developers we are looking for something, the future of SAP Development. No need to be afraid – just jump into the water and swim!
Inbal kicks off the event |
Yoram shows the code |
Here we go, let the fun begin |
Coding and discussing |
CodeJam food, thanks SAP! |
Coding while eating or Eating while coding? |
Yoram explains |
Jan Penninkhof going into details |
Recording the HANA Cafe NL podcast |
Recording the HANA Cafe NL podcast |
More pictures in our album.
HANA Cafe NL podcast
At the end of the event HANA Café NL sat together with Inbal Zilberman and Yoram Hod to record a podcast episode (0:47-18:44).
A short summary
What is SAP River? And why does it attract lots of people to join?
SAP River is the new definition language for business applications and the first compilation target is HANA (surprise ;-). With River you can focus on what you want to achieve, describe your application without getting into the details on how it’s done. It is to dramatically simplify the way we develop applications on top of HANA.
Will SAP River compete with current HANA toolset?
SAP River is more a design time concept, and on the background it will still generate the HANA artefacts. There are no penalties at runtime. So it’s not a matter of competition but an extension as it is now easier to describe and build your application.
What about the old River, are there any similarities?
Just the name and the idea behind it are similar. The old River was pattern and model based and by that extension/customization was hard to realize. The SAP River language helps you to do whatever you want. Focus on business logic.
What is the recommendation for ABAP developers? Start with River or with HANA native features?
In one year it will for sure be River. Today it may still be a baby, but growing very fast. Start with it and sometimes step out into HANA features.
Will there be more compilation targets?
SAP River is not HANA specific, the development team keeps it very clean. There is no block to compile it to other languages, River development team intends to open specs so that SAP or the community can compile it to other languages.
Risk if you know River but not into HANA artefacts?
SAP River will generate all HANA artefacts for you, but good knowledge of the basics comes in handy.
Is SAP River including native aspects of HANA?
There needs to be a way, from the beginning, to break out to existing code like JavaScript or HANA stored procedures. That allows SAP River to be used in extension scenarios as well, not only in greenfield projects.
Final words
We’ve seen the future and got enthusiastic!
Thank you:
- Inbal and Yoram for expertise and passion
- SAP for CodeJam event and food
- Ciber for hosting the event
- All participants!
Hi Twan
Sounds like a very interesting event, hopefully we can convince the River team to come to Australia and do similar.
I am trying to understand what problems is River solving.
I understand that River is kind of a code first (as opposed to visual model first) design time language / environment for simplifying the initial creation of OData services, it does this by rapidly creating the low level artificats like Tables, Views, Stored Procedures, JavaScript etc.
first question - why another language, why not JavaScript?
- JavaScript would lower the barrier of entry and potentially increase adoption for both existing and new SAP developers, not sure of the value of another proprietary language ontop of SQLScript and ABAP.
From your podcast i got the impression that River isnt intended to be magic, once the initial artifacts are created you still need to have domain knowledge of the HANA plumbing and need deep understanding of all the different parts of developing applications with the OData services.
second question - other than simplifying and accelerating the initial design of data API's, what application development problems is it solving, what makes it compelling to use or is it meant to be used in parallel with other accelerator tools?
Cheers
John P
Hi John,
Your description of River is correct but of course not complete. River is more than just simplifying the initial creation of OData services. The goal is to be the preferred language and framework to develop business application in HANA.
Why another language? I will keep it short although we can probably spend days on this question. Yes, we could done it with JavaScript but for inner DSL on top of any host language we would have to compromise and end up with not the best optimal and clean solution. We decided not to compromise and believe River has the best spec to describe business applications.
what application development problems is it solving?
Productivity. It does take care of all the plumbing let you focus on what your application should do and not how. Well, at least that the idea. River is not there yet but almost...
Yoram
Thanks for stepping in Yoram. Advice to John is go to sap-river.com and play around a bit. Look forward to your experiences. I can't answer your Javascript questions as I'm an ABAP developer 😛
Hi Yoram, Twan
Thanks for replying.
I did spend some time at sap.river.com and other places evaluating and investigating River and i can say I found it very easy to code and was suprised how quickly i was able to get services up and running. One feature i really liked was the OData service documentation, this is something that Gateway desperately needs! hopefully River doesn't stop there and goes on to adopt an API doco library similar to Swagger or Mashery's I/O Docs they have some very cool developer features like inline API test tools, this would be a real time saver.
The experience I had with River was comparible to rapidly creating OData Services on the Node.js based OData-server , it uses JavaScript as the definition language and I guess that is why i asked the question of why another language for developers to learn.
I too am an ABAP developers and like others working on HANA I am faced with the questions of where to code, when should i push down to the database layer and when to use plain old ABAP?, should i expose my services on Gateway or as XSOData? And now with River there is an additional abstraction layer in the middle and as much as i like it I am trying to understand when should i use it.
I just read the following blog FAQ: What is SAP River? and read - What are the use cases for SAP River? and after my experience i can see first 3 as being the viable use cases of when to use, hopefully others can share thier experiences of when you should use.
thanks again
jsp
Just a matter, John, of making a request for a CodeJam.
Exactly John, reach out to Craig or check http://scn.sap.com/docs/DOC-37775 about hosting a CodeJam event. I can highly recommend this 😉
Kind regards
Twan
Cheers, will ask around and see if others are interested also