SAP Community - SAP R/3

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

Update 01.01.2025
Please note that some information in this blog article may be outdated. For the most current details, refer to our Documentation and stay informed by following us on LinkedIn.

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 LinkedIn and explore the other articles in this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, Value-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).

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.

The functionality of automated ABAP downporting is impressive and greatly improves efficiency. Check out the abaplint dashboard of this project. 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

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, stay up-to-date by following on LinkedIn and explore the other articles in this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, Value-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

And here we go...

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

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->check_on_navigated( ).
   "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 - Navigation 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
You can find all the information about this project on GitHub, stay up-to-date by following on LinkedIn and explore the other articles in this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, Value-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 etc.)

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
You can find all the information about this project on GitHub, stay up-to-date by following on LinkedIn and explore the other articles in this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, Value-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( ).

    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.

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, stay up-to-date by following on LinkedIn and explore the other articles in this blog series:

(1) Introduction: Developing UI5 Apps Purely in ABAP

(2) Displaying Selection Screens & Tables

(3) Popups, Value-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

Here we go:

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.

Release of new Podcast Episode “SAP R/3 Port to Linux”

2024-10-25T09:41:44.320000+02:00

4th Anniversary of “The Open Source Way” Podcast

With an interesting new episode taking you three decades back in time, we would like to celebrate the 4th anniversary of the open source podcast series hosted by the SAP Open Source Program Office. Reflecting on this milestone for 'The Open Source Way' podcast, the OSPO team would like to thank all the contributors and listeners, and extend a big kudos to Karsten Hohage for moderating the series since its inception! We would also like to express our gratitude to Sezgin Devran, who had the initial idea and started this podcast in 2020.

The experts talking to Karsten have shared very personal stories, expertise, and insights into their activities in open source. The topics of the 45 episodes are as diverse as the field of open source itself – from open-source projects to compliance and security, collaboration models, and global initiatives such as foundations. We look forward to many more engaging episodes and conversations in the future.

SAP R/3 Port to Linux (October 2024 episode)

In the latest podcast episode, we take a fascinating journey back to the 1990s – a pivotal time in the world of technology – when the SAP software stack was first ported to Linux. Two industry pioneers, Christoph Rohland (former SAP, now at Software AG) and Harald Kuck (SAP, ABAP Platform) discuss the challenges, triumphs, and transformative moments of this significant transition. They offer very personal insights into how they led the transition of R/3 and its stack to run on Linux.

Why this episode matters

Today, Linux serves as the backbone of many SAP solutions, providing a robust open-source operating system infrastructure. However, the path to this point was anything but straightforward. Christoph and Harald share their first-hand experiences from the early days of open source at SAP, shedding light on how their innovative efforts laid the groundwork for the collaborative software landscape we enjoy today. They take us to the early years of Linux, when 8 CPUs were still a really big thing for a developer, when you tested external software on CDs, and when using fax for sending personal documents was still the modus operandi.

Key highlights from the episode:

Anecdotes from the frontlines: Listen to unique stories and insights from Christoph and Harald about the challenges they faced while porting the SAP software stack to Linux.
SAP’s role for Linux: You might be surprised to hear how some essential parts of the Linux kernel were really contributed by SAP in the late 1990s.
The evolution of Open Source: Hear about the times when open source began to play a role within SAP and the broader tech community and how these early efforts have influenced our approach to software development and collaboration.
The future of Linux and SAP solutions: Christoph and Harald discuss the ongoing relevance of Linux in the SAP ecosystem, and what the future may hold for open-source initiatives at SAP.
The key to driving innovation: Harald and Christoph emphasize the importance of developer initiative, a supportive management, and listening to your customers when pursuing innovative ideas.

Tune In Now!

Whether you're an SAP user, an open-source enthusiast, or simply curious about the technological advancements that shaped our current landscape, this episode is a must-watch. Join us as we celebrate the pioneers of open source at SAP and explore the impact of their work on the industry.

"Would you rather have Bill Gates know your name or an Email discussion with Linus Torvalds" (feel free to comment) was one question to Harald and Christoph. Hear the answer in the podcast. Let us know in the comments, if you have any particular topic of interest for future episodes or reach out to the SAP OSPO team directly.

_____________________________________________________________________________

About the authors

Ulrike Fempel, SAP Open Source Program Office
Ajinkya Patil, SAP Open Source Program Office, responsible for the podcast production

More information / links

How to Release PR document from HOLD or PARK status using BAPI

2025-02-21T09:28:32.886000+01:00

Introduction:

A purchase requisition is an internal document used in an organization to request the procurement of goods or services. In SAP, efficient management of purchase requisitions is crucial for smooth procurement operations. This blog will provide a clear guide on releasing PR documents from HOLD or PARK status using BAPIs and releasing the document for further processing.

Understanding Parked and Hold Documents in SAP:

First, let's understand the PARK and HOLD options in SAP. These functionalities are essential for managing purchasing documents, allowing users to save them temporarily for later processing.

Hold: If the document has incorrect or incomplete data and you want to save it temporarily to process later, use the Hold option.

Park: If the document has complete and correct data but needs further workflow approvals or budget checks, use the Park functionality.

Activating Hold and Park options:

To activate the PARK and HOLD options in transactions ME51N, ME52N, and ME53N, follow these two steps:

Activate Business Functionality
- Go to T-Code SPRO.
- Click on Activate Business Functions
- Expand the folder Enterprise_Business_Functions and activate the functionality LOG_MM_CI_3.

2. Enable PARK and HOLD Features In T-Code SPRO, follow this path:
Materials Management --> Purchasing --> Environment Data --> Activate 'Park and Hold' in Purchasing Documents.

By completing these steps, you will enable the PARK and HOLD functionalities for purchasing documents in your SAP system.

Changing PR document status from HOLD or PARKED to SAVED using BAPI:

To change the status of a purchase requisition document from HOLD or PARKED to SAVED, you can use the BAPI “BAPI_PR_CHANGE.”.

Below is an example of how to implement this in ABAP:

DATA: ls_prheader  TYPE bapimereqheader,
      ls_prheaderx TYPE bapimereqheaderx,
      lt_return    TYPE TABLE OF bapiret2.

IF  ls_prheader-preq_no IS NOT INITIAL.

 ls_prheader = VALUE #( preq_no       = |{ ls_prheader-preq_no ALPHA = IN }|
                        park_complete = abap_false
                        hold_complete = abap_false
                        memorytype    = abap_false ).
  
 ls_prheaderx = VALUE #( preq_no       = abap_true
                         park_complete = abap_true
                         hold_complete = abap_true
                         memorytype    = abap_true ).

CALL FUNCTION 'BAPI_PR_CHANGE'
  EXPORTING
   number     = ls_prheader-preq_no “Your PR Number
    prheader  = ls_prheader
    prheaderx = ls_prheaderx
  TABLES
    return   = lt_return.
IF VALUE #( lt_return[ type = 'S' ] OPTIONAL ) IS NOT INITIAL.
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
    EXPORTING
       wait = abap_true.
ELSE.
    ROLLBACK WORK.
ENDIF.
ENDIF.

Release Strategy:

The release strategy in SAP defines the approval process for purchase requisitions:

Purpose: Ensures PRs are reviewed and approved before conversion to purchase orders.
Release Codes: Each strategy can have up to eight release codes, indicating who must approve the requisition.
Approval Sequence: Specifies the order in which approvals must be obtained.
Assignment: Release strategies are assigned based on release conditions like document type and value.

Release Code:

A release code is a two-character ID that authorizes a person to approve or release a purchase requisition or external purchasing document.

Purpose: It serves as an electronic signature, replacing traditional handwritten approvals. This digitization streamlines the approval process and enhances efficiency.
Assignment: Release codes are assigned to employees based on their roles and authorization levels within the organization. For example, a clerk might have a release code for initial approvals, while a manager has a higher-level code.
Configuration:

Approval Process: The release strategy specifies which release codes must be used and the sequence of approvals required.

Releasing PR documents using BAPI:

To release a PR that needs approval from respective employees/approvers in your organization, you can use the BAPI - “BAPI_REQUISITION_RELEASE_GEN”.

Below is an example implementation:

DATA : lt_return TYPE TABLE OF bapireturn.
 
 CALL FUNCTION 'BAPI_REQUISITION_RELEASE_GEN'
   EXPORTING
     number     = iv_pr_num       “Your PR Number
     rel_code   = iv_release_code “Release code
   TABLES
     return      = lt_return.
 IF VALUE #( lt_return[ type = 'S' ] OPTIONAL ) IS NOT INITIAL OR 
    lt_return IS INITIAL.
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
    EXPORTING
       wait = abap_true.
 ELSE.
    ROLLBACK WORK.
 ENDIF.

Finding Release Codes:

You can find release codes under the Release Strategy tab in transactions ME51N, ME52N, and ME53N.

The following tables are useful for retrieving relevant information:

EBAN: To get the release group and release strategy for the PR number.
T16FS: To get release codes for a particular release group & strategy.
T16FW: To get approver names/IDs for a release code.

Conclusion:

This blog emphasized the significance of parked and hold documents, the activation of essential functionalities, and the use of BAPIs to change PR statuses. We also explored the release procedure and strategy, illustrating how structured approvals can enhance efficiency in your procurement processes.

Thank you for reading!

Streamlining SAP Background Job Execution with Event-Based Triggers

2025-04-16T10:37:33.019000+02:00

In some Business Scenarios, we need to collaborate with third-party solutions, such as bank integrations within the system. In such scenarios, scheduling pre-defined standard programs as part of the overall process is often necessary. We encountered a recurring issue with one such program (RFEBKA00), scheduled as a background job in our system to run hourly, checking an Application Server directory for the presence of specific files. Whenever a file was available, the job executed perfectly. However, if no file was present at the time of execution, the job would fail, resulting in unnecessary alerts and false alarms in our monitoring systems. Over time, this not only created confusion but also masked genuine job failures that required immediate attention.

To address this efficiently without deviating from SAP standards, I developed an innovative yet straightforward solution to prevent frequent false alerts and maintain accurate and clean monitoring while still using the original standard program.

There can be other business scenarios as well where this solution can help.

Solution Design:

a) To resolve this, we implemented a wrapper program serving as a pre-check mechanism. This wrapper performs the following actions:

Checks the necessary prerequisites (e.g., file presence in an Application Server directory).
If prerequisites are met, it triggers the standard SAP job - RFEBKA00 (program - RFEBKA00).
If prerequisites are not met, it gracefully exits with an informational message, thus keeping our monitoring precise and relevant.

b) Set up this wrapper program (ZXXX) as background job every hour and change current setup for ‘RFEBKA00’ job to trigger only for event - Z_EVENT’ raised by ZXXX program.

c) If team needs to check what time the file was found, they can still check the background job – ‘RFEBKA00’. Else, if this job was not run, that means, there was no file found at that time.

Technical Steps:

1. Create a new Background Event (Z_EVENT) in Tcode - SM62 (don’t check system event checkbox):

2. Create an External Command 'Z_LS' in Tcode - SM49:

3. Create wrapper program – ZXXX with below processing logic:

Fetch all the files present in the entered AL11 folder by using FM - 'SXPG_COMMAND_EXECUTE' for below parameters:
COMMANDNAME = 'Z_LS'
ADDITIONAL_PARAMETERS = '<AL11 folder path>'
If the required file is found in that folder, trigger job - 'RFEBKA00' by using FM – 'BP_EVENT_RAISE' for below parameters:
EVENTID = 'Z_EVENT'
If the event is successfully triggered, display Success message. Else, display information message - 'No file was found for processing in path' and run successfully.

4. Schedule a new background job to run every hour (like it is happening for RFEBKA00 job currently).
Schedule as: Periodic Job (every hour or as required), program Step: ZXXX (wrapper program).

5. Change ‘RFEBKA00’ job scheduling to – ‘only trigger after event – ‘Z_EVENT’, Job frequency: Periodic, keeping Program Steps same.

..And that's it!

Now, the job 'RFEBKA00' will only run if there is a file present in AL11 folder it looks for. This will filter out the case of failed/cancelled jobs because simply the file was not present at the time of execution.

Although there can be different ways to approach this challenge, I believe this solution could be beneficial in other similar business scenarios as well, enhancing operational efficiency and system reliability.

Please let me know your thoughts in the comments.

Cheers! 🎉

You Won't Believe Where ZLLM's Documentation Lives (And How It Got There)

2025-07-02T12:45:53.530000+02:00

How I Made AI Write Its Own Documentation... In SAP's Standard Format

Spoiler: The AI is already documenting itself in production*.

Hello again! 👋 It's Alice, and I have a confession: I absolutely love writing documentation.

But I hate writing it BY HAND. Especially in SAP's bizarre ITF format - that cryptic markup language designed back when the closest thing to modern markup was SGML, and HTML didn't even exist yet!

(Fun fact: ITF format was actually designed for SAPscript in the early 1980s as part of SAP R/2 - when "markup language" meant something completely different! ^_^)

But here's the thing - ZLLM has incredible documentation. Comprehensive, detailed, and perfectly formatted. And it lives exactly where every SAP developer NOT expects it: behind the standard "Show Documentation" button 😃

Plot Twist:

I didn't write a single line of that documentation manually.

ZLLM documented itself.

The Documentation That Writes Itself

Click on any ZLLM class in SE80 or ADT. Hit CTRL+SHIFT+F2 (Show Documentation).

What you'll see isn't your typical sparse ABAP documentation. It's rich, detailed, with examples, architecture diagrams, and usage patterns. All perfectly formatted in SAP's native documentation system.

