This blog series introduces the abap2UI5 Project. It is an open source project which helps you develop standalone UI5 applications in pure ABAP. All project information can be found here:

General Idea

Abap2UI5 gives you a cloud/on-premise ready and non-sap-gui way to create UI5 apps in pure ABAP without using OData, Javascript, Annotations or RAP – just like in the “old days” when we just needed a few lines of ABAP code to display tables and inputs with the CL_GUI_ALV_GRID and the CL_GUI_CFW framework.

Features

• easy to use – implement just one interface for a standalone UI5 application
• pure ABAP – development in 100% ABAP source code (no JavaScript, EML, DDL or Customizing)
• small system footprint – based on a plain http handler (no OData, SEGW, BOPF, BSP, RAP or FE)
• cloud and on-premise ready – works with both language versions (ABAP for Cloud, Standard ABAP)
• easy installation – abapGit project, no additional app deployment needed

In addition abap2UI5 has a very high system compatibility, you can install abap2UI5 with abapGit on nearly every ABAP system:

Works with all available ABAP stacks and language versions

• BTP ABAP Environment (ABAP for Cloud)
• S/4 Public Cloud ABAP Environment (ABAP for Cloud)
• S/4 Private Cloud or On-Premise (ABAP for Cloud, Standard ABAP)
• R/3 NetWeaver AS ABAP 7.50 or higher (Standard ABAP)
• R/3 NetWeaver AS ABAP 7.02 to 7.42 (Standard ABAP) – use the low syntax branch

Blog Series

If you are interested in the technical background, take a look at this first blog post: abap2UI5 – Development of UI5 Selection Screens in pure ABAP

Demo

For a first impression of abap2UI5, take a look to this demo – everything is created in the backend in pure ABAP. No additional app deployment or javascript is needed:

A simple example application with an input and a message output looks like this:

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~controller.

    CASE client->get( )-lifecycle_method.

      WHEN client->cs-lifecycle_method-on_event.
       
        "set init values here...
        IF check_initialized = abap_false.
          check_initialized = abap_true.
          product  = 'tomato'.
          quantity = '500'.
          RETURN.
        ENDIF.

        "event handling here...
        CASE client->get( )-event.
          WHEN 'BUTTON_POST'.
            client->popup_message_toast( |{ product } { quantity } - send to the server| ).
        ENDCASE.

      "view rendering here...
      WHEN client->cs-lifecycle_method-on_rendering.
        client->factory_view( )->page( title = 'abap2UI5 - First Example'
            )->simple_form( 'Input'
                )->content( 'f'
                    )->title( 'Input'
                    )->label( 'quantity'
                    )->input( client->_bind( quantity )
                    )->label( 'product'
                    )->input(  value = product enabled = abap_false
                    )->button( text  = 'post'  press   = client->_event( 'BUTTON_POST' ) ).
    ENDCASE.
  ENDMETHOD.
ENDCLASS.

As you can see, the only thing you have to do to develop an UI5 app with abap2UI5 is to create a new class implementing the following interface:

INTERFACE z2ui5_if_app
  PUBLIC .

  INTERFACES if_serializable_object.

  METHODS controller
    IMPORTING
      client TYPE REF TO z2ui5_if_client.

ENDINTERFACE.

Let’s go through the development process step by step starting with the controller:

Development with abap2UI5

Controller

The interface Z2UI5_IF_APP provides the method “controller,” which gives you the control of the frontend UI5 app similar to a Javascript controller of an UI5 freestyle application. Therefore they look very similar:

sap.ui.controller("sap.ui.myApp.controller.one", {

	onInit: function() {
	},

	onBeforeRendering: function() {	 
	},

	onEvent: function() {
	//event handling here
	},

	onAfterRendering: function() {	
	},

	onExit: function() {
	}	
});

METHOD z2ui5_if_app~controller.

    CASE client->get( )-lifecycle_method.

      WHEN client->cs-lifecycle_method-on_event.
        "event handling here....

      WHEN client->cs-lifecycle_method-on_rendering.
        DATA(view) = client->factory_view( ).
        "view rendering here....

    ENDCASE.
ENDMETHOD.

The abap2UI5 controller has two lifecycle events. The path on_rendering is called after every server request when the view is rendered and the path on_event when an UI5 event is raised.

Of course when everything is handled in one method this is not the idea of clean code, but abap2UI5 does not want to make any requirements on how apps are structured. So this method is the basic layer and then every users can implement different methods on top of this by themselves. Maybe one for init, one for user_commands etc.

