CDS - Typed Literals

Table of contents

• Introduction
• Preparation
• CAST
• Types
• Spaces
• Complete Example
• Conclusion

In this article, we'll discuss the typing of literals and how they help you develop in a type-appropriate way.

 

Introduction

When working with Core Data Service, not all information comes directly from the database. There are various ways to create new information and columns in the model. However, you should always keep in mind the performance rule that such fields are very high up in the hierarchy, especially when it comes to accessing large amounts of data. In this article, we'll look at the typing of literals in a Core Data Service. Some time ago we wrote about various literals in ABAP and how you can use them correctly.

 

Preparation

In the following examples, we use a new Core Data Service based on the interface view ZBS_I_DmoMaterial. We only need the view to perform the selection later and create the additional fields. For this, the key as a real field in the view is sufficient.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Typed Literals'
define view entity ZBS_C_DMOTypedLiterals
  as select from ZBS_I_DmoMaterial
{
  key MaterialNumber
}

 

CAST

Let's look at a simple example of how we've created such fields with the correct types in the past. In most cases, you'll find code snippets using casts to create an element and convert it to the correct data type. The literal is cast to the target type and made available in the view via an alias.

cast( 'USD' as abap.cuky( 5 ) ) as USDCast,

 

If we now use a typed literal, we first specify the base type and then, without spaces, the literal directly in the source code. In this case, too, we must specify an alias to make the element available in the view.

abap.cuky'USD'                  as USDLiteral,

 

The notation is somewhat shorter and clearer. Unfortunately, we don't see much of the type in the Data Preview, so we'll do a SELECT in an executable class and look at the two data types in the debugger. Basically, the two types are identical in content and type.

 

Types

Which types can we actually use for typing the literals? Basically, all built-in ABAP data types are possible; you can usually also use these in tables or custom entities, and they are accessible via "abap." retrievable. You will also find specific types such as:

• Client
• Language

 

In the documentation below, you will also find types that are excluded. These are mostly more complex types that cannot be set via a simple literal. Therefore, data elements or Simple Types from CDS are currently not possible.

 

Spaces

If you look through the documentation, there are some special considerations you should keep in mind when using strings. In this example, we define a string with a trailing space and define a short string and a normal string. The Short String should normally behave like a string, but has a maximum length to accommodate short texts.

abap.sstring'My String    '     as ShortString,
abap.string'My String    '      as NormalString

 

In this case, we would actually assume that the trailing spaces would remain and we would get the same string. Let's take a look at the debugger and the typing:

 

Here's where the special behavior comes into play, and the trailing spaces are truncated in the short string. The content is exactly 9 characters long. With a normal string, all characters are retained, and we get the 13 characters we defined.

 

Complete Example

You can find the view and the ABAP code from today's article in our GitHub repository for all Core Data examples. The specific changes are in this Commit, as the objects may change in the future.

 

Conclusion

You need a specific type of literal, then you can use the more concise variant of the typed literal. This keeps the declaration simple and clear, and you can use the literal directly in various places within the definition.

 

Source:
SAP Help - CDS View Entity, Typed Literals