Developing new UI5 apps is costly and time-consuming. We must use tools that keep the extensive investments in SAP made by both SAP and its customers.
Abstract
The development of new UI5 apps is a costly and time-consuming project.
The author suggests seeking tools to keep the extensive investments in SAP made by both SAP and its customers. Somebody can do this by enabling customers to enhance their existing ABAP-based reports and expose them as UI5 apps.
Existing roadmap from SAPGUI to UI5
UI5 Technology leads to a reduced need for development and improved mobile work capabilities. When developing a new UI5 app, the old SAP GUI processes are not reusable. Every legacy SAP GUI process, which is converted to a UI5 app, must be revised. That process, its UI, along with the supporting code, must be rewritten.
What can we tell about this new UI5 app?
One may think the resulting UI5 is a clone of the original report. No, we are talking about a brand new object composed of a new UI, a new ODATA service, and a new set of back-end methods. Like any newly developed code, it’s exposed to bugs and data errors for quite a long time until it reaches maturity.
One may think the resulting UI5 app will hold for the next 3-5 years. That is not the case. The pace in which SAP introduces new controls and approaches will make any UI5 app look ridiculously old after just three years (or so) of its issuing. The UX world is running incredibly fast, and no-one, SAP included, can foresee how, for example, the next table-control will look.
Existing roadmap drawbacks
As of the year 2000, SAP has been trying to push hard towards the web. It started with the SAP Dot Com initiative, and it has continued ever since. Back in the days, SAP presented the BSP (Business Server Page) application along with HTMLB (business HTML). If the reader is not familiar with the terms, there is a reason for that. These technologies are rarely ever mentioned in the past decade. The Webdynpro Java and Webdynpro ABAP presented yet another approach. In between, we had SAP NetWeaver Visual Composer and many mobile frameworks (Sybase Unwired Platform developed into The mobile platform [EOL, 2020], to name a few). All have ceased to exist. Companies invested in those areas are now cutting their losses.
The only approach survived is the SAP Internet Transaction Server (ITS), aka Web GUI. ITS was the first approach by SAP to extend business applications to a Web Browser or the Internet. It was done by converting SAP Dynpro (SAP GUI screen) into HTML format. ITS is the fallback SAP offers its S/4 customers whenever no Fiori app exists, which is often the case. Using the Belize theme, any SAP GUI screen is presented in the Web looking, somewhat, like a Fiori app.
ITS was the only approach to generically and systematically display any SAP GUI objects into HTML. Whereas, all other methods laid that burden on the back of the companies running SAP. BSP, HTMLB, Webdynpro JAVA & ABAP (and UI5 now) all force SAP customers to code each object into the web framework.
If SAP managers and the organizations’ stakeholders want to keep their investments, they must insist on rollout-like technology. It is a technology that uses the existing investment that is used in ABAP and exposes it as a UI5 application. No new code for data fetches, no new code for UI, and, hopefully, no new code to extend the old ABAP baseline (report/query/DB table).
Suggested alternative
Most ABAP-based reports use SAP ABAP List Viewer (ALV) as their foundation. The ALV is a framework that enables displaying tabular data in a user-friendly way. The ALV is the most common way by which SAP and its customers show display reports.
The ALV framework allows ABAP developers to separate content from presentation. That is to say, the developer gathers the data (tabular information in the form of an internal table), and the ALV framework provides presentation services (such as formatting, aggregation, filtering, and sorting, to name a few).
There are five generations of ALV issued by SAP, each using different SAP technology.
In numbers, ALV is, by all means, the current SAP standard to service users’ reports. SAP and its customers alike spent tens of thousands of development years to develop ALV reports.
Our approach bases itself on a new framework (InsightSAP) that displays any ALV report as a UI5 app. With short configuration, without any code (neither in ABAP nor in Javascript) involved.
We used a layered approach to move from ALV to UI5, by which:
- Using Insight, a configurable ABAP based application, we present all ALV reports as an ALV report- the same ALV report.
- The Insight data model (a single generic one) is displayed as a REST service.
- Our UI5 app (a single generic one) consumes the above REST service and displays it as a responsive, customizable mobile application.
We use one generic UI5 app–one app to rule them all–instead of many different apps.
This process is possible without any new code or any code changes to the old ALV. You can do this without developing a new UI, either at the SAP GUI or the UI5 side.
All could be done directly in Production, saving the time needed to ship things from DEV to the PROD system.
One can split the answer to the critical question regarding those assets that are not served as ALVs, into two;
- The more, the merrier– We are continually enhancing our framework to enlarge the number of objects we could display as ALV (v. to Insight). In an ongoing process, we keep developing utilities that enable new features, enhance existing SAP features, and expose SAP features that are not offered as ALV.
- ABAP queries – Since they could be easily manifest themselves as ALV reports, we present them as Insight reports.
- DB tables and views – Using the SAP standard program, any DB table or view could be displayed as Insight.
- SAP logs and IDocs – Using two utilities, both logs, and IDocs could be Insighted.
- Application logs, jobs, and many other SAP reports that do not use the standard ALV protocol were exposed and are transparent to Insight.
- UI5 apps – We are leaving those transactional processes to the UI5 developers. Since the burden of transferring all old assets to UI5 was removed from their shoulders, so to speak, the UI5 developers will have enough time to spend on real UI5 needs of the organization.
The alternative advantages
Our approach yields many benefits:
- Matured UI5 app –
- Content – All work spent on old ALV (assets) is saved to deliver matured and well-tested content
- Never outdated look & feel – As we ship a modified UI5 app twice a year, it cannot get outdated
- Asset rather than a liability–The ability to expose any ALV report as a UI5 app in minutes turns the UI5 advantages into an asset rather than becoming a liability relating to time and money spent.
- Enterprise identity–As we use only one UI5 app shared across the organization, an enterprise identity can be established, such as the look and feel of their logo and colors (CSS).
- Steep learning curve–Since we use only one UI5 app, there is only one look and feel to learn, and thus, learning time is dramatically shorter.
Overview of the architecture:
At first, the ALV report data and metadata are encapsulated as a generic data model to represent a report. Then, this model can be displayed as a REST service.
The UI5 app calls this REST service and builds the app UI/controls according to the report metadata (similar to what is done in SAP Fiori elements that read ODATA annotations).
The app is designed as a standard master-detail app (implementing FlexibleColumnLayout).
On the left pane, data records are divided into groups (a multi-level hierarchy), while the main view displays the data table (sap.m.Table) and charts (sap.suite.ui.commons.chartcontainer).
The original ALV report
The Insight report
UI5 app (Desktop mode)
UI5 app (Mobile mode)
