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

ABAP2UI5 – Development of UI5 Selection Screens in pure ABAP (no app deployment or javascript needed)


In ABAP Cloud there is no SAP GUI anymore and one thing i miss is a lot is the former selection screen. Just write a few lines of abap code and an application with gui and event handling is automatically generated. The IF_OO_ADT_CLASSRUN approach is no replacement, because you can not transfer any inputs and you also do not get a standalone UI5 app usable by an end user.

So how can we bring the selection screen approach to the new (non SAP GUI) ABAP Cloud environment?

One solution is this little abapgit project: abap2ui5 (abapGit) (Twitter)

With ABAP2UI5 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. At the moment it has the function scope of the former selection screen. Example:

The whole functionality is based on an a single http handler. The frontend app is a generic one page ui5 application and the framework generates dynamically at runtime UI5 XMLViews and JSON View Models based on the abap implementation of the customer.

Let’s start with a basic example:

First Start

Install the abap2ui5 project with abapGit first. After that you can find the Z2UI5_IF_APP interface in your system:

INTERFACE z2ui5_if_app PUBLIC.
  INTERFACES if_serializable_object.

  METHODS set_view
      view TYPE REF TO z2ui5_if_view.

  METHODS on_event
      client TYPE REF TO z2ui5_if_client.


Next create a new abap2ui5 application by creating a global abap class implementing the above interface. You can use the following code snippet:

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

    "set initial values
    IF check_initialized = abap_false.
      check_initialized = abap_true.

      product = 'tomato'.
      quantity = '500'.

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

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



  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'



As you can see, you defined the view and some controller logic in abap. So far there is nothing more to do. Your application is now ready to use.

To start the app, call the http interface Z2UI5_HTTP_CLOUD of the project in your browser. You can find the url in this package of the project:Change the url parameter app with the name of your new abap class, it looks similar to this:


When you are on an On-Premise system, you need to find the url by transaction SICF.

Next call the url in your browser and your new app is ready to use:

That is all you have to do! Now feel free to change the view and add your own custom logic to the controller.

Data Transfer & Event Handling

We now change the values on the frontend to potato and the quantity of 200:

Then we set a breakpoint in eclipse and take a look to the backend system:

As you can see the attributes of the class changed to potato and 200. So we got a working data transfer between client and backend and vice versa. Also the message toast is triggered in the backend and thrown in the frontend with the updated values:

Important: For the Value Transfer between frontend and backend, the attributes have to be in the public section of the implemented class.

So how does this work? Let‘s take a deeper look into the functionality.

Functional Background

The abap2ui5 approach is influenced by two general ideas:

First the IF_OO_ADT_CLASSRUN approach is very powerful. As a customer it is very comfortable that you just need to implement one interface. Also the 100% source code based approach makes it very easy to use and copy between systems and projects.

Second in the last year there was this very nice blog post (Thanks to Patrick VILLENEUVE ) about the idea of frontend developing based on a single page application combined with asynchronous ajax updates (“JSON over the wire”).

Abap2ui5 is influenced by this two ideas. The user only needs to implement one interface to develop a full working ui5 application and the frontend is kept as small as possible, so there is no specific app deployment or javascript needed. Everything is created in the backend during runtime.

Server-Client Communication:

By calling the abap2ui5 HTTP service, first a generic one page ui5 application is send to the client:

After that every event creates an ajax roundtrip between server and client. The updated values and the event information is send with the request to the backend. The response includes a new UI5 XML View+JSON View Model.


For example the response of the application in the beginning of the blog post looks like this:




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

Persistence, stateful-like feeling:

The HTTP Interface is based on REST, so there is no server session between two requests. Nevertheless the implementation holds all class attributes, because the abap2ui5 interface also implements the interface IF_SERIALIZABLE_OBJECT. With every request a UUID is created and the object is saved to the database:

The next request then recreates the object. For example, this is the reason why the check_initialized attribute is only false for the initial request.

