This blog explains in 5 steps the technical approach we follow when transforming an ABAP based Web Dynpro solution into a Fiori like application built with SAP UI5. 

SAP modules still satisfy today’s business needs from a backend perspective but some of their user interfaces are no longer aligned with today’s modern user experience standards. The approach we follow is to simply replace the user interface with another one while leveraging the same backend code and functionality. This approach then offers a much cheaper investment than:

1. Replacing the product with another one
2. Upgrading to the latest version
3. Writing a full blown custom developed application

In this example, we will focus on the SAP on premise Travel and Expense solution and more specifically on the general data screen.
The main idea of our approach is to understand how the Web Dynpro application was built and then start deconstructing it piece by piece. This process is known as reverse engineering and is quite time consuming when the involved technologies/frameworks are not understood properly.

The following will show step by step how we work.

Step 1 - Find where is the code in SAP

We start by running the standard SAP application and do a right click on a UI field to bring up the Web Dynpro contextual menu:

In the popup press "Technical Help ..."

This window that pops up now gives us all the necessary information to find the code in the SAP backend using SE80.

Step 2 - Build an identical screen with SAP UI5

SAP UI5 library provides all the UI elements necessary to recreate such screen including search help fields. Please note that for the moment the screen will have no data to be displayed and will have no field control (all fields editable and visible). Everything including labels are hard coded.

Step 3 - Understand how the Web Dynpro screen is populated.

This step contains two tasks:

1. The static analysis: This helps understanding the code and data structure just by reading it. It is important to first go through the contexts of both the Web Dynpro Component Controller and the View and then all the methods form the Component Controller, Assistance Class and View. By doing such, it is possible to understand where is data coming from and how is it being bind to the screen.
2. The dynamic analysis: That consists in debugging the code to understand the different states the screen can have.

In the case of the General Data screen from our example, these analysis lead to conclude that this screen is highly dynamic meaning that its various states can be directed by the following factors:

• Application customizing: By looking at the Web Dynpro View elements, we can see all containers and fields visibility attribute is set to true meaning that this aspect is controlled elsewhere. Indeed, there are many methods such as the WDDOMODIFYVIEW that will alter fields visibility based on some business logic inherent to the product. Looking further in the code and more precisely in the assistance class we can find the following:
  
  The function module in charge of returning the data also returns a table called “et_field_control” and that contains all information about visibility, read-only, mandatory of the screen fields.
• Data State: For example, when a user changes the country of his trip on the country, a round trip is done to the backend to check whether some fields such as border crossing should appear or not. In the screenshot below, we can see the action listener attached to country dropdown value change.
  
• Web DynPro configuration: This is inherent to any Web Dynpro screen. Indeed, anyone can use this concept to alter Web Dynpro screens.
  

Although it is rather tedious but straightforward to understand how to get the data, the customizing and the screen logic, there is one final step that consists of extracting all the metadata from the screen. This is important as it will return all the labels, translations and fields along with their type (input field, container, radio button, etc.). Using this in combination with the field control from the customizing then makes it possible to have the UI5 screen reusing these and therefore avoid any double maintenance for labels and translations.

For this task, the approach we chose was to also reverse engineer the Web Dynpro framework and find out which database tables were storing the screens definitions. We were then able, for each Web Dynpro screen, to extract a list of all its UI elements along with their type, properties, and labels. This code can now be reused for any application.

Step 4 - Connecting the backend with SAP UI5

At this stage, we have on one side the SAP UI5 screen and the reverse engineering work done on the backend (that we translated into new ABAP code). The next step is to get the two talking to each other.

SAP offers different mechanisms to create backend services that could expose data. Although the most advocated one by SAP is the NetWeaver Gateway, we preferred developing our own framework based on a BSP application. We were looking for a framework not restricting us to RESTful services. The particularity of this BSP is that it does not use any BSP Views, just Models and Controller. The controller receives the request, re-route it to the right method that then builds the appropriate response. In our case we return the response in a JSON format.

Below is an example of the method that is responsible to return the general data information.

Please note that the JSON conversion is bi-directional and realized via XSLT transformation. Below is the method we created to convert any ABAP object to a JSON string.

Step 5 - SAP UI5 Binding

Once the BSP application is up and running, it can then be called from any UI5 controller such as in the example below:

From the UI5 XML view side, the example bellows illustrate a section of the general data screen along with some of the data binding with the different models. We used one for the data, one for the field control and on for the dropdowns.

Below is a snapshot of the final result.

This blog covers only the technical aspect of the UI renovation. The development method we created can be used to convert any SAP business process and to bring it into the modern world. It can easily be adjusted to transform SAP GUI based transactions too.

More important than the technical part is the improvement of the business process as well. What does the user really need? Which functionality can be removed? Which process steps can be combined or de-coupled? For this part of the project we usually start with a design thinking workshop to exactly identify the end users requirements.

UI renovation allows SAP customers to fully leverage the investment into existing SAP modules and to reduce costs by optimizing the business process.