SAP-Formulare ohne Frust: Mein Workflow mit dox42
Wer im SAP-Umfeld entwickelt, weiß: Formulare sind oft ein Klotz am Bein. Man verbringt Stunden mit Adobe Forms…
In ABAP, the FILTER operator provides a powerful way to reduce internal tables based on a filter table. This enables an elegant and high-performance data filtering approach without explicit loops.
... FILTER type( itab {[EXCEPT] IN ftab [USING KEY keyname]}
| {[USING KEY keyname] [EXCEPT] IN ftab}
WHERE c1 op f1 [AND c2 op f2 [...]] ) ...
This syntax allows filtering an internal table (itab) based on conditions and values from a filter table (ftab).
For complete documentation, refer to the official SAP ABAP documentation: ABAP FILTER Operator – Filtertabelle
🔹 The internal table itab is filtered based on the values of a filter table ftab.
🔹 A comparison is made between the columns of itab and the key columns of ftab.
🔹 The result depends on the use of EXCEPT:
The USING KEY clause allows specifying an explicit key for either itab or ftab to optimize the lookup process. The key can be a sorted key or a hash key:
✅ Using a key for ftab → ftab must have a sorted key or hash key, which is used to efficiently check for matches. There are no special requirements for itab.
✅ Using a key for itab → itab must have a sorted key or hash key, which is used to improve lookup performance. There are no requirements for ftab.
✅ Without USING KEY → ftab must be a sorted table or a hash table, and the primary key is used implicitly. There are no requirements for itab.
🔹 The choice of which table to specify a key for depends on your optimization goals. If the filter table (ftab) is large and frequently accessed, defining a key for ftab can significantly improve performance. On the other hand, if the main table (itab) is large, defining a key for itab will optimize the filtering process. By specifying a key for the table that benefits most from indexing, you can ensure faster lookups and better performance.
In this example, we filter a list of customers (customers) using a filter table (filter). Since filter is a standard table without a primary key, we need to use USING KEY:
DATA customers TYPE TABLE OF scustom WITH EMPTY KEY.
DATA filter TYPE STANDARD TABLE OF scustom-id WITH EMPTY KEY
WITH UNIQUE SORTED KEY line COMPONENTS table_line.
SELECT * FROM scustom INTO TABLE @customers.
filter = VALUE #( ( '1001' ) ( '1003' ) ( '1005' ) ).
DATA(filtered_customers) = FILTER #(customers IN filter
USING KEY line
WHERE id = table_line ).Here, we define a sorted key on the main table (customers) instead of the filter table:
DATA customers TYPE SORTED TABLE OF scustom
WITH UNIQUE KEY id.
DATA filter TYPE STANDARD TABLE OF scustom-id
WITH EMPTY KEY.
SELECT * FROM scustom INTO TABLE @customers.
filter = VALUE #( ( '1001' ) ( '1003' ) ( '1005' ) ).
DATA(filtered_customers) = FILTER #( customers
USING KEY primary_key IN filter
WHERE id = table_line ).A common use case for the FILTER operator is to dynamically exclude specific fields from a component list based on configurable criteria. This example demonstrates how to achieve that using a custom filter table and the EXCEPT option.
DATA filter TYPE SORTED TABLE OF fieldname WITH UNIQUE KEY table_line.
SELECT field_name FROM zexclude_fields WHERE active = @abap_true INTO TABLE @filter.
DATA(components) = CAST cl_abap_structdescr(
cl_abap_typedescr=>describe_by_name( 'BUT000' ) )->components.
components = FILTER #( components EXCEPT IN filter WHERE name = table_line ).By leveraging the FILTER operator with a filter table, you can significantly improve performance in ABAP. Always evaluate where to use USING KEY based on the size of the tables involved, and make use of the EXCEPT clause when excluding records. Try implementing these techniques in your own projects to experience the performance benefits firsthand.