Skip to Content

First Impressions of SAP River – Much more than Silos in the Cloud

As an SAP Mentor, I am lucky to have the chance to be part of the SAP River private beta and get access to SAP’s new Platform as a Service (PaaS) platform in a relatively early stage. Please let me share some first expressions.

Fig. 1: River as a container for speedboats?

Application development with River is extremely quick

This is especially true for data-driven applications. You can get the skeleton of your application – its entities, their associations and relationships, data maintenance screens, and cross-entity forward navigation – up and running in minutes. This includes search screens, a full-blown REST API for your application, and data upload and download capabilities.

Fig. 2: Look and feel of  a typical SAP River application

River offers an amazing degree of agility

The tight integration of design time and run time allows you to switch back and forth between data modeling and data entry anytime.

The system is extremely robust and flexible with regard to changes in the data model even if there already are data in tables. Changing the attributes of an entity, its relationships with other entities or a composition relationship on the fly is a breeze, even if major changes to the data model occur that would cause you to run away from your SAPGui or NetWeaver Development Studio screaming and pulling out your hair if they occurred in classical SAP development environments.

Fig. 3: Form Editor

Because the user interface and the data model are really one (the data model and REST API are derived directly from what you model in the WYSIWIG form editor), you don’t have to go through the trouble of manually keeping the database layer, access layer, UI layer, and service layer consistent with each other as in more conventional development models.

(I should add that although every user interface starts out as a data maintenance screen, it’s possible to move away from pure Create-Read-Update-Delete user interfaces towards task-based user interfaces.)

Business logic

Going beyond reading and writing data from and to database tables, there are several ways to incorporate business logic into River applications.

  • One is to consume it through services, e.g. call Enterprise or RESTful Services or Rule Services (exposed by BRM or BRF+) in a back-end system.
  • One is to model it as “custom actions” with a graphical editor. (My first impression is that this is good for relatively simple tasks. You can use loop constructs, if-else-constructs, declare variables, and use a number of ready-made functions to implement such actions.)
  • Simple expressions for use in mappings, filters, joins, calculated fields, etc. can be created with a formula editor.
  • If all else fails, you can write server-side JavaScript. The ability to use server-side JavaScript gives you great flexibility. For example, River doesn’t currently have any tool support for consuming SOAP web services, but you can find the appropriate code snipplets on SCN and simply code the web service call in JavaScript.

Fig. 4: Action Edtor

My impression is that while the Create/Read/Update/Delete data (CRUD) and user interface part of an application may be 10 to 50 times faster (depending on developer skill) to develop in River than in ABAP or Java, the effort for implementing business logic is about the same in River as in traditional development platforms.

User Interface flexibility

If you invest just minutes into your user interface, you get off-the-shelf screens that closely represent your data model. If you want more control over the user interface, you have several options that allow you to deviate more or less from the standard River look and feel:

  • Re-skin your application with a custom style sheet
  • Integrate custom widgets (implemented as Flex components)
  • Create Flex-based user interfaces that run within the River framework
  • Other UI technologies are also supported, e.g. HTML5
  • Have the UI outside River (every part of your River application is accessible through the REST API, which gives you the freedom to implement the UI aspect elsewhere entirely)

User interface consistency

Unfortunately, the default style and colour scheme looks very different from the SAP Signature Design Theme so River has – currently – a very un-SAP-like look and feel.
I suggest that the River team change this quickly and make default River applications look more like Visual Composer, Web Dynpro, NetWeaver Business Client, and Webclient UI Framework: While it my appear to be nitpicking on a superficiality, the audiences of early-stages River demos are likely to be key influencers and decision makers. If these key people get the impression that River is, in its DNA, an isolated tool, or a platform for building “silos in the cloud”, River will be dead faster than you can say “bang”. SAP would be well-advised to stress the integration capabilities of River and its role as a speedboat circling the supertanker of the SAP Business Suite any way they can.


River allows three kinds of service integration:

  • outbound SOAP web service (Enterprise Service) calls – currently coded in JavaScript, soon with tool support
  • outbound REST calls – currently with arduous XML mapping, soon with tool support – great support for integration with ABAP systems through Gateway
  • inbound REST calls – out-of-the-box REST API for all your data and functions (actions), not sure about the limitations of the latter yet

