SAP Community - SAP R/3

abap2UI5 - (1) Introduction: Developing UI5 Apps Purely in ABAP

2023-02-23T00:15:11+01:00

Welcome to the first part of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

This first post offers an overview of the project. It highlights its features, presents demonstrations, and provides a step-by-step guide to the development process.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and explore the other articles in this blog series:

Introduction: Developing UI5 Apps Purely in ABAP (this blog post)
Displaying Selection Screens & Tables
Popups, F4-Help, Messages & Controller Logic
Advanced Functionality & Demonstrations
Creating UIs with XML Views, HTML, CSS & JavaScript
Installation, Configuration & Troubleshooting
Technical Background: Under the Hood of abap2UI5
Repository Organization: Working with abapGit, abaplint & open-abap
Update I: Community Feedback & New Features - Sep. 2023
Extensions I: Exploring External Libraries & Native Device Capabilities
Extensions II: Guideline for Developing New Features in JavaScript
Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Project Information
1. Features
2. Demos
3. Basic Example
Development Process
1. View
2. Controller
3. Event
4. Model & Data Binding
What's next?
Conclusion

Let’s begin with the first topic.

1. Project Information

This project offers a pure ABAP approach for developing UI5 apps, entirely without JavaScript, OData and RAP — similar to the past, when only a few lines of ABAP sufficed to display input forms and tables using Selection Screens & ALVs. Designed with a minimal system footprint, it works in both on-premise and cloud environments.

1.1 Features, Compatibility & Installation

100% ABAP: Developing purely in ABAP (no JavaScript, DDL, EML or Customizing)
User-Friendly: Implement just a single interface for a standalone UI5 application
Minimal System Footprint: Based on a plain HTTP handler (no BSP, OData, CDS, BOPF or RAP)
Cloud and On-Premise Ready: Works with both language versions (ABAP for Cloud, Standard ABAP)
Broad System Compatibility: Runs on all ABAP releases (from NW 7.02 to ABAP Cloud Stacks)
Easy Installation: abapGit project, no additional app deployment required

Use abapGit for installation, pull the repository, create a new HTTP service and call abap2UI5. Detailed information can be found in part 6 of this series. This project is compatible with all ABAP releases 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 this downport repository

1.2 Demos

For an impression of the possibilities of abap2UI5, take a look at the demos presented in this blog series — everything is developed in pure ABAP:


Selection Screens (Blog 2)	Tables, Lists & Maintenance (Blog 2)

Popups & F4-Helps (Blog 3)	File Editor, File Upload & Visualization (Blog 4)

But first let's start with a basic example.

1.3 Basic Example

A simple abap2UI5 app with an input and a message output looks like this:

CLASS z2ui5_cl_app_hello_world DEFINITION PUBLIC.

  PUBLIC SECTION.
    INTERFACES z2ui5_if_app.
    DATA quantity TYPE string.

ENDCLASS.

CLASS z2ui5_cl_app_hello_world IMPLEMENTATION.
  METHOD z2ui5_if_app~main.

    CASE client->get( )-event.
      WHEN 'BUTTON_POST'.
        client->message_toast_display( |{ quantity } Product ABC - send to the server| ).

    ENDCASE.

    client->view_display( z2ui5_cl_xml_view=>factory(
      )->page( 'abap2UI5 - Hello World App'
         )->simple_form( )->content( ns = `form`
            )->title( 'Input here and send it to the server...'
            )->label( 'Product-ABC'
            )->input( client->_bind_edit( quantity )
            )->button( text = 'post' press = client->_event( 'BUTTON_POST' )
      )->stringify( ) ).

  ENDMETHOD.
ENDCLASS.

As you can see, to develop an UI5 app with abap2UI5, simply create a new class and implement the method main of the following interface:

INTERFACE z2ui5_if_app PUBLIC.

  METHODS main
    IMPORTING
      client TYPE REF TO z2ui5_if_client.

ENDINTERFACE.

The output of this app looks like this:

abap2UI5 - Basic Example

Everything functions seamlessly out-of-the-box, offering bidirectional data transfer, event handling, and a user interface

2. Development Process

Let's walk through the development process step-by-step, beginning with the view, then progressing to the controller, and finally, we'll examine the model.

2.1 View

Abap2UI5 provides the possibility to develop UI5 Views similar to an UI5 freestyle application. You have complete freedom in structuring the view and the flexibility to use a wide range of UI5 controls. The view can be defined either directly as a string or crafted using the class z2ui5_cl_xml_view. Let's examine the app mentioned earlier and compare its UI5-View with its abap2UI5 counterpart:

UI5-View vs. abap2UI5-View

<Page title="Page title" >

	<f:SimpleForm title="Form Title">

		<f:content>

			<Title text="Input" />

			<Label text="quantity"/>

			<Input value="{/oUpdate/QUANTITY}"/>

			<Label text="product" />

			<Input value="tomato" />

			<Button press="onEvent" text="post"/>

		</f:content>

	</f:SimpleForm>

</Page>

view->page( title = 'Page title' )

        )->simple_form( 'Form Title'

          )->content( 'f'

             )->title( 'Input'

             )->label( 'quantity'

             )->input( client->_bind_edit( quantity )

             )->label( 'product'

             )->input( value = product editable = abap_false

             )->button( text  = 'post'  

                        press = client->_event( 'BUTTON_POST' ) ).

In abap2UI5, the XML-View is generated in ABAP and the class serves as a helper to simplify the creation of XML. However, ultimately, both approaches yield the same result, with the key difference being that in abap2UI5, the view is transmitted from the backend.

This is just a simple example and in the following blog posts, we will expand its functionality to include tables, lists, selection screens, charts and more.

abap2UI5 Control Library

Here is a selection of available UI5 controls that you can utilize with the class z2ui5_cl_xml_view:

z2ui5_cl_xml_view

More controls will be added in the future – check out the source code. Additionally in part five of this series, other view creation approaches with increased flexibility will be explained.

Most UI5 controls are compatible with abap2UI5 without requiring any additional adjustments. For example, Inputs can be used since it only consists of attributes that can be directly sent back to the server. Controls that rely on additional JavaScript logic need to be modified to work with abap2UI5. They have to be encapsulated in a custom control first.

We will see an example for this in part four of this blog series, where we will use a custom control for uploading and downloading files and check also out part 11 to learn how to implement your own custom control in abap2UI5.

2.2 Controller

The interface z2ui5_if_app consists of the method 'main', which gives you control over the frontend UI5 app, similar to the JavaScript controller of a UI5 freestyle application. Consequently, they look similar:

UI5-Controller vs. abap2UI5-Controller

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



	onInit: function() {

	},



	onBeforeRendering: function() {	 

	},



	onEvent: function() {

	},



	onAfterRendering: function() {	

	},



	onExit: function() {

	}	

});

  METHOD z2ui5_if_app~main.



    IF check_initialized = abap_false.

      check_initialized = abap_true.

      "set init values here...

    ENDIF.



    CASE client->get( )-event.

      WHEN 'POST'.

        "event handling here...

    ENDCASE.



    "view rendering here...

    client->view_display( z2ui5_cl_xml_view=>factory(

        )->shell( )->page(  )->simple_form( 'Title'

    "....



  ENDMETHOD.

The abap2UI5 framework redirects event handling from the frontend controller to the backend implementation of your class, granting you complete freedom in the backend to determine how to respond to specific frontend events.

A single 'main' method is used for this purpose (similar to what if_oo_adt_classrun does), without segregating the view and controller. This approach creates flexibility and enable the user to structure their apps according to their preferences. Therefore, this method acts merely as a foundational layer, on top of which users can build their own logic through distinct methods. For example, one might have a method for initialization, another for handling user commands, and so on.

Next, let's examine how events can be triggered on the frontend.

2.3 Events

The following events are available:

Event (User-Command)

view->( )->button( 

     text  = 'post' 

     press = client->_event( 'BUTTON_POST' ) ).

Usually it's enough to just send a simple user-command back to the server -- use the method _event

Event (Popup Close)

view->button(

     text  = 'close'

     press = client->_event_client( client->cs_event-popup_close ) ).

You can close a popup at the frontend with this event -- we will take a more detailed look at popups in the third blog post of this series

If more event functions are necessary, the framework can be extended in the future.

2.4 Model & Data Binding

When values need to be displayed in the frontend, define them as public attributes in your abap2UI5 app. These attributes will be bound by the framework, so it needs to have a chance to assign them from the outside. Additionally, if your values will also be updated in the frontend, make sure that they are not defined as read-only, otherwise, abap2UI5 will throw an error when attempting to modify them. There are three ways to bind data and sent it to the frontend:

Direct XML

view( )->label( 'product'

      )->input( value = product editable = abap_false ).

You can write the value into the attribute, abap2UI5 will then write it directly into the UI5-XML-View and sent it to the frontend.

Bind Local

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

You can bind the values locally, which your can use for local variables which are not public attributes of your class. Their value is saved right at the moment. Use cases for example are tables with contents for value helps.

One-Way-Binding

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

You can use one-way-binding, the values are then written into the view model and bound to the UI5-XML-View. This is useful for complex data models such as tables. We will see this in more detail in the next blog post.

Two-Way-Binding

view( )->label( 'quantity'

      )->input( value = view->_bind_edit( quantity ) editable = abap_true ).

You can use two-way-binding, it is similar to one-way binding, but it also sends values from the frontend to the server. This binding mode is useful for inputs and editable tables.

When defining the view, consider the data transfer to the frontend. To keep the request payload small use one-way-binding by default and two-way-binding only when necessary, such as when values need to be updated from the frontend. Besides that, abap2UI5 takes care of the rest by transforming the data into JSON, sending it to the frontend, and bringing back the updated values, as we'll see in part 7 of this series.

3. What's next?

Now you got a basic understanding of the functionality of this project. However, this was merely an overview. abap2UI5 is continuously evolving, and more blog posts are being written. If you wish to delve deeper into specific topics, explore the other blog posts next. Additionally, take a look to all the features of abap2UI5 by visiting the samples repository, which is also regularly updated with new features:

Samples of abap2UI5 (As of August 2023)

4. Conclusion

This was the first part of the introduction to abap2UI5. You now have an understanding of how to develop apps and its general functionality. While this post was quite technical, the upcoming parts of this blog series will showcase more demos & use cases and we will continuously add more features.

In the next part, we will develop abap2UI5 apps displaying tables and selection screens.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, leave a comment or create an issue.

abap2UI5 - (2) Displaying Selection Screens & Tables

2023-02-23T00:26:21+01:00

Welcome to the second part of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

In this post, we're focusing on selection screens and displaying tables. We'll enhance these features by adding a toolbar, various selection modes, and edit functionality.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and be sure to explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables (this blog post)

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Displaying Tables
1. Fieldcatalog
2. Toolbar
3. Selection Modes
4. Editable

Selection Screens

Conclusion

Before we begin let's look at this demo showcasing tables and lists to get an impression of what is possible with abap2UI5 – everything is created purely in ABAP in the backend.

Demo of Tables & Lists in abap2UI5

1. Displaying Tables

Let's start by examining the classic SAP-GUI method for displaying tables in ABAP:

TYPES: 

   BEGIN OF ty_s_flight,

       carrid TYPE s_carr_id,

       connid TYPE s_conn_id,

       fldate TYPE s_date,

       price TYPE s_price,

   END OF ty_s_flight.

DATA gt_flight TYPE STANDARD TABLE OF t_flight.



SELECT carrid connid fldate price FROM sflight INTO TABLE gt_flight.



DATA gr_flight TYPE REF TO cl_gui_alv_grid.

CREATE OBJECT gr_flight

  EXPORTING

    i_parent = cl_gui_container=>screen0.



gr_flight->set_table_for_first_display(

  EXPORTING

    i_structure_name = 'TY_S_FLIGHT'

  CHANGING

    it_outtab = gt_flight ).

Displaying a view with table output in ABAP takes only about 25 lines, making it an efficient process. With just a few extra lines, you can add buttons, toolbars, and interactions.

However, creating this result in a non-SAP-GUI or ABAP Cloud Environment requires either RAP or the development of UI5 freestyle applications. The first way requires CDS artifacts and the second one needs JavaScript knowledge. In both approaches you can not use 100% ABAP source code anymore which makes it considerably more complex.

In contrast, abap2UI5 aims to return to the classic SAP GUI approach. The code for the example above in abap2UI5 is as follows:

CLASS z2ui5_cl_app_demo_43 DEFINITION PUBLIC.



  PUBLIC SECTION.



    INTERFACES z2ui5_if_app.



    TYPES:

      BEGIN OF t_flight,

        carrid TYPE string,

        connid TYPE string,

        fldate TYPE string,

        price  TYPE string,

      END OF t_flight.

    DATA: mt_flight TYPE STANDARD TABLE OF t_flight.



ENDCLASS.



CLASS z2ui5_cl_app_demo_43 IMPLEMENTATION.



  METHOD z2ui5_if_app~main.



    SELECT carrid connid fldate price FROM sflight INTO TABLE mt_flight.



    DATA(page) = z2ui5_cl_xml_view=>factory( )->page(

            )->scroll_container( height = '70%' vertical = abap_true

                )->table( items = client->_bind( mt_flight )

                )->columns(

                    )->column( )->text( 'Carrid' )->get_parent(

                    )->column( )->text( 'Connid' )->get_parent(

                    )->column( )->text( 'Fldate' )->get_parent(

                    )->column( )->text( 'Price'  )->get_parent(

                )->get_parent(

                )->items( )->column_list_item( )->cells(

                    )->text( '{CARRID}'

                    )->text( '{CONNID}'

                    )->text( '{FLDATE}'

                    )->text( '{PRICE}' ).



    client->view_display( page->stringify( ) ).



  ENDMETHOD.

ENDCLASS.

As you can see, with just a few additional lines compared to the classic approach, we can create a standalone UI5 application displaying tables (and now it's also ABAP OO 😉). We set the content of the table with the class z2ui5_cl_xml_view as follows:

page->scroll_container( height = '70%' vertical = abap_true

       )->table( items = view->_bind( t_tab ) ).

Unlike Labels and Texts shown in the previous blog post, we can't directly write the value of the attribute into the XML for a table, as a table has a deep data model. Instead, we use one-way binding with the method '_bind'. The content of the table is then automatically transformed into JSON and sent to the frontend as part of the UI5-View-Model.

1.1. Fieldcatalog

In classic ABAP, column definition was done using the fieldcatalog. In abap2UI5, we define it with the view class as well:

         )->columns(

             )->column( )->text( 'Carrid' )->get_parent(

             )->column( )->text( 'Connid' )->get_parent(

             )->column( )->text( 'Fldate' )->get_parent(

             )->column( )->text( 'Price'  )->get_parent(

         )->get_parent(

             )->items( )->column_list_item( )->cells(

                )->text( '{CARRID}'

                )->text( '{CONNID}'

                )->text( '{FLDATE}'

                )->text( '{PRICE}' ).

There are many customization options for column outputs, similar to the classic fieldcatalog, such as choosing a checkbox instead of a normal text output, changing the title or adding hotspots. The full source code of this example can be found here.

In this example, column definition is set manually, but automatic definition using RTTS is also possible, similar to 'cl_salv_table' We'll explore this in part four of this blog series, where we develop a table maintenance app. Next, let's extend the table output with a toolbar.

1.2 Toolbar

Here’s what a demo app of a table with toolbar looks like:

Toolbar in abap2UI5

The view definition is similar to the first example, with the table header extended:

tab->header_toolbar( )->overflow_toolbar(

                )->title( 'title of the table'

                )->button(

                    text  = 'left side button'

                    icon  = 'sap-icon://account'

                    press = client->_event( 'BUTTON_SORT' )

                )->segmented_button( selected_key = mv_key

                    )->items(

                        )->segmented_button_item(

                            key = 'BLUE'

                            icon = 'sap-icon://accept'

                            text = 'blue'

                        )->segmented_button_item(

                            key = 'GREEN'

                            icon = 'sap-icon://add-favorite'

                            text = 'green'

                )->get_parent( )->get_parent(

                )->toolbar_spacer(

                )->generic_tag(

                        text           = 'Project Cost'

                        design         = 'StatusIconHidden'

                        status         = 'Error'

                    )->object_number(

                        state      = 'Error'

                        emphasized = 'false'

                        number     = '3.5M'

                        unit       = 'EUR'

                )->get_parent(

                )->toolbar_spacer(

                )->button(

                    text  = 'Sort'

                    icon = 'sap-icon://sort-descending'

                    press = client->_event( 'BUTTON_SORT' )

                )->button(

                    icon  = 'sap-icon://edit'

                    press = client->_event( 'BUTTON_POST' ) ).

The full source code of this example can be found here. Next we will add different selection modes.

1.3. Selection Modes

There are four selection modes available: (1) SingleSelect, (2) SingleSelectLeft, (3) SingleSelectMaster and (4) MultiSelect. Here’s a preview of the selection modes in action:

Selection Modes in abap2UI5

The selection mode is set in the beginning of the table definition:

 page->table(

     mode  = 'SingleSelectLeft'

     items = client->_bind_edit( t_tab ) ).

In addition, we define the column that saves the information of the selected rows. Similarly to the classic fieldcatalog, we define a column which will be automatically updated with the selected rows. We set the column with the name 'selkz' (more modern names are also possible 😉) as the 'selected' attribute for the column list item:

tab->items( 

    )->column_list_item( selected = '{SELKZ}'

        )->cells(

            ...

You can find the full source code of this example here. Now we will make the table editable.

1.4. Editable

Look at this example of an editable table in abap2UI5:

Editable Tables in abap2UI5

The code is similar to the previous example, but the column definition differs. Every time the editable function is activated, input controls are used instead of text controls:

 IF check_editable_active = abap_true.



      tab->items( )->column_list_item( )->cells(

              )->input( '{TITLE}'

              )->input( '{VALUE}'

              )->input( '{INFO}'

              )->input( '{DESCR}'

              )->checkbox( selected = '{CHECKBOX}' enabled = abap_true ).

 ELSE.

      tab->items( )->column_list_item( )->cells(

             )->text( '{TITLE}'

             )->text( '{VALUE}'

             )->text( '{INFO}'

             )->text( '{DESCR}'

             )->checkbox( '{CHECKBOX}' ).

ENDIF.

Furthermore, we need to ensure that abap2UI5 sends the updated values back to the server. Therefore, we have to change the type of the data binding from one-way to two-way binding:

DATA(tab) = page->table( items = view->_bind_edit( t_tab ) ).

Now, with every request, the changed table data is sent back to the server. The full source code of this example can be found here.

Up until now, we have implemented many of the basic features found in cl_gui_alv_grid and cl_salv_table for our table output. There are still many more functionalities to explore, as we will see in the next blog posts. But before that, let's move on to the last part of this post and take a look at selection screens -- an important aspect of ABAP development that enables us to obtain selection criteria for database queries.

2. Selection Screens

We start again with a demo:

Selection Screen - Example in abap2UI5

This is the source code of the above view:

view->page( 'abap2UI5 - Selection-Screen'

    )->simple_form('Input' )->content( 'f'

        )->label( 'Input with value help'

        )->input(

            value       = view->_bind( screen-colour )

            placeholder = 'fill in your favorite colour'

            suggestion_items = view->_bind_one_way( mt_suggestion ) )->get(

            )->suggestion_items( )->get(

                )->list_item( text = '{VALUE}' additional_text = '{DESCR}' 

        )->get_parent( )->get_parent(



        )->label( 'Date'

        )->date_picker( view->_bind( screen-date )



        )->label( 'Date and Time'

        )->date_time_picker( view->_bind( screen-date_time )



        )->label( 'Time Begin/End'

        )->time_picker( view->_bind( screen-time_start )

        )->time_picker( view->_bind( screen-time_end ) ).



        )->label( 'Checkbox'

        )->checkbox(

           selected = view->_bind( screen-check_is_active )

           text     = 'this is a checkbox'

           enabled  = abap_true



       )->label( 'Combobox'

       )->combobox(

           selectedkey = view->_bind( screen-combo_key )

           items      = view->_bind_one_way( VALUE ty_t_combo(

              ( key = 'BLUE'  text = 'green' )

              ( key = 'GREEN' text = 'blue'  )

              ( key = 'BLACK' text = 'red'   )

              ( key = 'GRAY'  text = 'gray'  ) )

           ) )->get( )->item( key = '{KEY}' text = '{TEXT}'

        )->get_parent( )->get_parent(



      )->label( 'Segmented Button'

      )->segmented_button( view->_bind( screen-segment_key ) )->get(

        )->items( )->get(

             )->segmented_button_item( key = 'BLUE'  icon = 'sap-icon://accept'       text = 'blue'

             )->segmented_button_item( key = 'GREEN' icon = 'sap-icon://add-favorite' text = 'green'

             )->segmented_button_item( key = 'BLACK' icon = 'sap-icon://attachment'   text = 'black'

       )->get_parent( )->get_parent(



      )->label( 'Switch disabled'

      )->switch( enabled = abap_false    customtexton = 'A' customtextoff = 'B'

      )->label( 'Switch accept/reject'

      )->switch( state = screen-check_switch_01 customtexton = 'on'  customtextoff = 'off' type = 'AcceptReject'

      )->label( 'Switch normal'

      )->switch( state = screen-check_switch_02 customtexton = 'YES' customtextoff = 'NO' ).

This looks very technical, but this level of complexity was also present in classic selection screens. The class z2ui5_cl_xml_view provides only the technical rendering layer upon which users can build their own more user-friendly functions. You can find the full source code of the above example here.

And an other demonstration is here:

Selection Screen - More Controls

3. Conclusion

This concludes the second part of our introduction to abap2UI5. We've seen that abap2UI5 strives to mimic the classic ABAP way of developing apps for displaying tables and selection screens. We can also easily add toolbars, utilize selection modes, and make tables editable.

In the next part, we will build upon this by focusing on the controller logic, displaying messages and creating popups & F4-Helps.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, create an issue or leave a comment.

abap2UI5 – (3) Popups, F4-Help, Messages & Controller Logic

2023-03-30T18:03:26+02:00

Welcome to the third part of this blog series introducing abap2UI5 -- an open-source project for developing UI5 apps purely in ABAP.

In this post we'll focuses on the controller logic, showcasing how different apps can call each other and exchange data. Additionally, we'll delve into message output and the development of popups, which we'll use to to create F4-Helps.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and be sure to explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic (this blog post)

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Controller Logic

Popups

Popover

F4-Help

Messages

Conclusion

Let’s begin with the first topic.

1. Controller Logic

In abap2UI5, apps can easily call each other and transfer data, reminiscent of the function modules used to call screens of other function groups in the past. Take a look at this demo demonstrating two apps calling each other and exchanging values:

Controller Logic in abap2UI5

To call a new app, create the app instance and call it with the method 'nav_app_call':

client->nav_app_call( NEW z2ui5_cl_app_demo_25( ) ).

Initial values can be set by changing the attributes of the class before calling it:

DATA(lo_app_next) = NEW z2ui5_cl_app_demo_25( ).

lo_app_next->mv_input_previous = mv_input.

client->nav_app_call( lo_app_next ).

You can also recreate the previous app and read its attributes:

DATA(lo_called_app) = CAST z2ui5_cl_app_demo_25( client->get_app_by_id( client->get( )-id_prev_app ) ).

client->message_box_display( `Input of the previous app:` && lo_called_app->mv_input ).

For a 'Back' or 'Exit' command, you can also call an already existing app again:

data(lo_prev_stack_app) = client->get_app( client->get( )-id_prev_app_stack ).

client->nav_app_leave( lo_prev_stack_app ).

The difference between 'nav_app_leave' and 'nav_app_call' is that the former reduces the call stack, while the latter increases it. This is similar to the 'call screen' and 'leave screen' commands in the SAP GUI screen logic. Therefore, you need to consider two IDs:

id_prev_app_stack - the ID of the calling application

id_prev_app - the ID of the previously used app (ignoring the call stack)

The draft table working in the background makes the flow logic very simple, but select the appropriate ID and method carefully to avoid unexpected behavior. The source code for this example can be found here. Next, we'll use this logic to display popups.

2. Popups

The view of a popup is defined just like a normal view, offering a wide range of possibilities. Here's a demo:

Popups in abap2UI5

The full source code of this example can be found here. To define a popup, start the view definition with a dialog control. For instance, a former 'Popup_to_decide' FM developed with abap2UI5 might look like this:

lv_popup_xml = z2ui5_cl_xml_view=>factory_popup(

        )->dialog(

                title = 'Title'

                icon = 'sap-icon://question-mark'

            )->content(

                )->vbox( 'sapUiMediumMargin'

                    )->text( 'This is a question, cancel or confirm?'

            )->get_parent( )->get_parent(

            )->footer( )->overflow_toolbar(

                )->toolbar_spacer(

                )->button(

                    text  = 'Cancel'

                    press = client->_event( 'BUTTON_CANCEL' )

                )->button(

                    text  = 'Confirm'

                    press = client->_event( 'BUTTON_CONFIRM' )

                    type  = 'Emphasized' ).

To display this view as a popup, set the content in the variable 'xml_popup':

client->popup_display( lv_popup_xml ).

You can also show the main view in the background by filling both xml variables:

client->view_display( lv_main_xml ).

client->popup_display( lv_popup_xml ).

Popups can also be closed without additional server roundtrips, use the method _event_client:

client->_event_client( client->cs_event-popup_close ).

The simple popup to inform is a good use case for this:

lo_popup->dialog( 'Popup - Info'

          )->vbox(

               )->text( 'press close to go back to the main view without a server roundtrip'

          )->get_parent(

          )->footer( )->overflow_toolbar(

               )->toolbar_spacer(

               )->button(

                   text  = 'close'

                   press = client->_event_close_popup( )

                   type  = 'Emphasized' ).

Here's a demo showing the code snippet in action:

Popups and Flow Logic in abap2UI5

You can find the source code for this demo here.

3. Popover

For situations where you don't want to block the entire screen, a popover is useful. To display a popover, define the view with the popover control instead of the dialog control, and specify the placement and ID of the control for display:

Popover with abap2UI5

Set the ID of the popover placement using the following parameter:

client->popover_display( xml = xml_popover by_id = 'TEST' ).

The rendering of the popover is as follows:

xml_popover = z2ui5_cl_xml_view=>factory_popup( )->popover(

             title     = 'Popover Title'

             placement = mv_placement

        )->footer( )->overflow_toolbar(

             )->toolbar_spacer(

             )->button(

                text  = 'Cancel'

                press = client->_event( 'BUTTON_CANCEL' )

             )->button(

                text  = 'Confirm'

                press = client->_event( 'BUTTON_CONFIRM' )

                type  = 'Emphasized'

             )->get_parent( )->get_parent(

             )->text(  'make an input here:'

             )->input( value = 'abcd'

       )->get_root( )->xml_get( ).

You can find the source code for this demo here. Popovers are particularly useful in conjunction with tables to display additional information for certain cells, as shown in this example:

Popover on cell level

Next, let's use popups to create F4-Helps.

4. F4-Help

F4-Helps can be created in various ways. Check out this demo:

Demo F4-Help

The source code is available here. F4-Helps in abap2UI5 are simply normal popups. For instance, a popup to choose a table entry can be defined like this:

z2ui5_cl_xml_view=>factory( 

      )->dialog( 'abap2UI5 - F4 Value Help'

      )->table( mode = 'SingleSelectLeft' items = client->_bind( mt_suggestion_sel )

          )->columns(

              )->column( )->text( 'Color' )->get_parent(

              )->column( )->text( 'Description'

          )->get_parent( )->get_parent(

          )->items( )->column_list_item( selected = '{SELKZ}' )->cells(

              )->text( '{VALUE}'

              )->text( '{DESCR}'

      )->get_parent( )->get_parent( )->get_parent( )->get_parent(

      )->footer( )->overflow_toolbar(

          )->toolbar_spacer(

          )->button(

              text  = 'continue'

              press = client->_event( 'POPUP_TABLE_F4_CONTINUE' )

              type  = 'Emphasized' ).

Or you can also create popups to fill select options, as shown here:

Select Options in abap2UI5

There's complete freedom in developing F4-Helps—they can range from simple to complex as needed.

5. Messages

Messages can be displayed in various ways. The simplest method is a message toast:

 client->message_toast_display( 'this is a message toast' ).

Alternatively, use a message box:

 client->message_box_display( 'this is a message box' ).

 client->message_box_display( text = 'this is a message box' type = 'error' ).

The message strip can be integrated into the view:

page->message_strip( text = 'This is a Message Strip' type = strip_type ).

Here's a demo of these three message types:

Message Strip, Box and Toast

The source code is availible here.

In situations where errors occur, it may be necessary to display a message that covers the entire page. An illustrated message can be a good solution for this purpose, and you can use it with the following syntax:

page->illustrated_message( illustrationtype = 'NoEntries'

    )->additional_content(  )->button(

       text  = 'information'

       press = client->_event( 'BUTTON_MESSAGE_BOX' ) ).

A lot of different illustration types are available, as you can see in this documentation. A demo of the illustrated message looks like this:

Illustrated Message with abap2UI5

You can see the demo source code here. The last option to display messages is the Message View. It is useful for T100, BAPIRET or other logging tables. You can display it on the page or as a popover using this code:

popup->message_view(

         items      = client->_bind( t_msg )

         groupitems = abap_true

    )->message_item(

         type        = `{TYPE}`

         title       = `{TITLE}`

         subtitle    = `{SUBTITLE}`

         description = `{DESCRIPTION}`

         groupname   = `{GROUP}` ).

Check the full source code here and here's the demo:

Message View in abap2UI5

6. Conclusion

This concludes the third part of this introduction to abap2UI5. We've covered how apps can call each other and exchange data, as well as the development and application of popups for creating F4-Helps and displaying messages and errors.

In the next part, we will expand upon these concepts by developing comprehensive demo applications. These demos will illustrate various use cases and highlight additional features of abap2UI5.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, create an issue or leave a comment.

abap2UI5 - (4) Advanced Functionality & Demonstrations

2023-04-02T16:43:25+02:00

Welcome to part 4 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

In this post, we will explore various demos, including File Editor, Table Maintenance, and Charts, among others. These demos aim to showcase the diverse use cases and features of abap2UI5.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and be sure to explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations (this blog post)

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

While we've already explored classic scenarios like selection screens and table outputs, the UI5 Library also enables the development of abap2UI5 applications for a broad range of additional use cases. This post covers the following areas:

File Editor

Table Maintenance

File Upload & Download

Visualization with Charts

Monitoring & Timer

Layouts

Side Effects

List Report

Conclusion

Let's begin with the file editor.

1. Demo - File Editor

The File Editor uses the Code Editor Control. It displays text files and highlights the syntax for a lot of different code types (xml, json, js, abap, yaml...). This functionality is part of UI5 and works seamlessly, requiring no extra effort. We simply need to fill in the attributes of the editor control in the rendering method. For the editor content, we use two-way binding to retrieve the updated frontend values and we call function modules to read and update the MIME repository. Here's a preview of the demo app in action:

Demo File Editor

Check out the source code here.

The UI5 Library provides information about all controls, including their attributes and possible values:

Available Code Types for Syntax Highlighting of the Editor Control

2. Demo - Table Maintenance

Combining the Editor Control with an editable Table Control, as explained in the second blog post, enables us to create an abap2UI5 table maintenance app. This app provides three input formats (XML, JSON, CSV) and converts the data into an internal table to edit it with the Table Control. Once the data is modified, it exports it again with the Editor Control. This example is easily adaptable to other tables by simply changing the table type in ABAP. The transfer of data between the server and client is generic and independent of DDIC artifacts or HTTP interfaces, making it applicable for a lot of different use cases:

Demo Table Maintenance

Access the source code here. A cl_salv_table flavored ABAP snippet:

Dynamic Column Definition with RTTS

3. Demo - File Upload & Download

Selecting files from the frontend via the browser and uploading & downloading PDFs, images, ZIPs, or other files is a common requirement. The JavaScript 'FileReader' provides this functionality, but there is no UI5 control for that. Therefore, abap2UI5 has a little custom control 'zz_file_uploader' which encapsulates this functionality. This control allows us to use the 'FileReader' like any other abap2UI5 control via its attributes in the renderer method. This approach also offers the possibility to include further JavaScript functions in abap2UI5 in the future. Here's what the demo app looks like:

Demo File Upload/Download

Check out the source code here.

Some snippets of how you can wrap JavaScript functions for the use in abap2UI5:

Custom Control Interface	Custom Control Implementation

ABAP Interface	ABAP Implementation

Learn more about how to develop custom control in part 11 here.

4. Demo - Visualization with Charts

This demo tries to be a bit more beautiful. Tables aren't always the best way to visualize data, so with abap2UI5 we can also use the Donut Chart, Bar Chart, Line Chart or Radial Micro Chart. By implementing event handlers, we can enhance interactivity and respond to clicks on specific chart points:

Demo Visualization

Check out the source code here.

This ABAP snippet may seem more complex, but achieving the same result using an UI5-XML-View would require equivalent effort:

Rendering Donut Charts in abap2UI5

5. Demo - Monitoring & Timer

Next, we will combine the visualization functionality with a timer. The abap2UI5 timer has the similar functionality to the former cl_gui_timer. You can set an interval and an event that is called after the timer finishes. This allows us to create apps that visualize certain data and refresh themselves every few seconds:

Self-Refreshing Monitor

Check out the source code here.

Set the following control in the view definition to active the timer:

DATA(lo_view) = z2ui5_cl_xml_view=>factory( ).

lo_view->_z2ui5( )->timer( 

      finished = client->_event( `TIMER_FINISHED` ) 

      delayms = `2000` 

      checkrepeat = abap_true ).

6. Demo - Layouts

The object page is a useful way to display information for business objects. It is composed of a header and content, which are divided into sections and subsections. Navigation is a built-in functionality of the UI5 control, so it works out of the box:

Object Page Layout with abap2UI5

Check out the source code here and here.

A lot of different Layouts are available in UI5, check out the Fiori UX Guidelines to know when to use which:

Fiori Design Guidelines

7. Demo - Side Effects (Expression Binding)

This demo demonstrates side effects. You can use the _bind function with JavaScript functions to create an expression binding. This enables attributes of different controls to affect each other. For example, you can activate a button only when an input is made. This allows for small checks to be done directly at the frontend without needing a server roundtrip or render again the entire view. The demo looks like this:

Expression Binding in abap2UI5

Check out the source code here.

There are many different expressions available, check out the documentation. When ABAP is combined with JavaScript in an expression, it looks like this:

ABAP and JavaScript in an Expression Binding

But watch out not to send too many calculations to the frontend, you might make HANA jealous 😅

8. Demo - List Report

This final example demonstrates the use case of a list report. The first view displays a table, and you can navigate to the detail page by clicking on an entry. All basic functionalities, such as filtering, sorting, searching, and layout handling, have been implemented. You can also modify table settings, such as visible columns, titles, or selection mode:

List Report in abap2UI5

Check out the source code here.

This example demonstrates that you can create apps with abap2UI5, which are similar to Fiori Elements Floorplans. However, in this situation, you should consider whether it might be better to use RAP directly instead of developing everything manually in abap2UI5. You can check out the Floorplans here:

Fiori Elements Floorplans

9. Conclusion

This marks the end of part four of this introduction to abap2UI5. We explored several demos to gain a better understanding of the various use cases and features of abap2UI5.

In the next part, we will explore different ways of creating UIs and enhancing them with HTML, CSS, JavaScript and third-party libraries.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, create an issue or leave a comment.

abap2UI5 – (5) Creating UIs with XML Views, HTML, CSS & JavaScript

2023-04-12T18:43:21+02:00

Welcome to part 5 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

This post explains various ways of creating views and enhancing them with HTML, CSS and JavaScript.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and be sure to explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript (this blog post)

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Creating UI5 Views in the Backend
1. View Class Way
2. View Class Generic Way
3. Pure XML Way

HTML, CSS & JavaScript

Canvas & SVG

External Libraries

Additional Comments

Conclusion

Let’s begin with the first topic.

1. Creating UI5 Views in the Backend

There are various methods for creating views in abap2UI5. To illustrate, we will create a simple view consisting of an input field and a button, comparing different creation processes. Here's how the view looks:

View created in three different ways

1.1. View Class Way

We'll start by creating the view using the method detailed in previous blog posts, utilizing the class z2ui5_cl_xml_view. Here's an example of the code for creating the view:

lo_view->shell(

      )->page(

              title          = 'abap2UI5 - NORMAL NORMAL NORMAL'

              navbuttonpress = client->_event( 'BACK' )

              shownavbutton  = abap_true

          )->header_content(

              )->link(

                  text = 'Source_Code'

                  href = z2ui5_cl_xml_view_helper=>hlp_get_source_code_url( app = me get = client->get( ) )

                  target = '_blank'

          )->get_parent(

          )->simple_form( 'Form Title'

              )->content( 'form'

                  )->title( 'Input'

                  )->label( 'quantity'

                  )->input( client->_bind( quantity )

                  )->button(

                      text  = 'NORMAL'

                      press = client->_event( 'NORMAL' )

                  )->button(

                      text  = 'GENERIC'

                      press = client->_event( 'GENERIC' )

                     )->button(

                      text  = 'XML'

                      press = client->_event( 'XML' ) ).

The class z2ui5_cl_xml_view provides ABAP-typed methods for creating UI5 controls. The class acts as an ABAP-typed proxy for the SAPUI5 Library and as an result only contains code with no extra logic:

This class stores all control information in a tree structure and ultimately generates a stringified XML view based on that structure. This class is continuously updated with additional controls. If there is a control that you would like to use that is not currently part of the class, you can open an issue or add it by yourself and submit a pull request on GitHub that it becomes available for everyone to use.

Notably, every method in the class calls the generic method _generic to save the control information. As a result, we can skip the first step and call this generic method directly. This will be the second approach for generating a view for abap2UI5, which we will explore now.

1.2. View Class Generic Way

To use a control that is not included in the view class, we can also use the method '_generic'. This approach, while offering flexibility, requires more code and forgoes the benefits of typed interfaces. Here's an example:

lo_view->_generic( 'Shell' )->_generic(

       name      = `Page`

       t_prop = VALUE #(

           ( n = `title`          v = 'abap2UI5 - GENERIC GENERIC GENERIC' )

           ( n = `showNavButton`  v = `true` )

           ( n = `navButtonPress` v = client->_event( 'BACK' ) ) )

       )->_generic(

            name = `SimpleForm`

            ns   = `form`

            t_prop = VALUE #(

                ( n = `title` v = 'title' )

       ) )->_generic(

            name = `content`

            ns   = `form`

       )->_generic(

            name = `Label`

            t_prop = VALUE #(

                ( n = `text` v = 'quantity' )

       ) )->get_parent( )->_generic(

            name = `Input`

            t_prop = VALUE #(

                ( n = `value` v = client->_bind( quantity ) )

       ) )->get_parent(

        )->_generic(

            name = `Button`

            t_prop = VALUE #(

                ( n = `text`  v = `NORMAL` )

                ( n = `press` v = client->_event( 'NORMAL' ) ) )

           )->get_parent(

           )->_generic(

            name = `Button`

            t_prop = VALUE #(

                ( n = `text`  v = `GENERIC` )

                ( n = `press` v = client->_event( 'GENERIC' ) ) )

            )->get_parent(

                 )->_generic(

            name = `Button`

            t_prop = VALUE #(

                ( n = `text`  v = `XML` )

                ( n = `press` v = client->_event( 'XML' ) ) ) ).

