SAP ABAP Replacement Objects

«« Previous
Next »»

A CDS view can be assigned (using the name of its CDS entity) as a replacement object to a transparent database table and to a classic database view in ABAP Dictionary. The prerequisite here is that the structure type that is defined by the database table or by the classic view is the same as the structure type defined by the CDS view.
  • The number of components must match.
  • The names of the components must match (except for the client column) and must be in the same order.
  • The technical type properties predefined data type, length and number of decimal places must match for every component.
  • The CDS view cannot have any input parameters.
  • It is not possible to simultaneously have a replacement object defined and SAP buffering switched on for a database view with a changeable maintenance status.
In the following cases if a database table or a classic view is accessed and a replacement object is assigned to the table or view, the replacement object is evaluated instead of the database table or classic view:
  • Use as a data source of a SELECT statement in Open SQL. This also applies to subqueries in any open SQL statement and to the statements OPEN CURSOR and FETCH. This bypasses any SAP buffering defined for the database table or the classic view.
  • Checking a foreign key relationship for (Web) Dynpros.
All other access types are still performed on the database table or classic view such as:
  • Writes in Open SQL
    • Modifying writes in Open SQL
    • Use of addition SINGLE FOR UPDATE in statement SELECT
  • Writes like this produce a syntax check warning and are forbidden in strict mode from Release 7.50.
  • Use in other database objects, such as:
    • Use as a data source of a view defined on the database
    • Access from database procedures or database functions
Here it is not important how the database object was created. This means, in addition to natively created views, the views defined for classic database views in ABAP Dictionary or for CDS views on the database also do not access the replacement object. A similar principle applies to AMDP procedures and AMDP functions. Even if Open SQL is used to access a classic database view of ABAP Dictionary, a CDS view or a CDS table function, which comprises database tables with replacement objects, no redirection occurs. In these cases, the replacement object must be accessed directly. For classic database views, a replacement object can be created that performs this task without the need to modify the programs.
  • Other access types than with Open SQL, for example:
    • Access with Native SQL ( ADBC, AMDP, EXEC SQL)
When you define a replacement object for a database table for a classic database view, the system checks whether the specified CDS view fulfills the prerequisites. If a CDS view used as a replacement object is changed later on in such a way that the prerequisites are no longer fulfilled, a runtime error DBSQL_REDIRECT_INCONSISTENCY occurs when an Open SQL read is performed on the database table or on the database view.

No replacement objects can be defined for global temporary tables. In customer systems, replacement objects can only be defined for self-defined database views but not for database tables.

  • You should be extremely careful when specifying a proxy object for a database table or a database view. Incorrect usage can cause inconsistencies.
  • Replacement objects are mainly intended for existing aggregate tables. These are database tables, which contain aggregated data from other tables. Instead of aggregating data in an ABAP program and writing data to an aggregate table, which can be exclusively accessed by reads in programs, the aggregation can be performed for every read using the CDS view. This prevents redundant data from being stored. In addition, aggregation on the database can improve performance if it is necessary to read large volumes of data for aggregation in ABAP. Replacement objects can make this possible without invalidating the programs.
  • The prerequisite for assigning a replacement object to an existing database table or database view is that the CDS view returns the expected data and that, apart from aggregation, only Open SQL reads are performed on the aggregate table.
  • After the definition of a replacement object, no further writes should be performed on an aggregate table. These writes result in a warning from the syntax check and have been banned in the upcoming release.
  • Make sure that apart from the use of Open SQL, no other type of access is performed on an aggregate table with a replacement object. The CDS view used as a replacement object in particular is not allowed to access the represented object, because the content is usually no longer updated.
  • We do not recommend transporting table content for which a replacement object is defined. These contents are automatically no longer transported in the upcoming release.
  • SAP buffering should be deactivated for an aggregate table for which a replacement object is defined, in order to prevent buffer invalidations.
  • In customer systems, it may be useful to define a replacement object for a self-defined classic database view, if a replacement object has been defined for one of their basis tables at SAP. In this case, the replacement object of the view must access the replacement object of the basis table.
  • The classic projection view, maintenance views and help views are not defined on the database. Access to their basis tables is carried out on AS ABAP by using Open SQL. If a basis table has a replacement object, its reads are redirected as required.
  • Frameworks that use Open SQL, such as the Data Browser, automatically access replacement objects, if these objects are defined for a database table or a database view. Frameworks that use Native SQL, such as SADL, have to make sure that they access a replacement object rather than the database table or the database view.
  • Wherever possible, any programs, which have been directly accessing aggregate tables or views with aggregate tables as basis tables, should be modified so that they directly access the CDS views that are used as replacement objects. However, this can usually not be done by simply replacing the data source in the relevant SELECT statements. This is because a client-specific CDS view does not have a client column and therefore the used target objects no longer match.

Replacement Object for Database Table

This example demonstrates a database table with a replacement object.

Source Code

REPORT demo_table_replacement_object.


  METHOD main.
    DATA(out) = cl_demo_output=>new( ).

    "Aggregate table (GTT)
    SELECT FROM demo_sumdist_agg
           FIELDS *
           INTO TABLE @DATA(result_agg).
    DELETE FROM demo_sumdist_agg.

    "Table with replacement object
    SELECT FROM demo_sumdist
           FIELDS *
           INTO TABLE @DATA(result).

    ASSERT result = result_agg.

    "Direct access to CDS view
    SELECT FROM demo_cds_sumdist
           FIELDS @sy-mandt AS mandt, demo_cds_sumdist~*
           INTO TABLE @DATA(result_cds).

    ASSERT result_cds = result.

    out->write( result ).

    "Classic view on demo_sumdist without replacement object
    SELECT FROM demo_sumdist_obs
           FIELDS *
           INTO TABLE @DATA(result_view_obs).
    IF result <> result_view_obs.
        'Classic view without replacement object differs.' ).

    "Classic view on demo_sumdist with replacement object
    SELECT FROM demo_sumdistview
           FIELDS *
           INTO TABLE @DATA(result_view).
    IF result =  result_view.
        'Classic view with replacement object is the same.' ).

    out->display( ).
  METHOD class_constructor.
    DELETE FROM demo_sumdist_agg.
    INSERT demo_sumdist_agg FROM
      ( SELECT
          FROM scarr AS s
            INNER JOIN spfli AS p ON s~carrid = p~carrid
          FIELDS s~carrname,
                 SUM( p~distance ) AS sum_distance
          GROUP BY s~mandt, s~carrname, p~distid ).

  demo=>main( ).


This program accesses two database tables, DEMO_SUMDIST_AGG and DEMO_SUMDIST. These tables are identical except for the fact that the CDS view DEMO_CDS_SUMDIST is defined as a replacement object for DEMO_SUMDIST.

The database table DEMO_SUMDIST_AGG is filled with aggregated data (done here in the static constructor of the class demo). When DEMO_SUMDIST is accessed, the replacement object performs exactly the same aggregation:

@AbapCatalog.sqlViewName: 'DEMO_CDS_SUDI' 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
define view demo_cds_sumdist 
  (client, carrname, distid, sum_distance) 
  as select from scarr as s 
            join spfli as p on s.carrid = p.carrid 
  { key s.mandt, 
    key s.carrname, 
    key p.distid, 
    sum(p.distance)  }           
  group by s.mandt, s.carrname, p.distid 
Similar access to the database tables produce similar results, which can be verified using the statement ASSERT.

A third SELECT statement accesses the CDS view DEMO_CDS_SUMDIST directly. To produce the same results set for the comparison with the other results as when accessing the database tables, the client column must be added, since the results set of a client-specific CDS view does not contain a column of this type.

A classic database view DEMO_SUMDIST_OBS contains the database table DEMO_SUMDIST as a basis table. There is no redirect to the replacement object of DEMO_SUMDIST in a SELECT. A classic database view DEMO_SUMDISTVIEW that is otherwise similar has the following CDS view as a replacement object:

@AbapCatalog.sqlViewName: 'DEMO_CDS_SUDIV' 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
define view demo_cds_sumdistview 
   as select from demo_cds_sumdist 
  { key client, 
    key carrname, 
    key distid, 
    sum_distance }           
This view accesses the replacement object of the database table DEMO_SUMDIST. When DEMO_SUMDISTVIEW is accessed using SELECT, its replacement object is evaluated and the result again matches the preceding result.

«« Previous
Next »»

No comments:

Post a Comment