UI5 rules the SAP universe. There is a plethora of new tools and infrastructures provided by SAP (HANA database, HANA Cloud Platform (Java), Server Side Javascript in XS, Core Data Service and much much more). But the actual king for me is UI5. Though it’s not much more than a set of libraries and styles in a technology which has been there for ages. Whether it’s a brilliantly composed infrastructure, I can’t judge – as I don’t really know the alternatives. But it doesn’t matter: UI5 it the user interface technology which is being pushed by SAP intensively and which will surely be highly attractive to millions of SAP GUI-accustomed users out there. Hardly any end user can judge the impact of business logic being executed as a stored procedure inside the HANA database or the flexibility of running an infrastructure on HCP. But everybody can look at a UI5-based simplified user interface he once knew in the SAPGUI and say “that looks fresh – and it even works on my phone. Awesome!”. Therefore, I consider UI5 as the driver for business application renovation for the next years.
It’s not about SAP GUI vs. HTML5
Alright, beautiful new world, here you are. I’m learning JavaScript and will somehow manage to deal with an un-typed programming language. I’ll simply expose my business logic as OData via Gateway, as UI5 is based on this protocol. Should not be a big deal, should it? But slowly, second thoughts creep into minds of those developers who actually implemented transactional applications in the past. Some asked related questions quietly also this year in Berlin. Questions like “what about locking”? This addresses one major change in application development caused by the OData-protocol: Applications are supposed to be stateless. And not having exclusive locks which provide a server-side state about who’s under control of which instance is part of that. It struck me also this year was, how little SAP and the brilliant heads available in the sessions actually seem to care about this change and how easy this questions is answered with “there are only optimistic locks”. And I’m even more surprised by how relaxed the developers having asked this question accept the answer.
For me, this change in paradigm is huge! Let me explain why.
Stateless business applications
In the classical SAP development world (=ABAP, until just recently), applications were stateful: The application server knew about the state of the transaction in process. While saving, the state was committed to the database. Locks were either resolved or a new transaction started immediately based on the last image of the previous “transaction” including its locks. To me, this behavior seems absolutely appropriate for business applications: Multiple persons operating on the same data expect to exclusively work on it once they’ve successfully started to perform operations on the data. In our project, even a late exclusive locking (on first write access, not on clicking the “edit”-button) needed some explanation to the users before they could accept it as a feature (not as a bug). I do not know whether this expectation really is a need for business applications or whether it’s just something (SAP) users got used to throughout the years – I believe it’s both. In addition to resolving concurrency, users expect that a system validates their input. And in some cases, does not only prevent further processing, but also the saving of inconsistent states.
In a mobile world, where connectivity to the application server may not be as stable as in a wired office, this interaction pattern is not appropriate: The server must not hold a state which might be lost after the connection was lost or which leaves objects in a locked state as the transaction cannot be completed. At maximum it is acceptable to read data with some mechanism which informs the client that data which he has read is out-of-date as someone else has changed it (optimistic locks). The OData-protocol, upon which UI5 is based, implies such a stateless behavior. While the actual frontend-developer (those brilliant youngsters juggling with the Javascript) simply can rely on the model to which they bind the UI to be stateless while the grey-haired ABAP-developers who are glad to have mastered ABAP-OO are now confronted to fulfil the provisioning side of the protocol.
And there’s no in-built-support for enabling a stateless application-backend.
Figure 1: Evidence: The youngster with his responsive app and a group of fanboys and the grey-haired frustrated ABAPer - picture taken at TechEd 2014, Berlin
Options for stateless backends
Before I go on, let me say very clearly: I don’t know of any silver-bullet-application-design-pattern. I wanted to sketch some ideas which came to my mind and I want your feedback on them.
Assuming data has been read optimistically on opening the UI, the questions is what happens on write (“save”). I’d expect the optimistic read lock to be promoted to an exclusive one once a PUT or a POST are being transformed into backend modifications. If this locking is successful, other optimistic locks on these instances would be deleted. Thus, on a subsequent change from one of the other sessions, the backend could detect the concurrent change and then…
Dismiss concurrent changes
The most simple of the options surely is to inform the user that changes to the instances he wants to modify have occurred. Whether the current data is re-read automatically or whether the user is given a chance to actively refresh his UI is subject to what’s more acceptable to the user. Depending on the complexity of the operations performed, this interaction pattern can in fact be acceptable. Particularly for one-click actions and data which is actually owned by one user, this seems to be appropriate. No wonder leave-requests is the new “hello world” of the business applications.
Push channel
With a bit more of effort, the backend could provide a mechanism for actively notifying owners of deleted read-locks about changes which have occurred by another user. This limits the frustration as less data entered might be lost, but the mechanism remains: Simply inform the user and afterwards, dismiss his changes.
Merge
Knowing that concurrent changes might occur, one could also prepare the model for concurrent updateability: With an active/inactive-mechanism which allows to have multiple inactive versions for different users, the system could basically allow parallel operations on (parts of) the same data. A dedicated interaction with the system (e. g. an action “merge”), the always save-able inactive version of the business data which may even have been modified in several steps by the user could be merged with the active one. During this process, the backend can remember the changes done and include this in the algorithm once another session which has read and modified the original data pushes its changes to the backend. In this pattern, not even an optimistic lock would be required – but the merge-mechanism may be tricky to implement depending on the scenario. I believe that this interaction however would be most acceptable for users being used to stateful applications.
Is ABAP (and Web Dynpro ABAP) dead?
With the new world relying on Javascript in the frontend and the OData-protocol, it’s obvious that neither on the frontend nor on the backend ABAP is required anymore. You can even implement business applications with the UI5-look which are based on a completely non-SAP backend or you could use one of the other weapons SAP has in its technology arsenal for you (Enterprise Java on HCP, server side Javascript with XSJS or simply XSOData). But still, you could stick to good old ABAP and expose the service via Gateway. And from my point of view, there are good reasons to do this: ABAP (not as language, but as infrastructure) offers mature tools needed for business applications: A programming model which has first-level-citizens optimized for tabular data, a sophisticated authorization management integration, a brilliant change and transport system and much more.
I have sketched some options for a stateless backend, but honestly, I believe that still for transactional applications, the exclusive locking of a stateful application and the business transaction which allows to save only consistent data will remain the most required interaction pattern for complex use cases. In addition, connectivity has improved vastly over the past years and will surely be enforced more and more also with high-speed networks. Therefore, I believe that many new business applications will also be stateful at least in the next five to ten years. And if this is the case, the usage of the ABAP-based Floorplan Manager is appealing to me: Personalization capabilities are extremely powerful, the controls are optimized for the needs of business users, a real WYSIWYG editor is available and last but not least, the programming model is well established.
Consequently I guess we’ll have multiple types of applications based on OData and UI5 or FPM to exist side-by-side. Key with respect to user experience will be to provide styles for both the UI-technologies which don’t expose the differencein the application pattern to the user. Based on the use case, either a stateful or a stateless application may be launched without the user noticing any difference.
Importance of frameworks
Whatever your architectural decision looks like: To me it’s obvious that you need an application framework which helps you to implement generic consumers in order to fulfil different contracts. Whether it’s about providing generic feeders for the FPM UIBBs or about exposing the model as OData – having a metamodel in place will help you tremendously. Also these contracts evolve or the consumer (UI5, kapsel container offline plugin) require new aspects of the protocol to be implemented. Want samples: $expand, $top, delta tokens,… With the consumption technology evolving, it’s essential to have a technological foundation which keeps the pace. From my personal experience, I’d even say it’s not possible to actually implement this from scratch on your own. Luckily, we don’t have to (those who followed my previous posts know what’s coming): With BOPF, SAP provides a framework which has a strong metamodel optimized for the delevopment of business applications. There have been consumers around (the Floorplan Manager BOPF integration (FBI), the Gateway BOPF Integration (GBI), Post Processing Framework, … ) which leveraged the benefits of this model driven approach. However, these components have been established based on the needs of business applications built upon BOPF (majorly SAP Transportation Management). This lead to the sad fact, that these components only supported the set of features needed in the consuming applications, not in support of all features possibly required by the consumption technology (e. g. there is no FBI feeder for the Form Repeater UIBB, $expand is not supported by GBI).
But with SP8, this has changed tremendously: SAP now provides an abstraction layer called SADL, the service adaptation definition language. This runtime artifact consumes various types of metadata and provides generic adaptors to the latest UI-technologies. And what’s best: It’s being developed in close cooperation with the consumer-technologies (FPM, Gateway). Personally, I’ve got huge expectations with respect to SADL really making BOPF timelessly consumable software.
The only thing which I don’t understand at all: Why is an application framework based on well established technology not being promoted at TechEd? Of course, this is not as sexy as showing new UI controls, as integrating IoT-sensor data or as aggregating zillions of BSEG-items within the blink of an eye, but in the end, it (still) is all about business applications. So why not show how to actually enable developers to get this done? Maybe next year, when SAP cares more about actual application development. This year’s keynote was a step into this direction, at least I keep telling this to myself.
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