If you wish to use different namespaces, you have the option to modify them in the call of the factory method. The default namespaces are as follows:

Default namespaces of the abap2UI5 view class

This generic approach allows us to generate any control, but it requires more code to be written and we lose the benefits of typed interfaces that make the first approach more convenient to use.

Now, let us examine how the view output is ultimately provided to abap2UI5. The view class creates the UI5 view and outputs it as a string, which is then received by abap2UI5 as a ready-to-use UI5-XML-View:

client->view_display( page->stringify( ) ).

That means abap2UI5 is not involved in the creation of the views. It operates entirely independently of the view class and just receives the result and sends it to the frontend as it is.

Therefore you also have the freedom to build your own view class or encapsulate the existing one in a way that better fits your needs. The provided view class is just a suggestion but there might be better solutions for the view creation process. Keeping this in mind, we can now also bypass the z2ui5_cl_cml_view class and use XML directly, which will be the next approach we will focus on.

1.3. Pure XML Way

Now we copy the XML view directly into ABAP as a string and replace the event handler and data binding. The previous example in XML looks like this:

    data(lv_xml) = `<mvc:View controllerName="zzdummy" displayBlock="true" height="100%" xmlns:core="sap.ui.core" xmlns:l="sap.ui.layout" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:f="sap.ui.layout.form" xmlns:mvc="sap.ui.co` &&

`re.mvc" xmlns:editor="sap.ui.codeeditor" xmlns:ui="sap.ui.table" xmlns="sap.m" xmlns:uxap="sap.uxap" xmlns:mchart="sap.suite.ui.microchart" xmlns:z2ui5="z2ui5" xmlns:webc="sap.ui.webc.main" xmlns:text="sap.ui.richtexteditor" > <Shell> <Page ` && |\n|

&&

                          `  title="abap2UI5 - XML XML XML" ` && |\n|  &&

                          `  showNavButton="true" ` && |\n|  &&

                          `  navButtonPress="` &&  client->_event( 'BACK' ) && `" ` && |\n|  &&

                          ` > <headerContent ` && |\n|  &&

                          ` > <Link ` && |\n|  &&

                          `  text="Source_Code" ` && |\n|  &&

                          `  target="_blank" ` && |\n|  &&

                          `  href="<system>sap/bc/adt/oo/classes/Z2UI5_CL_APP_DEMO_23/source/main" ` && |\n|  &&

                          ` /></headerContent> <f:SimpleForm ` && |\n|  &&

                          `  title="Form Title" ` && |\n|  &&

                          ` > <f:content ` && |\n|  &&

                          ` > <Title ` && |\n|  &&

                          `  text="Input" ` && |\n|  &&

                          ` /> <Label ` && |\n|  &&

                          `  text="quantity" ` && |\n|  &&

                          ` /> <Input ` && |\n|  &&

                          `  value="` &&  client->_bind( quantity ) && `" ` && |\n|  &&

                          ` /> <Button ` && |\n|  &&

                          `  press="` &&  client->_event( 'NORMAL' ) && `"`  && |\n|  &&

                          `  text="NORMAL" ` && |\n|  &&

                          ` /> <Button ` && |\n|  &&

                              `  press="` &&  client->_event( 'GENERIC' ) && `"`  && |\n|  &&

                          `  text="GENERIC" ` && |\n|  &&

                          ` /> <Button ` && |\n|  &&

                             `  press="` &&  client->_event( 'XML' ) && `"`  && |\n|  &&

                          `  text="XML" ` && |\n|  &&

                          ` /></f:content></f:SimpleForm></Page></Shell></mvc:View>`.

abap2UI5 takes the XML view as it is and sends it to the frontend. The following demonstration showcases the three approaches in action. Each time, the view remains the same, but it is created using a different method:

App with views created in three different ways

Check out the source code here. The XML approach may appear unconventional and could potentially be difficult to maintain. However, it is a speedy way to create prototypes, as this approach enables us to copy and paste any code snippets from the SAPUI5 Library. Here is an example of how to copy the generic tile example of the UI5 API to abap2UI5:

Copying Views of the Documentation and Run it with abap2UI5

And here we add a popup using the same method:

Copying Popups of the UI5 Documentation and run it with abap2UI5

We add interaction by replacing the event handler with the abap2UI5 handler:

  `<Button text="BACK" type="Emphasized" press="` && client->_event( 'BACK') && `"/>`

We add data transfer by replacing the data binding with the abap2UI5 binding:

 ` <Input id="loadingMinSeconds" width="8rem" type="Number" description="seconds" value="` && client->_bind_edit( mv_value ) && `"/>`

Within minutes, we can create a fully functional prototype with event handling and data transfer:

UI5-XML-View in abap2UI5 with Events and Data Transfer

Check out the source code of the app here.

Although the video makes it seem easy, it is important to exercise caution when using this approach. You are now fully responsible for everything. abap2UI5 simply sends it as is to the frontend, so you must ensure that the namespace is correct, libraries can be loaded, images are displayed properly and so on. This approach provides flexibility, but also comes with the potential for problems to occur.

If you need to make corrections, you can activate logging, and the XML view output will be written to the console of your browser. From there, you can copy it, make adjustments and copy it back to the ABAP class:

Console Output of the UI5-XML-View

A great way to create views is to use sandboxes, for example use the OpenUI5 Sandbox:

OpenUI5 SandBox

After we now got full control of the view creation process, we can go one step further and add native HTML, CSS, and JS.

2. Using HTML, CSS & JavaScript

UI5 provides the ability to use native HTML in XML Views. You can refer to this documentation for more information. A simple example of HTML output in XML Views looks like this:

Native HTML and CSS in abap2UI5

Here is the XML view in ABAP for the above example (and a more readable version):

    app-next-xml_main = `<mvc:View controllerName="project1.controller.View1"` && |\n|  &&

                          `    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"` && |\n|  &&

                          `  xmlns:z2ui5="z2ui5"  xmlns:m="sap.m" xmlns="http://www.w3.org/1999/xhtml"` && |\n|  &&

                          `    ><m:Button ` && |\n|  &&

                          `  text="back" ` && |\n|  &&

                          `  press="` && client->_event( 'BACK' ) && `" ` && |\n|  &&

                          `  class="sapUiContentPadding sapUiResponsivePadding--content"/> ` && |\n|  &&

                   `       <m:Link target="_blank" text="Source_Code" href="` && z2ui5_cl_xml_view_helper=>factory( client )->hlp_get_source_code_url( ) && `"/>` && |\n|  &&

                          `<html><head><style>` && |\n|  &&

                          `body {background-color: powderblue;}` && |\n|  &&

                          `h1   {color: blue;}` && |\n|  &&

                          `p    {color: red;}` && |\n|  &&

                          `</style>` &&

                          `</head>` && |\n|  &&

                          `<body>` && |\n|  &&

                          `<h1>This is a heading with css</h1>` && |\n|  &&

                          `<p>This is a paragraph with css.</p>` && |\n|  &&

                          `<h1>My First JavaScript</h1>` && |\n|  &&

                          `<button type="button">send</button>` && |\n|  &&

                          `<Input id='input' value='frontend data' /> ` &&

                          `</body>` && |\n|  &&

                          `</html> ` && |\n|  &&

                            `</mvc:View>`.

<mvc:View controllerName="z2ui5_controller"

	xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

	xmlns:z2ui5="z2ui5"

	xmlns:m="sap.m"

	xmlns="http://www.w3.org/1999/xhtml"

    >

	<m:Button 

  text="back" 

  press="onEvent( { 'EVENT' : 'BACK', 'METHOD' : 'UPDATE' } )" 

  class="sapUiContentPadding sapUiResponsivePadding--content"/>

	<m:Link target="_blank" text="Source_Code" href="<<system>>m/sap/bc/adt/oo/classes/Z2UI5_CL_APP_DEMO_32/source/main"/>

	<html>

		<head>

			<style>

body {background-color: powderblue;}

h1   {color: blue;}

p    {color: red;}

</style>

		</head>

		<body>

			<h1>This is a heading with css</h1>

			<p>This is a paragraph with css.</p>

			<h1>My First JavaScript</h1>

			<button type="button">send</button>

			<Input id='input' value='frontend data' />

		</body>

	</html>

</mvc:View>

To enable interaction and data transfer, we add JavaScript to the XML view:

  app-next-xml_main = `<mvc:View controllerName="project1.controller.View1"` && |\n|  &&

                          `    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"` && |\n|  &&

                          `  xmlns:z2ui5="z2ui5"  xmlns:m="sap.m" xmlns="http://www.w3.org/1999/xhtml"` && |\n|  &&

                          `    ><m:Button ` && |\n|  &&

                          `  text="back" ` && |\n|  &&

                          `  press="` && client->_event( 'BACK' ) && `" ` && |\n|  &&

                          `  class="sapUiContentPadding sapUiResponsivePadding--content"/> ` && |\n|  &&

                   `       <m:Link target="_blank" text="Source_Code" href="` && z2ui5_cl_xml_view_helper=>hlp_get_source_code_url( app = me get = client->get( ) ) && `"/>` && |\n|  &&

                          `<html><head><style>` && |\n|  &&

                          `body {background-color: powderblue;}` && |\n|  &&

                          `h1   {color: blue;}` && |\n|  &&

                          `p    {color: red;}` && |\n|  &&

                          `</style>` &&

                          `</head>` && |\n|  &&

                          `<body>` && |\n|  &&

                          `<h1>This is a heading with css</h1>` && |\n|  &&

                          `<p>This is a paragraph with css.</p>` && |\n|  &&

                          `<h1>My First JavaScript</h1>` && |\n|  &&

                          `<button onclick="myFunction()" type="button">send</button>` && |\n|  &&

                          `<Input id='input' value='frontend data' /> ` &&

                          `<script> function myFunction( ) { sap.z2ui5.oView.getController().onEvent({ 'EVENT' : 'POST', 'METHOD' : 'UPDATE' }, document.getElementById(sap.z2ui5.oView.createId( "input" )).value ) } </script>` && |\n|  &&

                          `</body>` && |\n|  &&

                          `</html> ` && |\n|  &&

                            `</mvc:View>`.

Finally, we have a working frontend application that uses events and data transfer to the backend with HTML, CSS and JS:

HTML, CSS and JavaScript in abap2UI5

Here we create the server roundtrip with abap2UI5 and use the second parameter of the event method to transfer data to the backend:

sap.z2ui5.oView.getController().onEvent({ 'EVENT' : 'POST', 'METHOD' : 'UPDATE' }, document.getElementById(sap.z2ui5.oView.createId( "input" )).value )

Then in the backend the data can be found in the following parameter:

client->popup_message_toast( client->get( )-t_args[ 1 ] ).

The value of 'app-get-event_data' can also be filled with a stringified JSON, which provides a generic approach for sending data to the backend without requiring changes to the HTTP handler. Take a look at the full source code of the app here.

This approach provides a lot of freedom, but it also requires you to manage JavaScript, CSS, and HTML within your normal ABAP code. Good wrappers can be helpful, but it's worth considering whether it would be better to create a regular frontend app instead. Additionally, the code in this example isn't considered good practice because we're calling UI5 from the outside, using global variables etc. So, consider it only as an example to see what is possible, and not as a coding guideline to follow.

3. Canvas & SVG

We can now use this approach for functionalities that are not normally within the scope of UI5. For example, we can use canvas and SVG:

Canvas and SVG in abap2UI5

You can find the source code here.

4. External Libraries

Or including third-party open-source libraries -- for example use JSBarcode to display barcodes:

JSBarcode in abap2UI5

The source code of the app is here.

With this method, you can also incorporate additional libraries in the future for various functionalities, such as displaying QR codes, using barcode scanning with the camera, employing localization techniques, or utilizing other device capabilities.

Update 15.12.2023: Over the recent months, more external libraries have been integrated into abap2UI5. For more detailed information, please refer to part 10 of this series.

5. Additional Comments

As we have seen, there are many different ways to create views in abap2UI5, each with its own level of flexibility and maintenance requirements. The view creation process is independent to the rest of abap2UI5, as it simply takes the created view and sends it to the frontend as is. Therefore, each user can choose the method that works best for them.

The view class-based approach is very intuitive and is built on typed ABAP methods. The XML approach, which involves copying and pasting views, is extremely fast for creating prototypes with popups in a short amount of time, but maintaining the views can be challenging later on. The last approaches offer a lot of flexibility, but they require deep knowledge of JS and HTML and essentially use the ABAP source code as a BSP. It's a question whether frontend development may be better in this case.