Here's what makes this magical:

The documentation exists in standard SAP format (ITF), appears in standard SAP locations, but was generated by modern AI and written in human-readable Markdown first.

How I Built The Documentation Factory

Step 1: The Analysis Phase

" ZLLM analyzes the codebase
DATA(lo_analyzer) = zcl_llm_00_step_lazy=>new_from_string(
  iv_usr = 'Analyze this ABAP class and extract:'
           '- Purpose and responsibility'
           '- Public methods and parameters' 
           '- Usage patterns and examples'
           '- Integration points: {T}'
  io_llm = lo_llm
).

Step 2: The Generation Phase

" Generate comprehensive Markdown documentation
DATA(lo_generator) = zcl_llm_00_step_lazy=>new_from_string(
  iv_usr = 'Create technical documentation in Markdown format:'
           '- Overview section with clear purpose'
           '- Method documentation with examples'
           '- Code samples showing real usage'
           '- Integration notes and best practices'
           'Based on analysis: {T}'
  io_llm = lo_llm
).

Step 3: The Integration Magic

" Chain it all together
DATA(lo_doc_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
  ( lo_analyzer )
  ( lo_generator )
) ).

" Generate docs for entire framework
DATA(lr_result) = lo_doc_flow->exec( REF #( class_metadata ) ).

For the Markdown → ITF conversion and integration with SAP's documentation system, I used another one of my frameworks: XRAY. But that's a story for another article... ^_^

The Real Magic: Production-Ready Documentation

This isn't a toy example. This is live, production documentation that:

✅Appears in standard SAP tools (SE80, ADT, SE11)

✅Follows SAP documentation conventions

✅Updates automaticallywhen code changes

✅Includes real examplesand usage patterns

✅Maintains technical accuracy through AI analysis

### Before vs After:

Traditional SAP Documentation:

* It is a class.

ZLLM-Generated Documentation:

Why This Changes a Lot

For SAP Developers:

No more "TODO: Add documentation" comments
Comprehensive docs appear automatically in familiar places
Examples and usage patterns generated from actual code

For Enterprise Teams:

Documentation stays current with code changes
Consistent format across entire codebase
Onboarding new developers becomes trivial

For AI Adoption:

Demonstrates practical AI value in daily development
Shows integration with existing enterprise tools
Proves AI can enhance rather than replace existing workflows

The Recursive Beauty

Here's the beautiful irony: ZLLM used itself to document itself.

The framework that makes enterprise AI integration effortless also made documenting itself effortless. It's AI all the way down.

How You Can Build This

Want to auto-document your own ABAP code? Here's the starter pattern:

METHOD auto_document_class.
  " 1. Extract class metadata
  DATA(lo_metadata) = extract_class_info( iv_class_name ).
  
  " 2. Generate documentation
  DATA(lo_doc_step) = zcl_llm_00_step_lazy=>new_from_string(
    iv_usr = 'Create comprehensive documentation for this ABAP class: {T}'
    io_llm = lo_llm
  ).
  
  " 3. Chain and execute
  DATA(lo_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
    ( lo_doc_step )
  ) ).
  
  DATA(lv_markdown_doc) = lo_flow->start( REF #( lo_metadata ) )->to_string( ).
  
ENDMETHOD.

The Bigger Picture

This isn't just about documentation. It's about AI that enhances existing enterprise workflows instead of disrupting them.

Traditional AI Integration: "We need new tools, new processes, new training..."

ZLLM Approach: "Your existing tools just got smarter."

The documentation appears exactly where SAP developers (not?) expect it. No new interfaces to learn. No new processes to adopt. Just better, more comprehensive information in familiar places.

What's Next?

This is just one example of ZLLM eating its own dog food. Other production uses:

Code Analysis- Analyzing patterns across the entire ABAP stack

Performance Monitoring- Generating insights from system metrics

Test Generation- Creating unit tests from business requirements

Migration Planning - Analyzing code dependencies for S/4HANA migration

Ready to Document Your Code Automatically?

⭐Explore ZLLM: -> github/oisee/zllm

Comment below:What part of your ABAP development would you want AI to handle?

🔄Share if you think your SAP team needs this

Try it yourself:

1. Install ZLLM in your development system

2. Run the documentation generator on your classes

3. Watch as comprehensive docs appear in standard SAP locations

4. Never write manual documentation again

About Alice Vinogradova:

Senior Software Engineer with 20+ years in ABAP/SAP. I specialize in making enterprise AI practical, starting with solving our own problems first. If the AI can't document itself, how can it document your business processes?

P.S. Yes, this article was edited by ZLLM too. And the Markdown → ITF conversion? That's handled by my XRAY framework - another story of making SAP development less painful. It's recursive intelligence all the way down.

*production for development - is development.

Tags: #SAP #ABAP #AI #Documentation #TechLeadership #Automation

"The ideal documentation is one that doesn't need to be written because it writes itself."

How Retro Gamers Solved Time-Travel Debugging in 1995 (And Why Your Enterprise Debugger Still Can't)

2025-08-04T14:49:47.702000+02:00

A Tale of Two Debuggers

Scene 1: A modern enterprise developer in 2025, debugging a critical SAP integration. "If only I could go back in time and see what happened," they sigh, adding another log statement.

Scene 2: A 14-year-old in 2005, playing Super Mario on ZSNES. They press F1 to save state, die horribly, press F3 to load state, try a different approach. "Cool," they say, taking it completely for granted.

Welcome to the upside-down world where teenage gamers have better debugging tools than Fortune 500 companies.

TL;DR: github/ysichov/Smart-Debugger

https://github.com/ysichov/Smart-Debugger

The Secret That Wasn't a Secret

Here's what the retro computing community figured out decades ago:

Everything in a computer is deterministic except I/O.

That's it. That's the whole secret. Let me explain why this changes everything.

The Beautiful Math of Determinism

Same CPU state + Same memory + Same inputs = Same result
ALWAYS.

This means you don't need to record everything. You only need to record:

Initial state (once)
External inputs (keyboard, interrupts, timers)
I/O responses

For a Z80 system, that's maybe 100 bytes per second of recording. For an hour of debugging? About 360KB. That's smaller than a single Slack emoji.

The Timeline That Should Embarrass Us All

Let's put this in perspective with a side-by-side timeline:

🎮Gaming/Emulator World vs 💼 Enterprise World

1997

🎮ZSNES: Save states introduced. Gamers can save/load any moment instantly
💼Enterprise: "Have you tried adding more print statements?"

1999

🎮Nesticle: Frame advance debugging. Step through games frame by frame
💼Enterprise: "Maybe we should standardize on log4j?"

2003

🎮FCEU: TAS* tools mainstream. Input recording, RAM watch, Lua scripting
💼Enterprise: "Distributed debugging is impossible"

2004

🎮MAME: Debugger with memory watchpoints, execution trace, state diffing
💼Enterprise: "Remote debugging sometimes works if you're lucky"

2006

🎮DeSmuME: Dual-screen debugging, touchscreen record/replay
💼Enterprise: "Have you tried turning on verbose logging?"

2010

🎮MAME: Full rewind feature. Go back in time at any moment
💼Enterprise: "Debugging microservices is hard"

2014

🎮BizHawk: Multi-system TAS suite. Deterministic replay across different CPUs
💼Enterprise: "Maybe we need more logs?"

2018

🎮RetroArch: Netplay with rollback, achievements system, shaders
💼Enterprise: "Debugging in production is scary"

2020

🎮TAS Bot: AI playing games frame-perfectly using debug tools
💼Enterprise: "We added structured logging!"

2023

🎮LibTAS: TAS tools for native Linux games, not just emulators
💼Enterprise: "Time-travel debugging? Sounds futuristic!"

2025

🎮Every emulator: Rewind, replay, Lua scripting, memory analysis standard
💼Enterprise: "Our new AI can analyze your logs!"

The Tragedy in One Image

Teenager in 2004: *casually rewinds Mega Man X, 
                   adjusts one frame, gets perfect run*

Senior Developer in 2025: "The bug only happens in production 
                          on Tuesdays. We'll never catch it."

What Makes This Hilarious/Sad

A Nintendo emulator from 1998 can:

Run Super Mario
Let you save at any millisecond
Rewind time
Record and replay any bug perfectly
Show you every memory change in real-time

Your enterprise debugger can:

Set breakpoints (sometimes)
Print variables (if you're lucky)
Crash (frequently)

Enter Tool-Assisted Speedrunning: Debugging as Art

TAS creators took these debugging tools and turned them into an art form. Watch this:

They're not just playing games. They're:

Analyzing frame-by-frame execution
Tracking memory corruption
Exploiting race conditions
Optimizing code paths

Sound familiar? That's literally what we do when debugging, except they have better tools.

The ABAP Revolution: Finally, Someone Gets It

Yurii Sychov looked at ABAP debugging and had a radical thought: "What if we just... did what emulators do?"

His Smart-Debugger implements what gamers take for granted:

Variable time travel
Execution recording
State comparison
Visual debugging

But here's where it gets REALLY interesting...

The Memory Revolution: It's 2025, Not 1975

Modern servers have TERABYTES of RAM. An ABAP variable? Maybe 1KB. Even a complex object graph? Perhaps 1MB.

This means we can store:

Every variable change
Every method call
Every execution path
Multiple complete runs

Do the math:

1000 variables × 1KB each × 1000 changes = 1GB
Your server's RAM: 512GB
Percentage used: 0.2%

We're optimizing for constraints that haven't existed for 20 years.

The Graph Diff Revolution

Now here's where it gets wild. Since we can store everything, we can:

1. Record Multiple Executions

abap

" Run 1: Bug happens
execution_graph_1 = record_full_execution( buggy_input )

" Run 2: Bug doesn't happen  
execution_graph_2 = record_full_execution( good_input )

2. Build Execution Graphs

Graph 1 (Buggy):
main() → parse_input() → validate() → process() → CRASH
         ↓                ↓           ↓
      [user_id: 123]  [cache: empty] [null_ptr]

Graph 2 (Working):
main() → parse_input() → validate() → process() → success()
         ↓                ↓           ↓
      [user_id: 123]  [cache: valid] [object_ref]

3. Diff the Graphs

diff

@@ -15,7 +15,7 @@
 validate() {
   check_permission()
-  load_user_context()  // ← Returns null in buggy run
+  load_user_context()  // ← Returns valid object
   verify_data()
 }

Key difference: cache state at execution time
Buggy:   cache.contains(user_123) = false
Working: cache.contains(user_123) = true

4. Compare with Static Analysis

Your static analysis says load_user_context() can never return null. Your execution trace says it did. Boom. Bug found.

The AI Cherry on Top

Now feed this to an LLM with structured data:

{
  "execution_diff": {
    "divergence_point": "load_user_context()",
    "buggy_state": {"cache": "empty", "result": "null"},
    "working_state": {"cache": "valid", "result": "user_object"},
    "static_analysis": "method cannot return null"
  },
  "context": {
    "method_signature": "load_user_context(): User",
    "cache_invalidation_log": ["14:23:15 - cache cleared", 
                               "14:23:16 - request received"]
  }
}

Prompt: "Based on execution diff, identify root cause"

LLM: "Race condition detected: Cache was invalidated at 14:23:15, but the null check in load_user_context() only verifies if cache exists, not if the specific key is present. The 1-second window allows requests to hit empty cache."

Automated RCA achieved.

But Wait, What About Reality?

"Sure," you say, "but emulators work with closed systems. What about network calls? Databases? Microservices?"

Fair point! Modern systems have more non-determinism. But that's exactly why we need BETTER recording, not worse:

The I/O Boundary Principle Still Applies

" Instead of just keyboard input, modern I/O includes:
IO_Events = {
  network_responses,     " Record actual HTTP responses
  database_results,      " Record query results  
  timestamp_calls,       " Record time() returns
  random_values,         " Record RNG outputs
  thread_scheduling      " Record context switches
}

Yes, it's more complex than a NES emulator. But the principle remains: Record at the boundaries, replay deterministically.

The Call to Revolution

Here's what we should be demanding:

For Every Debugger:

Time travel (perfected in emulators since ~2010)
Deterministic replay (standard in TAS tools since 2004)
State diffing (TAS creators do this manually)
Execution graphs (we have the memory!)
Automatic RCA (we have the LLMs!)

The Technical Requirements:

Record I/O boundaries (a few KB/second)
Snapshot on demand (even 1GB is nothing)
Build execution graphs (basic CS)
Diff and analyze (solved problem)

Start Today

If you use ABAP: Get Smart-Debugger now ^_^
For other languages: Demand better tools
For tool creators: Study emulators, not enterprise

The Future Is Already Here

It's just unevenly distributed. And ironically, it's been living in game emulators for 30 years.

Next time someone tells you time-travel debugging is "too hard" or "too expensive," show them a 15-year-old speedrunner casually rewinding time to manipulate RNG in Pokémon. Then ask them why enterprise software can't do the same.

Memory is cheap. CPU is fast. The algorithms are known. The only thing missing is the will to build it.

Welcome to 2025. It's time to debug like it.

Your debugger doesn't suck because it's hard to build. It sucks because the culture around it never thought like a gamer. Time to change that.

P.S. 🎮TAS (Tool-Assisted Speedrun) A meticulously crafted playthrough of a video game using emulator tools like save states, slow motion, and frame-by-frame control. The goal: perfect execution—sometimes exploiting bugs—to achieve record-breaking performance or hilarious outcomes.

Alice Vinogradova is a Senior Software Engineer at Microsoft who thinks your debugger should be at least as good as a Super Nintendo emulator from 1998.

Hedonic Pricing: What Do Investors Pay For?

2025-12-26T22:55:40.142000+01:00

Executive summary
Investors do not primarily pay for short-term margin spikes or isolated growth initiatives. Instead, over a 35-year horizon, the market has consistently rewarded one thing above all else: persistency. This is the term Goldman Sachs attaches to the capital structure discipline, specifically leverage (Assets/Equity). We find that leverage explains the majority of the variation in Home Depot’s Market Cap / Equity, our proxy for the Price/Book ratio. This finding closely replicates Goldman Sachs’ famous analysis of what markets pay for, but applies to a single company and validates using long-horizon time-series data. Profitability and efficiency matter — but they come second.

This note describes our findings in three simple blocks:

data preparation and transformation
results and interpretation
what it means for Home Depot and investors.

1. Data preparation: looking at Home Depot the way markets do

This analysis starts from a simple premise:

If we want to understand how investors value Home Depot, we must model Home Depot the way investors observe it.

We assembled 144 quarters (1990–2025 YTD) of data covering both market valuation metrics (P/B ratio, Market Cap, Enterprise Value) and accounting fundamentals (assets, equity, leverage, margins, asset turnover).

This is important: unlike cross-sectional studies across many firms, this model is time-series for a single company. We are not asking why Home Depot is valued differently than Lowe’s. We are asking a more precise question:

What has historically driven changes in Home Depot’s valuation over time?

Log transformations: elasticity, not levels

All core variables are expressed in logarithmic form. This is essential for interpretation:

Coefficients become elasticities
Relationships become scale-free
Long-term growth dynamics dominate short-term noise

In plain English: we are modeling percentage changes investors respond to, not absolute dollar movements.

The dependent (predicted) variable is the

ln(Market Cap / Equity), a proxy for the P/B ratio, directly links market valuation to balance-sheet fundamentals — exactly how long-term equity investors think.

Three independent (predictor) variables are

Leverage = (Assets - Goodwill) / Stockholders Equity where we specifically remove Goodwill to account for “tangible leverage” only,

Net Margin = Net Income / Revenue,

Turnover = Revenue / (Assets - Goodwill) here too, assets are net of goodwill for "tangible turnover."

In one quarter, Home Depot reported negative net income. In 9 quarters the company reported negative equity - initially in 2019 as a result of the adoption of the FASB ASU No. 2016-02, "Leases (Topic 842)". This is why the lines in the plot below exhibit discontinuities: natural logarithm of a negative number is undefined.

In log terms, valuation and operating fundamentals move in clear and persistent co-movement over time. Sustained multiple expansion coincides with rising operating efficiency, greater leverage capacity, and improving margins, while periods of valuation compression align with broad-based fundamental deterioration. Valuation itself behaves as a slow-moving state variable, reflecting investors’ long-run assessment of economic capacity, whereas operating metrics adjust at higher frequency around that state. Even during externally imposed disruptions—such as recessions and market panics—temporary dislocations give way to re-convergence, underscoring that market multiples are ultimately disciplined by fundamentals rather than driven by sentiment alone.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This systematic co-movement directly motivates a hedonic valuation, in which observed market multiples are modeled as the equilibrium price investors assign to distinct operating characteristics rather than as standalone time-series outcomes.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2. The hedonic pricing regression: what explains Home Depot's valuation?

Conceptually, the model mirrors the DuPont identity, which decomposes Return on Equity into three elements:

Leverage (Assets / Equity)
Profitability (Net Margin)
Efficiency (Asset Turnover)

Our model - with the log-transformed data - is:

To accommodate periods of negative net margin and negative stockholders’ equity, we introduced dummy variables that flag sign changes (0 for positive values, 1 for negative). The inclusion of dummy variables allows the model to accommodate sign changes without materially altering coefficient magnitudes or inference.

The regression, run in R Studio, produced a formula where most coefficients are statistically significant at the 5% level (p<0.05). The ln_net_margin variable returned a p-value of 0.0744, indicating a 7.4% probability of observing this result (or one more extreme) if there were actually no relationship between ln_net_margin and ln_mktcap_over_equity.

We drop the decimals:

Here is the most intuitive interpretation of the model’s coefficients and log-terms: elasticity. These bars represent standardized coefficients, not raw elasticities, and are intended for relative magnitude and intuition, not literal percentage translation.

	Home Depot’s valuation is most sensitive to changes in asset turnover, indicating that improvements in capital efficiency drive market multiples more powerfully than margin expansion alone.
In raw log terms, leverage can be interpreted as follows: a 1% increase in leverage increases Market Cap / Equity by approximately 1%.
Net margins exhibit a comparatively modest elasticity, suggesting that accounting profitability, while important, does not independently command valuation premiums.

Taken together, the results align closely with how long-term equity investors think: sustainable valuation expansion is rooted in efficient deployment of capital, not short-term margin optimization.

The key result: persistency dominates

The model has R2 of 94.05% and Adjusted R2 of 93.91%. If we decompose the individual predictors’ contribution to this explained variance in Market Cap/Equity, the key conclusion emerges:

Visually, this is striking: the largest block by far is leverage. Most of what investors paid for Home Depot over 35 years is captured by three variables of which Leverage is the most significant. This is what Goldman Sachs found in their panel data analysis calling the hedonic pricing element persistency.

Persistency, in Goldman’s framework, means:

Stable capital structure
Predictable balance-sheet scaling
Consistency in how equity is multiplied into assets and cash flows

What we have done here is replicate that insight, but:

For one company
Using 35 years of quarterly data
With a fully transparent regression framework

The alignment is almost exact.

Notably, the model contains no explicit time trends, macroeconomic variables, or sentiment indicators—yet it explains over 94% of valuation variation, underscoring how consistently markets price the same economic fundamentals.

In Home Depot’s case, leverage alone explains roughly two-thirds of the market’s valuation signal. Profitability matters — but it is secondary, less persistent, and less trusted by investors as a long-term signal.

Both actual and predicted series represent the log market-cap-to-equity multiple where

The chart shows that a simple three-variable hedonic model tracks Home Depot’s valuation remarkably well over more than three decades. Even though the model has no awareness of time, cycles, or sentiment, its predicted valuation closely follows the actual market valuation across multiple regimes. Deviations between the two lines are concentrated in periods of market stress or speculative excess, while long-run trends are captured cleanly.

In other words, investors consistently price the same economic fundamentals, though they might temporarily lose discipline during panics and recessions.

This directly supports the executive intuition captured in the quote by Dilip Shanghvi, the founder and CEO of Sun Pharmaceuticals:

“I will never risk capital; but I will risk profit.”

Markets agree.

3. How solid is our model? Is it "too clean"?

No serious business model should avoid this question.

Residual behavior (what we checked)

We explicitly reviewed:

Residual distribution
Residuals vs. fitted values
Time clustering during stress periods

With F-statistics 684.4 on 3 and 130 degrees of freedom and p-value < 2.2 x 10-16, the model is structurally sound, though markets still panic occasionally — and then revert.

That is exactly what we would expect from real investors.

What do residuals tell us

Residuals widen during periods of macro-financial stress, including the Global Financial Crisis, COVID, and the post-2022 rate shock. This is expected: markets temporarily price fear, liquidity constraints, and narrative risk beyond firm-level fundamentals.

Outside stress regimes, residuals oscillate tightly around zero with no persistent bias. Deviations cluster in time rather than by sign, indicating regime effects rather than model misspecification. Overvaluation episodes—most notably the late 1990s—mean-revert as market discipline reasserts itself.

Bottom line: the model “fails” when markets panic — and reliably re-anchors valuation once sentiment normalizes.

* * *

So, what does this actually mean for Home Depot?

Insight #1: capital discipline is the valuation anchor

Home Depot’s high valuation multiple is not fragile. It is anchored in:

Consistent leverage
Predictable scaling of equity
Transparent capital return policy

Any unexpected shift in capital structure — aggressive deleveraging or sudden debt expansion — would matter far more to valuation than a bad margin quarter.

Insight #2: profitability matters — but only if it is repeatable

Operational improvements (margin, turnover, ROA) explain about one quarter of valuation variation. That is meaningful — but markets discount one-off wins. Investors prefer:

Incremental improvements
Predictable execution
Fewer surprises

Spectacular quarters impress analysts. Consistent ones move valuation.

Insight #3: macro matters less than headlines suggest

Despite constant focus on rates, housing cycles, and sentiment, macro variables explain only a single-digit share of long-term valuation variation. Home Depot’s valuation history is fundamentally a company-driven story, not a macro-driven one.

Once full-year 2025 financials are available, we will:

Re-estimate the model
Test coefficient stability
Re-evaluate valuation implications under the new regime and compare/contrast the hedonic pricing model with the traditional DCF valuation model

If history is any guide, the conclusion is unlikely to change — but the path may.

Final thought

Markets are often accused of being short-term and irrational. Over 35 years of Home Depot data suggests the opposite.

Investors are remarkably consistent in what they reward.

They pay for persistency.