abap2UI5 – Development of UI5 Selection Screens in pure ABAP

Introduction

In new ABAP releases, SAP-GUI is no longer available, and one feature that I miss a lot is the classic selection screen. With just a few lines of ABAP, an application with GUI and event handling was automatically generated. Unfortunately, if_oo_adt_classrun cannot replace this functionality since it does not allow data transfer of inputs to the server, nor does it generate a browser-based app that can be used by end users.

So how we can bring the Selection Screen approach to the new (non-SAP-GUI) ABAP Environment?

One solution is this little open-source project called abap2UI5. With this project you can create standalone and ready to use UI5 applications in pure ABAP. No app deployment or JavaScript is needed. Data transfer and event handling in the backend is automatically integrated. It has the function scope of the former selection screen.

Example:

The entire functionality is based on a single HTTP handler. The frontend app is a generic one-page UI5 application, and the framework dynamically generates UI5-XML-Views and JSON-View-Models at runtime based on the ABAP implementation of the user.

Let’s start with a basic example:

First App

After installing the project with abapGit you will find the interface z2ui5_if_app in your system:

INTERFACE z2ui5_if_app PUBLIC.
  INTERFACES if_serializable_object.

  METHODS set_view
    IMPORTING
      view TYPE REF TO z2ui5_if_view.

  METHODS on_event
    IMPORTING
      client TYPE REF TO z2ui5_if_client.

ENDINTERFACE.

To develop a new abap2UI5 application, create a global ABAP class and implement the above interface. You can use the following code snippet as a template:

CLASS z2ui5_cl_app_demo_01 DEFINITION PUBLIC.

  PUBLIC SECTION.

    INTERFACES z2ui5_if_app.

    DATA product TYPE string.
    DATA quantity TYPE string.
    DATA check_initialized TYPE abap_bool.

ENDCLASS.

CLASS z2ui5_cl_app_demo_01 IMPLEMENTATION.

  METHOD z2ui5_if_app~on_event.

    "set initial values
    IF check_initialized = abap_false.
      check_initialized = abap_true.
      product = 'tomato'.
      quantity = '500'.
    ENDIF.

    "user event handling
    CASE client->event( )->get_id( ).

      WHEN 'BUTTON_POST'.
        "do something
        client->popup( )->message_toast( |{ product } { quantity } ST - GR successful| ).

    ENDCASE.

  ENDMETHOD.

  METHOD z2ui5_if_app~set_view.

    "define selection screen
    view->factory_selscreen_page( title = 'My ABAP Application - Z2UI5_CL_APP_DEMO_01'
        )->begin_of_block( 'Selection Screen Title'
            )->begin_of_group( 'Stock Information'
                )->label( 'Product'
                )->input( product
                )->label( 'Quantity'
                )->input( quantity
                )->button( text = 'Post Goods Receipt' on_press_id = 'BUTTON_POST' ).

  ENDMETHOD.
ENDCLASS.

There is nothing else left to do and your application is already ready to start now.

Simply call the HTTP interface z2ui5_http_cloud of the project in your browser. You can find the URL for this interface in the project’s package:

Replace the ‘app’ parameter in the URL with the name of your new ABAP class. The updated URL should look similar to this:

<your_system>:<port>/sap/bc/http/sap/z2ui5_http_cloud?app=<your_abap_class_name>

Next call it in your browser and your new app will be displayed:

This is just a small example, but it can be seen as a starting point. Feel free to modify the view and add your own custom logic to the controller as needed.

Data Transfer & Event Handling

We will now change the values on the frontend to “potato” and a quantity of 200:

Then we set a breakpoint in Eclipse and take a look at the backend system:

As you can see, the attributes of the class have been changed to “potato” and 200. This demonstrates that we have a working data transfer between the client and the backend. Additionally, the correct event was sent and the message toast is triggered in the backend and displayed in the frontend with the updated values:

Note that the attributes must be in the public section of the implemented class, as this enables the transfer of values between the frontend and the backend.

How does this work? Let’s take a closer look into the functionality.

Functional Background

The development of abap2UI5 is influenced by the following ideas:

• the if_oo_adt_classrun interface allows users to create an output by implementing just one interface, which is extremely efficient
• selection screens provide a full working UI with data transfer & event handling, just a few lines of code are needed. this makes it additionally very easy to copy code snippets between systems or projects providing a simple way to reuse functionality
• frontend development based on a single page application combined with asynchronous AJAX updates provide ways to develop frontend applications using only backend languages, which is reducing a lot of complexity (for example, check out this very nice blog post of Patrick VILLENEUVE)

By calling the abap2UI5 HTTP service, a generic one-page UI5 application is first sent to the client:

After that, every event triggers an AJAX round-trip between the server and the client. The updated values and event information are sent with the request to the backend. The response includes a new UI5-XML-View and a JSON-View-Model:

Server-> Client:

For example, the response of first view of the application at the beginning of this blog post looks like this:

JSON-Response

UI5-XML-View

Client -> Server:

And after changing the input, the request with the updated values and event information looks like this:

JSON Request

Persistence, stateful-like feeling:

The HTTP Interface is based on REST, meaning that there is no server session between two requests. Despite this, the implementation saves all class attributes since the abap2UI5 interface also implements the interface if_serializable_object. With every request, the object is saved to the database:

z2ui5_t_draft

The next request then re-creates the object with the saved attributes from the previous request. For example, this is why the check_initialized attribute is only false for the initial request, because it gets set to true during the first request and then saved in the database with the other attributes.

Detailed Example

A more detailed example of a selection screen looks like this:

Selection Screen Rendering in pure ABAP

And the controller looks like this:

abap2UI5 Controller

Summary

The goal of abap2UI5 is to offer a simple and efficient method of generating selection screens on the new non-SAP-GUI ABAP Releases. The user can create apps with minimal effort and without the need to learn new technologies and languages. Knowledge of ABAP and previous experience with selection screen logic is enough to use this project and develop applications.

Thank you for reading this blog post – what do you think of this approach?

Your questions, comments and wishes for this project are always welcome.