The idea behind abap2UI5 is to just provide a basic layer that offers some flow logic (for easy switching between apps & handling events) and server-client communication (for creating models & transferring data). However, the entire view logic remains separated of the framework. Therefore, the class z2ui5_cl_xml_view is just loosely coupled to the abap2UI5 core functionality. With this approach abap2UI5 remains small and flexible, suitable for a wide range of use cases.

Feel free to find your best way to create views and extend abap2UI5.

Update 15.12.2023: We have explored now various methods for integrating JavaScript into abap2UI5, but have not yet addressed the best practices for encapsulating this code. This topic will be covered in part 11, where we will focus on the development of Custom Controls for the integration of JavaScript for the use with abap2UI5.

6. Conclusion

This concludes part five of this introduction to abap2UI5. You now have an understanding about the various methods of creating views in the backend and ideas how to extend it with HTML, CSS and JavaScript.

In the next part, we will focus on how to install, configure and debug abap2UI5.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, create an issue or leave a comment.

abap2UI5 – (6) Installation, Configuration & Troubleshooting

2023-04-14T17:28:49+02:00

Welcome to part 6 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

This post explains the installation, configuration and troubleshooting steps of abap2UI5.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and be sure to explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting (this blog post)

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Installation
1. Install the Project
2. Create a new HTTP Service
3. Implement the Handler Method

Configuration
1. Options & URL Parameters
2. Title
3. Synchronize the Configuration
4. Theme
5. Bootstrapping
6. Launchpad
7. CSS

Security

Debugging
1. Frontend
2. Backend

Conclusion

Let’s begin with the first topic.

1. Installation

1.1. Install the project with abapGit

If you are new to abapGit, start by reviewing this Guideline for on-premise systems and this Tutorial for cloud environments.

The project is based on a single code line for both language versions (ABAP Cloud, Standard ABAP), so you can pull this repository in both cases. For lower releases (NW 7.03 to 7.40) use this downport repository.

1.2. Create a new HTTP Service

Next, create a new HTTP service in your system. In an on-premise environment, you need to create and configure a new ICF service. Follow this guideline for that and see how to develop a new HTTP request handler here. In a cloud scenario, follow this tutorial.

1.3. Implement the Handler Method

Now copy the following implementation into your new handle_request method.

ABAP Standard:

METHOD if_http_extension~handle_request.



   DATA(lv_resp) = SWITCH #( server->request->get_method( )

      WHEN 'GET'  THEN z2ui5_cl_fw_http_handler=>http_get( )

      WHEN 'POST' THEN z2ui5_cl_fw_http_handler=>http_post( server->request->get_cdata( ) ) ).



   server->response->set_header_field( name = `cache-control` value = `no-cache` ).

   server->response->set_cdata( lv_resp ).

   server->response->set_status( code = 200 reason = `success` ).



ENDMETHOD.

ABAP Cloud:

METHOD if_http_service_extension~handle_request.



   DATA(lv_resp) = SWITCH #( request->get_method( )

      WHEN 'GET'  THEN z2ui5_cl_fw_http_handler=>http_get( )

      WHEN 'POST' THEN z2ui5_cl_fw_http_handler=>http_post( request->get_text( ) ) ).



   response->set_status( 200 )->set_text( lv_resp

      )->set_header_field( i_name = `cache-control` i_value = `no-cache` ).



ENDMETHOD.

By calling your new HTTP handler via browser, you can start abap2UI5 and see the landing page:

abap2UI5 Landing Page

Optionally you can install the abap2UI5 samples repository next and check out all the examples:

abap2UI5 Samples Repository

Now you are ready to develop your first own app. See the first blog post to find more information about the development process.

2. Configuration

2.1. Options and URL Parameters

There are two ways to set the configuration: one is by setting it via URL parameter, and the other option is by importing it as a configuration by calling the index HTML.

By default, the following parameters are set:

lt_config = VALUE #(

   (  n = `src`                       v = `https://sdk.openui5.org/resources/sap-ui-cachebuster/sap-ui-core.js` )

   (  n = `data-sap-ui-theme`         v = `sap_horizon` )

   (  n = `data-sap-ui-async`         v = `true` )

   (  n = `data-sap-ui-bindingSyntax` v = `complex` )

   (  n = `data-sap-ui-frameOptions`  v = `trusted` )

   (  n = `data-sap-ui-compatVersion` v = `edge` ) ).

If you want to make changes, simply copy the table, adjust the necessary parameters and then import the table again when calling the method:

DATA(lt_config) = VALUE z2ui5_if_client=>ty_t_name_value( 

      (  n = `data-sap-ui-theme`         v = `sap_belize` ) "<- adjusted

      (  n = `src`                       v = `https://sdk.openui5.org/resources/sap-ui-cachebuster/sap-ui-core.js` )

      (  n = `data-sap-ui-async`         v = `true` )

      (  n = `data-sap-ui-bindingSyntax` v = `complex` )

      (  n = `data-sap-ui-frameOptions`  v = `trusted` )

      (  n = `data-sap-ui-compatVersion` v = `edge` ) ).



DATA(lv_resp) = SWITCH #( request->get_method( )

   WHEN 'GET'  THEN z2ui5_cl_fw_http_handler=>http_get( lt_config )

   WHEN 'POST' THEN z2ui5_cl_fw_http_handler=>http_post( request->get_text( ) ) ).

You can find a list of all configuration parameters here. Additionally, you can modify these parameters with the sap-ui- prefix to use them as URL parameters.

2.2. Title

You can set the title with the following snippet in your definition of the view:

DATA(view) = z2ui5_cl_xml_view=>factory( ).

view->_z2ui5( )->title( i_client->_bind_edit( `My Title` )

abap2UI5 with changed title

Check out the following sample.

2.4. Synchronize the Configuration

You can also synchronize your configurations with all other ui5 apps in your system by reading the customizing from the following table prior to making the method call (Enjoy the view – this is the only SAP GUI screenshot included in this blog series 😉😞

Configuration SAP UI5 Bootstrapping

2.4. Theme

The most common change is to the theme. You can find all available themes here. The newest theme is Horizon (sap_horizon) and it is used in all the demos of this blog series. Other popular themes are:


Belize (sap_belize)	Quartz Light (sap_fiori_3)

Evening Horizon (sap_horizon_dark)	High Contrast Black (sap_horizon_hcb)

2.5. Bootstrapping

In an on-premise landscape, you can bootstrap the UI5 library from your local system. Typically, the path is "/sap/public/bc/ui5_ui5/resources/sap-ui-core.js" or "resources/sap-ui-core.js". In a cloud scenario, you can refer to SAP guidelines available here.

2.6. Launchpad

Abap2UI5 is based on a single-page index.html, which makes it not compatible with FLP out-of-the-box (since FLP replaces the index.html). However, it is no problem to encapsulate abap2UI5 in a UI5 standard app for the use with launchpads. Check out and install this additional repository.

2.7. CSS

You can change the CSS by sending HTML with your View in your app. An example can be found here:

abap2UI5 app with changed CSS

3. Security

At the backend, abap2UI5 is a plain HTTP handler that every user creates and configures by themselves (visibility, authentication & other security parameters). In the implementation of your apps you have to take care of a secure programming style like always when developing HTTP-Handlers (call authorization checks, avoid dynamic SQL etc.). Check this for more information.

At the frontend, abap2UI5 is a normal one page UI5 application. It loads the external library UI5 from a CDN or your own customized directory. The UI5 framework is used to render the HTML and only methods of the UI5 framework are called to handle the all events.

Additionally to prevent cross-site-scripting the following parameter are set in the index.html:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' 'unsafe-inline' 'unsafe-eval' ui5.sap.com *.ui5.sap.com sdk.openui5.org *.sdk.openui5.org cdn.jsdelivr.net *.cdn.jsdelivr.net"/>

It only allows libraries from the same server, ui5.sap.com, openui5.com or cdn.jsdelivr.net, which we needed to use for some external libraries. Adjust the importing parameter 'content-security-policy' when you want to include more external URLs:

DATA(lv_resp) = SWITCH #( request->get_method( )

           WHEN 'GET'  THEN z2ui5_cl_fw_http_handler=>http_get(

                          content_security_policy = `<meta http-equiv="Content-Security-Policy" content="default-src 'self' 'unsafe-inline' 'unsafe-eval' ui5.sap.com *.ui5.sap.com sdk.openui5.org *.sdk.openui5.org cdn.jsdelivr.net *.cdn.jsdelivr.net"/>` ) 

           WHEN 'POST' THEN z2ui5_cl_fw_http_handler=>http_post( request->get_text( ) ) ).

You can find more information about CSP here.

4. Debugging

When your app is in the development process, you can activate the debugging tools by changing the following parameter:

DATA(lv_resp) = SWITCH #( request->get_method( )

       WHEN 'GET'  THEN z2ui5_cl_fw_http_handler=>http_get(

                           check_debugging = abap_true )

       WHEN 'POST' THEN z2ui5_cl_fw_http_handler=>http_post( request->get_text( ) ) ).

4.1. Frontend

After that, you can can start an app and press the shortcut STRG+A and the debugging tools are displayed:

abap2UI5 Debugging Tools

Next follow the left menu and press for example View XML:

abap2UI5 Debugging Tools - XML-View

Most of the issues arise because the XML is not valid. You can check it there or copy & paste it to an XML validator. Another good way to test the XML are UI5 sandboxes, such as the OpenUI5 Sandbox.

You can also check the View Model and previous request here. If a parameter is bound with _bind_one, it should be written in the oViewModel. If a parameter is bound with _bind, it should be written in oUpdate. You can also check the last request to ensure that all updated values have been sent to the server.

To take a more detailed look at the UI, use the UI5 Inspector. This tool is helpful for analyzing and checking certain controls:

UI5 Inspector with an abap2UI5 app

You can find more guidelines here.

Also, keep in mind that abap2UI5 is based on REST, so you don't need to restart the app all the time after a change, like in the former screen logic where changes were only visible after restarting. Just triggering a server roundtrip is enough to see the changes:

View Development in abap2UI5

4.2. Backend

Set a breakpoint in your app and check the values that abap2UI5 provides you, as well as the values you give back to abap2UI5. Check if the view XML is filled and if it is valid. Normally, abap2UI5 throws an exception if something unexpected happens, which can help you to identify the problem. If you want to gain a deeper understanding, you can also debug the framework itself.

The framework is based on a single http handler. Set a breakpoint here and check incoming requests and outgoing responses:

abap2UI5 HTTP Handler

The initial request loads the UI5 index.html, which is independent of your application and should normally not cause any problems:

abap2UI5 Get Handler (index.html)

After this, the AJAX roundtrip logic begins. Every event and interaction creates a new HTTP Post request, which triggers the following method:

abap2UI5 Post Handler

As you can see, we call the user's app on line 44. You can also check if your app has been successfully updated after the frontend on line 39 and check the following method:

Update app after frontend (PAI)

And the reverse direction, setting the response with the values of your app in this method:

Create frontend model before output (PBO)

If you find a bug in the framework or running into problems with your app, feel free to open an issue.

5. Conclusion

This was part six of this introduction to abap2UI5. You now have an understanding how to install & configure it and got insights into troubleshooting & debugging.

In the next blog post, we will focus on the technical background of this framework and summarize all the project's key ideas by covering topics such as its architecture, codebase and compatibility.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, create an issue or leave a comment.

SAP ISU Intercompany and Data Exchange : Choice

2023-04-21T01:26:31+02:00

In this blog I will discuss about what do you mean by Intercompany and Data Exchange.

Let’s Consideration and Scenario where in your area Electricity is providing from various Supplier A, Supplier B , Supplier C, etc. Generally in deregulated market we have this option to choose the energy suppliers.
Deregulated in Utilities Market means where you will purchase the Electricity and then Supply to the Customers in short you will not generate the electricity you will purchase and then sell the electricity, where as Regulated in Utilities Market means generating electricity and distribution to the customers up to services you will give.

Deregulation of market has given consumers the freedom to choose their energy suppliers and to change the supplier if they are not satisfied with the services of the supplier they can leave the exciting supplier and choose a new supplier.

For Deregulated market it will not possible to manage lots of data of the customers keeping a track because lots of data will be shared between retailer and distributor. To help this SAP comes up a sub module called Intercompany Data Exchange {IDE}. This will helps to automates data between retailer and distributor in a deregulated market.

In IDE {Intercompany Data Exchange} will contain 3 main parts.
1. Grid.

2. Communication Control.

3. Process management.

Let’s understand one by one.

Grid: It contains the generation of service and distribution of service to particular period.
For example a customer is on Supplier A with for 10 years and now want to switch to new Supplier i.e. Supplier B. This will help in technical way to understand which supplier had supplied in a particular range of Months or Years.

Communication Control: The flow of data will be sending and receiving. In SAP it is possible with the help of IDOC’s.

Process Management: Let’s a customer wants to update the Mobile number then retail supplier should update the info accordingly.

IDE process allows processing of multiple message formats, thus providing options for using the same system to support different markets scenario’s.

In short we can modify the details customer details, switching the customers to different provider, etc.

Thanks for reading the blog.

abap2UI5 – (7) Technical Background: Under the Hood of abap2UI5

2023-04-26T10:37:54+02:00

Welcome to part 7 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

This post will focus on the technical background and summarize all the project's key ideas by covering topics such as its architecture, codebase and compatibility.

Blog Series & More

You can find all the information about this project on GitHub, stay up-to-date by following on Twitter and be sure to explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshoooting

(7) Technical Background: Under the Hood of abap2UI5 (this blog post)

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post delves into the inner workings of abap2UI5, guiding you from the basics to more advanced concepts. Simply follow the sections from (1) to (30), and at the end, you'll find a concise summary.

Technical Background

abap2UI5 is designed as an open-source project. The goal in doing this is not only to make it accessible to everyone, but also allow for exchange of ideas. Therefore, this last blog post contains all technical details: It shares the underlying concept behind this approach, explains its adaptation to the ABAP Environment, its differences to RAP and finally focuses on its code line. While my background is mostly in traditional ABAP and UI5 areas, I am not an expert in all of the topics I will touch upon, but I was interested in what they can bring to the project. This being said, if you catch any mistakes, please feel free to correct me. As always, I welcome all feedback.

(1) HTML Over the Wire

Let's start by taking a closer look at the concept of "HTML Over the Wire", an approach that influenced abap2UI5 and is well explained in this blog post:

You can write fast, modern, responsive web applications by generating your HTML on the server, and delivering that (with a little help) directly to the browser. You don’t need JSON as an in-between format. You don’t need client-side MVC frameworks. You don’t need complicated bundling and transpiling pipelines. But you do need to think different. [...]

This is what HTML Over The Wire is all about. It’s a celebration of the simplicity in HTML as the format for carrying data and presentation together, whether this is delivered on the first load or with subsequent dynamic updates.

I came across this concept on SCN when I read this blog post, which explained how to use htmx to create Fiori-like apps. Over-the-wire approaches include server-side rendering (SSR) similar to that of a multi-page application (MPA). However, after the initial request, the browser retrieves only HTML fragments asynchronously via AJAX, so the entire page is not re-rendered anymore. Unlike a single-page application (SPA), the server handles also the application's logic and state:

HTML "Over the Wire" Lifecycle (Quelle)

The idea of combining View & Data and transferring them together to the frontend is significantly distinct from most of the current approach where HTML, CSS & JavaScript are strictly separated and stored at the frontend whereas the data is sent by the backend.

(2) Hypermedia Driven Application (HDA)

This leads to a concept that we could refer to as a hypermedia-driven application (HDA), which is introduced here. Let's compare this approach to that of multi-page applications (MPA) and single-page applications (SPA):

MPA vs. SPA vs. HDA (Quelle)

In a hypermedia-driven application (HDA), the browser is limited to displaying HTML, processing JavaScript and CSS, but has no knowledge of the application's state (i.e., what has happened before and what will happen next). The application's logic is completely maintained on the server. In contrast, in a single-page application (SPA), all routes and potential actions are defined upfront and implemented at the frontend. As a result, any modifications to the application requires rebuilding the frontend app (more information here).

(3) Separation of Concerns

In a HDA, the idea of separation of concerns is not highly prioritized. CSS, JavaScript, and HTML are not cleanly separated, and the backend is responsible not only for the data but also for generating the UI and the program flow. However, the advantage of this approach is that we can maintain and customize everything in one place, as we're accustomed to in the past for example in former SAP GUI applications (more information here).

(4) Dive Deeper

The first approaches in this direction were introduced back in Phoenix LiveView (2018) and in Laravel Livewire (2019). Now, there are several frameworks that work on similar principles, such as htmx, hotwire or unpoly (check out newer blog posts here and here).

In the end, all of these concepts share the belief that it's possible to develop apps with much less complexity, but only slightly lower level of UI fidelity compared to SPAs. Or, when we try to illustrate it visually, they aim to find a "sweet spot" between MPAs and SPAs:

"Sweet Spot" between SPA and MPA (Quelle)

Most of my knowledge about this subject comes from this blog posts, and it's still relatively new to me (so I don't consider myself an expert). However, it's fascinating to see the existing frameworks and to contemplate what might be achievable in the future, such as selectively re-rendering specific parts of the view or implementing smoother page transitions. I recommend taking an hour to watch this video, where all of these concepts are presented very well.

But now let's start to ask what we can bring of this concept to UI5 and the ABAP environment?

(5) UI5 Architecture