Detailed Example

Now you can create more complex applications, there are a lot of controls still working to build your own selection screens. Take a look to the GitHub repository for a more detailed example. It can be implemented in abap like this:

And the controller looks like this:

Project Information

Project features:

  • easy to use – 100% source code based, just implement one abap interface for a standalone ui5 app
  • lightweight – based on a single http handler (no odata, no segw, no bsp, no rap, no cds), compatible to very old abap stacks
  • easy installation – abapgit project, no additional app deployment or javascript needed

Compatible with all availible abap stacks and language versions:

  • BTP ABAP Environment (Abap Cloud)
  • S/4 Public Cloud (Abap Cloud)
  • S/4 Private Cloud or On-Premise (Abap Cloud, Abap Standard)
  • R/3 NW 7.5 and downport to old releases possible (Abap Standard)


The goal of the abap2ui5 project is to create an easy and fast way to generate selection screens in the new abap cloud environment. Of course it is also working on an on-premise system. The customer has minimum effort to create apps and is not forced to learn new technologies and languages. The knowledge of abap and the former selection screen logic is enough to use this project and create ui5 applications.

On abapGit you find all information you need to use this project and for latest updates and news follow this project on Twitter.

So what do you think of this approach?

Next steps could be including more controls and extend the event handling.

Thanks for reading this blog post!

