(DV-2302) Filtering Screen

Owned by SNP
Feb 07, 2023
7 min read

The Set filters screen allows you to define filter values to be used during the DB table read. It supports three types of filtering options:

It is allowed to use all three 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 in 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 to 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, and 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 the current class:

  • lo_run_ctx->A_VARIANT_ID: After image ID

  • lo_run_ctx->INITIALIZED: Is the 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: Run ID of the Variant execution

  • lo_run_ctx->START_TIMESTAMP: Timestamp of the start of the run

  • lo_run_ctx->TC_TECHNAME: Test case technical name 

  • lo_run_ctx->TC_TYPE: Test case type

  • lo_run_ctx->VARIANT_ID: VariantID

  • lo_run_ctx->TABLE_NAME: Table name for the Variant (30c)

  • lo_run_ctx->ROWCOUNT: Row count 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 (characteristic) 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 the 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 on whether the currently processed line is relevant for the selection, or not. Returning value X includes the line in the data image, and 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 the 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 rule's 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 to 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 the current class:

  • lo_run_ctx->A_VARIANT_ID: After image ID

  • lo_run_ctx->INITIALIZED: Is the 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: Run ID of the Variant execution

  • lo_run_ctx->START_TIMESTAMP: Timestamp of the start of the run

  • lo_run_ctx->TC_TECHNAME: Test case technical name 

  • lo_run_ctx->TC_TYPE: Test case type

  • lo_run_ctx->VARIANT_ID: VariantID

  • lo_run_ctx->TABLE_NAME: Table name for the Variant (30c)

  • lo_run_ctx->ROWCOUNT: Row count 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 of the 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: