Cast Operations and Case Statements in CDS

Cast Operations

Cast operations represent some of the most important fundamental SQL functions. You can use cast operations for determining the type of a calculated field and for converting the type of existing fields on the database level. The CDS syntax supports casts onto elementary ABAP types as well as onto data elements.

@AbapCatalog.sqlViewName: 'zcds_cast_v'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'View with Cast Operations'
define view ZCDS_CAST as select from t000 {
    t000.logsys as ProjectedField,
    '20170809'  as CharacterField,
    cast ( '20170809' as abap.dats )    as DateField,
    cast ( cast ( 'E' as abap.lang ) as sylangu preserving type ) as LanguageField,
    1.2 as FloatingPointField,
    fltp_to_dec( 1.2 as abap.dec(4,2) ) as DecimalField
}
    


By default, a field keeps the type of its origin if it’s simply projected into a CDS view. For example, field ProjectedField retains the type from its underlying base field t000.logsys.

If fields are locally defined, an implicit type assignment is applied. As a result, field CharacterField is defined as a char field of length 8 based on the literal value 20170809. By explicitly casting the same literal value onto type DATS, field DateField becomes a date field.

You can also nest cast operations. This option is illustrated by expression cast ( cast ( 'E' as abap.lang ) as sylangu preserving type ). The value E is implicitly regarded as a character value of length 1. In a first step, the type of corresponding field LanguageField is explicitly set to LANG. In a second step, data element sylangu finally determines the type of the field. Because there is no change of the technical type, this conversion is accompanied by addition PRESERVING TYPE.

Field DecimalField is constructed from value 1.2. Due to this value assignment, it’s implicitly defined as a field of type FLTP. To convert this field into a field of type DEC, function FLTP_TO_DEC is applied.

Note:
You should always explicitly cast calculated fields onto the desired data type if feasible from a technical perspective. Otherwise, you may experience unexpected side effects from implicit type assignments.


Case Statement:
You can use case statements for defining conditional calculations in your CDS view logic. Within a single case statement, you can define multiple execution paths via WHEN-THEN switches. Based on the WHEN condition, you can apply dedicated THEN instructions, which finally determine the calculated value of a field. At the end of a case statement, you can add an ELSE instruction without conditions. This branch allows you to handle cases that aren’t covered by the WHEN conditions. Without this fallback valuation, the calculated field may have the value null, if none of the explicit WHEN conditions match.


define view entity Z_ViewWithCaseStatements
  as select from ZI_SalesOrder
{
  key SalesOrder,
      case (SalesOrderType)
        when 'TAF' then 'X'
        when 'OAF' then 'X'
        else ''
      end     as IsStandardOrder,
      cast( case (SalesOrderType)
        when 'TAF' then 'X'
        when 'OAF' then 'X'
        else ''
      end as abap.char(3) ) as IsStandardOrderAsChar3,
      case when SalesOrderType = 'TAF' then 'X'
           when SalesOrderType = 'OAF' then 'X'
        else ''
      end as IsStandardOrder2
}

The first case statement checks the value of field SalesOrderType and sets the value of field IsStandardOrder to the constant X if the sales order type has a value of TAF or OAF. In all other cases, the value is set to the initial value. In the given case, the calculation implicitly results in a field of type CHAR with length 1.

You can influence the resulting type explicitly using a wrapping cast operation. This is illustrated for the second case statement, which uses the same logic as the first cast statement. Due to the enclosing cast operation, field IsStandardOrderAsChar3 receives type CHAR with length 3.

The third case statement contains the same logic as the first case statement. From a principle perspective, the WHEN conditions of the branches of this third case statement may also implement complex rules, for example, by applying pattern comparisons with LIKE as well as by combining multiple conditions with AND and OR operators. In contrast, the WHEN conditions in the first case statement only support simple comparisons of operands.



Comments

Popular posts from this blog

Exception handing in OData

ALV reort using CL_SALV_TABLE