Assigned Tags

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

      Very interesting.

      Thanks for sharing.


      It seems it isn't compatible with NW 7.5. .e.g It uses the new class CL_ABAP_RANGE.

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

      Hi Shai,

      Thanks for reading and your comment! Technically it is portable to very old releases, because it is only using a plain http handler and some abap code, but i still need to replace the modern syntax and abap classes. I will fix this and replace cl_anap_range as soon as possible.


      Author's profile photo Matthew Billingham
      Matthew Billingham

      That class only a front end for the function modules





      Author's profile photo Marco Beier
      Marco Beier

      Powerful & Lightweight approach. There is so much one can do with ICF HTTP Handlers.

      Really appreciate that a technical part was included in this post, I love reading them.

      Author's profile photo Kai Sicker
      Kai Sicker

      I really like the approach. Kudos!

      I always asked myself in the context of S4 migration:
      What shall I do with the tons of legacy reports in my company that start with a selection screen, trigger some logic and give out a protocol generated with WRITE statements?
      RAP is great when you have underlying tables but if not it is not a solution (correct me if I'm wrong).

      I will definitely give this a try and if it works out it could remove one of the major impediments of migration from Dynpro to UI5.
      (Replacement for WRITE-based protocols would still be an issue but that's another topic)


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

      Hi Kai,

      Thanks for reading and your comment! Yes I think so too, with RAP you always need an underlying table and then you also have to handle all these DDIC artifacts etc.

      Including the write statement is a very good idea! Similar to the popups, i can add a write method and then at the frontend a new UI5 View is created with some sap.m.Text. The basic functionality should be not so complicated and I can try to add this soon. But of course including tables, icons and so on, is more effort.


      Author's profile photo Michael Keller
      Michael Keller

      Kai Sicker: Maybe custom entity and/or virtual fields and a lot of "good will" and work may help. I made a lot of very powerful tools for customers in SAP context with selection screen starting and then ALV or functions that are just executed from selection screen. That was cheap, fast and powerful. So I'm a big fan of backward compatibility to protect customer's already done investments.

      Oblomov Dev: Nice approach what I have seen so far. Thanks for sharing!

      Author's profile photo Petr Plenkov
      Petr Plenkov

      Hi! Great exercise. So it looks like some ABAP SSR concept is being applied here. Could you please share the use case and the problem you tried to solve ?

      I think what you’ve created is similar to ABAP web dynpro - stateful SSR written in ABAP

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

      Hi Petr,

      Thanks for reading and your comment!

      Use Case 1:

      I use if_oo_adt_classrun a lot for testing. I like the easy and lightweight approach, just implement one interface to create outputs is a very good service. This pure abap code based approach makes it also very easy to copy and collect code snippets etc. But unfortunately you have no chance to send input values to the server with if_oo_adt_classrun. So this approach could be one solution to solve this.

      Use Case 2:

      I miss the selection screen in the abap cloud environment. Of course you can use RAP, but for a simple selection screens you have a much higher effort with RAP compared with the selection screen in the past. This approach is very similar to the former selection screen syntax and logic and could also be helpful for colleagues who are not so familiar with all the new abap cloud stuff in the beginning 😉

      Dynpro / Web Dynpro

      Yes similar to the selection screen, there is also no dynpro or web dynpro in the cloud anymore. So far i only focused on the selection screen functionality, but adding more features and including more UI5 Controls and Events is possible. So this project and approach could also handle a lot more features similar to dynpro or web dynpro in the future.


      Author's profile photo Rodrigo Giner de la Vega
      Rodrigo Giner de la Vega

      Dude, this is awesome !!!

      This is what SAP should had aimed all along. The stament that they created ABAP cloud/SAP so any ABAPer could leverage they knowledge for easy transition to the cloud is nonsense, The only thing that are shared is "syntax" and not even, because all the new syntax introduced and you can't use 95% of the ABAP workbench.

      SAP UI5 is awful, just like Webdynpro was awfull and CRM UI was horrendous. BSP was cool and shocking when you deploy a UI5 app is deployed as a BSP app. -__-

      For any customer that want to stick to on-premise deployment this would be great.

      I'm cheering for you !!! keep the good work.


      Author's profile photo Tomas Buryanek
      Tomas Buryanek

      SAP UI5 is awful, just like Webdynpro was awfull...

      Nice to see I am not alone thinking this 🙂

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer

      I'd like to hear more on why "SAP UI5 is awful". Would you mind sharing?

      Author's profile photo Gabor Farkas
      Gabor Farkas

      This is a great concept, I like the idea of replicating the declarative and easy form of selection screens.

      Maybe it would also be worth looking into creating a purely frontend equivalent where you can use a simplified language to describe screens and it would build the UI5 view automatically.

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

      Hi Gabor,

      yes, great idea! I already experimented with defining and persist ui5 abap views in the backend at design time, similar to the good old-fashioned screen painter. Then at runtime this views could be modified to real ui5 views based on the implemented class and send together with a matching view model to the frontend. That gives the user more freedom in the selection of ui5 controls and how the view is structured. I can give this a try when i finished the current changes.


      Author's profile photo Marc Bernard
      Marc Bernard

      Don't persist anything. That makes things more complicated (like transporting). Keep it 100% code. That's the beauty of this approach.

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer

      We already have it: Fiori Elements

      For example, you can use local annotations (frontend only) or CDS View Annotations (backend only), no js code required.

      Author's profile photo Gabor Farkas
      Gabor Farkas

      Yeah that's a fair point, Fiori Elements is kind of a similar concept and it's indeed very powerful.

      Author's profile photo Felipe Silva
      Felipe Silva

      This is really great! I see it as a bridge for those old z developments to the "new world". Curious to try it out and make it work in non cloud scenarios.


      Author's profile photo Christian Crusan
      Christian Crusan

      Nice work! If you now add a support for display  table content like ALV (not necessary with all the features, just the header and rows) this would make it even more useful.

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

      Yes, something similar to the classic ALV Fullscreen output with a rudimentary fcat should be possible. I will take a look on it.

      Author's profile photo Bruno Santana
      Bruno Santana



      I'm tryng create my tests here but I'm facing with one error during my pull from git.


      error from DDIF_TABL_PUTImport of object Z2UI5_T_001 failed

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

      Are you using an on-premise system or cloud? which version is your system?

      Author's profile photo Bruno Santana
      Bruno Santana


      S4 2020