The system class CL_OSQL_REPLACE implements a replacement service that can be used to redirect access to data sources in
Open SQL statements during the execution of
unit testsABAP Unit. The system class CL_OSQL_REPLACE can only be used in
test classes by ABAP Unit.
The static method ACTIVATE_REPLACEMENT of the system class CL_OSQL_REPLACE is used to define replacement rules.
A three-column internal table is passed to the parameter REPLACEMENT_TABLE:
The first column SOURCE contains the name of a data source defined in the ABAP Dictionary, that is, a database table, a classic view, or a CDS entity.
The second column, TARGET, contains the name of a database object in the current database to which an Open SQL access to the data source named in the first column is redirected.
The third column, SCHEMA, contains the name of a
database schema to be searched to find the database object from the second column. If the third column is empty, the
ABAP database schema is used.
An ID can be passed to the parameter FLG_DML to define whether the redirection also applies to write Open SQL statements:
If the value abap_false is passed to the parameter FLG_DML, the redirection only applies to
queries, that is, to the
main queries of
reads and for the subqueries of all accesses.
If the value abap_true is passed to the parameter FLG_DML, the redirection also applies to the database tables to be changed by
writes.
The redirection can be to any database objects, in particular variants of the database tables or views
defined in the ABAP Dictionary. The database objects that are redirected to must have the same structure as the object that is redirected from, otherwise the result is database specific and exceptions may arise.
A successful redirection applies for the entire execution of a module test until the
internal session is
ended or there is another redirection. A redirection is ended explicitly if an empty internal table is passed to the method ACTIVATE_REPLACEMENT.
Note
From a technical perspective, a redirection replaces the names of the database objects in the platform-specific SQL statements, which the
database interface generates from the Open SQL statements and passes to the database system.
Redirection of the data sources used by Open SQL is used during module tests so that test tables
and test data can be processed instead of the actual tables and their data. In particular, this enables testing of system programs that access system tables.
Additional Methods
As well as the method ACTIVATE_REPLACEMENT, CL_OSQL_REPLACE has the following methods:
The methods IS_REPLACEMENT_ACTIVE and IS_REPLACEMENT_ACTIVE_DML are used to check whether a redirection is active and whether it also applies to writes.
The methods SET_ACTIVE_FOR_DML and TOGGLE_ACTIVE_FOR_DML are used to set or change the setting for writes for an existing redirection.
Restrictions and Special Features
Data Sources of Reads
The following applies to data sources of reads:
The data source of a read can only be redirected to an object defined in the ABAP Dictionary if the object appears in the database with the name that it is defined with in the ABAP Dictionary.
To redirect a read from a projection view to another data source, the underlying database table can be redirected.
If the data source of a subquery in the WHERE condition of a write statement is redirected to the target of the write, the behavior is undefined and unexpected errors may occur.
If a read is redirected to a CDS view or a CDS table function for which one or more
CDS roles are defined as part of
CDS access control,
the associated access conditions are evaluated independently of the target of the redirection. CDS roles that are defined for the target of a redirection are ignored.
A CDS table function can only be redirected to a
table function. However, this does not have to be an
AMDP function.
If a direct or indirect read of a CDS table function is redirected to another data source, the
static constructor of the
AMDP class in which the associated
AMDP function is implemented is executed.
If a read of a data source is redirected to an
AMDP function that is known in the current AS ABAP, the
AMDP framework creates the associated variant in the database if necessary, and the
static constructor of the associated
AMDP class is executed.
If the source or target of a redirection is a database table of the
ABAP database schema defined in ABAP Dictionary, for which a
replacement object is defined, the redirection is evaluated first and then the replacement object.
If a data source of a read is redirected to a database table for which a replacement object is defined, a redirect to the replacement object is made.
If a database table is redirected for which a replacement object is defined, the redirection is applied and the replacement object is ignored.
If a replacement object is defined for a database table and the replacement object is redirected, the redirection is ignored and the replacement object is accessed.
The same restrictions apply to the target of a write as to the data sources of reads, if applicable. In addition, targets of writes cannot be redirected to the following objects defined in the ABAP Dictionary:
Writes to a projection
view cannot be redirected if the rows to be changed are defined by a work area or an internal table.
Therefore, it is only possible to redirect accesses to the database table of a projection view if there
are no writes to the view (except with the statements
DELETE with a WHERE condition or
UPDATE with the addition SET). Otherwise, a runtime error occurs.
Example
See the program DEMO_CL_OSQL_REPLACE.
A production class prod reads data from the database table SCARR in the
method select, and deletes a row from this table in the method delete.
The test class test_prod tests the methods of the production class.
In the method setup, access to SCARR is redirected for read and write
Open SQL statements with cl_osql_replace=>activate_replacement to a test
table DEMO_TEST_SCARR, which was defined in ABAP Dictionary as a copy of SCARR. The database schema of DEMO_TEST_SCARR is passed here explicitly for demonstration purposes, but this is not necessary for database objects from the
ABAP database schema.
In the method setup, the test table DEMO_TEST_SCARR is supplied with two rows of test data from an internal table testdata.
In the method test, the method select is called
and the return value is compared with the internal table testdata. Calling
the method delete deletes a row of test data from the test table and checks that the deleted row no longer exists.
In the method teardown, the test data is deleted from the test table.
Execution of the module test should always be successful, regardless of the content of SCARR.