UI5 differs significantly from frameworks like htmx and unpoly. In an UI5 app, all of the logic is handled at the frontend, while the backend utilizes an OData-Implementation. This means that ABAP is only used for delivering data and has no opportunities to implement its own logic or UI. We have a "heavy javascript" approach here in a classic SPA architecture (we'll take a closer look at RAP later).

But one specific characteristic we should examine closely is how the UI5 framework creates views. Each HTML output is rendered from an XML-View (let's ignore the former HTML/JS/JSON-Views), with its associated data from the server. The view is stored at the frontend as part of the app:

UI5 normally - ABAP delivers only Data

(6) "UI5 Over the Wire" Architecture

And here is now the trick: what if, in addition to sending data from the backend, we also send the view?

"UI5 Over the Wire" - ABAP delivers Data & View together

Despite still relying on frontend HTML rendering, all necessary information (view & data) is now retrieved via AJAX from the backend. As a result, the UI5 app remains a SPA, but its role is now reduced to that of a HDA, which is responsible solely for displaying the view and its data:

UI5 app downgraded to an HDA - Displaying Data & View received from the server

This means that the frontend app is not aware of what it is currently displaying (whether it's a table, list or input) and neither is it aware of what actions will be taken next. The app logic remains completely on the server and the frontend app is just a small HDA transmitted with the first request:

"UI5 Over the Wire" - Server to Client Communication

The HDA displays the view with its data and sends back each event to the server for determination of the next action and output. This process is somewhat similar to the PAI/PBO process used in former SAP GUI apps:

UI5 vs. "UI5 Over the Wire" - Communication

We use an AJAX roundtrip logic similar to "HTML Over the Wire" approaches, but in this case, we cannot send HTML directly. Instead, we send a View combined with its Data. This results in a concept that we could refer to as "UI5-View Over the Wire".

(7) Carrying Data and Presentation together

A typical "UI5-View Over the Wire" response looks like this:

"UI5 Over the Wire" - Response with View & Data together

But is this maybe just the same like RAP, but in a different format?

(8) RAP

RAP also aims to find a "sweet spot" between a SPA and MPA. I am not certain of the exact approach they use to bring their view and model to the frontend, but they enrich responses either within the JSON itself or within the metadata of the initial OData-Request and the view and the model is defined previously in CDS Views in the backend:

RAP - Definition of Views with UI Annotations

RAP - Definition of Data Models with DDL

This approach also leads to an architecture with a thin frontend and a strong backend similar to an HDA. But RAP aims to achieve this in a well-organized and controlled manner: Every API is based on the OData-Protocol, Views are defined with UI Annotations, Data Models are defined in DDL, Model updates are developed in local implementations of RAP classes and everything is separated in different layers that are orchestrated in a Virtual Data Model. Finally, this approach ensures a highly organized development process which is effective in most use cases.

However, in situations where significant Model and View changes are needed, especially at runtime, this approach can be a bit too unflexibel. Model changes with RTTI are not supported, and extending the view quickly goes beyond the functional scope of backend annotations, requiring development of Apps with Fiori Elements (with the need for extra deployment again).

Overall RAP does not mix View, Model and Logic as radically as the "Over the Wire" approaches. Luckily in an open-source project we do not need to take care of any conventions and can risk a little bit more. As we have seen in (6) where the first trick was sending Views from the backend instead of storing them at the frontend app, we can now further enhance flexibility (9)(10).

(9) Define one generic HTTP-Service for all Apps

First, we do not define a specific HTTP-Service for transmitting the View and the Data. Instead, every app uses the same generic HTTP-Handler including two strings (one for the View and one for the Data) eliminating the need to develop individual OData-Services with SEGW or CDS. During runtime the ABAP variables & tables are transformed into a JSON-Model and transmitted as a string to the frontend. In JavaScript it is parsed again into a JSON-Model and binded to the UI5-View:

Data Transfer in abap2UI5 - ABAP variables & tables are automatically synchronized with the UI5-Model

Furthermore we not only send the data but also the metadata (Data Model) with every request (7). This is different from classic OData communication, where the metadata is sent with the initial OData request to establish the model at the beginning, and only the data is exchanged afterward. With this approach, we can now send different models with every request:

OData vs. UI5 Over the Wire - Model & Data transfer

(10) Define Model at Runtime

This enables the possibility to define models not only at design time, but also at runtime. The user doesn't have to do any extra work because abap2UI5 handles the entire process in the background during every AJAX request:

abap2UI5 - Dynamic Data Binding & Model Creation

In apps we can use RTTI now again in a way that is similar to how it was used with ALVs. This means that there is no need to create separated apps for each model. In this demo, you can see an abap2UI5 app with a view including a table output that displays a generic table and its type is created and modified at runtime (similar to SE16):

Replacing the Model (metadata) at Runtime

(11) Define View at Runtime

Same for the view: In RAP, only certain predefined control attributes can be modified at runtime, while the view is defined in CDS artifacts with UI annotations previously. However, in an abap2UI5 app, it is possible to replace entire view controls. For example, in the following app, a table control is replaced with a list control and vice versa:

Replacing the View at Runtime

(12) View & Model independent from the HTTP-Service

In the end, the View & Model are defined independent from the HTTP-Service and we are no longer forced to deliver a predefined static OData-Service for every app, as is the case in RAP. The number of backend artifacts is significantly reduced:

RAP vs. Model & View decoupled from the (single & generic) HTTP-Service

Let's take a look to the HTTP-Handler that provides us with this flexibility.

(13) HTTP-Service

All apps and data models use the same single generic HTTP-Handler, which can be observed by setting a breakpoint in your app and examining the call stack.

Call stack of an abap2UI5 app

Every app implementation is a REST-based HTTP-Post implementation, in which no session is maintained between two requests.

(14) REST

This makes it compatible with all mobile use cases and devices, as well as with 'RESTful' Environments such as the BTP ABAP Environment and the new language version 'ABAP Cloud'. Similar to an OData-Implementation, where data changes are reflected in the app without requiring an app restart, it is now possible to develop the entire application and modify its view without restarting the frontend app. Take a look at this demo:

Developing the ABAP class without restarting the frontend app

We get also the advantage shared by all over-the-wire approaches that there is no need for cache busting anymore, as the frontend app remains unchanged during the development process.

Up until now, we have observed that the abap2UI5 frontend app is unaware of the specific application, just like the generic HTTP-Service on the server, which has also no knowledge of the particular model and view it is transmitting. So, which layer ultimately defines what happens in this architecture?

(15) The abap2UI5 App

The only non-generic part of this concept is the app of the user implementing the interface z2ui5_if_app:

abap2UI5 app - one place for everything

In this architecture, the app has complete freedom in creating the view and the model, but it also bears full responsibility for ensuring that everything else functions correctly. The app must handle the program logic, application states, and remember where it was coming from and where it want to go next. All of this is concentrated in this single app layer.

However, this is not a big deal for ABAP! From an ABAP perspective, this is similar to past practices of using selection screens or working with ALVs. Every SAP GUI app was, in a way, an HDA where ABAP performs all the necessary functions (it was just not a browser-based environment). Moreover, in this architecture, we are not limited to implementing an OData-Service or confined to a local implementation of a global RAP class with restrictions, such as commit sequences, anymore. We can now leverage the full capabilities of the ABAP stack again. Creating data models based on internal tables is straightforward, working with generic data models, as seen in (10), is easily achievable at runtime with RTTI and extended ABAP concepts like serialization are also applicable, as we will see in the next section.

(16) Draft

With RAP, users can save interim results in drafts, giving them the opportunity to interrupt their work and continue later. The abap2UI5 architecture works as if we send a completely new app to the frontend after every event, but we still want to preserve the inputs and state that the user has made before. To achieve this, the z2ui5_if_app interface includes the if_serializable_object interface, which enables us to serialize and persist all important information of every request (such as the current view or its status):

z2ui5_t_draft - the abap2UI5 persistence for interim results

Furthermore, these drafts help us jump back to previous states with minimal effort, reducing the complexity that we would typically encounter in an HDA scenario when implementing a cancel or exit event of a view. Similar to the HTTP-Service, these drafts are also defined only in a generic way, eliminating the need to manually create typed draft tables for every data model, as required in RAP, and reducing again the number of backend artifacts:

RAP vs. Single (generic) Draft Table in abap2UI5

With this approach, we achieve a stateful-like PAI/PBO feeling similar to SAP GUI apps, even though we are still operating within the AJAX roundtrip logic. Furthermore since every request can be made to a different application server, abap2UI5 is compatible with scalable cloud environments, ensuring compatibility for future use:

SAP GUI (stateful) vs. abap2UI5 (restful)

However, it is important to note that this feature should only be used for interim results and be cautious when serializing other parts of your app.

We have gained a lot of flexibility with (9) (10) (11) (16), now the next sections will focus more on how the framework tries to reduce its complexity. Let's begin by taking a look at the initial request.

(17) Initial Request

The first GET request sends the artifacts of the UI5 (HDA) app to the browser. Typically, we would deploy a BSP to the ABAP stack for this, but in abap2UI5, the code is copied as a string into the implementation of the initial request of the HTTP-Handler:

index.html stored in ABAP Source Code instead of using a BSP

This provides us a 100% abapGit project that solely uses ABAP source code, making it easily installable on every ABAP system by eliminating the need for separated frontend artifacts or deployments.

(18) Everything is maintained & developed in the Backend

Considering the fact that all user apps are also in pure ABAP, we can now maintain and develop everything in the backend. Duplicating apps, making changes, renaming or other refactoring takes only a few moments. The deployment process is reduced to just activating an ABAP class, enabling us to create many apps in a short amount of time. For example, all the apps of the sample section were created rapidly using mostly copy-pasting, which would have been unfeasible for separately developed and deployed frontend apps. This represents a significant reduction in complexity and an advantage of all 'Over the Wire' apps, as we observed in (3).

(19) No Extra Layer

Another way to reduce complexity is by avoiding the creation of extra customizing layers. As shown in (13), there is only one stack call between the user's app and the HTTP-Handler, and there are no additional layers such as OData, SADL or Gateway. This allows us to bring the UI5 frontend framework and its functionality as pure as possible to the abap2UI5 apps in the backend.

UI5 is evolving rapidly, and additional layers can quickly become outdated. With this approach, all UI5-Controls which will be released in the future will also be automatically useable in abap2UI5. However, a potential downside is that we have to deal with the complexity of the frontend UI5 API and learn the concepts of XML-Views and UI5 Controls. Ultimately, it comes down to personal preference whether you prefer to learn UI Annotations or directly learn the concepts of SAP UI5.

(20) No Hiding of Complexity

But not having an extra layer also means that the framework does not necessarily abstract away complexity, unlike what other frameworks aim for. In abap2UI5, the user directly sends his XML-View to the frontend and is responsible for ensuring that it is valid and executable:

XML-View created by the user and ready for the 'Wire'

Luckily, we can significantly simplify the creation process by creating utility classes. For instance, by offering with z2ui5_cl_xml_view a class-based approach to create views that provide access to the UI5 API via ADT code completion:

z2ui5_cl_xml_view - UI5 API (frontend) used for Code Completion in ADT (backend)

This is in contrast to RAP, where you benefit of well-documented and organized extra layers, but sometimes they have limited functionality. Take side effects for example. In RAP, you are restricted to use the +, -, and * operators. In abap2UI5 you have to write JavaScript directly, which requires a lot more knowledge, but it provides the benefit of accessing the full expression binding functionality available at the frontend:

Expression Binding (Side Effects) in abap2UI5 - Mixture of ABAP and JavaScript

(21) Separated _bind and _event method

In the first approach of this framework the event and data binding were included in every method call:

First approach - Data binding and events are not separated from the view

In the current approach, they are separated from the view and created using additional methods. Moreover, the entire process of data binding and transfer is automatically handled by the framework (9):

Actual Approach - extra methods for the event and binding

This is a difference from many other UI rendering processes, where data and UI are usually imported together. Separating them here simplifies the view creation process, avoids data redundancies, and prevent the framework from becoming messy. The current approach has fewer lines of code than the first approach that only focused on selection screens, because the entire view creation process is clearly separated from the rest now and kept outside of the framework.

(22) "Over the Wire" sending JS, HTML & CSS

Furthermore we can also add extra functionality (JS, HTML, CSS) without extending the framework itself or changing the abap2UI5 frontend app. For instance, let's take the Upload Files App as an example, which has its own custom control that is not part of the framework and is sent "Over the Wire" after calling the app:

App delivering its own JavaScript "Over the Wire"

With any request there is the chance to sent own JavaScript or Custom Controls to the frontend. The abap2UI5 framework just sends it as it is to the frontend. All upcoming requests can now use this JavaScript for example to use Custom Controls in their UI5 Views:

abap2UI5 app sending custom Javascript to the client

(23) As simple as possible

So, we have seen in (22), apps can be made very complex, but the opposite is also possible - we can make them extremely simple. One beautifully minimalistic approach is the use of if_oo_adt_classrun. By implementing just one method, we can generate an output with a single click (F9). This is extremely efficient and was one of the role models for abap2UI5. Here's a comparison of both approaches:

if_oo_adt_classrun vs. abap2UI5

To summarize what we have covered so far, abap2UI5 is built in a highly generic manner, placing most of the responsibility on the user's apps. As a result, we gain a a lot of flexibility and freedom in the app implementation, but we also have full responsibility for the view creation and the program flow. Furthermore we have to keep the following downsides in mind.

(24) Downsides compared to UI5 & RAP

Most notably, compared to UI5, we cannot implement offline capabilities because in such a situation we cannot continuously ask the server after every event to determine what will happen next.

Furthermore, using HANA DB capabilities directly at the frontend leads to problems. By using the same generic HTTP-Service for every app, we have decoupled the UI from the rest. However, in a RAP scenario, they use a typed OData and can directly touch HANA capabilities via a CDS View (and skip the ABAP layer). With this approach, pagination or fuzzy searchs can be easily integrated in UI5 freestyle or RAP apps. The combination of OData-Service directly calling a CDS View of HANA is extremely effective here.

Of course, we can also select from CDS Views in an abap2UI5 app and send the result to the frontend. But implementing this manually requires more effort, and we cannot render a fuzzy search help at the frontend, because we are forced to replace the entire view after every request with this approach. As always, every advantage we gain with abap2UI5, such as flexibility in creating models, comes with a corresponding trade-off of lower functionality in other areas.

Additionally Fiori Elements with all its floorplans & templates is very straightforward and will also get a lot of updates in the future. In the end the wide range of UI5 use cases makes a comparison of the different approaches very difficult and cannot bet finally discussed here. Now, let's continue to the last part of this blog post and take a closer look at the framework's code line.

(25) System Footprint

The system footprint is kept as small as possible, abap2UI5 is based only on ABAP classes without the use of CDS and RAP artifacts. Most of the coding is outside of the framework delegated to the user (21) (22). In total the framework consists only around of 2,300 lines of code, spread over one HTTP-Handler, two interfaces and one database table:

System footprint of abap2UI5

The entire framework logic is implemented in the HTTP-Handler class:

This is all that abap2UI5 does

The functionality focuses solely on the communication between the backend and frontend, controlling the application flow, and creating the view model. We saw the initial GET request in (17). The POST request is handled by this implementation:

AJAX Post Handler

In the end, we get a pure source code-based framework, which offers us the following possibility.

(26) Running Everywhere Apps

Essentially, abap2UI5 generates two strings, one containing an XML-View and the other containing the JSON-View-Model. These strings are then transmitted to and from the frontend. As a result, there is no need for a high ABAP release, as this can be accomplished even with very old releases. This approach allows us to run on both the latest ABAP Cloud stack and on-premise systems, as well as very old releases, making it a release-independent solution. Additionally, we do not necessarily lose access to new UI5 features, as we have the option to bootstrap the UI5 framework at the frontend from a Content Delivery Network (CDN) and use the latest UI5 version even on very old releases:

Local Bootstrapping - UI5 version depends on the SAP release

CDN Bootstrapping - UI5 version independent from the SAP release

As a result, abap2UI5 apps can also be developed to be portable across various SAP systems, releases, and environments. If an app is developed once on ABAP Cloud 2305, it can also be used on lower releases. Similarly, apps developed on older Netweaver releases can run on BTP ABAP Environment or S/4 Public Cloud ABAP Environment. However, for this compatibility to be possible, abap2UI5 and its apps need to be designed to work with both language versions, 'ABAP Cloud' and 'Standard ABAP'. To avoid redundancy, abap2UI5 tries to achieve this by using a single code line.

(27) One-Code-Line

With this approach, the use of dependencies is limited to cloud-released APIs and functions available in lower Netweaver releases simultaneously. To handle this, abap2UI5 only uses SAP dependencies when it is really needed -- for instance in the GUID creation:

GUID creation compatible to ABAP Cloud and Standard ABAP

As you can see, creating methods that are compatible with both 'ABAP Cloud' and 'Standard ABAP' is considerably more complex. Fortunately, abapUI5 only requires GUIDs as a dependency. However, when developing apps, you must be aware of this (and I have no experience if this is feasable). But in the end, it does have a key advantage: abap2UI5 runs on ABAP 2305 and is still portable down to NetWeaver v702.

(28) Compatibility & Downporting

Downporting abap2UI5 code normally would result in a release that is difficult to maintain and debug. To avoid this, abap2UI5 is divided into two repositories: a main repository (compatible from NW 7.50 to ABAP 2305) and a downport repository (compatible down to NW 7.02).

The low-syntax branch is automatically generated using abaplint. The separate branch enables development with all new ABAP expressions available since ABAP v750 while still ensuring that all abap2UI5 features added in the future are automatically downported and available for ABAP v702.

I'd like to extend a thank you to lars.hvam here -- he both recommended using a separated downport version and kindly helped to set abaplint up for this project. At a point when I was tediously downporting everything manually, this was a great shortcut. The functionality of automated ABAP downporting is impressive and greatly improves efficiency. Check out the abaplint dashboard of this project and the tool abaplint.

(29) Contribution

Furthermore it has been great merging every PR that has worked with and improved the project. Thank you at this point to the following who contributed their code: jacques.nomssi, marcbernardtools, Sun-Tassein, christian.guenter, axel.mohnen.ctie lars.hvam And, thank you to those who featured the project in their channels: rich.heilman, thomas.jung, jelena.perfiljeva, paul.modderman.01 And also let's not forget, besides abaplint this framework uses abapGit and benefits from the work of the people who built it:

abap2UI5 runs on every system with abapGit & abaplint

Lastly, I'd like to say that abap2UI5 did not just emerge out of thin air. Since I've started developing in ABAP I've been looking to SCN blog posts on topics like serialization, JSON parsing, HTTP-Communication, OData and UI5. I'd like to express my gratitude to those who've devoted time to sharing their knowledge, this project certainly wouldn't have been possible without it.

(30) Finish & Begin

This was the explanation of the technical background. If you are interested in more information, take a look at the previous version of this project. It provides a more in-depth explanation of the server-client communication and you can see how it all started: abap2UI5 - Development of UI5 Selection Screens in pure ABAP.

Summary

Long blog post short: Inspired by "HTML Over the Wire" (1)(2)(3) we mixed UI and Data together (7) and created an "UI5 Over the Wire" approach by sending the XML-View from the server (6). Then we used a single generic HTTP-Service for all apps (13) independent from the View and Data Model (12). It provides us with great flexibility allowing us to dynamically create Data Models (10) and Views (11) at runtime, resulting in a significantly reduced number of backend artifacts.

Next, we explored various ideas on how the framework reduces its own complexity by avoiding frontend artifacts (17), eliminating extra customizing layers (19), and separating the view from the framework (21), as well as app-specific JS or HTML (22). Finally, we got a pure source code approach with only one database table, two interfaces, one class and just 2,300 lines of code (25). It is developed in a single code line (27), making it cloud and on-premises ready and downportable to old releases (28). Its apps in combination with abapGit can be developed that they are running on nearly every release (29).

All in all, with abap2UI5, you need to disregard some common rules: there is no separation between View and Model in the HTTP communication (12), HTML & JavaScript are stored directly in the source code (17) (22), we don't use OData or RAP (7) and there are other downsides to consider (24). However, if you accept all of this, you get a very minimalistic approach where you only need to implement a single method to develop standalone UI5 applications (15).

Conclusion

Going into this, I had no idea whether or not this idea would be interesting or find its audience. It surprised me how many people were installing it, and it really inspired me to keep putting ideas into the project over the past couple month. I’m not sure how many of these apps will find themselves in a productive system or if they’ll just stay as testing or tooling for developers, but regardless I hope working with abap2UI5 has been fun. I’d like to thank everyone who was willing to give this approach a try and 'hop over the wire'. 🙃

In the next part, we will see how the project is organized on GitHub with the tools abapGit, open-abap and abaplint.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, leave a comment or create an issue.

Error "Person Already Hired" While Replicating Employee Master Data From SAP SuccessFactors Employee Central To SAP S/4HANA Or SAP ERP HCM System.

2023-06-11T09:29:51+02:00

Hello Reader,

How are you? I hope you are fine. Today I will be sharing with you one of the reasons of the error “person already hired” while trying to replicate the Employee Master data from SAP SuccessFactors Employee Center to SAP S∕4HANA . If you are an Integration Consultant and you are a beginner at Replication of Employee Master Data from SAP SuccessFactors Employee Center to SAP S∕4HANA then this blog is for you. Even if you have a little bit of experience, you can also read the blog and provide any comments or suggestions about the topic and also provide your valuable feedback.

So let us start the blog.

If you are integrating the SAP SuccessFactors Employee Center with the On-premise SAP S∕4HANA system then the first step is data migration. You first need to migrate the existing employee master data and organizational data from SAP S∕4HANA to SAP SuccessFactors Employee Central. It is strongly recommended to use standard SAP Infoporter tool for the migration in order to avoid any errors while replicating back the employee master data to SAP S∕4HANA.

But you can also migrate the data by custom approach for example by CSV import of all data into SAP SuccessFactors Employee Central. Which in turn can cause problems while replicating master data back to SAP S/4HANA.

Why not using an SAP infoporter tool can cause problems?

When we use the standard SAP infoporter tool for migration of data from SAP S/4HANA to SAP SuccessFactors Employee Central, all the employees that we migrate from SAP S/4HANA to SAP SuccessFactors Employee Central will have their PERNR ( employee id / userId) stored in a Employee Key mapping table (ECPAO_EE_KMAP). So that when we run the replication of all employees from SAP SuccessFactors Employee Central to SAP S/4HANA, the existing PERNR are utilized instead of assigning new PERNR.

If you do not use the standard approach for migration of data then the Employee Key mapping table would not get populated. When we run the replication of all employees from SAP SuccessFactors Employee Central to SAP S/4HANA, all the employees will try to create a new PERNR in SAP S/4HANA. But for employees that already exist in SAP S/4HANA with the same PERNR, the replication process would throw an error that says “person already hired”.

Now you are not trying to rehire the employee but still you are getting this error. This is because when the system is checking for the PERNR in employee key mapping table (ECPAO_EE_KMAP), it does not find it so the program considers it as a new employee so it tries to hire it in the system but since the employee already exist in the system, it will resist and hence throw the error “person already hired” ( as shown in screenshot below).

Error person already hired

Resolution:

Now that you have used a custom approach to migrate the data from SAP S/4HANA to SAP SuccessFactors Employee Central and you do not have any entries in employee key mapping table (ECPAO_EE_KMAP) for the existing employees in SAP S/4HANA, you would have to populate the ECPAO_EE_KMAP table for all the employees that already exist in SAP S/4HANA.

Since there is no standard report for this, you would need to create a custom report to fill this data in the ECPAO_EE_KMAP table. You can check the table in transaction se16 and then search for ECPAO_EE_KMAP table.

Now try to replicate the employee master data, you will no longer get the error “person already hired”.

Conclusion:

In this article, we can conclude that we should always follow the standard approach (Infoporter) while migrating data from SAP S/4HANA system to SAP SuccessFactors Employee Central. But if you have already followed the custom approach, we still have a work around as given in this blog.

Similar articles:

https://userapps.support.sap.com/sap/support/knowledge/en/2758271

https://answers.sap.com/questions/209772/employee-key-mapping-from-ec-to-sap.html

Thank you for reading this blog. Please comment if you have any queries, also share your valuable feedbacks.

Thank you,

Zainab Fatima

How to provide Developer Access Key/ Object Keys in SAP

2023-06-19T15:44:50+02:00

My Second Blog post!

In this blog, I will explain on how to generate developer keys or object access keys & also explain on the below topics:

What is Developer Key

What is Object Key

Which table stores them?

Developer Key:

Developer key is required to register user as developer in SAP service marketplace so that they perform customization in SAP system. Whenever developer try to create and changes program (or) object, it will ask to enter developer key to perform the changes.

There are two types of objects:

Repository Objects

Customer specific objects

Changing a repository object requires you both Developer Key and Object Key (also called as Object Access Key, Developer Access Key).

Object Access Key:

For every object you change it will ask for an Object Access key, with which can change SAP source or SAP dictionary object; this task is in general done by Basis team. User sends a request to Basis team for generating the key.

Note: In some cases, security team provides Developer access key or object key.

The developer key is issued by SAP for an individual developer user account, and Object access keys are issued for the development object that needs to be changed.

However, changing a program /object starting Z* i.e. customer specific object, you just need a developer key.

It can be access in Service Market Place at http://service.sap.com/sscr

Steps to register developer key:

1. Select Launch the SCCR Application, a new dialog box appears to enter S-User ID & password. Security/basis people will logon with their S-User ID credentials.

2. On the left pane--> you will see the option Developer--> click on developer.

3. On the below right screen, you will see an option to register developer. Click on Register button. A pop-screen will appear.

4. Enter the user ID, whose ID needs to registered as a developer & in the below tab select the SAP system installation number.

5. SAP installation number can be find from SAP system -->status screen.

6.Once the details are filled, click on submit to complete the process.

7. You will get a message on top screen that the developer is register successfully & you can see the developer key in the message. copy & provide these details with the user.

Developer access key details are stored in a DEVACCESS table if user is already registered as a developer for a particular SAP system.

Execute SE16 t-code --> enter the table DEVACCESS--> Enter the User ID & execute to see the DEV key details for the user.

Steps to register Object key:

1. Select Launch the SCCR Application, a new dialog box appears to enter S-User ID & password. Security/basis people will logon with their S-User ID credentials.

2. On the left pane--> you will see the option Objects--> click on object button.

3. On the below right screen, you will see an option to register object keys. Click on Register button. A pop-screen will appear.

4. Enter the Basis release details, Program ID, Type & Object name details received from user & select the installation number.

5. SAP installation number can be find from SAP system -->status screen.

6.Once the details are filled, click on submit to complete the process.

7. You will get a message on top screen that the Object key is register successfully & you can see the object key in the message. copy & provide these details with the user.

Tables storing them:

Developer access key details are stored in a DEVACCESS table if user is already registered as a developer for a particular SAP system.

Execute SE16 t-code --> enter the table ADIRACCESS--> Enter the Program ID, Type & Object name & execute to see the DEV key details for the user.

2501703 - Frequently asked questions about SAP Software Change Registration (SSCR)

I hope in this blog you have learned what is a developer key or object access key, the steps to generate them & the tables storing them.

In case you have any queries, leave a comment below. I will help you.

Or you can post your questions in our community Ask Questions

What is Condition Update in SAP SD

2023-08-12T16:36:00+02:00

As an SAP SD consultant, I come across many such magical configurations and settings after analyzing the screens day in and day out. Here are my findings for all SAP Consultants out there, making their life easier.

So, today we are going to talk about the use of "Condition Update" in SAP SD. This is one of the most commonly asked questions in SAP SD Interviews too.

Pre-req: You should be well aware of SAP SD Pricing Procedure configuration and assignment.

What does every SAP Consultant know?

"Condition Update" is one of the characteristics of "Condition Type" that helps control discounts. It lets us set limits on how much discount or how many orders can get a particular discount. It's useful to manage discounts and make sure they are used the way we want.

Now what is Condition Type? Condition type is an element assigned to each category of pricing element while setting up the pricing. For eg: Freight, Discount, Surcharge, Tax, List Price, Min Order Charge, etc are all different type of pricing elements that sums up to reach the final price for a product. These are all Condition Types. Enough of condition type! (Tcode: V/06) Can we get back to the original topic? CONDITION UPDATE!

So, the condition update is a boolean attribute that can be checked or unchecked in the Condition Type configuration screen. This attribute sets a limit on Condition type based on the below restrictions:

Maximum Cond. Value

Maximum Number of Sales Orders

Maximum Cond. Base Value

If either of the above settings is maintained then the condition type would behave according to it. If Max. cond. value is reached then the condition type would not trigger an additional discount.

Which information do SAP Consultants miss out on?

Well, all of the above makes sense, but how does it work in action? How system identifies that the above condition type is not applicable anymore as it had a "condition update" setup as per either of the three criteria?

Let's dive deeper.

Condition Update in action:

As we enable this "Condition Update" configuration in the condition type config screen, its impact would be visible while maintaining the condition record (Tcode: VK13). Each condition record created for the above condition type would have the option to set up any of the below three condition update settings.

Maximum Condition Value:

For Example: if we set up a Maximum Condition Value of 100 Euros in the discount condition record for a discount condition type, that means this condition type would be triggered in orders and show the corresponding discount condition value till the maximum discount of 100 Euros is not reached. If the discount condition value comes out to be more than 100 Euros, then the discount condition value will reflect a maximum discount of 100 Euros only and not the expected discount of 125 Euros.

MRP of Heater: 100 Eu

Discount scheme	25 Eu per heater
Max Cond. Value	100 Eu

Transactions	Prod	Qty	MRP	Discount	Expected Discount
Order 1	Heater	5	500	100	125
Order 2	Heater	2	200	50	50

Real-time scenario: If you buy a heater from us, you will get a discount of 2000 per piece maximum of up to 10000 Rs.

Maximum Number of sales orders:

For Example: If the Maximum Number of sales orders = 2 for X001 condition type.

The condition type X001 would not trigger from the 3rd order onwards which would have otherwise expected.

Discount Scheme	25% per heater
Max no. of orders	2

Transactions	Prod	Qty	MRP	Discount	Expected Discount
Order 1	Heater	5	500	125	125
Order 2	Heater	2	200	50	50
Order 3	Heater	1	100	0	25

Real-time scenario: 50% discount for the first three orders.

Maximum Cond. Base Value:

It is named as Base value but it is actually a quantity indicator.

For Example: If we set up a Maximum Cond. base Value of 10 Each for a discount condition type X001. That means this condition type would be triggered in orders and show the corresponding discount till the maximum discount of 10 quantities of that line item is not reached. If the quantity comes out to be more than 10 Each, then the discount condition value will reflect a maximum discount of 10 quantities only and not what is otherwise expected.

Discount Scheme	10 Eu Discount per heater for 10 heaters
Max Cond. Base value	10

Transactions	Prod	Qty	MRP	Discount	Expected Discount
Order 1	Heater	12	1200	100	120
Order 2	Heater	5	500	50	50

Real-time scenario: If you buy a laptop from us, you will get Rs.1000 discount per laptop for the first 4 quantities.

Now how system remembers these updates like 9 quantities are ordered and now only 1 more quantity can have a discount. Post that, stop giving discounts. That is stored in an info structure: S071 (Tcode: OMO1, Table: S071). Orders containing that condition type (with condition update) would be recorded in this info structure and the same record would keep updating and help determine the restriction during sales order creation.

Wait a sec, What is info structure? How it's different than regular tables? Well! info structure is again a table but is maintained for a different purpose. This table is created for operative purposes, that stores data along with frequency. Three main fields of info structure are period units, characteristics, and key figures. Period stores frequency like a day week, month, etc, and characteristic is master data that stores data like plant, company code. etc and key figures store transactional data like sales volume, value, etc. Want to know more? click here.

Key Pointers:

This config. is generally used during NPI (New Product introduction) when the seller tries to increase product adoption. So, you might not find it used often.

For percentage condition types (like K007), Maximum Cond. Base Value - Condition Update setting is not present as a parameter to restrict condition types.

SAP Gap: SAP ECC allows only "01"-"03" as input for the "Maximum Number of Orders" field. For more than that, additional ABAP changes (code changes) would be required.

Generally, "Maximum Cond. Value" is utilized for providing discounts. So when you maintain it in the VK13 condition record, make sure you input "-" minus along with the amount and unit of measurement as well.

"Maximum Number of sales orders" is generally used for the condition types where "Calculation type" is equal to a percentage (Calcul. Type: A).

"Maximum Cond. Base Value" does not work for the condition types where "Calculation type" is equal to a percentage (Calcul. Type: A).

Pricing Tables-fields: Maximum Cond. Value = KONP-KOMXWRT, Maximum No. of Orders = KONP-ANZAUF, Maximum Cond. Base Value = MXKBAS.

I hope this will help you. Please leave comments in case I missed anything.

Thank you.

Happy learning 🙂

What is Sales Area in SAP SD?

2023-08-15T11:22:18+02:00

This is probably the first thing you learn when you start with SAP SD Module. I know there are many articles, blogs, and videos on this topic and you probably would think what else this article is going to offer?

Well! Stay with me for a few more minutes.

Let's start with:

What does every SAP Consultant know?

In simple terms, Sales Area = Sales Org + Dist. Channel + Division. We maintain this assignment in SPRO.

By definition, Sales Area is a combination of three organizational units that define customer and material reach. It excludes non-required or unfeasible combinations of different organizational units. It looks pretty simple, but what if I tell you have missed a lot of things?

Components of Sales Area:

Sales Org: It is an organization unit that sells, distributes, and negotiates terms of sales for products.

Distribution Channel: This is a channel via which products/services reach customers. For e.g.: Retail, Online, E-commerce, and direct sales.

Division: It is a grouping of broad categories of products in one organization unit. For every division, you can make customer-specific agreements on, for example, partial deliveries, pricing, and terms of payment.

Which information do SAP Consultants miss out on?

The Sales Area assignment sets the base of your ERP Implementation. Most of the companies which are already on SAP ERP have this assignment in place and would rarely change it. The scenario where a company would need a new Sales Area assignment would be during introducing a new Distribution Channel or introducing a new division of products.

Sales Area is more than just an assignment. We should define sales areas considering a lot of factors like Pricing Strategy, Legal observation, Business Practices, etc. It touches every point of the Order to Cash (OTC) cycle from quotation to revenue recognition. Let's dive deeper to understand how Sales Area and its associated data impacts on overall organization's ERP setup:

What all gets Influenced by the Sales Area:

Pricing: One of the most important impacts of the Sales Area is on product pricing strategies. We can maintain different product pricing in different Sales Areas. We can configure SAP Sales order pricing for the same product & customer based on Sales Area.

Master Data Defaults: There are some sales region-specific attributes that should be present in the system prior to successful order processing. We store all these customer-specific attributes in Customer Master Data (Tcode: VD03) and material-specific attributes in Material Master Data (Tcode: MM03) under Sales Area Specific section. If plan to create only Sale Area but you see a lot of multi-valued attributes and you cannot fit them all under one sales area, then probably you should go back and check if you need to create one more sales area? Some examples of these attributes are: Customer Group, Sales District, Default Currency, Terms of payment, Invoicing Dates, Shipping conditions, Delivery priority, Business Partners, Material Group, Unit of measurement, Tax settings, etc. This information gets defaulted in the sales order as per your selection of Sales Area but can be modified in the sales order manually if needed. Remember, changing important parameters like tax setting, and incoterm in sales orders will re-trigger the order pricing.

Reporting: Sales Area is your first differentiator in all your business reports. Be it sales orders created in the past month, or orders invoiced in the past year, sales area becomes one of the most important factors for business reports.

Sales Order Processing: Each sales order you process in SAP requires Sales Area as a pre-requisite. So when you provide a sales area, you narrow down the region & rules in which customers and materials should transact.

Shipping & Deliveries: You would say that shipping point determination is determined based on the storage location, delivering Plant, and loading group. So the Sales area is not directly involved. However, one attribute, "Delivering Plant" is determined from Master Data - Sales Area tab. Delivery attributes for the same customer may vary for each sales region and hence we should have sales area data as an umbrella to hold all sales region-specific master data attributes.

Credit Management: Credit limits, exposure, and risk categories may vary per sales region.

Localization: Sales Area Data allows localization of sales operations, considering local business practices, languages, and legal requirements.

Compliance and Legal Requirements: Different sales areas might have unique legal and compliance requirements, which can be managed effectively through sales area data.

Listings & Exclusions (L&E): When any organization receives an order to produce a product exclusive to a particular client, then they would have to hide that product from other clients. In that case, you use the L&E feature in SAP. This feature allows you to set the rules based on Sales Area.

Intercompany Sales: This is an internal sale between two wings of the same company. In this scenario, the purchasing company should be extended to the Sales Area of the Selling Company.

Remember: Once you create Sales Area Data in Customer or Material Master, you can not delete it.

I hope this will give you a holistic perspective.

For Sure, I am missing many more such Sales Area dependencies. Please add them to the comments.

Happy learning 🙂

abap2UI5 - (8) Repository Organization: Working with abapGit, abaplint & open-abap

2023-08-21T08:07:06+02:00

Welcome to part 8 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

This post delves into the repository organization of abap2UI5 and its utilization of GitHub, abapGit, abaplint and open-abap. In my prior experience, I was mainly working on projects following classic CTS and only occasionally using abapGit to pull in open-source projects. However, this project offered a valuable opportunity to understand how to establish a thoroughly tested Git repository for the ABAP community, and it was a great learning experience! While seasoned ABAP developers might be familiar with these tools, my aim is to introduce them to those less acquainted with them.

This post will lead you through the abap2UI5 repository setup, step by step, beginning with abapGit, and then progressively introducing additional settings and tools.

Blog Series & More

You can find all the information about this project on GitHub and stay up-to-date by following on Twitter. Also, make sure to explore the other articles in this blog series.

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap (this blog post)

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Git - GitHub & abapGit

GitHub - Working with Separated Branches

abaplint - Syntax Check & Code Compatibility

abaplint - Static Code Analysis

abaplint - Quickfixes

abaplint - Cross Checks

abaplint - Dashboard

GitHub - Contribution with Forks & Pull Requests

GitHub - Branch Protection

open-abap - Downport Functionality

open-abap - Unit Testing

open-abap - abap2UI5-web

Conclusion

Let’s begin with the first topic.

1. Git - GitHub & abapGit

The codebase of abap2UI5 is version-controlled in a public Git repository on GitHub. This means that the code is not managed on an SAP system, as is typically done with ABAP projects and from where it can be transported to other systems. Instead, it is centrally stored in a public repository, allowing the current state of the project to be accessible at any time to everyone and installable on any system:

GitHub - Public Repository of abap2UI5

Before making changes, the current code state is initially pulled (downloaded) onto a private ABAP system and after implementing the changes, the updated code is always pushed back to the public GitHub repository. The current coding state on the ABAP system is thus used solely as temporary storage:

GitHub - Code Changes of the public abap2UI5 repository

And the leading and authoritative code version is the one stored on GitHub:

GitHub - Source Code of abap2UI5

In addition to public accessibility, this approach offers the advantage that the entire project exists independently of an ABAP system, and changes can be developed periodically on various systems, such as shared ABAP Cloud Trial, ABAP Dev Edition, or S/4. For instance, a significant portion of the project was created using the shared ABAP Cloud Trial on which you cannot guarantee that no one will modify your code or that your changes won't be removed after a few days. But storing the code on GitHub solves this concern.

Furthermore, all the features of GitHub can now be utilized. To highlight just two examples, take a closer look at the issue management:

GitHub - Overview of Issues

Or tracking code changes with the commit history:

GitHub - Commit History

This significantly enhances the transparency of the entire project! Changes can be retraced, actual problems are documented in issues, new requirements can be collected and evaluated. This is only possible because of the open-source project abapGit, which integrates every ABAP system from version 702 and higher with GitHub.

abapGit - Git Client for ABAP

If you're new to Git and abapGit, the following blog post is a good starting point. A big thank you to this excellent tool and and the team behind it.

2. GitHub - Working with Separated Branches

Given this setup, a question arises: what happens when I pause my work and fail to complete my current task? It's possible that I've just begun making a change but have been unable to test and finish it, which leaves the code in an incomplete state. Pushing this into the main branch would result in a scenario where everyone could potentially download a non-functional abap2UI5 version containing errors.

To address this, the code within each git repository can be segmented into multiple branches. For simplicity, we'll only divide the repository into two branches now. The initial repository stands as our main branch, housing the latest functioning "stable" version and remains available for others to download. The second branch assumes the role of a development branch ("dev"), which is a duplicate of the code and is intended for active changes:

GitHub - Separated Development Branch for working on a New Feature

The "dev" branch contains the changes until the new feature is ready. Upon completion, it is merged into the main branch with a Pull Request (PR), making the feature accessible to everyone:

GitHub Pull Request - Incorporating Changes from the Dev Branch into the Main Branch

Repository after Merge - Both Branches Now Contain the Updated Source Code

As you can see the separate branch ensures that only finalized and tested features find their way into the main branch.

3. abaplint - Syntax Check and Code Compatibility

But how can we guarantee that the code we push to the main branch, tested on one system, will function across all the other ABAP systems it's downloaded to?

As previously mentioned, a significant portion of abap2UI5 is developed on a shared ABAP Cloud Trial System, containing types and functions that are unavailable on lower releases like NetWeaver v7.50. Additionally, there are two language flavors: 'Standard ABAP' and 'ABAP for Cloud,' both requiring consideration. Fortunately, the open-source project abaplint addresses these concerns:

abaplint - Static Code Analysis

The tool abaplint can be setup in various ways; in the case of abap2UI5, it is used as a GitHub Addon:

abaplint - Installation as a GitHub Add-on

For the project-specific setup, simply add an abaplint.json file to the repository. This file contains all settings and is structured as follows:

abaplint - Configuration via abaplint.json

First we aim to ensure that the written code is executable down to Netweaver version 7.50 by configuring the following option in line 12:

  "syntax": {

    "version": "v750",

You can choose the version that suits your needs. With this setup, abaplint now checks the source code after each change, ensuring syntax validity down to ABAP v7.50:

abaplint - Checking the ABAP code

abaplint - Identifying Incompatible Syntax

In this case we used the "cmis_string" type, which is unavailable in NetWeaver 7.50 and causing findings:

abaplint - Detailed Overview of Identified Issues

These checks provide us with the opportunity to address issues before they are integrated into the main branch and preventing potential problems during the installation on other systems. This serves as an aid in identifying mistakes at an early stage and reduces significantly the effort required to solve them. After fixing the error, abaplint performs another check:

abaplint - Checks Passed Succesfully

This time, no issues are found anymore, and the code changes can be merged into the main branch with confidence it'll function on any release down to NW 7.50. The setup now appears as follows:

abap2UI5 Setup - Repository with abaplint Syntax Check for Different ABAP Systems

But this was just the beginning; abaplint is more than only a syntax checking tool to regain control over all the different ABAP releases and language flavors (although this alone would be impressive enough) -- it is a static code analysis tool with a lot of more possibilities, which we'll delve into next.

4. abaplint - Static Code Analysis

When developing new features, static code checks play a significant role in enhancing code quality. We can achieve this using abaplint and have access to over 159 distinct rules. You can check them here:

abaplint - Rules for Static Code Analysis

The configuration file shows which ones are activated for the project:

abaplint - Rule Configuration via Package.json

For example, classic checks like "no database access in loops" (here):

   "db_operation_in_loop": true,

Or ABAP Style Guideline-influenced recommendations, such as better boolean usage (here):

 "prefer_xsdbool": true,

Checks for unused variables and types (in cases where we might have overlooked this in Eclipse)(here):

    "unused_types": true,

    "unused_variables": {

      "severity": "Error",

      "exclude": ["z2ui5_cl_fw_utility.clas.testclasses.abap"],

      "skipNames": ["lv_dummy", "i_mv_editor"]

    },

Analyses of the overall code complexity of functions, for example the cyclomatic complexity (here):

"cyclomatic_complexity": {

    "exclude": [],

    "severity": "Error",

    "max": 20

  }

Or checks enhancing readibilty, like avoiding 'exporting' in method calls (here):

"exporting" : true

I recommend reviewing all of these rules; some are vital for quality maintenance, while others suit personal or project-specific needs. Collectively, they elevate the codebase significantly. With activated rules and abaplint as a GitHub AddOn, the code is checked now with each push to the main branch:

abaplint - Pull Request successfully checked with abaplint

Of course, this isn't a guarantee that everything will function flawlessly, but it does provide a robust additional safeguard. The project setup appears with this as follows:

abap2UI5 Setup - Repository Organization with Static Code Checks using abaplint

But why not perform this directly in Eclipse and conduct static code analysis with ATC? One downside is that ATC checks are system-dependent, which means that if I want to make changes today on system A and continue tomorrow on system B, I have to set up ATC again. This can also pose challenges when different people on various systems collaborate. With abaplint, we can carry out centralized static code checks at the repository level on GitHub, which is a significant advantage over ATC.

5. abaplint - Quickfixes

Abaplint also provides Quickfixes as we know them from ATC. They are accessible directly on GitHub:

abaplint - Quickfixes on GitHub

Alternatively, they can be accessed via the command line. In the following example, we use GitHub Spaces. After installing abaplint, we can add a new check and execute automated Quickfixes:

abaplint - Installation and Automated Quickfixes (Part I)

abaplint - Installation and Automated Quickfixes (Part II)

In this case, a fix is added to remove double spaces (more complex fixes are also available). You can observe abaplint's code adjustments:

abaplint - Code Adjusted by abaplint

Lastly, we simply need to merge these modifications back into the _dev branch concluding the process -- everything only takes a few moments. Visit the repository and explore for yourself! Begin by initiating a new GitHub Codespace and executing the following commands in the terminal:

Install the abaplint CLI globally by running:
```
npm install @abaplint/cli -g
```

Perform automated code fixing by entering:
```
abaplint --fix
```

But might we be encompassing functionalities that are also offered, for example, by ABAP Cleaner? While ABAP Cleaner is unquestionably a valuable tool, abaplint boasts a multitude of capabilities beyond code verification and aesthetics, as we'll explore further later on. But the reason I once again prefer abaplint is because of its project-level configuration on GitHub, which eliminates the requirement to install and set up a local Eclipse AddOn (a step that would also be necessary for everyone undertaking a code modification) which saves a lot of time.

For further information on setting up abaplint you can also check out this blog post and now let's delve into another very useful feature of this tool: its cross-checks.

6. abaplint - Cross Checks

The abap2UI5-samples repository depends on artifacts from abap2UI5. For example, when both are installed on an ABAP server, syntax checks verify method calls and API compatibility. But how to manage these dependencies when both repositories are on GitHub, and changes occur independently in different systems? The abaplint Cross Check offers a solution for this. Project dependencies can be customized in the abalint.json file of each repository, as demonstrated here:

abaplint - Define Dependencies

Now, modifying a method in the main abap2UI5 repository automatic triggers checks for syntax compatibility of the samples repository. To illustrate, we change the importing parameters of an abap2UI5 method:

abap2UI5 - Incompatible Code Change in the Main Repository

Attempting to update the abap2UI5 main branch with a PR now encounters abaplint cross-check failures and triggers errors:

abaplint - Cross Check Failures due to Missing Importing Parameter used by the Samples Repository

The more apps utilizing abap2UI5, the harder managing dependencies gets. Cross-checks significantly assist in handling this complexity. If you have a GitHub project using abap2UI5, set up abaplint and customize a dependency to abap2UI5. This way, you will receive early warnings about incompatible changes. The repository configuration is now as follows:

abap2UI5 Setup - Repository with abaplint Cross-Checks

For more details about cross-checks, refer also to this blog post.

7. abaplint - Dashboard

Abaplint is powerful, with much more to explore, while we only focused on a few aspects. For a good overview of all features you can also take a look at the dashboards of public ABAP projects using abaplint:

All these charts and statistics provide a comprehensive and transparent overview of the code quality of each project. This can also help you make informed decisions when you are uncertain about public repositories and whether you want to download it or not.

8. GitHub - Contribution with Forks & Pull Requests

Abap2UI5 is open source and developed alongside other projects or during free time. Contributions to this project are greatly appreciated, check out this contribution guideline. But what happens when someone wants to make a modification to the actual source code of the project? In this case they can create a Fork of the repository, obtaining a personal copy of the complete repository to implement changes:

GitHub - Create a new Fork

Upon completion, they open a Pull Request, notifying the abap2UI5 repository owner about the change:

GitHub - Create a Pull Request from a new Fork

The changes can now be reviewed by the repository owner and additionally abaplint runs its checks. Very useful: The PR creator is also promptly notified about the abaplint results upon opening the PR:

GitHub - abaplint checks Pull Requests

On this way the contributor gains access to all the essential information regarding the required Code Standards of the project and is enabled to improve the code of the Pull Request also by himself. The inclusion of abaplint checks on GitHub streamlines this contribution process and significantly reduces coordination efforts. The whole setup appears now as follows:

abap2UI5 Setup - Contribution with Forks

Check out all Forks of abap2UI5 here and see who already contributed to the project here.

9. GitHub - Branch Protection

When collaborating, another feature enhances teamwork. All abaplint checks configured thus far (syntax check, static code checks, cross checks) can be made mandatory. This prevents accidental pushing of changes to the main branch or bypassing these tests. This feature is provided by GitHub's branch protection rules:

GitHub - Setup Branch Protection Rules

Now, merging is deactivated until all tests run successfully, and the repository setup appears as follows:

abap2UI5 Setup - Repository with Branch Protection

10. open-abap - Unit Testing

Now, returning to code quality: Good code quality encompasses more than just static checks and one important aspect we haven't examined yet are unit tests. ABAP unit tests are typically executed on the ABAP Server (initiated through Eclipse or a background job):

abap2UI5 - Unit Tests running on an ABAP Server

But how do we ensure Pull Request submitters perform unit tests, confirming their changes are well-tested? Therefore, in addition to conducting static code checks, it is essential to run unit tests on GitHub as well. The challenge lies in being able to run these tests in a non-ABAP environment and automating this process.
To achieve automation, we can leverage GitHub Actions and for running unit tests we can use the open-source project open-abap:

open-abap - Any platform ABAP, serverless ABAP, ABAP on Node.js

Open-abap transpiles ABAP code into JavaScript, enabling its execution on a Node.js server. This capability permits us to run unit tests on Node.js directly on GitHub within a GitHub Action. The configuration for this action looks like this:

GitHub Action - Unit Tests with open-abap

With each code change the unit tests are now running as you can see for example here:

GitHub Action - Running Unit Tests with open-abap

This feature is truly remarkable! It decouples the entire testing process from any specific ABAP server and ensures that only thoroughly tested code makes its way to the main branch. The project setup is as follows now:

abap2UI5 Setup - Running Unit Tests with open-abap

11. abaplint - Downport Functionality

After configuring multiple static checks and unit tests, we now circle back to where we began: Syntax checking for different systems. While we have ensured compatibility down to ABAP 750, let's now delve into what I consider one of abaplint's most valuable features: its downport functionality.

It's somewhat discreetly accessible as a quick fix, yet it holds a strong functionality playing a significant importance for the project. This function facilitates automatic downporting from higher releases to lower ones. In practical terms, this means we can maintain the main branch using 750 syntax with all its new language features, while still ensuring the project remains installable on an ABAP 702 system through abaplint's downport capability.

The function can be executed by adjusting the syntax to 702 in the abaplint configuration and then initiating the downport via automated quickfixes. You can see a demonstration here:

abaplint - Downporting 7.50 Syntax down to 7.02 Syntax (Part I)

abaplint - Downporting 7.50 Syntax down to 7.02 Syntax (Part II)

Check the downport repository to see that all new language features are downported to compatible 702 syntax:


Before: 7.50 Syntax	After: 7.02 Syntax

Furthermore, to eliminate manual effort, this process can be also automated using a GitHub Action, similar to what we have already employed for unit tests. We establish an additional downport repository that automatically receives updates with every code change from the abap2UI5 main branch. The GitHub Action responsible for this task is configured here:

GitHub Action - Automated Downporting with abaplint

And the downported code is stored here:

abap2UI5 - Downport Repository

This is once again an impressive feature! Attempting to downport every abap2UI5 version manually would remain unfeasible especially in a hobby-like project. And beginning development entirely in 702 would render the code quite challenging to understand and maintain (not to mention, it would also be unenjoyable to write).

Ultimately, we add now one final GitHub Action which tests and guarantees the error-free downportability of the code before merging it into the main branch. As a result, the definitive setup for abap2UI5 is as follows:

abap2UI5 Setup - Final Configuration

12. abap2UI5-web with open-abap

Details of the tools' inner workings are beyond this article's scope. Essentially, during unit tests, code is initially downported to version 702 and transpiled to JavaScript. It's then executed on a Node.js server. However, if it's executable there, why not directly use Node.js to use abap2UI5?

As a final showcase, let's turn our attention to the project abap2UI5-web, which demonstrates the capabilities of all the tools we've utilized in this blog post. In this project, the complete abap2UI5 source code is transpiled and executed on a Node.js server. This enables the launch of abap2UI5 apps directly from GitHub Codespaces without any reliance on an ABAP server.

Don't miss to try this out yourself! Simply navigate to the repository and initiate a new GitHub Codespace. Then, open a new terminal and execute the following commands:

npm install

npm test

And that's it! You can now try abap2UI5 apps on a Node.js server. Explore this final demonstration:

abap2UI5-web - Running abap2UI5 on Node.js (Part I)

abap2UI5-web - Running abap2UI5 on Node.js (Part II)

The ABAP Server is now entirely bypassed! Regard this as an experiment, yet it underscores the potential that these tools hold for the future. Can we also create UIs in ABAP using browser based playgrounds similar to those found in UI5? The capability to directly modify and execute ABAP code in a browser is still available as you can try here and here:

ABAP Code transpiled to JavaScript (Demo)

abaplint running on open-abap (Demo)

If you want to learn more about this topic, check out this blog post.

13. Conclusion

This concludes the journey through the tooling utilized by abap2UI5. As you have likely gathered from this article, I am truly impressed! I never anticipated such seamless integration of these tools (abapGit, abaplint, open-abap) with ABAP, a language deeply intertwined with SAP's proprietary environments and solutions (SE80, ADT, CTS or gCTS).

Going the open-source way and configuring these tools on GitHub for an ABAP project has been an enlightening experience! Many thanks to lars.hvam for the exceptional work and support in setting this up, as well as to all other contributors who have played a role in developing these tools. 🙏

Their continuous efforts over the years in developing these tools have not only made organizing an ABAP Project on GitHub possible but have also elevated Static Code Checks and DevOps to a very high standard. Attempting to achieve all of this without these tools or solely on an ABAP Server would have required much more effort (or maybe even been impossible).

I hope that this article sparked your interest and motivated you to give these tools a try. Perhaps you now also want to manage your upcoming ABAP project with abapGit and abaplint? Feel free to share your ideas and experiences, or if there's something I missed out on, I welcome your insights.

In the next part, we'll explore various new features added over recent months to abap2UI5.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, leave a comment or create an issue.

abap2UI5 - (9) Update I: Community Feedback & New Features - September 2023

2023-09-11T07:47:21+02:00

Welcome to part 9 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

In the last few months, a bunch of new features – both big and small – have been added to abap2UI5. Some were in response to issues, some from pull requests and some were inspired by SAP UI5 documentation. These all work to further enhance the functionality of abap2UI5 – which we'll explore in this blog post.

We'll begin with tree controls and move on to partial rerendering with model updates & nested views. Then we explore the use of dynamically created data models, for example, for importing CSVs. Additionally, we'll examine additional UI5 controls like Navigation Container, Gantt Charts, Planning Calendars, Message Managers, and extensions related to Excel Downloads and Generic Search Helps. Finally, we'll delve into a full demo app and explore the use of abap2UI5 in different ABAP extensibility scenarios.

Blog Series & More

You can find all the information about this project on GitHub and stay up-to-date by following on Twitter. Also, make sure to explore the other articles in this blog series.

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023 (this blog post)

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This post covers the following areas:

Tree Controls

Partly View Rendering with Model Updates

Partly View Rendering with Nested Views

Displaying Dynamic Data with S-RTTI

CSV Upload/Download

Excel Upload/Download

Navigation Container

Visualization with Planning Calender, Gantt Charts and Process Flows

Message Manager

Generic Search Help

Developer Code Challenge

Demo & Samples Repository

Conclusion

Let’s begin with the first topic.

1. Tree Controls

In addition to displaying tables and lists, it is now also possible to use controls based on tree models. This enables the visualization of hierarchies:

abap2UI5 - Displaying UI5 Tree Controls

Among many other use cases, tree structures can also be used to create popups for selecting items:

abap2UI5 - Popup with Tree Control to Select an Item

To generate the output shown above, you need to define a nested structure in ABAP as follows:

TYPES: 

    BEGIN OF ts_tree_row_base,

             object TYPE string,

             col2   TYPE string,

             col3   TYPE string,

             col4   TYPE string,

    END OF ts_tree_row_base.

 

TYPES: 

    BEGIN OF ts_tree_level2.

             INCLUDE TYPE ts_tree_row_base,

    END OF ts_tree_level2.

 

TYPES tt_tree_level2 TYPE STANDARD TABLE OF ts_tree_level2 WITH KEY object.

 

TYPES:

    BEGIN OF ts_tree_level1,

             INCLUDE TYPE ts_tree_row_base,

             categories TYPE tt_tree_level2.

    END OF ts_tree_level1.

 

TYPES tt_tree_level1 TYPE STANDARD TABLE OF ts_tree_level1 WITH KEY object.

And the UI5 Tree Control is used in the view definition:

DATA(tab) = page->tree_table(

        rows = `{path:'` && client->_bind( val = mt_tree path = abap_true ) && 

               `', parameters: {arrayNames:['CATEGORIES']}}` ).

tab->tree_columns( )->tree_column( label = 'Object'

        )->tree_template(

        )->text( text = '{OBJECT}')->get_parent( )->get_parent(

        )->tree_column( label = 'Column2'

        )->tree_template(

        )->text( text = '{COL2}')->get_parent( )->get_parent(

        )->tree_column( label = 'Column3'

        )->tree_template(

        )->text( text = '{COL3}')->get_parent( )->get_parent(

        )->tree_column( label = 'Column4'

        )->tree_template(

        )->text( text = '{COL4}').

You can check the full source code of these examples here and here. Thank you to axelmohnen and WegnerDan for their contributions and examples in this direction.

2. Partly View Rendering I (Model Update)

In the initial version of abap2UI5, the standard approach involved rerendering the entire view after each request. This approach can be beneficial when making full changes to the entire application or when the entire UI changes with a page transition. However, in cases where only specific entries in a table or the values of an input field need to change, repeatedly rerendering the entire view can result in an uncomfortable user experience. For example it disrupts the user's current focus and scroll position. Therefore, abap2UI5 has now been extended to allow updating only the view model and keeping the view stable during a backend request. Rerendering is now controlled by two different methods:

view_display - This method rerenders the entire view

view_model_update - This method updates only the view model, and the UI5 framework will rerender only the affected controls

Let's consider the following example: Initially, a new view is created with a table and a search field. Subsequently, with each input change, the backend sends the newly matching table, and only the table entries in the UI are rerendered. The rest of the UI remains stable and the focus also stays unchanged in the input field:

abap2UI5 - Model Update after Input Change

Check out the source code here. This becomes even more useful when you have a table and have scrolled to a certain position. Take a look at this demo where new entries are added to a table every few seconds, and the scroll position and focus remain unchanged:

abap2UI5 - Stable Focus and Scroll Position after Backend Model Updates

As a general recommendation, it is advisable not to rerender the whole view unnecessarily, but only when it is required. While some UI5 Controls may need a complete rerendering, most cases can avoid it. However, it is essential to ensure that the entire view is rerendered after leaving or returning to an app. For this purpose, the event 'on_navigated' can now be checked, which is always true after an app navigation:

if client->get( )-check_on_navigated = abap_true.

   "rerender the whole View

endif.

Next, let's explore another method for partial rerendering.

3. Partly View Rendering II (Nested Views)

Another approach for selectively rerendering views involves using nested views. This allows you to create, for example, a master-detail page. You can use two independent views displaying a tree control on the left side and another view with inputs and buttons on the right side. Take a look at this example:

abap2UI5 - Master-Detail Layout with Nested Views

Many other use cases are possible. To mention just one more, you can display two tables and move entries from the left one to the right table:

abap2UI5 - Nested Views with Interacting Tables

Check out the source code here. The nested view is added to the main view with the following function:

client->nest_view_display(

      val            = lo_view_nested->stringify( )

      id             = `ParentView`

      method_insert  = 'addMidColumnPage'

      method_destroy = 'removeAllMidColumnPages'

    ).

And the methods to rerender the nested view are similar to the ones of the main view:

nest_view_display - This method rerenders the entire nested view

nest_view_model_update - This method updates only the view model, and the UI5 framework will rerender only the affected controls in the nested view

A big thank you to choper725 for the example and testing abap2UI5 with nested views.

4. Displaying Generic Data References with S-RTTI

One common requirement in ABAP is displaying tables which are typed during runtime. Sometimes you only know during runtime which database table you need to display or have to create a table with RTTI depending on local created types. When it comes to ALVs, this is not a problem because you can also create field catalogs dynamically. Here the abap2UI5 approach reaches its limits because we serialize the app with XSLT after every request and unfortunately generic data references with locally created types cause XSLT errors during serialization:

XSLT Serialization Error - Locally Created Types not supported

Fortunately the open source project S-RTTI solves this problem:

Open Source Project S-RTTI

With S-RTTI, we can serialize and save the RTTI of every variable, enabling us to clear it at the end of each request. Then, with the next request, the variable is recreated again based on the S-RTTI information. When encountering XSLT errors, abap2UI5 now automatically checks if this framework is installed and uses S-RTTI for serialization. As a result, generic data references with locally created types can now be seamlessly used with abap2UI5. Many thanks to sandra.rossi for this idea and excellent project.

5. CSV Upload & Download

One compelling use case for the functionality described above is the import of tables via CSV. The following application reads the file and, based on its contents, creates an internal table with the data from the CSV. Finally, it displays the table in a UI5 Table Control. Take a look at this example:

abap2UI5 - Upload CSV and Create Internal Table with its Content

By utilizing S-RTTI in combination with abap2UI5, only about 153 lines of ABAP are needed to fulfill this requirement. You can check out the source code here.

6. Excel Upload & Download

Besides CSV, another common requirement is the use of Excel files, especially downloading internal tables as Excel files. In UI5, this is achieved using the Spreadsheet Control. However, they rely on frontend JavaScript logic and are not usable without additional work in abap2UI5. Fortunately, choper725 contributed a custom control that encapsulates the frontend logic within a UI5 control, making it usable in a view definition of abap2UI5. Take a look at this example:

abap2UI5 - Excel Download via Custom Control

You can find the logic of the custom control here and the source code of the demo here. This approach combines JavaScript Logic at the frontend with ABAP Logic at the backend. Thank you choper725 for this extension.

Another approach for handling Excel files could be to keep the entire logic in the backend and send and receive only the final file to the frontend, similar to what we did with the CSV. You can achieve this by using the project abap2xlsx combined with abap2UI5. Currently, there is no working Excel functionality usable in both language versions ('ABAP for Cloud' and 'Standard ABAP'), but maybe in the future, there will be a chance for this, allowing for the entire logic to be held in ABAP without the need for extra JavaScript or the use of UI5 Spreadsheet Controls (pure ABAP 😍). Feel free to support this idea here.

Next let's explore some more UI5 Controls.

7. Navigation Container

First we take a look at the UI5 Navigation Container. Check out this demo:

abap2UI5 - nav container

You can find the source code here. The Navigation Container allows you to structure your output with multiple views, switching between them using an event. You can achieve this behavior by calling the following method in abap2UI5:

client->_event_client( val = 'NAV_TO' t_arg  = VALUE #( ( `NavCon` ) ( mv_selected_key ) ) ).

Furthermore, a lot of new controls for visualization are available.

8. Visualization with Planning Calender, Gantt Chart and Process Flow

Look for example at this demo with UI5 Gantt Charts:

abap2UI5 - Gantt Chart

Check out the source code here. Or the UI5 Planning Calender:

abap2UI5 - Planning Calender

Check out the source code here. And the UI5 Process Flow:

abap2UI5 - Process Flow

Check out the source code here. All of these controls assist in visualizing your data in a format other than a table or list. Thank you choper725 for these extensions.

9. Message Manager

Message Handling can be done in UI5 with the Message Manager. Depending an input field types it is automatically filled with message and the output is seamlessly integrated to the UI. Look at this demo:

abap2UI5 - Message Manager

In abap2UI5, you can now add messages, delete messages, or read its messages. Thank you choper725 for the demo, you can find the source code here.

10. Generic Search Help

When users input data, in addition to the message manager, search helps are a valuable assistance to fill input fields. While, of course, with abap2UI5, you have the capability to create your own popups and develop search helps manually, wouldn't it be nice to leverage the search helps that are still available in the ABAP System?

Fortunately, axelmohnen put in some effort and created an initial approach in the form of a generic Search Help Popup App. This app reads the standard SAP Search help and generates an abap2UI5 Popup from it, reminiscent of the previous SAP GUI popups:

abap2UI5 - Generic Search Help (Activated DDIC Objects)

As an example the demo above shows the search help for all activated Dictionary Objects. Check out the source code here and the generic popup app here. Of course, there is still some work to do, but even now it shows how easily you can work with generic typed tables and generic created popups in abap2UI5. Once again, the open-source project S-RTTI is used for realizing generic serialization. Thank you a lot axelmohnen for your contribution and for sharing this idea.

11. Developer Code Challenge

During the SAP ABAP Developer Challenge last May, abap2UI5 was used to create text adventure games based on Axage by enno.wulff. One particularly remarkable solution was developed by jacques.nomssi, which includes images, text areas, input controls and many more. Look at this solution:

abap2UI5 - Open-Source Axage with Magical World in ABAP

For more information about this project, you can refer to his blog post about the "Magical World in ABAP" here. He also has developed an abap2UI5 version of his ABAP Scheme project. Thank you jacques.nomssi

12. Demo & Sample Repository

Let's conclude the blog post with a complete demo where we can see that by combining a variety of controls, we are able to create apps with comprehensive functionality. This demo showcases tables, item navigation, rating indicators, pictures, text areas, search functionalities, and many more features:

abap2UI5 - Complete Demo

The source code is a bit more complex, as you can see here. However, it shows that creating more intricate apps is also possible. While abap2UI5 apps only implement a single method of an interface, you can easily also further encapsulate your apps to manage the growing logic of your views and controller. A big thank you to Th0masMa for this great demo!

All code snippets and demos in the blog series are collected in the abap2UI5 samples repository:

abap2UI5 - Samples

Feel free to explore it; the code snippets can be quickly copied & pasted and are ready-to-use for your own development.

13. Conclusion

This concludes the update on the functionalities of abap2UI5. Feel free to try out the new features in your own abap2UI5 apps, and should you encounter any problems, please don’t hesitate to open an issue. Many of the new functionalities have been developed in response to issues raised in the past months. This proactive approach helps to identify areas where additional functionality is needed and it makes sense to extend abap2UI5.

I also encourage everyone to contribute to the project by submitting pull requests or expanding the samples repository. With abap2UI5, copying & pasting apps or functionalities is straightforward, so the more publicly available code snippets exist, the easier it gets to create apps with abap2UI5. Therefore, if you create your own app, also consider sharing it via a public git repository or as a pull request to the samples repository. Up until now, the number of samples has grown to nearly 100, which was only possible with the help of contributors from the ABAP community. 🙏

In the next part, we will extend abap2UI5 with external libraries.

Thank you for reading! Your questions, comments and wishes for this project are always welcome, leave a comment or create an issue.

Creation and mapping of a new pay group from SuccessFactors to the S/4 system in SAP

2023-11-02T15:53:12+01:00

Dear all,

In this blog, I am discussing the creation and mapping of a new pay group from SuccessFactors to the SAP S/4 system. I will be explaining each step of the process, from creating a new pay group in SF to mapping to the S/4 system, followed by the data replication process.

1. Creating a new pay group in SuccessFactors

In manage data, create a new pay group with your preference. It is recommended to have two digits as an external code for your pay group. Once the pay group external code is provided, enter the description and set the status to active. Parallelly, enter the payment frequency as per your requirement. Finally, map the legal entity for which this pay group you are creating and save it. Below is the screenshot attached for your reference.

Pay group creation and mapping a legal entity

2. Creating a payroll area in the SAP S/4 system

Go to: SPRO--IMG--Personnel Management--Personnel Administration--Organisational Data--Organisational Assignment--Create a payroll area.

Once the payroll area is created in the S/4 system, we need to allow data replication from EC for payroll areas in correction phase. So, even if your payroll control is in the correction phase, it would not affect your data replication. The below step is the way to enable this functionality.

Enabling data replication from EC for payroll areas in the correction phase

In the above image, it is shown that the allow replication check box is enabled for my newly created payroll area. Do not forget to check this box.

3. Mapping pay group to payroll area.

After doing this step, the real mapping part begins. We need to map the pay group, which is created in SuccessFactors, to the payroll area, which is created in the SAP S/4 system.

Go to SPRO--IMG--Personnel Management--Integration with SuccessFactors Employee Central--Business Integration Builder--Basic Settings--Define value mapping details and execute.

Then select the EC instance and value mapping entity as the pay group.

Enter the ERP key that you have created as a payroll area code in the SAP S/4 system and the EC key that you have created as a pay group external code in SF.

Mapping the ERP key to the EC key

4. Create a payroll control record.

Create a payroll control record for your newly created payroll area in PA03 T-code.

Note: Make sure you have created a payroll control record first before starting a replication process from SuccessFactors to the SAP S/4 system.

5. Pay group change in SuccessFactors and replication of data.

After completing all the above processes, we need to upload the changes for the pay group for the required employees in SuccessFactors by navigating to import employee data. Download the compensation and job history templates and upload the compensation template first, followed by the job history template with the effective date.

Note: Select incremental load for the additional changes, which will keep the previous records in the system. The full purge is for the fresh import, which will clear all the existing data. Based on your requirements, select your purge type. Do not forget to validate your file before importing it into the system.

You can run replication using the T-code ECPAO_EE_ORG_REPL_QUERY . If you are running replication for one employee, then enter the employee ID in the External Employee ID field, or else ignore that. Followed by selecting the enable payload logging and enable extended verbose logging check boxes and test mode if testing is required.

By completing all those steps above, your payroll area will be updated in the SAP S/4 system. Now you are ready to run the payroll for those employees.

Thanks for referring to my blog. Keep supporting me in posting more blogs.

Regards,
Aravind R
HXM consultant

cds2alv – Generate ALV list reports for CDS views

2023-11-21T00:27:44+01:00

Welcome to this blog post introducing cds2alv.

cds2alv is an open source project offering a framework to generate ALV list reports for CDS Consumption Views similar to Fiori Elements. It was originally created as an environment to allow developers to learn CDS and SAP Fiori independently.

It has since evolved into a tool for quickly creating monitoring transactions based on CDS and serves as an intermediate step in the transition from ALV list reports using ABAP SQL to SAP Fiori apps using CDS and OData.

The project is available on GitHub and featured on dotabap.

Features

Easy to learn: Report generation requires no further knowledge apart from CDS

Consistent User Experience: The generated reports share a common Look and Feel

Interactive: The generated reports support Intent-Based Navigation similar to SAP Fiori and BOPF actions

Future Ready: By Design, CDS views created to be used with this framework, can later be used as a basis for SAP Fiori Elements apps offering the same or similar functionality

Extensible: Reports can be enhanced by additional features that can be switched on or off for each view individually

The project is to be installed using abapGit. For further information please refer to the installation guide. It is maintained on release R/3 NetWeaver AS ABAP 7.50, and it runs on S/4HANA On-Premise with minor adjustments.

Evolution

The framework came to be as the result of several efforts to streamline and automate various repetitive tasks during the development process of list reports. The desire for this first arose in a project in late 2017. Over the course of this project several reports had the be developed, all of which featured almost the exact same selection screen, selection logic, ALV layout and event handling.

In the end this led to the development of a custom ALV wrapper class with a simplified interface to allow efficient and uniform integration of ALV into custom reports and classes. The other three pain points, uniform treatment of selection screens, selection logic and event handling, remained unsolved for the time being.

The next step towards a solution was the discovery of CDS and the Virtual Data Model (VDM). The Interface Views served as an elegant solution to the problem of reusable selection logic.

Finally, the problem of finding a generic solution for selection screens and event handling could be solved using CDS annotations and Intent-Based Navigation, borrowing the respective solutions from SAP Fiori elements.

The first version of cds2alv was finished in late 2021, but that version was still rather unpolished. Over the course of the last two years it was revised and refined to its present state.

If you want to learn more about the tool‘s history and its underlying ideas, please check out my talk from the ABAPconf 2021 (in German language): ABAPConf 2021

Usage

Reports are generated and executed via transaction code ZCDS_ALV_START. This transaction code works similarly to the classical SE16 transaction. Reports for specific CDS views can be made available individually by means of a parameter transaction.

Initial Screen of Transaction ZCDS_ALV_START

Demo

The repository contains a subfolder with a simple demo showcasing the basic features. Alternatively, the framework can also provide a demonstration by itself by using it to generate list reports for the framework’s own CDS views.

Development Process

Using cd2alv, developing an ALV list report boils down to creating and annotating the CDS Consumption View and possibly defining a parameter transaction for individual use. An overview of supported annotations is given as part of the documentation.

Intent-Based Navigation

There are several possible ways in which cds2alv can handle Intent-Based navigation:

Individual implementation: Handling for a specific CDS view can be implemented using an exit class.

Standard implementation: Three options for reusable Handling are supported:
1. Function Module: The value of a cell with in the ALV grid is passed as an importing parameter to a function module.
2. Business Object Method: The value of a cell is used as key value to instantiate a BOR object. Subsequently a method of this object is called.
3. Transaction call: The value of a cell is stored in a SET-/GET-Parameter, follow by calling a transaction.

We plan to add support for static methods and instance methods of classes with public parameter-less constructors in the near future. The standard implementations are defined using the framework’s own view cluster ZVC_CDS_ALV_FW.

Definition of Intent-Based Navigation in View Cluster ZVC_CDS_ALV_FW

Extensibility

The reports generated by cds2alv can be extended by predefined plug-in extensions. These extensions can enhance several steps of the program flow as described in the documentation. We also plan to offer a selection of ready made extensions as part of a separate repository in the near future.

abap2UI5 - (10) Extensions I: Exploring External Libraries & Native Device Capabilities

2023-12-04T09:28:37+01:00

Welcome to part 10 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

So far, we've focused on utilizing standard UI5 controls and primarily adopting UI5 samples for integration with abap2UI5. However, we also have the opportunity to use third-party libraries or harness native device capabilities at the frontend. This includes functionalities like barcode scanning, image capture, and geolocation services. In this blog, we will delve into these advanced features and their integration with abap2UI5

All demos showcased in this blog are ready for use and can be easily tried out by installing the abap2UI5-samples with abapGit.

Blog Series & More

Find all the information about this project on GitHub, stay up-to-date by following on Twitter and exploring the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating Views with XML, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Setup: Working with abapGit, abaplint & open-abap

(9) Updates I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities (this blog post)

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

This article covers the following areas:

Displaying Barcodes with bwip-js

Scanning Barcodes with the UI5 Barcode Scanner

Reading Frontend Information (UI5 Version, Device Information etc.)

Reading Geolocation & Visualizing with the UI5 Map Container

Capturing Pictures and Sending them to the Backend

Highlighting & Providing Contextual Help with driver.js

More Libraries (FontAwesome, ImageMapster...

Let's begin with the first topic:

(1) Display Barcodes with bwip-js

There are numerous libraries available for rendering barcodes at the frontend. For this example we use the open-source framework bwip-js, although other libraries could also be suitable. You can explore the repository here and view a demo of all its capabilities at this link.

JavaScript Framework bwip-js

Many types of barcodes are available, and you can find a list of all supported barcode types here:

Supported Barcodes of bwip-js

To use this library in abap2UI5, the functionality is encapsulated within a custom control. You can view the source code here. The output of the demo app looks like this:

bwip-js integrated in abap2UI5

This encapsulation allows abap2UI5 app developers to easily utilize bwip-js features through properties, similar to how they do with any other UI5 control. The complexity of the bwip-js framework stays in the custom control, simplifying development at the app level. Take a look at the following view definition, which generates the barcode at the frontend:

cont->simple_form( title = 'Barcode' editable = abap_true

      )->_z2ui5( )->bwip_js(

              bcid = ms_barcode-sym

              text = ms_barcode-text

              scale = mv_scale_x

              height = conv string( mv_scale_y + mv_scale_x ) ).

The bwip-js demo in action looks like this:

abap2UI5 App in Action: Displaying Barcodes Using bwip-js

As you can observe, it resembles the original demo, but it is now fully integrated into abap2UI5, allowing bwip-js to be used entirely in pure ABAP. The app's source code comprises just 137 lines. You can view the full example on GitHub:

Source Code for Displaying Barcodes in Pure ABAP with abap2UI5 (here)

The bwip-js library and the Custom Control's code are loaded beforehand. This is done as follows:

cont->_generic( ns = `html` name = `script` )->_cc_plain_xml( z2ui5_cl_cc_bwipjs=>get_js( ) ).

This loading process occurs at the app level to minimize the framework's load time at startup and ensure it is only loaded when necessary. Alternatively, the loading can also be initiated at the framework's start. An importing parameter is available for loading custom JavaScript at startup here. Some Custom Controls with basic functionality are always preloaded, as you can find here.

(2) Scan Barcodes with the UI5 Barcode Scanner

Displaying barcodes is useful, but their functionality is limited without the ability to scan them. Initially, UI5 lacked native barcode scanning capabilities. This gap was bridged by developing custom controls to integrate libraries like Zbar, ScanBot, or Quagga.js into UI5. However, in recent years, this additional effort has become redundant as UI5 now incorporates scanner libraries built upon the zxing scanner engine. These functionalities are encapsulated within the sap.ndc.BarcodeScanner controls. Check out the samples here:

UI5 Barcode Scanner Control

This integration allows them to run seamlessly with both UI5 and abap2UI5 right out of the box. We can simply use this UI5 Control in our view as follows:

)->barcodescannerbutton(

     scansuccess = client->_event( 

           val   = 'ON_SCAN_SUCCESS' 

           t_arg = VALUE #( ( `${$parameters>/text}`   ) 

                            ( `${$parameters>/format}` ) ) )

     dialogtitle = `Barcode Scanner` ).

After each button click, a popup appears, allowing you to scan. The scanned format and text are then sent with the event "ScanSuccess" to the backend. See this demo, recorded on an iPhone:

abap2UI5 App in Action: Scanning QR-Codes (Running on an iPhone)

Similar to the first example, we can access the entire functionality through the properties of the UI5 control. This simplifies its use with abap2UI5, and only a small implementation logic is required for the above example. You can find the full source code on GitHub:

Source Code for Scanning Barcodes in Pure ABAP with abap2UI5 (here)

(3) Read Frontend & Device Information

Sometimes, you may want to respond within the application based on specific factors like the actual device, UI5 library version, or other frontend information. We can easily send this information to the backend, enabling you to respond in the ABAP code to certain situations. You can obtain some information using the following method:

abap2UI5 - Return Values of the Method client->get( )

Additionally, the framework now features a custom control, included here, to read more information from the frontend. Explore this demo:

abap2UI5 - Read Frontend Information via Custom Control

It can be utilized in the same manner as all other UI5 Controls, as demonstrated here:

 client->view_display( view->shell(

          )->page(  title = 'abap2UI5'

          )->_z2ui5( )->info_frontend(

                finished          = client->_event( `INFO_FINISHED` )

                device_browser    = client->_bind_edit( device_browser )

                device_os         = client->_bind_edit( device_os )

                device_systemtype = client->_bind_edit( device_systemtype )

                ui5_gav           = client->_bind_edit( ui5_gav )

                ui5_theme         = client->_bind_edit( ui5_theme )

                ui5_version       = client->_bind_edit( ui5_version ) 

          )->stringify( ) ).

Explore the full source code on GitHub:

Source Code for Reading Frontend Information in Pure ABAP with abap2UI5 (here)

Further enhancements can be added in the future.

(4) Reading Geolocation & Visualizing with the UI5 Map Control

The frontend's geolocation can be accessed using the Geolocation API. For example, the source code for the frontend might look as follows:

<script>

const x = document.getElementById("demo");



function getLocation() {

  if (navigator.geolocation) {

    navigator.geolocation.getCurrentPosition(showPosition);

  } else {

    x.innerHTML = "Geolocation is not supported by this browser.";

  }

}



function showPosition(position) {

  x.innerHTML = "Latitude: " + position.coords.latitude +

  "<br>Longitude: " + position.coords.longitude;

}

</script>

For integration with abap2UI5, the following custom control encapsulates this functionality and it can be utilized in a view definition like this:

)->_z2ui5( )->geolocation(

      finished         = client->_event(  )

      longitude        = client->_bind_edit( longitude )

      latitude         = client->_bind_edit( latitude )

      altitude         = client->_bind_edit( altitude )

      altitudeaccuracy = client->_bind_edit( altitudeaccuracy )

      accuracy         = client->_bind_edit( accuracy )

      speed            = client->_bind_edit( speed )

It reads out the latitude, longitude, etc.:

abap2UI5 App in Action: Calling the Geolocation API at the Frontend

However, it becomes fascinating when visualized on a map. While options like Google Maps or OpenStreetMap are available, we opt for a simpler approach by just integrating the UI5 Map Container Control into abap2UI5. Check out the control samples here:

UI5 Map Container Control

The Map Container Control in an abap2UI5 view looks like this:

  )->map_container(  autoadjustheight = abap_true

                    )->content( ns = `vk`

                        )->container_content(

                          title = `Analytic Map`

                          icon  = `sap-icon://geographic-bubble-chart`

                            )->content( ns = `vk`

                                )->analytic_map(

                                  initialposition = `9.933573;50;0`

                                  initialzoom = `6`

                                )->vos(

                                    )->spots( client->_bind( mt_spot )

                                    )->spot(

                                      position      = `{POS}`

                                      contentoffset = `{CONTENTOFFSET}`

                                      type          =  `{TYPE}`

                                      scale         =  `{SCALE}`

                                      tooltip       =  `{TOOLTIP}`

And here is a demo combining the Geolocation and UI5 Map Container in a single, integrated example:

abap2UI5 App in Action: Geolocation Information Visualized with the UI5 Map Container

Explore the full source code of the demo on GitHub:

Source Code for Reading and Displaying the Geolocation in Pure ABAP with abap2UI5 (here)

The map container also offers a lot more functionality - it's possible to display multiple spots or visualize complete routes:

UI5 Map Container Control - More Features

(5) Capturing Pictures

Capturing screenshots in modern browsers is accomplished using the Media Capture and Streams API. Similar to previous examples, for integration with abap2UI5, we encapsulate this functionality in a custom control, as shown here. It can be utilized in a view definition as follows:

page->_z2ui5( )->camera_picture(

          value    = client->_bind_edit( mv_picture_base )

          onphoto  = client->_event( 'CAPTURE' ) ).

We send a user command to the backend with the event "onPhoto" and use a two-way binding for the data of the picture. This means when a picture is taken, it's transmitted to the backend in base64 format. To avoid unnecessary data transfer, we immediately clear this property and only send the picture to the frontend when it's needed:

CASE client->get( )-event.

      WHEN 'CAPTURE'.

        INSERT VALUE #( data = mv_picture_base time = sy-uzeit ) INTO TABLE mt_picture.

        CLEAR mv_picture_base.

        client->view_model_update( ).



     "....

ENDCASE.

A complete demo looks as follows:

abap2UI5 App in Action: Capturing Pictures (Running on an iPad Mini)

Again, the encapsulation into a custom control keeps the abap2UI5 app compact, requiring only 120 lines of code. You can view the complete source code on GitHub:

Source Code for Capturing Pictures in Pure ABAP with abap2UI5 (here)

This only represents the basic functionality of the Camera API at the frontend. Looking ahead, there's potential to upgrade the Custom Control to alter resolution or more camera settings. Although this app served primarily as a test case, photos frequently prove invaluable in business contexts, especially for documentation purposes. Whether they are stored as GOS attachments in an on-premise system or used with SAP BTP Document Management Service in cloud scenarios, you can also consider implementing these use cases with abap2UI5.

(6) Highlights & Contextual Help with driver.js

A few weeks ago, I received an excellent pull request from choper725. It introduced the JavaScript framework driver.js designed to present contextual help or highlight specific areas of the screen as user guidance. Check out the framework here:

JavaScript Framework driver.js

This framework can be seamlessly integrated into abap2UI5. Here's what the demo looks like:

abap2UI5 App in Action: Highlights & Contextual Help with driver.js

The full source code is available on GitHub:

Source Code for Using driver.js in Pure ABAP with abap2UI5 (here)

In this example, only basic functionality is implemented, but it effectively showcases its potential. The combination of UI5 together with driver.js opens up various additional use cases for the future.

Special thanks to choper725 for contributing this custom control and demo to abap2UI5. Another addition from him is Font Awesome and ImageMapster, which we will explore next.

(7) More Libraries...

There is a wide range of libraries compatible with both UI5 and abap2UI5. To see what has been integrated thus far, you can visit this folder. Smaller libraries can also be quite useful for specific use cases. As an final example, let's take a look at the Font Awesome icons here:

abap2UI5 App using Font Awesome

And check out the full source code on GitHub:

Source Code of Font Awesome used with abap2UI5 (here)

Or take a look to the ImageMapster Example:

abap2UI5 App using ImageMapster

It can handle Events by clicking on certain Image areas, check out the full source code on GitHub:

Source Code of ImageMapster used with abap2UI5 (here)

And finally check out Animate.css:

abap2UI5 App using animate.css

And check out the source code on GitHub:

Source Code of animate.css used with abap2UI5 (here)

Conclusion

It was exciting to experiment with all these features to explore what's possible with the abap2UI5 approach. Although this was just a start, and much more can be developed in the future, it already showcases its potential: The use of native device capabilities with external libraries encapsulated within custom controls allows straightforward accessibility through properties in pure ABAP. It opens up a lot of use cases while keeping the development effort on app level very low.

All these features have now been integrated into the abap2UI5 framework and are ready to run out-of-the-box after installation with abapGit. Storing JavaScript in ABAP classes may seem unconventional, but it ensures full compatibility across any ABAP system and language version. This strategy eliminates the need for deployment of additional frontend artifacts or further configurations beyond the ABAP source code. Additionally, all applications developed using these functionalities also automatically qualify as abapGit apps, facilitating easy transport and exchange between systems.

Are you using external libraries with UI5? Consider contributing them to abap2UI5, I always welcome new pull requests and have recently updated the repository to streamline the process of adding new custom controls.

In the next part, you find a guideline of how to include your own JavaScript functionality to abap2UI5.

Thank you for reading and I hope you enjoy experimenting with the new demos. Your feedback is always appreciated. Feel free to raise an issue or leave a comment.

abap2UI5 - (11) Extensions II: Guideline for Developing New Features in JavaScript

2023-12-11T11:05:38+01:00

Welcome to part 11 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

In the last post, we explored various additional functionalities and external libraries that can be integrated with abap2UI5, but without delving into the technical background. Now, we aim to address that. This blog post will explain how to enhance abap2UI5 with custom functionalities and additional JavaScript logic. It is designed as a step-by-step guide for UI5 developers, demonstrating how they can develop frontend logic and make it accessible for the use in ABAP through abap2UI5 apps.

Check out the the corresponding GitHub repository here.

Blog Series & More

Find all the information about this project on GitHub, stay up-to-date by following on Twitter and explore the other articles of this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript (this blog post)

(12) Update II: Community Feedback, New Features & Outlook - Jan. 2024

Content

We will start from the ground up, creating a new project and integrating all the essential logic required for frontend and backend communication. Finally, we will adapt this logic into an abap2UI5 artifact and use it in an abap2UI5 app in the backend. The content is structured as follows:

General Idea & Creating a new UI5 project

Frontend Development (JS)
1. Creating a new Custom Control
2. Receiving data in the Frontend (JS) sent from the backend
3. Invoking backend functions (ABAP) from the frontend
4. Receiving data in the backend (ABAP) sent from the frontend
5. Calling frontend functions (JS) from the backend
6. Optional I: Implementing faceless controls (without UI)
7. Optional II: Loading external libraries

Backend Development (ABAP)
1. Migrating frontend logic to the ABAP Backend
2. Developing an abap2UI5 app using the new Custom Control

Additional Comments

Conclusion

Let’s begin with the first topic:

1. General Idea & Creating a New UI5 Project

This guideline is centered around one core concept: We rigorously encapsulate all JavaScript logic within a Custom Control (CC). This approach offers the following advantages:

It ensures that there are no dependencies outside of the Custom Control. This means we can easily copy and paste it into the backend with confidence in its correct functionality

We can use the properties of the Custom Control in the XML view for data exchange and communication between JS and ABAP. The Event and Data Binding functionality of the UI5 framework ensure smooth operation and ease of use

By avoiding globally defined variables and relying solely on the UI5 API, we guarantee that the application functions correctly even when the UI5 version is updated or when abap2UI5 operates in different contexts, such as the Fiori Launchpad or SAP Build Workzone Service

Let's start by launching your preferred development environment. Here we use Business Application Studio as it comes pre-equipped with UI5 tooling and create a new UI5 freestyle application. Upon completion, your project folder should resemble the following structure:

Structure of a new UI5 Freestyle App

2.1. Creating a new Custom Control (CC)

Numerous guidelines are available for developing Custom Controls in SAP UI5, such as blog articles and documentation. We will now follow the recommended approach from the documentation to create a new Custom Control. This process begins with creating a new folder and file:

New Folder & File for the Custom Control (CC)

Next, copy & paste the following snippet as your starting point:

sap.ui.define("project1/control/MyCustomControl",[

	"sap/ui/core/Control"

], (Control) => {

	"use strict";



	return Control.extend("project1.control.MyCustomControl", {



		renderer(oRM, oControl) {

            oRM.openStart("div", oControl);

            oRM.openEnd();

            oRM.write( 'test');

            oRM.close("div");

        }

	});

});

Basic HTML is used for creating a first output. Integrate the new Custom Control (CC) into your XML View by making the following adjustment to the file View1.view.xml:

<mvc:View controllerName="project1.controller.View1"

    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

    xmlns="sap.m" xmlns:z2ui5="project1.control">

    <Page id="page" title="{i18n>title}">

        <content>

        <z2ui5:MyCustomControl id="test" />

        </content>

    </Page>

</mvc:View>

This XML View will be later created in ABAP on the backend, which means any configurations we establish here can be transmitted from the server. Meanwhile, we can use the CC to add all JavaScript logic we later want to process on the frontend.

Now we will extend step-by-step the functionality of this Custom Control.

2.2 Receiving Data in the Frontend (JS) Sent from to the Backend (ABAP)

First we want to send values from ABAP to the frontend Javascript Logic. We start by setting the property value in your XML view (this can later be done in ABAP):

<mvc:View controllerName="project1.controller.View1"

    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

    xmlns="sap.m" xmlns:z2ui5="project1.control">

    <Page id="page" title="{i18n>title}">

        <content>

        <z2ui5:MyCustomControl id="test" value="MyBackendValue"/>

        </content>

    </Page>

</mvc:View>

And we add the property "value" to the Custom Control (together with a setter and getter method) that it can receive its data:

sap.ui.define("project1/control/MyCustomControl",[

	"sap/ui/core/Control"

], (Control) => {

	"use strict";



	return Control.extend("project1.control.MyCustomControl", {

	    metadata : {



                 properties : { value: 	{type : "string" } },



	    setValue(value){

		this.setProperty("value", value);

             },

	    getValue(){

		return this.getProperty("value");

              },



            renderer(oRM, oControl) {

                oRM.openStart("div", oControl);

                oRM.openEnd();

                oRM.write( oControl.getValue("value") );

                oRM.close("div");

  } }); });

We display the value in the rendering method to verify if it is correctly transmitted to the frontend. When you begin testing this demo in a terminal (using the command 'npm run start'), you should observe the following result:

CC - Displaying values sent from the backend

As you can observe, the values are successfully sent to the Custom Control. This illustrates how we can later transmit data from the backend to the frontend. Just add more properties and retrieve the backend values at the frontend by simply reading the control's property using the following command:

oControl.getValue("value");

Next you can use these backend values to implement your JavaScript logic. But at a certain stage, it will become necessary to interact with the backend again. In the next section, we will trigger backend interactions, by focusing on the use of events in Custom Controls.

2.3 Invoking Backend Functions (ABAP) from the Frontend

In addition to the properties, we can enhance the Custom Control by adding events. We'll setup a "change" event which is triggered after a delay of 5 seconds. Typically, you would implement logic that culminates in triggering an event; however, for this example, we're adopting a straightforward approach to emphasize the underlying principle. The updated snippet for the Custom Control now appears as follows:

sap.ui.define("project1/control/MyCustomControl",[

	"sap/ui/core/Control"

], (Control) => {

	"use strict";



	return Control.extend("project1.control.MyCustomControl", {

		metadata: {



			properties: {

				value: { type: "string" }

			},

			events: {

				change: {}

			}

		},



		setValue(value) {

			this.setProperty("value", value);

		},

		getValue() {

			return this.getProperty("value");

		},



		onAfterRendering() {



			setTimeout((oControl) => {

				oControl.fireChange();

			}, 5000, this);



		},



		renderer(oRM, oControl) {

			oRM.openStart("div", oControl);

			oRM.openEnd();

			oRM.write(oControl.getValue("value"));

			oRM.close("div");

		}

	});

});

Next, we need to manage the event in our controller, which is a process we will later replicate in ABAP. To begin, make the following adjustments to the XML:

<mvc:View controllerName="project1.controller.View1"

    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

    xmlns="sap.m" xmlns:z2ui5="project1.control">

    <Page id="page" title="{i18n>title}">

        <content>

        <z2ui5:MyCustomControl id="test" value="MyBackendValue" change="onMyBackendChangeHandler" />

        </content>

    </Page>

</mvc:View>

And the following adjustments to the controller:

sap.ui.define("project1/control/MyCustomControl",[

    "sap/ui/core/mvc/Controller"

],



    function (Controller) {

        "use strict";



        return Controller.extend("project1.controller.View1", {



            onMyBackendChangeHandler: function (){

                sap.m.MessageToast.show( 'Frontend Event raised, and processed in the backend');

            }

        });

    });

When we test the application again, we observe that the Control is loaded and, after five seconds, the event is triggered. It is then handled in the controller by displaying a message toast. In a later step, we will implement the call of the message toast in ABAP:

CC - Invoking backend functions from the frontend

We can use this event now and start to process some backend logic. But normally after the frontend logic some data is also changed, consequently, a new question arises: How can we transmit updated frontend values to the backend for processing in our ABAP event handler?

2.4 Receiving Data in the Backend (ABAP) Sent from the Frontend

The simplest method is to use data binding, a common practice in UI5 development for monitoring value changes. For instance, this is useful when a user modifies an input field at the UI and you need to track this change in JavaScript. Therefore, instead of directly entering the value into the XML view, we utilize data binding now and adjust the view as follows:

<mvc:View controllerName="project1.controller.View1"

    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

    xmlns="sap.m" xmlns:z2ui5="project1.control">

    <Page id="page" title="{i18n>title}">

        <content>

        <z2ui5:MyCustomControl id="test" value="{MY_BINDED_VALUE}" change="onMyBackendChangeHandler" />

        </content>

    </Page>

</mvc:View>

And we adjust the controller (which again only simulates the ABAP backend and will be replaced later):

sap.ui.define("project1/control/MyCustomControl", [

    "sap/ui/core/mvc/Controller"

],



    function (Controller) {

        "use strict";



        return Controller.extend("project1.controller.View1", {

            onInit: function () {



                var data = { 'MY_BINDED_VALUE' : "backend value" };

                var oModel = new sap.ui.model.json.JSONModel(data);

                this.oView.setModel( oModel );



            },

            onMyBackendChangeHandler: function (oEvent){

                var data = this.oView.getModel().getData();

                sap.m.MessageToast.show( 'Frontend Event raised, and processed in the backend, value: ' + data.MY_BINDED_VALUE );

            }

        });

    });

Next we modify this value at the frontend by updating the property. We'll achieve this by enhancing our setTimeout method to include the setValue method call:

			setTimeout((oControl) => {

				oControl.setValue("frontend value");

				oControl.fireChange();

			}, 3000, this);

The outcome appears as follows: initially, the view is rendered using the value received from the backend:

CC - Initial Load (1/2)

And after 5 seconds, it is replaced with the frontend value set by the JavaScript logic:

CC - Setting data in the frontend and sent to the backend (2/2)

As you can see, we simply need to update the property using the command:

oControl.setValue("frontend value");

The SAP UI5 framework automatically manages the remaining processes, significantly reducing the complexity that we typically encounter when handling frontend-to-backend data exchange. Furthermore, we will later observe that the abap2UI5 framework also streamlines the transfer of data binding to the attributes of the ABAP classes implementing 'z2ui5_if_app,' requiring no further actions.

Now let's assume that some backend logic is processed in response to the updated frontend values and the event. The final step is to determine a way to trigger a specific function on the frontend from the backend, which we will do next.

2.5 Calling Frontend Functions (JS) from the Backend

To prepare for this, we first include in our Custom Control a new frontend function and property:

sap.ui.define("project1/control/MyCustomControl",[

	"sap/ui/core/Control"

], (Control) => {

	"use strict";



	return Control.extend("project1.control.MyCustomControl", {

		metadata: {



			properties: {

				value: { type: "string" },

				checkCallMyFunction: { type : "boolean" }

			},

			events: {

				change: {}

			}

		},



		setValue(value) {

			this.setProperty("value", value);

		},

		getValue() {

			return this.getProperty("value");

		},

		setCheckCallMyFunction(checkCallMyFunction) {

			if (checkCallMyFunction) {

				this.myFrontendFunction();

			}

			this.setProperty("checkCallMyFunction", false);

		},

		init() {

		},



		myFrontendFunction(){

			sap.m.MessageToast.show( 'myFrontendFunction called' );

		},



		onAfterRendering() {



			setTimeout((oControl) => {

				oControl.setValue("frontend value");

				oControl.fireChange();

			}, 3000, this);



		},



		renderer(oRM, oControl) {

			oRM.openStart("div", oControl);

			oRM.openEnd();

			oRM.write(oControl.getValue("value"));

			oRM.close("div");

		}

	});

});

To keep it simple, we just call a message toast, but of course, more complex logic can be implemented here. The key to calling this function from the backend is to use a boolean property that we transport as an attribute and can toggle in the backend to true. Then every time the backend sets it to true, the function is called at the frontend. The following changes to the XML are necessary:

<mvc:View controllerName="project1.controller.View1"

    xmlns:mvc="sap.ui.core.mvc" displayBlock="true"

    xmlns="sap.m" xmlns:z2ui5="project1.control">

    <Page id="page" title="{i18n>title}">

        <content>

        <z2ui5:MyCustomControl id="test" value="{/MY_BINDED_VALUE}" change="onMyBackendChangeHandler" checkCallMyFunction="true"/>

        </content>

    </Page>

</mvc:View>

And now, when we test the application, we can observe that the function is being called:

CC - Processing JS function, triggered from the backend

Info: We now have established all the essential communication mechanisms between the backend and frontend. Both sides are capable of exchanging data and triggering each other's functions.

2.6 Optional I: Implementing Faceless Controls

The example above includes the rendering of a UI. However, if your goal is solely to call functions at the frontend or integrate your JavaScript logic, you can opt to skip the rendering part and use it as a 'faceless' Custom Control. In this scenario, only properties are transferred through the XML view, the rendere method is empty and there is no impact on the UI. For example take a look to the CC to set the title here or to read frontend information here.

2.7 Optional II: Loading External Libraries

More functionality can be included by using external libraries. You can also load these libraries in your custom controls, as demonstrated in the bwip-js custom control example. Check it out here.

3. Backend Development (ABAP)

Now, we want to transfer the Custom Control functionality to abap2UI5. If you're primarily a UI5 developer, this would be the perfect moment to reach out to your ABAP colleagues for assistance... 🦖🦖🦖

3.1 Migrating Frontend Logic to the ABAP Backend

Access your ABAP backend system and create a new ABAP class with a new method named 'get_js' and a single return parameter. Next, ensure that the following option is activated in Eclipse:

Eclipse - Setting to copy & paste large string from the clipboard

Now, we copy & paste the entire Source Code of the Custom Control into Eclipse:

press strg+v now!

The snippet of the ABAP class now looks as follows:

Javascript of the CC after copy & paste to ABAP

Next, we replace the namespace for its use in abap2UI5. In our case, the original namespace was 'project1.control'. We will substitute this with 'z2ui5':

CC with replaced Namespaces and with added sap.declare function at the beginning

Check out the full source code on Github:

Source Code (here)

3.2. Developing an abap2UI5 Application Using the New Custom Control

As mentioned earlier, the controller and XML View that we initially developed in JavaScript will now be implemented in ABAP. Therefore, we are now creating an abap2UI5 app. For this, we create another class and implement the interface 'z2ui5_if_app'. In the abap2UI5 app, the XML View with the new CC from above now appears as follows:

    DATA(view) = z2ui5_cl_xml_view=>factory( ).

    client->view_display( view->shell(

      )->page( 'abap2UI5 - My CC App'

      )->_generic(

        name   = `MyCustomControl`

        ns     = `z2ui5`

        t_prop = VALUE #(

            ( n = `value`               v = client->_bind_edit( mv_binded_value ) )

            ( n = `change`              v = client->_event( 'MY_FRONTEND_EVENT' ) )

            ( n = `checkCallMyFunction` v = `true` )

             )

      )->stringify( ) ).

And the logic for the controller in JavaScript now looks in ABAP in the abap2UI5 app as follows:

    CASE client->get( )-event.

      WHEN 'ON_CC_LOADED'.

        display_view( ).

      WHEN 'MY_FRONTEND_EVENT'.

        client->message_box_display( |Frontend Event raised, and processed in the backend, value: { mv_binded_value }| ).

      WHEN 'BACK'.

        client->nav_app_leave( client->get_app( client->get( )-s_draft-id_prev_app_stack  ) ).

    ENDCASE.

Additionally, we need to implement some logic to ensure that the Custom Control is loaded first upon the application's start before we can utilize it in our view. We will set up this process as follows:

    DATA(view) = z2ui5_cl_xml_view=>factory( ).

    client->view_display(

      view->_generic( ns = `html` name = `script` )->_cc_plain_xml( zcl_a2ui5_my_custom_control=>get_js( )

          )->_z2ui5( )->timer( client->_event( `ON_CC_LOADED` )

          )->stringify( ) ).

Check out the full source code on GitHub:

Source Code of the abap2UI5 Demo App (here)

Now, you can start the new app. The entire logic that was previously processed as a UI5 frontend application is now integrated into the backend and can be utilized through abap2UI5 apps. The final demo, running in abap2UI5, now appears as follows:

abap2UI5 app - Demo using the new CC

This concludes our development journey, which began at the frontend, progressed into the backend, and finally ends in the use within an abap2UI5 app. The Custom Control till now just contains basic functions, you can now begin to enhance it with more JavaScript logic.

4. Additional Comments

There are multiple ways to develop and encapsulate JavaScript logic and integrate it into abap2UI5. The method explained here is simply the one that has worked best so far. The ease of using data binding and events on the frontend greatly simplifies interaction with the backend. And in the backend, the Custom Control ensures seamless use in ABAP via properties in Views in abap2UI5 apps.

However, improvements are always possible. If you prefer other methods, feel free to use what works best for you. As highlighted in part 5 of the series, you can send plain JavaScript, CSS, and HTML to the frontend. Essentially, you have complete freedom in your approach and you might find more suitable methods to meet your specific needs.

Furthermore, this was just a basic example. Custom Controls can be developed to be much more complex, for example with features like aggregations. Be sure to also explore more blog posts about Custom Control development and experiment for yourself.

The full source code is available on GitHub, check it out here. It's open for future extensions, and you're welcome to create issues and PRs.

5. Conclusion

This concludes our guideline on how to enhance abap2UI5 with new JavaScript logic.

Thank you for reading, and I hope this inspires you to experiment with adding your own functionalities to abap2UI5. 👷‍♀️👷

Your feedback is always appreciated. Feel free to raise an issue or leave a comment.

Third party system approvals substitution to S4 System through interface

2023-12-14T22:07:28+01:00

Introduction:

The development of this interface will facilitate the entry of delegation values into the standard SAP table HRUS_D2. 3PL system will provide a file that will be sent to SAP nightly utilizing PI for processing. The file will be tab delimited in format and will be placed in be placed in a SAPIN folder: \\saptest\\sapin\erp\\folder

Overview:-

1) 3PL system will provide a file.

2) The file will be tab delimited in format and will be placed in be placed in a SAPIN folder.

3) Path \\saptest\\sapin\\erp\\folder

4) Check conditions. If yes, based on conditions data will be created or updated or modified in HRUS_D2 table. Send log information through email.