I’m not quite sure yet how difficult it is (or will be) to implement asynchronous integration scenarios.

The most significant type of integration will be River calling SAP Gateway. SAP Gateway is an add-on to SAP Business Suite systems that allows you to expose its data and functionality through Atom-based REST web services. SAP Gateway speaks exactly the same protocol natively and allows you (currently, but not for long, with heavy XML editing) to created Linked Applications whose data can be displayed, edited, and otherwise managed in a River application but reside not in River’s database but anywhere they are accessible through Atom-based REST web services.

This means that River’s primary use case will not be stand-alone applications (“silos in the cloud”) but fringe or edge innovation on top of the applications in your on-premise SAP back-end or other core applications (speedboats).

Alternatively, integration via CSV file export and import is possible but limited to root entities: If an entity has a hierarchic structure and contains sub-nodes (composition as opposed to aggregation with independent entities), these cannot be exported and imported via the CSV file import. As a work-around, you can create complicated constructs in which you upload sub-node data into one table (staging area) and then propagate it into another by means of custom actions.

Configuration by exception

The overall principle seems to be: Plain vanilla River applications are available at your fingertips and within minutes; if you want to deviate from the default way of doing things, it’s usually possible with more or less additional effort. River never feels like a closed system and is much more open than, say, Visual Composer. On the other hand, many development tasks are completed much quicker than with Visual Composer. I would say it is really unparalleled for data-driven applications. (See Jürgen Schmerder’s excellent blog post SAP “Project River” – how does it compare to xyz?.)

Total cost of usership

The obvious benefit of Platform as a Service (PaaS) offerings is that you as a developer or Independent Software Vendor (ISV) and, more importantly, your customers don’t have to operate the platform. When customers ask you about sizing, the server resources they have to reserve, the requirements for hardware, operating system, and database, and about the deployment procedure, it will be nice to tell them they need just a standard web browser, internet access, and a URL – and not to worry about deployment.

If you run SAP NetWeaver Composition Environment, Enterprise Portal or AS ABAP as an on-premise development platform, you’re likely to have at least one person permanently busy administrating and maintaining the platform. That’s part of the total cost of ownership. At River, you’re not an owner but a user, so you will have to invest less time and effort into keeping the platform running and up to par. However, it’s unclear how this will affect the cost side because, to my knowledge, the pricing models and rates for SAP River are not yet known.

Application Lifecycle Management

I was surprised by the sophisticated application lifecycle management functions built into river:

  • You can maintain several versions of your application, create snapshots and any point and return to older versions if necessary.
  • There are separate prototype/development/test and production environments and versions – and a function for promoting a version into production.
  • Separate user management for development and production.
  • Capability to have develop the next version of your application while keeping a maintenance version from which to patch the currently productive version.
  • Capability to copy, export, and import applications and with or without data dumps.

Further tidbits and information

