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.
Integration
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, salesforce.com, has two PaaS offerings (Force.com and Heroku.com) 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.
24 Comments