5) If no, continue business process.

Step By Step Procedure for Creating Proxy

1.The Proxy Service Interface has to be created by PI consultant from PI side. This will further reflect in ABAP side in T-Code “SPROXY”.

2.Create the Proxy from T-Code “SPROXY”.

3.The Proxy created from PI side will be reflected with following details in SPROXY.
Software Component: Service_1.0_of_erp.com
Namespace: http://erp.com//3PLtoSAPService
Service Interfaces: Service_Async_Out

4. Proxy Name will be available once we generate the Proxy.

To generate proxy we need to right click on Service Interface “Service_Async_Out” for Outbound and click on “Create Proxy”.

5.We need to give the “Package” and “Transport Request” to which the Proxy needs to be saved.

6.Once the proxy is created for a service interface then that Interface will be marked as Green.

7. we can find the Proxy Name when we double click on the generated Service Interface. In this case since the Outbound Proxy was already generated we can find the Proxy name of that.

8 .The objects created when we generate a Proxy is as follows
I. Data Type
ii. Message Type
iii. Proxy Class.

Implement proxy class method

Switch to the Properties tab. Double-click the implementing class. and then double-click the method.

Maintain the implementation of the method.

Purpose: Upload data into HRUS_D2 table(Substituted by User).using below function modules in our interface.

