Showing results for 
Search instead for 
Did you mean: 

Two worlds collide - REST vs ERP?

Former Member
0 Kudos

The blog by Denise Nepraunig about the adoption of SAPUI5 brought up some interesting points, such as the "coolness" factor of SAPUI5 vs other frameworks, and how well the SAPUI5 framework is integrated with backend services via OData.

However, there is one issue hardly ever mentioned: how does SAPUI5 (or any browser/mobile app running on REST-based technology) handle persistent ERP transactions?

The SAP backend is built in ABAP. The holy grail of ABAP is the "logical unit of work" - the persistent session that has to be kept alive from start to end of a user transaction. All of the existing SAP GUI technologies are built around this principle - even WDA, which is based on BSP and has the option for "stateful" applications.

This is where I am currently struggling to find support within the UI5/Fiori framework.

How do you "RESTify" VA01? Or MM02?

How do you reconcile what is effectively a "fire-and-forget" paradigm with a "cradle-to-grave" backend transaction?

I haven't seen this too much in the marketing materials for SAPUI5... or any other html/JS-based frontend technology, for that matter. What I have seen, are blogs, forum posts etc where "old-school" developers are lambasting REST (and, by proxy, what they roughly classify as the "new school" Web kids) for blatantly ignoring the requirements of keeping the well-oiled backend clockwork running in a persistent way.

Now, when our users demand new, cool SAPUI5 apps in favour of the "old-school", boring SAPgui or WDA screens, we'll have to balance this against the need for accommodating the good old ERP functionality - all of it written in ABAP 30 years ago - and not lending itself very well to the new REST-based, stateless approaches.

Some complain about the millenial generation having an attention span of microseconds, compared to the baby-boomers who are still capable of spending whatever time it takes reading an article from top to bottom. I find it a fitting analogy - the persistent, A to Z procedural way of completing a business transaction, compared to the jittery, flitting nature of a browser-based UI.

Anyone facing the same challenge? How are you adapting SAPUI5 to complex business needs, where statefulness is implicitly required? Or are you?



Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Well, this is an interesting topic. I'm working on digitization projects since years and my simple answer is - in most of the cases you can not adopt a stateful process 1:1 to a "stateless" web frontend.

What often happens is that there is a need for something in between which connects the stateful SAP processes with a web frontend.

I worked on several projects in which an old fashioned application or even a complete process landscape with a huge overhead in managing specific processes should be brought to web.

The typical workflow for these scenarios starts before you plan to bring some processes to a web frontend: Analyze - Cut - Modularize - Implement

The questions are usually the following:

- Shall this process really be transformed 1:1 for web? (My experience; usually it's cutted)

- Is this process already modularized? (Does a API layer in ABAP exists? Are there maybe already services available?)

- How should the process work "in the new world"?

- Are there more complex scenarios necessary which makes an process orchestration (e.g. BPMN) necessary?