/
(DV-2211) Filtering screen

(DV-2211) Filtering screen

Owned by SNP
Nov 25, 2022
7 min read

The Set filters screen allows you to define filter values to be used during the DB table read. It supports 3 types of filtering options: Static filter, Dynamic filter, WHERE condition. It is allowed to use all the 3 types of filters for a single field, the relation between each filter is logical AND operation.

The Static filter supports a maximum of 100 distinct filtering fields. It is possible to swap between the descriptions of table filtering fields and their technical name by clicking on the 'Display Description/Technical Name' button.

 

The Dynamic filter allows the runtime execution of a piece of ABAP code which returns a table of selection ranges, which then are applied as filtering values during the DB read. This is an advanced feature; it is expected that the user has at least basic knowledge of the ABAP syntax and coding. Each field of a table can have a maximum of one dynamic filter rule defined in a single variant.

 

To create a rule, click on the insert row button.

First, fill in the field name, then fill type A (ABAP dynamic filter) and finally, provide a rule name. The ABAP code of a rule can be opened by double-clicking on its name. If the rule doesn't exist, a pop-up will ask for confirmation to create it. The naming is restricted to a Z prefix for the rules created by the customer.

The Local option in the filter row defines that if a variant is executed on a remote system through RFC, the ABAP code should be executed locally on the main system where the test was started from. If unchecked, it will be executed remotely on the target system.

 

The ABAP editor allows the edition of the code.

 

The code's syntax can be checked with the “Check syntax” button.

 

The code can be pretty printed by clicking on the “Pretty print” button.

 

By clicking on the “Confirm” button. the code will be saved regardless of the validity of its syntax to allow continuous writing of the ABAP.

 

By clicking on the “Cancel” button. all the changes made for the code since the last confirmation will be discarded. A variant can be saved with a syntactically incorrect rule, but at saving, a warning pop-up will inform the user of the code's incorrectness.

The code of the rules report is locked, only a part of the form is editable, where the filter code should be written. The user can use the “add_to_range” macro to add a value to the selection range returning table. From the form, the context of the current run is accessible through the “lo_run_ctx” object. This object carries the available information of the run (e.g. the timestamp of the last run of the variant).

 

Available information from the context class in current class

  • lo_run_ctx->A_VARIANT_ID - after image id

  • lo_run_ctx->INITIALIZED - is context class initialized

  • lo_run_ctx->LAST_START_TIMESTAMP - the timestamp of the last run

  • lo_run_ctx->PL_TECHNAME - testplan technical name

  • lo_run_ctx->RFC_DEST - RFC destination of the Variant

  • lo_run_ctx->RUNID - runID of the Variant execution

  • lo_run_ctx->START_TIMESTAMP - timestamp of the start of the run

  • lo_run_ctx->TC_TECHNAME - testcase technical name 

  • lo_run_ctx->TC_TYPE - testcase type

  • lo_run_ctx->VARIANT_ID - VariantID

  • lo_run_ctx->TABLE_NAME - tablename for the Variant (30c)

  • lo_run_ctx->ROWCOUNT - is rowcount selected

  • lo_run_ctx->STORAGE_ID - StorageID for SM Table Variant

  • lo_run_ctx->T_FIELD_MAPPING - table of Field Mapping definition

  • lo_run_ctx->T_CHAR_FIELD  - table of selected key(charachteristic) fields of the Variant

  • lo_run_ctx->T_KYF_FIELD - table of selected value fields of the Variant

  • lo_run_ctx->T_TAGS - table with Variant TAGs

  • lo_run_ctx->EXT_TABNAME_LONG - external table name for SM Table Variants (255c)

  • lo_run_ctx->T_DYN_FLT - table with Dynamic Filters of the Variant

  • lo_run_ctx->T_CONTENT - table of DF ABAP codes  

Example for adding values to range:

  add_to_range:   'I' 'EQ' 'Any low value' 'Any high value',   'E' 'GT' 'Any low value' 'Any high value'.

 

The ABAP relevancy filter allows the runtime execution of a piece of ABAP code to further restrict the selection of data already taken from the DB. The output of the ABAP relevancy filter is the information whether the currently processed line is relevant for the selection, or not. Returning value ‘X’ includes the line in the data image, value ‘ ‘ excludes the line. Each field of a table can have a maximum of one relevancy filter defined in a variant.

To be able to use relevancy filtering, the impacted field must be filled in the key or value fields of the variant. This is an advanced feature; it is expected that the user has at least basic knowledge of the ABAP syntax and coding. It is feasible to use relevancy rules together with dynamic filters for the same variant.

The “Set filters” button gets you to the screen where all filter values and logic to be used during the DB table read can be defined.

 

To create a relevancy filter rule, click on the insert row button.

First, fill in the field name, then type R (ABAP relevancy filter), and provide a filter name. The ABAP code of a rule can be opened by double-clicking on its name. If the rule doesn't exist, a pop-up will ask for confirmation to create it. The naming is restricted to Z prefix for rules created by the customer.

 

The Local option in the filter row defines that if a variant is executed on a remote system through RFC, the ABAP code should be executed locally on the main system where the test was started from. If unchecked, it will be executed remotely on the target system.

The ABAP editor allows the edition of a rules code.

 

The code's syntax can be checked with the “Check syntax” button.

 

The code can be pretty printed by clicking on the “Pretty print” button.

 

By clicking on the “Confirm” button, the code will be saved regardless of the validity of its syntax to allow continuous development.

 

By clicking on the “Cancel” button. all the changes made for the code since the last confirmation will be discarded. A variant can be saved with a syntactically incorrect rule, but at saving, a warning pop-up will inform the user of the code's incorrectness.

 

The code of the form is locked. Only a part of the form is editable, where the code should be written.

From the form, the context of the current run is accessible through the “lo_run_ctx” object. This object carries the available information of the run (e.g. the timestamp of the last run of the variant).

 

Available information from the context class in current class

  • lo_run_ctx->A_VARIANT_ID - after image id

  • lo_run_ctx->INITIALIZED - is context class initialized

  • lo_run_ctx->LAST_START_TIMESTAMP - the timestamp of the last run

  • lo_run_ctx->PL_TECHNAME - testplan technical name

  • lo_run_ctx->RFC_DEST - RFC destination of the Variant

  • lo_run_ctx->RUNID - runID of the Variant execution

  • lo_run_ctx->START_TIMESTAMP - timestamp of the start of the run

  • lo_run_ctx->TC_TECHNAME - testcase technical name 

  • lo_run_ctx->TC_TYPE - testcase type

  • lo_run_ctx->VARIANT_ID - VariantID

  • lo_run_ctx->TABLE_NAME - tablename for the Variant (30c)

  • lo_run_ctx->ROWCOUNT - is rowcount selected

  • lo_run_ctx->STORAGE_ID - StorageID for SM Table Variant

  • lo_run_ctx->T_FIELD_MAPPING - table of Field Mapping definition

  • lo_run_ctx->T_CHAR_FIELD  - table of selected key fields of the Variant

  • lo_run_ctx->T_KYF_FIELD - table of selected value fields of the Variant

  • lo_run_ctx->T_TAGS - table with Variant TAGs

  • lo_run_ctx->EXT_TABNAME_LONG - external table name for SM Table Variants

  • lo_run_ctx->T_DYN_FLT - table with Dynamic Filters of the Variant

  • lo_run_ctx->T_CONTENT - table of DF ABAP codes  

Example for edited part of the form, where the filters code is written

 

 Example for “Display logs”, where the number of excluded rows by caused relevancy filtering is visible