SAP_WAPI_SUBSTITUTE_DELETE
SAP_WAPI_SUBSTITUTE_MAINTAIN
RH_UPDATE_SUBST_LIST_SERVER

Total 3 scenarios are there

Once the file triggers proxy then checking the conditions. Based on conditions data will be created or updated or modified.

Scenario1: If file data not in a table, then it inserts a new record same as in file.

Scenario2: If file data in a table, then it updates existing record same as in file.

Scenario3: Table data not in a file then need to update end date and active with ‘space’.

After file execution sent an email with log information (which email is maintained in ZEMAIL table).

METHOD zclii_service_async_in~service_async_in.

*/ Structure declarations
TYPES: BEGIN OF ty_input,
us_name TYPE xubname,
rep_name TYPE xubname,
begda TYPE begdatum,
endda TYPE enddatum,
reppr TYPE hr_rep_prf,
active TYPE hs_rep_act,
END OF ty_input.
TYPES: BEGIN OF ty_final,
us_name TYPE xubname,
rep_name TYPE xubname,
begda TYPE begdatum,
endda TYPE enddatum,
reppr TYPE hr_rep_prf,
active TYPE hs_rep_act,
message(100) TYPE c,
END OF ty_final.

DATA: substituted_obj TYPE swragent,
substitute TYPE swragent,
sub_beg TYPE swr_substbegin,
sub_end TYPE swr_substend,
sub_pfile TYPE swr_substprof,
sub_act TYPE swr_substactive,
lang TYPE sylangu,
ext_badi TYPE xfeld,
ret_code TYPE sysubrc,
msg_lines TYPE TABLE OF swr_messag,
msg_str TYPE TABLE OF swr_mstruc,
subs_tab TYPE TABLE OF swragent,
date(2) TYPE c,
month(2) TYPE c,
year(4) TYPE c,
lv_datum(8) TYPE c,
lv_dat(8) TYPE c.

