ABAP - BOPF Eigene Abfrage

In einigen Fällen möchtest du Schnittstellen nach Außen bekannt geben und deinem User die Möglichkeit geben häufig genutzte Abfragen immer wieder performant durchzuführen? Dafür gibt es eigene Abfragen die du im BOPF definieren kannst. Wir zeigen dir heute an einem Besipiel wie du so etwas umsetzen kannst.

BOBX

Alles beginnt zuerst einmal mit der Definition der Abfrage im Datenmodell. Dazu gehst du wieder in die Transaktion BOBX, um das Modell zu erweitern und eine eigene Abfrage zu erstellen. Du hinterlegst einen Namen und optional eine Beschreibung und kannst dir die DDIC Objekt Namen wieder dazu generieren lassen.

Wir möchten dem Verwender eine einheitliche Abfrage ermöglichen und stellen dazu einige Felder aus unserem Datenmodell in einer Struktur zur Verfügung, dessen Namen wir uns ebenfalls vom System generieren lassen. Bevor wir die Klasse anlegen, benötigen dazu noch die komplette Struktur.

Datenschnittstelle

Schauen wir uns auch noch einmal die Datenschnittstelle der Methode an, bevor wir uns an die Implementierung machen. Wie du aus einigen älteren Artikeln wiedererkennen wirst, sind uns bereits viele Parameter bekannt. So gibt es wieder die Konfigurationsdaten des aktuellen Knotens und Objekte zum Lesen und Ändern von Daten.

Für ein eigenes Query relevant sind vor allem die Selektion (IT_SELECTION_PARAMETERS) die die Werteingrenzungen für die einzelnen Felder enthalten, das Query Objekt (IO_QUERY) mit dem wir Standardabfragen durchführen können und die Rückgabefelder ET_KEY, sowie ET_DATA. Sollte etwas schief gehen, sollte natürlich noch das Message Objekt (EO_MESSAGE) befüllt werden.

Implementierung

Du musst dazu nun die folgenden Schritte durchführen: Zerlegen der Selektion in die einzelnen Ranges und Durchführung eines Select auf die Datenbank. Du kannst natürlich aus Performancesicht auch einen Datenbank View oder CDS View verwenden, die etwas performanter wären als der JOIN.

Im nächsten Schritt übergibst du die Daten an das Query Objekt, der nun anhand der Einstellungen und Schlüssel die richtigen Daten selektieren und zurückgeben wird.

DATA:
  lt_key       TYPE /bobf/t_frw_key,
  lt_r_create  TYPE RANGE OF crdat,
  lt_r_partner TYPE RANGE OF bu_partner.

eo_message = /bobf/cl_frw_factory=>get_message( ).
CLEAR: et_key, et_data.

LOOP AT it_selection_parameters REFERENCE INTO DATA(lr_param).
  CASE lr_param->attribute_name.
    WHEN 'CREATION_DATE'.
      INSERT VALUE #(
        sign    = lr_param->sign
        option  = lr_param->option
        low     = lr_param->low
        high    = lr_param->high
      ) INTO TABLE lt_r_create.
    WHEN 'PARTNER'.
      INSERT VALUE #(
        sign    = lr_param->sign
        option  = lr_param->option
        low     = lr_param->low
        high    = lr_param->high
      ) INTO TABLE lt_r_partner.
  ENDCASE.
ENDLOOP.

SELECT c~db_key
 FROM ztest_d_contract AS c
 INNER JOIN ztest_d_partner AS p
  ON p~parent_key = c~db_key
 WHERE c~creation_date IN @lt_r_create
   AND p~partner IN @lt_r_partner
 INTO TABLE @lt_key.

IF sy-subrc = 0.
  io_query->query(
    EXPORTING
      is_ctx                  = is_ctx
      it_filter_key           = lt_key
      io_query_authorities    = io_query_authorities
      is_query_options        = is_query_options
      io_query                = io_query
      io_read                 = io_read
      io_modify               = io_modify
      iv_fill_data            = iv_fill_data
      it_requested_attributes = it_requested_attributes
    IMPORTING
      eo_message              = eo_message
      et_key                  = et_key
      es_query_info           = es_query_info
      et_data                 = et_data
  ).
ENDIF.

Fazit

Du siehst, für eine eigene Implementierung einer Abfrage, ist nicht viel nötig und wir haben dich heute dafür mit dem passenden Wissen ausgestattet. Probier doch einmal aus, eine eigene Abfrage in dein Datenmodell zu implementieren.