ABAP in Practice - Fiori Data incorrect

Table of contents

• Introduction
• Preparation
• Task
• Solution
• Request
• Filter
• Key
• Correction
• Summary
• Conclusion

In this article, we'll look at an error in Fiori that requires some analysis and ultimately leads to a completely different problem.

 

Introduction

Analyzing RAP applications isn't always easy in everyday life, especially if you're not yet familiar with the ABAP RESTful Application Programming Model. The numerous objects and the large stack sometimes cause one or two problems. In this example, we'll build a small application that looks fine at first glance, but then leads to a lengthy error analysis.

 

Preparation

So that you can replicate the example yourself, we've created a small Git repsitory on GitHub. This gives you a template for all objects or allows you to drag the entire case into your system. After the components have been installed, you still need to start the executable class ZCL_BS_DEMO_EXAMPLE_FIORI_DATA so that data is created in the tables.

The repository contains a few tables for our data model. Here, we use a document that has positions, and notes can then be created for certain positions. We want to combine the data because the business department would like to see it side by side, similar to classic ALV.

 

 

Otherwise, you will find the modeled Core Data Services, which then generate the report. We are not using any behavior, as this is intended purely as a display report.

 

Task

The department has now tested our application and wanted to run the report, but a strange result appeared in the display. We received a corresponding screenshot of the data; all data from the database was displayed without selection. Individual items appear to be repeated repeatedly.

 

We are conducting an initial analysis and, as developers, are directly looking at the data from the Core Data Service "ZBS_C_DMOExFioReport". So far, everything seems to be working fine; the data is being loaded completely, and no errors are detectable. The same number of records will also be found and passed to the UI.

 

Now for your task. You have the service and the Fiori Elements application at your disposal, and you should now begin analyzing the application. You should find the error that is causing the UI to be inconsistent and fix it. All the tools you need, such as the browser and the ABAP Development Tools, are at your disposal.

 

Hint: In the next section, we will discuss the solution. If you would like to complete the task independently, you should pause here.

 

Solution

Let's now look at various points and try to find a way to solve the problem. We won't always follow the correct path, but will look at different methods that might lead to a solution.

 

Request

So let's first look at the request that goes to the backend and what we receive as a result. To do this, you can open the console in your browser and look in the Network tab. If you start the selection using the "Go" button, the browser will send various requests, which appear here.

 

The $batch request is interesting for us because it sends the requests to the backend in a batch. If we look at the "Payload" tab there, we will find the various requests. In this case, a GET is performed against the reporting, and no further data is restricted besides the standard pagination.

 

In the response, we find the system's response and can extract the JSON string with the structure to view it and check the data.

 

If we check the data, everything is fine. The different positions are loaded and linked together. So far, the query is correct, and we receive the same result as we saw in the Core Data Service.

 

Since we are receiving the data correctly, the next conclusion would actually be that the processing in the UI is causing an error, and therefore we are not seeing the correct data. In principle, I would agree with this, but this is purely Fiori Elements standard, and we have not made any adjustments. If we take a second application for comparison, the data is displayed correctly there.

 

Filter

Let's try the filter in the application again. We receive all data correctly from the backend. What if we want to see a document and a position that isn't visible? If we enter the filter, the position is loaded correctly. However, the note in the back area is still incorrect.

 

Slowly, a picture seems to be becoming clearer. Somehow, the system is having trouble assigning the correct data records. For correct assignment, it is therefore important that the keys are clearly defined.

 

Key

We already looked at the Core Data Service and the result in the task description; everything looks correct there. So let's check the defined keys in the modeling again and look at the consumption view.

 

It doesn't look that obvious at first, with no warnings and no notifications from the system. However, if we go down one level and run the check on the views, we'll be surprised by a few warnings.

 

Correction

In principle, someone could provide you with such a view, and you wouldn't even notice the problem at first. What we now need to do is define the additional keys. Whenever we adopt fields from a "one-to-many" association, we should also adjust the key. Therefore, we will revise the fields for ZBS_I_DMOExFioReport.

define root view entity ZBS_I_DMOExFioReport
  as select from ZBS_I_DMOExFioDocument
{
  key DocumentId,
  key _Position.PositionNumber,
  key _Position._Notes.NoteId,
      CreationDate,
      _Country._Text[ Language = $session.system_language ].CountryName,
      _Position.Customer,
      _Position._Notes.Description
}

 

And so that we can activate the two views, we also need to update ZBS_C_DMOExFioReport with the new logic for the key fields.

define root view entity ZBS_C_DMOExFioReport
  provider contract transactional_query
  as projection on ZBS_I_DMOExFioReport
{
  key DocumentId,
  key PositionNumber,
  key NoteId,
      CreationDate,
      CountryName,
      Customer,
      Description
}

 

After activating both views, we can take another look at the preview. The data is now displayed correctly in the Fiori Elements application.

 

Summary

The problem wasn't immediately apparent and was actually a result of the modeling of the data sets at the beginning of our data retrieval. Since we started with the document, this was our primary key from the very beginning. However, with each additional level of data that we display in the view, we add more rows to the display, multiplying our data. Here, it is also important to extend the key to ensure uniqueness.

The data preview displays all data in the database, but there is no indication as to whether the key is unique. We need to review and compare the definition again later. A hint, an exception, or a dump in the event of a key violation would probably be very helpful in error analysis.

 

Conclusion

With this example, we wanted to demonstrate that the problem may not always come from the expected direction, but that there are sometimes other causes. We also wanted to show you different methodologies for approaching it and how you might get started with data analysis.