*/ Data declarations
DATA:
*/ Internal Tables
lt_input TYPE TABLE OF ty_input,
lt_output TYPE TABLE OF ty_input,
lt_modify TYPE TABLE OF ty_input,
lt_temp TYPE TABLE OF ty_input,
lt_insert TYPE TABLE OF ty_input,
lt_update TYPE TABLE OF ty_input,
lt_updatex TYPE TABLE OF ty_input,
lt_deletex TYPE TABLE OF ty_input,
lt_email_address TYPE ifp_tab_address,
lt_binary_content TYPE solix_tab,
lt_email_body TYPE TABLE OF tline,

*/ Local Reference
lo_email TYPE REF TO zcl_gen_utilities,

*/ Local Structures
ls_output TYPE ty_input,
ls_insert TYPE ty_input,
ls_update TYPE ty_input,
ls_updatex TYPE ty_input,
ls_deletex TYPE ty_input,
ls_email_body TYPE tline,
ls_email_address TYPE ifp_str_address,

*/ Local Variables
lv_string TYPE string,
lv_size TYPE so_obj_len,
lv_subject(50),
lv_enddate TYPE sy-datum,
lv_err TYPE c,
lc_tab TYPE c VALUE cl_bcs_convert=>lc_tab,
lc_crlf TYPE c VALUE cl_bcs_convert=>lc_crlf.

DATA:
subst_tab TYPE STANDARD TABLE OF hrus_d2, "TABLES PARAM
wa_subst_tab LIKE LINE OF subst_tab,
err_tab TYPE STANDARD TABLE OF hrscmperr, "TABLES PARAM
wa_err_tab LIKE LINE OF err_tab.

DATA: lt_final TYPE TABLE OF ty_final,
ls_final TYPE ty_final,
lt_hrus TYPE TABLE OF hrus_d2,
lt_temp TYPE TABLE OF hrus_d2.

*/ Constants Declarations

CONSTANTS: lc_eamt_parameters TYPE string VALUE 'ZEMAIL', "
lc_ricefid_1234 TYPE zparam_name VALUE 'EMAIL1234', "
lc_param_name TYPE zmaptype1 VALUE 'Z1234_EMAIL'. "
"lc_eamt_parameters TYPE string VALUE 'ZEAMT_PARAMETERS', "

REFRESH: lt_input, lt_output, lt_update, gt_insert, lt_updatex,
lt_final, lt_hrus, lt_temp, lt_temp, subst_tab, err_tab, gt_deletex.
CLEAR: ls_final, ls_output, ls_insert, gs_update, ls_updatex, ls_deletex.

IF input-delegation_update_sap IS NOT INITIAL.
MOVE-CORRESPONDING input-delegation_update_sap-record TO lt_input.

LOOP AT lt_input INTO DATA(ls_input).
ls_output-us_name = ls_input-us_name.
ls_output-rep_name = ls_input-rep_name.
ls_output-begda = ls_input-begda.
ls_output-endda = ls_input-endda.
ls_output-reppr = ls_input-reppr.
ls_output-active = ls_input-active.
APPEND ls_output TO lt_output.
CLEAR:ls_output,
ls_input.
ENDLOOP.

