Skip to Content
Technical Articles
Author's profile photo Oblomov Dev

abap2UI5 – (1/3) Development of UI5 Apps in pure ABAP

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:

Repository on GitHub

News on Twitter

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.


  • 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

(1/3) Development of UI5 Apps in pure ABAP (this blog post) This blog post focuses on how we can use ABAP2UI5 to develop applications in general
(2/3) Lists, Tables, Toolbar and editable Examples to display lists and tables with an ABAP2UI5 application are explained here.
(3/3) Demo apps (coming soon) Some full working demo apps are introduced in this blog post.

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


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.


    INTERFACES z2ui5_if_app.

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


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'.

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

      "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' ) ).

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

  INTERFACES if_serializable_object.

  METHODS controller
      client TYPE REF TO z2ui5_if_client.


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

Development with abap2UI5


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:

UI5-Controller vs. abap2UI5-Controller
sap.ui.controller("", {

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


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.


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

UI5-View vs. abap2UI5-View
<Page title="Page title" showNavButton="true" navButtonTap="onEvent" >
	<f:SimpleForm title="Form Title">
			<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"/>
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.


There are two event methods possible at the moment.

Event (User-Command)

view->( )->button( 
     text = 'post' 
     press = client->_event( 'BUTTON_POST' ) ).
Most of the times it is enough to just send a simple user-command back to the server. For this you can use the method _event( )

Event Popup Close

     text  = 'close'
     press = client->_event_close_popup( ) ).
With this event you can close a popup at the frontend, we will take a more detailed look to popups in the third blog post of this series.

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  ).
Just put the value into the attribute, then abap2UI5 writes the value directly into the UI5-XML-View and sends it to the frontend


view->( )->label( 'product'
        )->input( value = _bind_one_way( product ) editable = abap_False ).
Abap2UI5 writes the value into the View Model and binds the View Model to the XML View. Helpful for deep data models like tables, we will take a look to this in the next blog post


view( )->label( 'quantity'
      )->input( value = view->_bind( quantity ) editable = abap_true ).​
Same as one-way-binding, but in addition the frontend values are send back to the server with every request. So make sure that the value you bind here are public attributes of your app that abap2UI5 can assign it and update the values from outside. This binding mode is useful for inputs or editable tables.

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.


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!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Shai Sinai
      Shai Sinai


      Author's profile photo Luis Frey
      Luis Frey

      Hi All.. nice Discussion?

      Why do they do that? Isnt it more easy to get JavaScript/TypeScript 😉 Developer, than SE80-ABAPers..

      Ore takes Chat GPT from here?

      Author's profile photo Shai Sinai
      Shai Sinai

      Well, to begin with, I don't see any Javascript developer writes logic in the ABAP backend.

      Author's profile photo Gabor Toldi
      Gabor Toldi

      There are several reasons  : One developer does all in a small application. Software creators can better use there ressources, there are better concepts than pure MVC, which is anyway broken with UI5. To support several UI Types, view shouldn't have to much logic..

      Author's profile photo Axel Mohnen
      Axel Mohnen

      Hi oblomov,

      Thanks a lot for that interesting blog series.

      One question: Is it possible to create a value help based on the binded field DDIC type?

      In you example I only see fixed value list.

      Thanks a lot.

      Kind regards


      Author's profile photo Oblomov Dev
      Oblomov Dev
      Blog Post Author

      Hi Axel,

      thanks for reading this blog post!

      The fixed value list is only an example. You can also call a function module or read database tables to get the allowed input values. When you want to use the values of an DDIC value help, you have to read this manually with abap and then send it instead of the fixed values to the frontend (there is no build in function for this like dynpros or seelction-screens have).





      Author's profile photo Axel Mohnen
      Axel Mohnen

      Hi Oblomov,

      thanks for the reply. I saw you new demo class "Z2UI5_CL_APP_DEMO_09" for the F4 custom popup. This was exactly what I was looking for!

      Another question:

      Are you able to run the ABAP2UI5 service embedded in the SAP Fiori Launchpad? I created a target mapping in the FLP customizing for external URL, but this runs the app in a separated window.

      Is there a way to run the app embedded in the FLP? Maybe having a generic SAPUI5 component with the ABAP2UI5 app ID.

      Thanks a lot.

      Kind regards


      Author's profile photo Oblomov Dev
      Oblomov Dev
      Blog Post Author

      Hi Axel,

      I never really tried to embed abap2UI5 in the FLP, but so far i know you can only embed UI5 applications which base on a component container, because the FLP replaces the index.html.

      Due to the fact that abap2UI5 is based on a single onepage index.html file it should not be possible to embed it in FLP. You can only use it with a separated window. But if you find out something else, let me know! Till now I did not do a lot of research in this direction.

      Kind regards!