There is so much more to say I cannot cover in this first blog post. Just some keywords:

  • There’s a job scheduler in River.
  • River runs on SAP’s new “In-Memory Computing Engine” (ICE), formerly and colloquially called NewDB – the in-memory database system that creates the magic of HANA.
  • SAP did not create it from scratch but bought an existing platform named Coghead which they shut down and developed further before it was reborn as River.
  • Coghead have at one point announced that they had 17,000 developers working on their platform. Even if you take that number with a grain of salt, it’s interesting to know. Richard Hirsch’s excellent blog post on The specified item was not found. will tell you more on River’s pre-life as Coghead and how SAP could leverage that.
  • SAP’s competitor in the on-demand market,, has two PaaS offerings ( and with well over 100,000 applications. PaaS is not the future, it’s the present and it’s even got a bit of history.
  • With SAP’s Carbon Impact application and KeyTree’s iApprove, there are already two productive SAP-based applications live on the River platform. Carbon Impact has hundreds of entities and thousands of data fields. iApprove has a custom-built Flex-based user interface.
  • Check out the SCN Wiki > Emerging Technologies > River
  • Use cases: The question of where to use SAP River deserves special consideration.
You must be Logged on to comment or reply to a post.
  • It is critical that SAP define exactly what sort of use cases are to be covered by River. At some point in the scale of application complexity, the advantages of using River as a development platform diminish. I always found it curious that SAP decided to develop Carbon Impact with River. CI shows the potential of River but it may be too complex for the type of apps that most devs will be using the platform for.



  • Hello Thorsten,

    Thanks for the great review of features. I’d really like to dedicate some time to learn the platform, maybe in a near future.

    Looks like any “cloud” offering such PaaS needs a greater appeal versus any “on premise” solution. Specialty in development heavy clients anything remote or cloudy doesn’t feel right.
    Do you think that the Mobile/Tablet Ready River applications would find a niche?

    Best Regards,
    Marlo Simon.

    • Hi Marlo,
      Yes, I agree that this is the gut-level feeling of many people which must be overcome in order to achieve a good adoption of cloud-based solutions.
      I believe that you point just to the right door-opener: Being the back-end for tablet and mobile applications is, in my opinion, a very good use case for River for several reasons, among them:
      – rapid and synched development of mobile client and River application without having to follow the slower release cycles of the ABAP back-back-end
      – River’s REST APIs are easy to consume for mobile applications
      – ABAP back-ends are less exposed to the internet – a tunnel to the River platform will suffice
      In summary, this architecture allows for a high degree of decoupling between the mobile client and the ABAP back-end, which can (but doesn’t have to) be desirable for many reasons.
      • Nice!!

        That’s the architectural approach that I’d recommend to the venturous ones.
        Let’s see how the adoption patterns mature an hope that we can find some early adopters down here in Brazil.

        Marlo Simon.

  • Hello Torsten,

    very nice blog again!

    I am just wondering how well River has been integrated with other SAP solutions so far taking into account that it is the former Coghead solution?

    I am asking because accessing backend data and fuctionality via Gateway and webservice call is one thing but for example user roles and priviledges or single-sing-on is another.

    Best regards

    • Frank,
      That’s a very good question. The concept seems to be the following:
      1. In River, you store credentials. Credentials are like a key to a back-end system, e.g. a username/password combination for an SAP system, or a certificate, or a username/password combination for BasicAuth HTTP access.
      2. Each credential is assigned to a River user.
      3. Credentials are grouped into credential sets.
      4. Credential sets are assigned to River applications.
      If the concept stays basically the same, this means basically that you maintain River users and backend users seperately and create a mapping between them.
      But who knows, they might use OpenId or other techniques for future identity management with regard to On-Demand/On-Premise integration.
      I think that’s a general question that interests anyone who expects cloud-based and on-premise solutions to work together seamlessly, so I expect SAP to invest into good solutions.
      However the mapping occurs (performed administrator, dynamically at run-time), as soon as you’re calling the back-end it happens with a defined back-end user and the back-end is able to perform authorization checks and determine whether or not it should deliver the data or execute the requested function.
        • Hi Richard,
          I know that, the “OpenID” field in the login screen smiles at me every day and I remember the warnings from the River team not to use it at the moment. 😉
          I meant OpenID (or OAuth or whatever) as a Single-Sign On mechanism to allow you to access back-end data with your personal back-end user id without having to maintain separate identities in River and ABAP, defining a mapping between them, or storing username/password combinations or certificates for individual users in River.
          • I think much depends on how you want to access the back-ends. SAML would probably be the ideal option. If you look at StreamWork, they are already using SAML to integrate with back-ends. If I remember correctly, River and StreamWork are both running on the same technology (NW 7.0?), so that functionality might already be present in River – just unused. I don’t think SAML was that popular when CogHead was still in existence, so there might be changes necessary there as well.

            If we are talking about using REST APIs to access back-end data (ie via Gateway), then OAUth would probably be the best choice.


          • I’m mostly replying so that I am subscribed to the discussion, but one point: My understanding is that River is the platform used for Carbon Impact. Streamwork uses a different platform (JRuby/RoR-based?), though it may also be running on a NW Java app server.
          • Ethan,

            I’m more interested in the Application Server that is buried beneath all that code. I think both are running on a NW Java app server. If StreamWork and River are running on the same type of AppServer, then I assume that River could also use SAML – just as StreamWork does. How it would fit into the existing River architecture is an entirely different story.


          • Ah, I see what you are saying. Makes sense.

            Relatedly, there is an IETF draft under the OAuth work group that specifies how to exchange an SAML assertion token for an OAuth access token.

            Interesting times 🙂

          • Ethan,
            Good to have you here!
            I heard or read somewhere that at some point (experimentally, I believe), the River team had both River and StreamWork running on the same AS Java and using the same User Management Engine (UME), allowing for single-sign on between the two. If River was an On-Premise solution, this would also allow us to use the AS Java’s capability to have trust relationships with ABAP back-ends for single sign-on purposes.
            Given that River is a cloud-based solution, I share Richard’s expectation that OAuth and SAML will be supported.
          • Hi Thorsten,

            Good to be here 🙂 That would be awesome to have as an on-premise solution! Great idea. I’m afraid it’s got to be at least 2 or 3 years away, but I’ll keep my fingers crossed and thumbs pressed.


          • Ethan,
            I agree, even though it makes me feel highly schizophrenic: When SAP delivers on-premise (e.g. HANA), I say we need it in the cloud. When they deliever in the cloud (e.g. River), I say it would be nifty on-premise. We’re all a greedy bunch, aren’t we? On-premise, on-demand – and of course on-device for rarely connected scenarios. 😉
          • The use of UME in River / StreamWork integration scenarios assures that the user store / identities are the same; however, since the integration usually takes place via REST APIs, other tools / standards are necessary.

            Regarding the trust relationships between AS Java and ABAP Back-ends, I wonder what the impact of REST APIs and/or Gateway will have on such relationships.


          • Given that Gateway uses the good old ICF, I would be surprised if SAPlogon tickets attached to the HTTP request wouldn’t be good enough to authenticate you. If River runs on the AS Java and has a trust relationship with the AS ABAP (exchanged certificates at server level), it can issue such SAPlogon tickets and attach them to the outgoing HTTP request.
          • Like the idea but it surprises me a little bit — if I remember correctly, Gateway currently only supports BASIC Authentication. Of course, this information is a few months old and things could have changed in the meantime.


          • It could be because the ICF gives you control over the supported authentication method for each ICF node. You can choose from existing methods, add your own, and even determine the sequence in which they should be tried. There’s an ICF node under which all Gateway-powered REST services are located: Here, SAP can determine the default authentication behaviour. If the administrator or developer is allowed to manually configure the generated lower nodes, they could use this to override the default settings.
            I’m curious how much control at ICF node level the productive version of Gateway will offer – the current alpha version gives you a lot of control.
  • Hi Thorsten
    Great blog … great discussion.

    From what I know:
    SAML and OAuth are both on the table as is openid and they are all in various states of completion.

    As for the technology and perhaps I am telling tales out of school but check this link

    The user interface pattern you mention are very valid and when gateway becomes available this will make intergrating on premise back ends much easier than rolling your own ICF classes – though that still is a valid option.

    I dissagree about a “signature css”. I think it is more useful to show something that look quite unlike what people are used to especially for mobile rollouts. I take you point about showing it to people who expect SAP to look a certain way but I think this is a great opportunity to show that SAP can do great looking experiences.

    Oh and let’s not get carried away with saying Keytree’s app is productive. If anyone would like to get more information about iApprove I would be happy to take questions privately or they can get in touch with Keytree at

    I think River is a great on demand platform for SAP and it will continue to grow and mature in the months to come.


    • I agree with Nigel.   SAP needs to allow new UI technologies than what we are used to from SAP.

      There is a place for SAP GUI, the native WebDynpro framework is a good step forward, but this ‘River’ function may just be the thing that brings the SAP UI technology into the current standards.

      We are constantly being asked to elevate the UI for our users.  The peer comparisons with Adobe Flash, custom .NET, etc leaves SAP at a disadvantage.


    • Those of you who have an account on the preview landscape might want to check – after the update deployed today, the design has changed to the new “signature CSS”, inspired by Sales OnDemand rather than “classical” SAP apps.

      So, River looks like SAP, but not like “old” SAP. Taste aside, I am quite happy with this decision…


  • Hi Thorsten

    How could I miss this gem?? Too occupied with SAPPHIRE NOW topics, I suppose…
    Anyway, even months later, this is a great description of what you can do with project River.
    Thanks a lot for writing it up!