This is a test message to test the length of the message box.
Login
ABAP RAP Search
Created by Software-Heroes

RAP - Search

466

In this article we deal with the generic search for RAP objects and how we can also interpret incorrect entries.



So far, in the RAP series, we have mainly dealt with search helps that are linked directly to fields and allow input help to be generated for them. But here the user must know in which field he actually has to search for information and should know the demarcation to some extent.

 

Introduction

In RAP objects we can also activate the generic search. This is a search field that can search 1-n columns for the information entered. With this search field, there are various ways we can design efficient searches:

 

Activate

The generic search can be activated with the help of a header annotation in the corresponding consumption view of the RAP object, so the function is available in the UI. To do this, the following annotation must be inserted somewhere above the definition:

@Search.searchable: true

 

However, the annotation cannot stand alone in the CDS view, the compiler will issue an error message that at least one element must be marked as searchable. In this case, we mark the invoice number and the partner as searchable. To do this, we add the corresponding annotations to the fields:

          @Search.defaultSearchElement: true
  key     Document,
...
          @Search.defaultSearchElement: true
          Partner,

 

The corresponding search is now defined and we can try it once in the application. In the first case, we enter a document number once and get the following result:

 

In the second test case, we enter a partner number once and receive all documents with the corresponding partner number, in this case 35 pieces:

 

Fuzziness

What does not work in the current version of the search is searching for patterns or incorrect entries. The information is not always exactly what you are looking for in the column. Sometimes they deviate by small nuances and are therefore not displayed in the search result. There is fuzziness in the search, which determines how much error tolerance is used in the search. Let's define the rate on the two fields:

          @Search.defaultSearchElement: true
          @Search.fuzzinessThreshold: 1.0
  key     Document,
...
          @Search.defaultSearchElement: true
          @Search.fuzzinessThreshold: 0.9
          Partner,

 

The "Threshold" determines how imprecise the values in the column can be. At 1.0 the value must match 100%, the lower the rate, the broader the search and the more hits the search returns. We set the second field to 0.9 so that we can start a rough search via the partner. If we now enter the value "1234", we get a hit:

 

However, if we search for the value "12347", we get no hit. An error was deliberately built into the string here. Let's set the threshold to 0.8 and try the search again:

 

The fuzziness is now less precise and we also get hits that are actually only similar to what we were looking for. Invoices can also be found that may have received an error during entry and no longer have the information you were looking for.

 

Consumption View

Simply by adapting the annotations in the consumption view, we were able to implement a generic search that can also find deviations. You can find the entire Core Data Service here with the corresponding new annotations:

@EndUserText.label: 'Consumption for ZBS_R_RAPCINVOICE'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true
@Search.searchable: true
define root view entity ZBS_C_RAPCInvoice
  provider contract transactional_query
  as projection on ZBS_R_RAPCInvoice as Invoice
{
          @Search.defaultSearchElement: true
          @Search.fuzzinessThreshold: 1.0
  key     Document,
          DocDate,
          DocTime,
          @Search.defaultSearchElement: true
          @Search.fuzzinessThreshold: 0.8
          Partner,
          @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_BS_DEMO_CRAP_VE_EXIT'
  virtual NumberOfPositions : abap.int4,
          _Position : redirected to composition child ZBS_C_RAPCPosition
}

 

Conclusion

Implementing a generic search in Fiori Elements is very easy, requiring little annotation and no great development. The implementation should not be a problem for you and so you do not need a separate search for each field.


Included topics:
RAPBTPSearch
Comments (0)



And further ...

Are you satisfied with the content of the article? We post new content in the ABAP area every Friday and irregularly in all other areas. Take a look at our tools and apps, we provide them free of charge.


RAP - Translation app (example)

Category - ABAP

Let's take a look at a practical example of developing a RAP application in the ABAP environment and how you can create an app with little effort.

08/02/2024

RAP - Custom Entity Value Help (Deep Dive)

Category - ABAP

With the Custom Entity you have the most freedom in RAP when developing ABAP Cloud applications, but what about potential errors?

07/12/2024

RAP - Deep Action in OData v4

Category - ABAP

In this article we will look at actions with deep structures, how we can create them and pass data to an API endpoint.

05/24/2024

BTP - Connect On-Premise (Consumption Model v2)

Category - ABAP

In this article we want to provide another update on the connection of on-premise systems and how this is done with a communication arrangement.

12/15/2023

RAP - Show app count (Tile)

Category - ABAP

This example is about displaying a counter on the tile of a Fiori Elements application and how such a thing can be implemented.

10/06/2023