10 Tips For SAP River Developers

SAP River has been released as of SAP HANA SP7 in December, so I've had my hands on it for over a month now, and written a good pile of code. Thanks to the River team for supporting my... many... questions. I thought I'd give back with some developer tips for River.

1) Use sap-river.com (sometimes)

Even if you, like me, have an on-premise SAP HANA appliance with SAP River.The reason for this is that sap-river.com has a newer version of the interface and can often pick out errors in your code that HANA Studio may fail to do. Also, you can share your code with other people in the cloud, which can be handy.

If you don't have a SAP HANA appliance loaded with SAP River, then sap-river.com is a great way to get started and build some apps!

2) Take time to design your schema

You will get every minute you take to design your schema back, ten times over, when you come to develop apps. There are a number of key things, but remember that River doesn't support changing elements within entities when they have data - only adding of new entities:

- Think carefully about entities and the relationships between them

- Get the key, and required elements in the entities locked down

- Use the correct types, and reduce the length of them where possible (especially strings, which default to length 5000)

3) Never duplicate data

In the latest app I am building, there are a lot of time-based elements. For instance there is a person, who has a date of birth, an age (in decimal, integer, remainder and age band form). There are another 5 or so entities which also relate to time, and age (in 4 forms) is stored against each of those entities so you can get age at time of transaction.

With River, we need to store 1) date of birth and 2) date of transaction - all the other 20-30 copies are entirely redundant. Instead we calculate them on demand by using calculated elements:

element Age: Integer = sap.hana.util.dateTime.daysBetween(BirthDate,sap.hana.util.dateTime.currentUTCTimestamp())/365.25;

We can do age bands just as easily

element ageRange : Integer = select one rangeId from AgeRange where (age >= ageFrom && age < ageTo);

entity AgeRange {

     key rangeId: Integer;

     ageFrom: Integer;

     ageTo: Integer;

There is massive simplicity caused by never duplicating data - you never need to worry about whether an element is up to date. And even in my testing with large volumes of records, I get <200ms round trip times from the OData services from Chrome.

4) Use enumerated types to create the equivalent of foreign key restrictions

This is very handy - enumerated types are your friend! If you use them then they will restrict the entry criteria, which is very handy indeed.

element country: CountryCode;
type CountryCode: String(2) enum { US; CA; }

5) You can get the OData documentation in a browser

I don't find that the OData browser works that well in HANA Studio - it works much better in a browser. Happily, you can go directly to it and bookmark your project, using the following syntax:

6) Keep an eye on the HANA Index Server Trace file

Sometimes your RDL will misbehave and the syntax checker in HANA Studio won't pick it up. You get this dreaded message:

project:project.rdl

Internal error occurred, please check the logs / contact your Administrator.

When this happens, you can try using the sap-river.com version of the editor, or alternatively you can look at the HANA Index Server Trace. This will often give you a clue as to where the problem is.

I also recommend introducing new concepts slowly - for instance I built 10 views in a row yesterday, which all had the same problem, and troubleshooting the RDL was difficult until I removed 9 of them, corrected one, and duplicated my code 9 times.

7) Python is your friend!

I use Python to test all my RDL code - it is much better than Postman when it comes to the need to test and retest OData, plus you get the added advantage of being able to reload data quickly. I use Python either on my Mac, or when I need better performance, on the HANA server itself.

The HTTP Requests library is an excellent way to connect to River and test your code. It's also a great way to do data loads because you get all the River syntax checking, which you don't get if you load CSVs.

The only downside is that the current implementation of River only allows one record per OData call, which means that a large number of records can take some time to load! For higher-performance loads, I've been testing using HTTP Threads in Python to queue up data, and insert with up to 10 concurrent threads.

8) Use your River project for other stuff too

By default, your River project will have just one file - the RDL that contains all your code. However, I usually reuse the HANA repository workspace for all of my development artifacts - it is a handy dumping ground, to keep all your code in one place!

- Associated SQL for testing purposes

- Python files and associated CSV for loading data

- SAPUI5 artifacts

- Information views (Calculation Views)

9) Use GitHub to share your River repository workspace

This is a tip from Bluefin colleagues Brenton O'Callaghan and DJ Adams. Your River/HANA repository workspace will exist in whatever folder you put it in, and you can handily configure your River repository workspace to also be the location for a GitHub repository. Now you can share your River project with friends and co-developers in the cloud. At Bluefin we also use an on-premise Gitlab instance that Oliver Rogers built, which allows us to store more sensitive code in a safe place.

Registration URL: https://lnkd.in/fcw_BHa