View

Abap2UI5 provides the possibility to develop UI5 Views similar to an UI5 freestyle application. The only difference is that views are not defined in XML, instead they are created with the Z2UI5_IF_VIEW interface. With this the user has complete freedom in structuring the view and also the flexibility to use a lot of different UI5 controls. Let’s take a look to the app form the beginning and compare the UI5 View with the abap2UI5 View:

Example View

<Page title="Page title" showNavButton="true" navButtonTap="onEvent" >
	<f:SimpleForm title="Form Title">
		<f:content>
			<Title text="Input" />
			<Label text="quantity"/>
			<Input editable="true" value="{/oUpdate/QUANTITY}"/>
			<Label text="product" />
			<Input value="tomato" />
			<Button press="onEvent" text="post" enabled="true"/>
		</f:content>
	</f:SimpleForm>
</Page>

view->page( title = 'Page title' )
        )->simple_form('Form Title'
          )->content( 'f'
             )->title( 'Input'
             )->label( 'quantity'
             )->input( client->_bind( quantity )
             )->label( 'product'
             )->input( value = product editable = abap_false
             )->button( text = 'post'   press   = client->_event( 'BUTTON_POST' ) ).

In the following blog posts of this series, we will extend the functionality of this view.

abap2UI5 Control Library

All available UI5 Controls can be found in the view interface (more will be added in the future):

Which UI5 controls are working with abap2UI5?

Only controls which do not depend on additional JavaScript logic are working. That means for example we can use the Input control, because it has just attributes, which abap2UI5 can send directly back to the server so we don not need any additional javascript for this. Most of the controls 70-80% work like this and we can use them with abap2UI5 out of the box.

Controls which need an additional JavaScript implementation like the Message Manager are not working out of the box. But there is the possibility to build a Custom Control around it and make it controllable by the server and with this a part of abap2UI5. We will see this in the last blog post, when we use a custom control to upload and download files.

Events

There are two event methods possible at the moment.

Event (User-Command)

view->( )->button( 
     text = 'post' 
     press = client->_event( 'BUTTON_POST' ) ).

Event Popup Close

view->button(
     text  = 'close'
     press = client->_event_close_popup( ) ).

If there is the need for more event functions, it is possible to extend abap2UI5 in the future.

Model (Data Binding)

There are three possibilities how abap2UI5 sends data to the frontend:

Direct XML

view( )->label( 'product'
      )->input( value = product editable = abap_false  ).

One-Way-Binding

view->( )->label( 'product'
        )->input( value = _bind_one_way( product ) editable = abap_False ).

Two-Way-Binding

view( )->label( 'quantity'
      )->input( value = view->_bind( quantity ) editable = abap_true ).​

So the user has to decide during the view definition how the data is send to the frontend and if it should be send back or not. To keep the request payload small it is recommended to use two-way-binding only if it is needed and values are changed at the frontend.

REST and Draft

Abap2UI5 is based on REST. No session exists between two HTTP requests. Therefore it is compatible to  mobile use cases and mobile devices. It is also compatible to “restful” environments like BTP ABAP Environment or the new language version ABAP Cloud.

Besides that after every request the actual state of the app is serialized and persisted to the database. The Z2UI5_IF_APP includes the interface IF_SERIALIZABLE_OBJECT, therefore it is possible to use attributes of the app instance between two requests and it feels like working with a stateful application like in a dynpro or selection-screen environment:

The persistence of abap2UI5 is called a draft table, although it is not completely the same as you know from RAP. The abap2UI5 drafts are not type specific, they just persist the app class in a generic way. Therefore there is no extra work in creating typed draft tables, everything works automatic in the background.

The drafts are very helpful for interim results, but maybe don’t exaggerate with this possibility. It is not a good idea to build endless chains of apps saving each other in attributes or try to save millions of entries in internal tables. But of course this is also not a good programming style in general.

Summary

That was the first part of the introduction to the ABAP2UI5 Project. Feel free to install this project and try out the examples and demos.

In the next blog post we will use ABAP2UI5 to send deep data models to the frontend and develop apps displaying lists and tables.

Feel free to install this project and try out the examples and demos. For news and improvements follow this project on Twitter or take a look to the GitHub repository.

Your comments, questions and wishes are welcome, create an issue or leave a comment.

Thanks for reading!