LOOP AT lt_output INTO DATA(ls_output) WHERE reppr = '0003'.
month = ls_output-begda+0(2).
date = ls_output-begda+2(2).
year = ls_output-begda+4(4).
CONCATENATE year month date INTO ls_output-begda.

month = ls_output-endda+0(2).
date = ls_output-endda+2(2).
year = ls_output-endda+4(4).
CONCATENATE year month date INTO ls_output-endda.

SELECT SINGLE * FROM hrus_d2 INTO @DATA(ls_hrus) WHERE us_name = @LieneS_output-us_name
AND rep_name = @LieneS_output-rep_name
AND begda = @LieneS_output-begda.
"Case1 File data not in a table then insert a record
IF sy-subrc <> 0 AND ls_hrus IS INITIAL.
MOVE-CORRESPONDING ls_output TO ls_insert.
APPEND ls_insert TO gt_insert.
"Case2 File data in a table then update a record
ELSEIF ls_hrus IS NOT INITIAL.

IF ls_output-endda = ls_hrus-endda. "It triggers Maintain Function module
MOVE-CORRESPONDING ls_output TO gs_update.
APPEND ls_update TO lt_update.
ELSEIF ls_output-endda <> ls_hrus-endda.. "It triggers delete FM and insert a record
MOVE-CORRESPONDING ls_output TO ls_updatex.
APPEND ls_updatex TO lt_updatex.

MOVE-CORRESPONDING ls_output TO ls_deletex.
ls_deletex-endda = ls_hrus-endda. "need
APPEND ls_deletex TO gt_deletex.
ENDIF.

ENDIF.
CLEAR: ls_insert, ls_output, ls_hrus, gs_update, ls_updatex, ls_deletex.
ENDLOOP.

"Case3 Table data not in a file then need to update enddate and active
LOOP AT lt_output INTO DATA(gs_modify).
month = gs_modify-begda+0(2).
date = gs_modify-begda+2(2).
year = gs_modify-begda+4(4).
CONCATENATE year month date INTO gs_modify-begda.

month = gs_modify-endda+0(2).
date = gs_modify-endda+2(2).
year = gs_modify-endda+4(4).
CONCATENATE year month date INTO gs_modify-endda.

APPEND gs_modify TO lt_temp.
CLEAR: gs_modify.
ENDLOOP.

IF lt_temp IS NOT INITIAL.
SELECT * FROM hrus_d2 INTO TABLE lt_temp WHERE reppr = '0003'.

LOOP AT lt_temp INTO DATA(gs_temp).
DELETE lt_temp WHERE us_name = gs_temp-us_name
AND rep_name = gs_temp-rep_name
AND begda = gs_temp-begda.
CLEAR: gs_temp.
ENDLOOP.
lt_hrus = lt_temp.

"Delete the records
LOOP AT lt_temp INTO DATA(ls_temp) WHERE active = 'X'.
substituted_obj-otype = 'US'.
substituted_obj-objid = ls_temp-us_name.

substitute-otype = 'US'.
substitute-objid = ls_temp-rep_name.
APPEND substitute TO subs_tab.

sub_beg = ls_temp-begda.
sub_end = ls_temp-endda.

CALL FUNCTION 'SAP_WAPI_SUBSTITUTE_DELETE'
EXPORTING
substituted_obj = substituted_obj
start_date = sub_beg
end_date = sub_end
delete_without_date = 'X'
lang = sy-langu
ext_badi = ' '
IMPORTING
ret_code = ret_code
TABLES
substitutes = subs_tab
msg_lines = msg_lines
msg_str = msg_str.
CLEAR: ls_temp.
REFRESH: subs_tab.
ENDLOOP.

"Change end date and active with space
LOOP AT lt_hrus INTO ls_hrus.
IF ls_hrus-active = 'X'.
gs_modify-us_name = ls_hrus-us_name.
gs_modify-rep_name = ls_hrus-rep_name.
gs_modify-begda = ls_hrus-begda.
lv_datum = sy-datum.
lv_dat = lv_datum - 1.
year = lv_dat+0(4).
month = lv_dat+4(2).
date = lv_dat+6(2).
CONCATENATE year month date INTO gs_modify-endda. "need to modify
gs_modify-reppr = ls_hrus-reppr.
gs_modify-active = ls_hrus-active.
APPEND gs_modify TO lt_modify.
CLEAR: gs_modify, ls_hrus, lv_dat.
ELSE.
MOVE-CORRESPONDING ls_hrus TO gs_modify.
APPEND gs_modify TO lt_modify.
CLEAR: gs_modify, ls_hrus.
ENDIF.
ENDLOOP.
ENDIF.

LOOP AT lt_deletex INTO ls_deletex.
substituted_obj-otype = 'US'.
substituted_obj-objid = ls_deletex-us_name.
substitute-otype = 'US'.
substitute-objid = ls_deletex-rep_name.
APPEND substitute TO subs_tab.
sub_beg = ls_deletex-begda.
sub_end = ls_deletex-endda.

CALL FUNCTION 'SAP_WAPI_SUBSTITUTE_DELETE'
EXPORTING
substituted_obj = substituted_obj
start_date = sub_beg
end_date = sub_end
delete_without_date = 'X'
lang = sy-langu
ext_badi = ' '
IMPORTING
ret_code = ret_code
TABLES
substitutes = subs_tab
msg_lines = msg_lines
msg_str = msg_str.
CLEAR: ls_deletex.
REFRESH: subs_tab.
ENDLOOP.

"Case1 Create a new record
IF lt_insert IS NOT INITIAL.

LOOP AT lt_insert INTO ls_insert.
substituted_obj-otype = 'US'.
substituted_obj-objid = ls_insert-us_name.
substitute-otype = 'US'.
substitute-objid = ls_insert-rep_name.
sub_beg = ls_insert-begda.
sub_end = ls_insert-endda.
sub_pfile = ls_insert-reppr.
sub_act = ls_insert-active.

CALL FUNCTION 'SAP_WAPI_SUBSTITUTE_MAINTAIN'
EXPORTING
substituted_obj = substituted_obj
substitute = substitute
sub_beg = sub_beg
sub_end = sub_end
sub_pfile = sub_pfile
sub_act = sub_act
lang = sy-langu
ext_badi = ' '
IMPORTING
ret_code = ret_code
TABLES
msg_lines = msg_lines
msg_str = msg_str.

IF ret_code = 0.
ls_final-us_name = ls_insert-us_name.
ls_final-rep_name = ls_insert-rep_name.
ls_final-begda = ls_insert-begda.
ls_final-endda = ls_insert-endda.
ls_final-reppr = ls_insert-reppr.
ls_final-active = ls_insert-active.
ls_final-message = 'Create a new record'.
APPEND ls_final TO lt_final.
ELSE.
ls_final-us_name = ls_insert-us_name.
ls_final-rep_name = ls_insert-rep_name.
ls_final-begda = ls_insert-begda.
ls_final-endda = ls_insert-endda.
ls_final-reppr = ls_insert-reppr.
ls_final-active = ls_insert-active.
ls_final-message = 'Record is already existed'.
APPEND ls_final TO lt_final.
ENDIF.

CLEAR: ls_insert, ls_final.
ENDLOOP.
ENDIF.
"Case2 Update a existing record
IF lt_update IS NOT INITIAL. "It triggers update a existing record
LOOP AT lt_update INTO gs_update.
substituted_obj-otype = 'US'.
substituted_obj-objid = gs_update-us_name.
substitute-otype = 'US'.
substitute-objid = gs_update-rep_name.
sub_beg = gs_update-begda.
sub_end = gs_update-endda.
sub_pfile = gs_update-reppr.
sub_act = gs_update-active.

CALL FUNCTION 'SAP_WAPI_SUBSTITUTE_MAINTAIN'
EXPORTING
substituted_obj = substituted_obj
substitute = substitute
sub_beg = sub_beg
sub_end = sub_end
sub_pfile = sub_pfile
sub_act = sub_act
lang = sy-langu
ext_badi = ' '
IMPORTING
ret_code = ret_code
TABLES
msg_lines = msg_lines
msg_str = msg_str.

IF ret_code = 0.
ls_final-us_name = gs_update-us_name.
ls_final-rep_name = gs_update-rep_name.
ls_final-begda = gs_update-begda.
ls_final-endda = gs_update-endda.
ls_final-reppr = gs_update-reppr.
ls_final-active = gs_update-active.
ls_final-message = 'Modified Existing Record'.
APPEND ls_final TO lt_final.
ELSE.
ls_final-us_name = gs_update-us_name.
ls_final-rep_name = gs_update-rep_name.
ls_final-begda = gs_update-begda.
ls_final-endda = gs_update-endda.
ls_final-reppr = gs_update-reppr.
ls_final-active = gs_update-active.
ls_final-message = 'Record is already existed'.
APPEND ls_final TO lt_final.
ENDIF.

CLEAR: gs_update, ls_final.
ENDLOOP.
ENDIF.

IF lt_updatex IS NOT INITIAL. "It triggers delete FM and insert a new record

LOOP AT lt_updatex INTO ls_updatex.
wa_subst_tab-us_name = ls_updatex-us_name.
wa_subst_tab-rep_name = ls_updatex-rep_name.
wa_subst_tab-begda = ls_updatex-begda.
wa_subst_tab-endda = ls_updatex-endda.
wa_subst_tab-reppr = ls_updatex-reppr.
wa_subst_tab-active = ls_updatex-active.
APPEND wa_subst_tab TO subst_tab.

CALL FUNCTION 'RH_UPDATE_SUBST_LIST_SERVER'
TABLES
subst_tab = subst_tab
err_tab = err_tab
EXCEPTIONS
no_wf_plvar = 1
. " RH_UPDATE_SUBST_LIST_SERVER

IF sy-subrc EQ 0.
"All OK
ELSEIF sy-subrc EQ 1. "Exception
"Add code for exception here
ENDIF.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = '1'
* IMPORTING
* RETURN =
.
WAIT UP TO 1 SECONDS.
IF sy-subrc = 0.
ls_final-us_name = ls_updatex-us_name.
ls_final-rep_name = ls_updatex-rep_name.
ls_final-begda = ls_updatex-begda.
ls_final-endda = ls_updatex-endda.
ls_final-reppr = ls_updatex-reppr.
ls_final-active = ls_updatex-active.
ls_final-message = 'Modified Existing Record'.
APPEND ls_final TO lt_final.
ELSE.
ls_final-us_name = ls_updatex-us_name.
ls_final-rep_name = ls_updatex-rep_name.
ls_final-begda = ls_updatex-begda.
ls_final-endda = ls_updatex-endda.
ls_final-reppr = ls_updatex-reppr.
ls_final-active = ls_updatex-active.
ls_final-message = 'Record is already existed'.
APPEND ls_final TO lt_final.
ENDIF.
CLEAR: ls_final, ls_updatex, wa_subst_tab.
REFRESH: subst_tab.
ENDLOOP.

ENDIF.
"Case3 modify a existing record
IF lt_modify IS NOT INITIAL.
LOOP AT lt_modify INTO gs_modify WHERE active = 'X'.
wa_subst_tab-us_name = gs_modify-us_name.
wa_subst_tab-rep_name = gs_modify-rep_name.
wa_subst_tab-begda = gs_modify-begda.
wa_subst_tab-endda = gs_modify-endda.
wa_subst_tab-reppr = gs_modify-reppr.
wa_subst_tab-active = ''.
APPEND wa_subst_tab TO subst_tab.
CALL FUNCTION 'RH_UPDATE_SUBST_LIST_SERVER'
TABLES
subst_tab = subst_tab
err_tab = err_tab
EXCEPTIONS
no_wf_plvar = 1
. " RH_UPDATE_SUBST_LIST_SERVER

IF sy-subrc EQ 0.
"All OK
ELSEIF sy-subrc EQ 1. "Exception
"Add code for exception here
ENDIF.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = '1'
* IMPORTING
* RETURN =
.
WAIT UP TO 1 SECONDS.
IF sy-subrc = 0.
ls_final-us_name = gs_modify-us_name.
ls_final-rep_name = gs_modify-rep_name.
ls_final-begda = gs_modify-begda.
ls_final-endda = gs_modify-endda.
ls_final-reppr = gs_modify-reppr.
ls_final-active = ''.
ls_final-message = 'Modified Existing Record'.
APPEND ls_final TO lt_final.
ELSE.
ls_final-us_name = gs_modify-us_name.
ls_final-rep_name = gs_modify-rep_name.
ls_final-begda = gs_modify-begda.
ls_final-endda = gs_modify-endda.
ls_final-reppr = gs_modify-reppr.
ls_final-active = ''.
ls_final-message = 'Record is already existed'.
APPEND ls_final TO lt_final.
ENDIF.

CLEAR: gs_modify, ls_final, wa_subst_tab.
REFRESH: subst_tab.
ENDLOOP.
"table data not in a file then need to update end date and active with ‘space’.
LOOP AT lt_modify INTO gs_modify WHERE active = ''.
ls_final-us_name = gs_modify-us_name.
ls_final-rep_name = gs_modify-rep_name.
ls_final-begda = gs_modify-begda.
ls_final-endda = gs_modify-endda.
ls_final-reppr = gs_modify-reppr.
ls_final-active = ''.
ls_final-message = 'Activate with set to space'.
APPEND ls_final TO lt_final.
CLEAR: gs_modify, ls_final.
ENDLOOP.

ENDIF.

*/Sending email notification

IF lt_final IS NOT INITIAL. "Email

CREATE OBJECT lo_email.

lv_string = lv_string &&
'User Name'(012) && lc_tab &&
'User Name'(013) && lc_tab &&
'Start Date'(014) && lc_tab &&
'End Date'(015) && lc_tab &&
'Substitute Profile'(016) && lc_tab &&
'Substitution Active'(017) && lc_tab &&
'Message'(018) && lc_crlf.

LOOP AT lt_final ASSIGNING FIELD-SYMBOL(<fs_output>).

lv_string = lv_string &&
<fs_output>-us_name && lc_tab &&
<fs_output>-rep_name && lc_tab &&
<fs_output>-begda && lc_tab &&
<fs_output>-endda && lc_tab &&
<fs_output>-reppr && lc_tab &&
<fs_output>-active && lc_tab &&
<fs_output>-message && lc_crlf .

ENDLOOP.

ls_email_body-tdline = 'Hi'.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = ''.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = ''.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = 'Pleae see the attached file for the 3PL Substitution to S4'.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = 'Can you please check the records'.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = ''.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = ''.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

ls_email_body-tdline = 'Thank you'.
APPEND ls_email_body TO lt_email_body.
CLEAR ls_email_body.

* Convert the inernal table data into binary format.
IF lv_string IS NOT INITIAL.
lo_email->create_excel_content( EXPORTING
email_data = lv_string
IMPORTING
binary_content = lt_binary_content
size = lv_size ).
ENDIF.

* Append all the emails
DATA(l_util) = NEW zcl_gen_utilities( ).
l_util->read_parameters_table( EXPORTING table = lc_eamt_parameters
name = lc_ricefid_1234
maptype1 = lc_param_name
IMPORTING data = DATA(lt_param_tab) ).

CLEAR lt_email_address.

LOOP AT lt_param_tab INTO DATA(lw_param_tab).
CLEAR ls_email_address.
ls_email_address-address = lw_param_tab-param1.
APPEND ls_email_address TO lt_email_address.
CLEAR ls_email_address.
ENDLOOP.

CLEAR lv_subject.
lv_subject = '3PL Substitution to S4'.

IF lt_email_address IS NOT INITIAL.

lo_email->send_email_with_xls_attachment( EXPORTING
subject = lv_subject
email_address = lt_email_address
binary_content = lt_binary_content
size = lv_size
email_body_tab = lt_email_body ).

ENDIF.
ENDIF. "Email

ENDIF.

ENDMETHOD.

abap2UI5 - (12) Update II: Community Feedback, New Features & Outlook - January 2024

2024-01-08T09:16:02+01:00

Welcome to part 12 of this blog series introducing abap2UI5 — an open-source project for developing UI5 apps purely in ABAP.

Happy New Year, everyone! 🎆🎇

As we enter 2024, let's take a moment to check out the new features added to abap2UI5 towards the end of last year and then delve into the ongoing changes currently underway. Some updates were in response to user issues, while others were inspired by community pull requests.

Blog Series & More

You can find all the information about this project on GitHub and stay up-to-date by following on Twitter. Also, make sure to explore the other articles in this blog series.

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, F4-Help, Messages & Controller Logic

(4) Advanced Functionality & Demonstrations

(5) Creating UIs with XML Views, HTML, CSS & JavaScript

(6) Installation, Configuration & Troubleshooting

(7) Technical Background: Under the Hood of abap2UI5

(8) Repository Organization: Working with abapGit, abaplint & open-abap

(9) Update I: Community Feedback & New Features - Sep. 2023

(10) Extensions I: Exploring External Libraries & Native Device Capabilities

(11) Extensions II: Guideline for Developing New Features in JavaScript

(12) Update II: Community Feedback & New Features - Jan. 2024 (this blog post)

Content

This post covers the following areas:

New Controls
1. Splitting Container
2. Timeline
3. Feed Input
4. Side Panel

New Custom Controls
1. cl_demo_output
2. Multi Input Ext.
3. Table Filtering Ext.

New Functions
1. Nested Views with 3 Levels
2. Data Binding on Cell Level
3. Debugging Tools

Community Feedback
1. TechEd
2. Advent of Code
3. Developer News

Actual Changes & Outlook
1. Integration with Launchpad & BTP
2. UI5 Version 2.x
3. SAP UI5 Roadmap 2024

Let’s begin with the first topic.

1. New Controls

An increasing number of controls from the UI5 API are being integrated into abap2UI5 and can be utilized through the class z2ui5_cl_xml_view. A special thanks to choper725 and all others who have contributed PRs in this direction over the last few months.

1.1. Splitting Container

Organize your view using a Splitting Container; this control allows you to divide the view as needed and makes the sizes dynamically adjustable. Check out this demo:

Splitting Container in abap2UI5

You can find the full source code here.

1.2. Timeline

Visualize your time-dependent data with the Timeline Control. Check out the following example:

Timeline in abap2UI5

Filtering and sorting on the frontend work out-of-the-box. You can find the full source code here.

1.3. Feed Input

Display chat and message texts using the Feed Input. Check out this demo:

Feed Input in abap2UI5

You can find the full source code here.

1.4. Side Panel

Try out the Side Panel to display a menu alongside your main page:

Side Panel in abap2UI5

You can find the source code here.

2. New Custom Controls

Custom controls are an effective way to incorporate additional JavaScript logic into abap2UI5 and access it from the backend. You can find more information about this concept in the previous blog post here. The following new custom controls are now part of abap2UI5.

2.1 CL_DEMO_OUTPUT / IF_OO_ADT_CLASSRUN

Building on these two classes, numerous test programs have been created. If you also want to send their output to a browser, you can now do so with abap2UI5. A Demo Output Custom Control has been developed that sends the HTML output of cl_demo_output to the frontend. Check out this demo:

cl_demo_output Displayed in abap2UI5

Check out the full source code here. The same functionality works for the interface that creates output in ADT; check it out here.

2.2 Multi Input Extension

Sometimes, UI5 controls require additional JavaScript logic, because their current state cannot be easily transmitted to the backend through an event. This is particularly true for the Multi Input control, which involves additional token handling that is not automatically sent to the backend with the Multi Input Control's events. To address this, an additional Multi Input Custom Control has been created to ensure that all tokens are sent to the backend, and vice versa. Check out this demo:

Multi Input & Token Handling in abap2UI5

You can find the source code here.

2.3 Table Filtering Extension

One advantage of the ui.table control is that many functionalities work at the frontend without the need for additional logic. For example, you can use filtering. Unfortunately, when making a backend request and performing a model update, these filters are deleted. To address this, a small Table Custom Control has been added which enhances the filter functionality. It saves the current filter values and reapplies them after a model update. Check out this demo:

Table with Filtered Values After Model Updates in abap2UI5

You can find the source code here.

3. New Functions

From time to time, the abap2UI5 framework itself requires extensions. The following new features have made their way into abap2UI5 over the last few months:

3.1 Nested Views with 3 Levels

Nested views offer a way to partially rerender specific parts of the view. It is now possible to use up to two nested views and for example combine them for displaying positions and item details. Check out this demo:

Nested Views with 3 Levels in abap2UI5

You can find the source code here.

3.2 Binding on Cell Level

Previously, it was only possible to bind the value of variables, components of structures, and tables to attributes of the view. Now, you can also bind values to specific cells of internal tables. This is especially helpful, for example, in generating multiple input fields based on table entries. To achieve this, simply extend the _bind method with the table and the index of your row:

LOOP AT t_tab REFERENCE INTO DATA(lr_row).

   DATA(lv_tabix) = sy-tabix.

   page->input( value = client->_bind_edit( val = lr_row->title tab = t_tab tab_index = lv_tabix ) ).

   page->input( value = client->_bind_edit( val = lr_row->value tab = t_tab tab_index = lv_tabix ) ).

ENDLOOP.

This code snippet generates an input control for each cell within the internal table. Here's the code in action:

Data Binding on Cell Level in abap2UI5

You can find the full example here.

3.3 Debugger Tools

The only way to validate the XML View, Models, and Responses was by using the console. Now, by pressing CTRL+F12, a new popup opens, providing all information on Views, Models, and backend communication.

Debugging Tools of abap2UI5

This simplifies issue identification, and further functionalities can be integrated into this popup in the future.

4. Community Feedback

It's always gratifying to see the project gaining attention from other developers, being utilized in various projects, or featured in presentations. From this perspective, abap2UI5 enjoyed a very successful conclusion to last year. 🎉

4.1 SAP TechEd

The SAP Developer Advocates highlighted ABAP Open Source projects and showcased a small abap2UI5 demo with a Feed Control during last year's SAP TechEd Developer Keynote.

This achievement wouldn't have been possible without the great abapGit project, which is essential for open source development in ABAP. I hope I've emphasized enough in this blog series how much abap2UI5 benefits from the contributions of other developers & open source projects. Much of this groundwork was done even before abap2UI5 existed. A big thank you for the showcase and to all developers who are actively engaged in the ABAP Open Source Community! 🙏

https://www.youtube.com/watch?v=kLbF0ooStZs&t=3052s

4.2 Advent of Code

This year, in the Advent of Code, jorgen_lindqvist41 gave abap2UI5 a try. He created an excellent template for solving the daily puzzles, which you can view in his blog post. The template is available on GitHub here, and his solution can be seen here.

Actually this inspired me to join the Advent of Code as well, but instead of solving puzzles, I ended up adding a new feature - cell binding - to abap2UI5, filling a missing aspect of the framework, as I found in his repository here. But perhaps I'll return to it one day or use this template to join again next year. 🧑‍🎄

Advent of Code with abap2UI5

4.3. SAP Developer News

This blog series concluded last year with a final post on extending abap2UI5 with new features using custom controls. A big thank you for featuring this article in the Developer News! Let's see which additional custom controls will find their way into abap2UI5 in 2024!

https://www.youtube.com/watch?v=CfH9L03WUCg&t=350s

5. Actual Changes & 2024

Currently, most changes are being made with a focus on ensuring compatibility with upcoming updates of the UI5 library and enabling the integration of abap2UI5 with launchpads and BTP Cloud Services.

5.1. Launchpad & BTP Integration

abap2UI5 is designed for simplicity, operating on a single HTTP handler. This design allows easy installation on both 'ABAP Cloud' and 'Standard ABAP'. However, sometimes it's useful to have an independent UI5 app that isn't tied to the ABAP artifacts, making it deployable to BTP or other services. To address this, you have now also the option to use a standalone UI5 app which interacts with the backend via the HTTP handler, displaying abap2UI5 apps:

abap2UI5 Extension - BTP Proxy App

There is still some work to do, but if you're interested in beta testing, please explore this project and report any issues encountered. Upon completion of testing, I might take this opportunity to explore the new SCN blog platform and write a detailed article on this topic.

This integration approach is also applicable for the integration with on-premise launchpads. The following repository offers an UI5 app as a BSP, ensuring a straightforward installation with abapGit:

abap2UI5 Extension - On-Premise Launchpad

Feel free to explore this repository as well and report any encountered issues.

5.2 UI5 Version 2.x

Another current focus is ensuring compatibility with future improvements of the UI5 Library. Towards the end of last year, the initial version of UI5 2.x was released. For more information, refer to this blog post:

https://blogs.sap.com/2023/12/21/introducing-openui5-2.x/

This new version removes certain dependencies, resulting in limitations on using specific UI5 features. For example, module loading is now constrained, and the use of UI5's jQuery is no longer supported. You can conduct tests by bootstrapping from the following source:

https://sdk.openui5.org/nightly/2/index.html

Changes have already been implemented in recent weeks, allowing abap2UI5 to operate with the new UI5 version:

abap2UI5 Bootstrapped with UI5 Version 2.x

In some custom controls and demos, there are still some changes to be made, but these will be addressed in the future. I also suggest periodically bootstrapping with UI5 2.x to ensure proper functionality of your apps. Should you encounter any problems, please create an issue.

5.3 UI5 Roadmap 2024

Moreover, several new functionalities for the UI5 Library are currently under development. You can find more details about them in the UI5 roadmap available here:

https://roadmaps.sap.com/board?PRODUCT=73554900100800001361

It will be exciting to see how many of these changes can also be integrated into abap2UI5.

6. Conclusion

This concludes the update on abap2UI5 functionalities. Feel free to experiment with the new features in your own abap2UI5 apps. This project is continuously evolving without a fixed roadmap or specific goal. Every pull request is appreciated, and now I'm eagerly looking forward to what 2024 will bring to the project. 🙂

Thank you for reading! Your questions, comments, and wishes for this project are always welcome. Leave a comment or create an issue.