CDS - Parameter

Table of contents

• General
• Usage
• Data-Preview
• Reuse
• Select
• Default
• Conclusion

Article update: Since release 7.57 (S/4 HANA 2022), DEFINE VIEW is marked as obsolete, you should use DEFINE VIEW ENTITY instead. These may differ from the examples in some places. You can find more information about the new views in this article.

---

So far, we've mostly treated CDS Views like tables when it comes to selects, joins or inclusions. In this article we want to show you another aspect of use.

 

General

Another way to control inputs and constraints in a Core Data Service is through parameters. The parameters are specified and defined directly after the definition of the CDS view. Like a field, they also receive a data type, which can either be an internal data type or a data element from the dictionary. As soon as a parameter has been defined, this also becomes a mandatory input when calling the Core Data Service.

If you want to use a parameter, you can use a colon followed by the parameter name, or you can use $parameters to access all of the view's parameters. We recommend the second variant because you get a good code completion here.

 

Usage

The parameters are created after the view is defined, but where can they be used throughout the view? The following example is intended to show the various uses:

@AbapCatalog.sqlViewName: 'ZBSCDMOPARAM'
@EndUserText.label: 'CDS with parameter'
define view ZBS_C_DmoParameter
  with parameters
    P_Date  : abap.dats,
    P_Type  : abap.char( 1 ),
    P_Field : abap.char( 10 )
  as select from ZBS_I_DmoInvoice
{
  key DocumentNumber,
      DocumentDate,
      _Partner.PartnerName,
      _Partner.Country,
      case $parameters.P_Type
        when 'A' then 'New'
        when 'B' then 'Old'
        else 'Unknown'
      end      as Status,
      $parameters.P_Field as ImportedField
}
where
  DocumentDate = $parameters.P_Date

 

In the scenario shown above, we address the following usage scenarios:

• Limiting the amount of data using the where condition
• Use in a function
• Direct use as a new field

 

Data-Preview

The data preview in Eclipse changes accordingly, the data of the view is not displayed immediately, but in the first step we receive an input mask to fill in the parameters of the view before the data is displayed:

 

After filling the parameters, the data is displayed and contains the corresponding transferred values:

 

You can use the outlines to check the entered parameters and the data type and values:

 

If you want to change the parameters again, you will find a corresponding "Parameters" button in the data preview. With one click the input window opens and you have the possibility to change the parameters. The popup will also give you hints on entering the correct format.

 

Reuse

In the next step, we want to set another view on the created view, since we want to use the view as the basis for our data. For this reason, however, we also have to supply the parameters when they are called. The new view could now look like this:

@AbapCatalog.sqlViewName: 'ZBSCDMOPARAMRE'
@EndUserText.label: 'Reuse with parameters'
define view ZBS_C_DmoParameterReuse
  with parameters
    P_Date : abap.dats
  as select from ZBS_C_DmoParameter(
                 P_Date : $parameters.P_Date,
                 P_Type : 'A',
                 P_Field : 'From Outer'
                 )
{
  key DocumentNumber,
      DocumentDate,
      Status,
      ImportedField
}

 

This time we only implement one parameter that we give to the view from outside. We supply the other two parameters with fixed values. With the select you have to supply the parameters in brackets after the view name. When calling up the data preview with the same date, we get the following view:

 

Select

In the next step we integrate such a view into a program, how must such a view be integrated and how can the parameters be supplied. The following example:

SELECT FROM ZBS_C_DmoParameter(
    p_date = '20210422',
    p_type = 'C',
    p_field = 'Program'
  )
  FIELDS *
  INTO table@DATA(lt_parameter).

 

The parameters must be specified in brackets after the view name, and the individual parameters are separated from one another with commas. The rest of the access is standard ABAP SQL, the parameters must be specified, the compiler will also point this out to you.

 

Default

We might want to preassign certain parameters with system fields, such as a date, in order to get current data. To do this, we can use an annotation to infer the data from the current environment. In this case we access @Environment.systemfield, so we adjust our parameter view once:

@AbapCatalog.sqlViewName: 'ZBSCDMOPARAM'
@EndUserText.label: 'CDS with parameter'
define view ZBS_C_DmoParameter
  with parameters
    @Environment.systemField: #SYSTEM_DATE
    P_Date  : abap.dats,
    P_Type  : abap.char( 1 ),
    P_Field : abap.char( 10 )
  as select from ZBS_I_DmoInvoice
{
  key DocumentNumber,
      DocumentDate,
      _Partner.PartnerName,
      _Partner.Country,
      case $parameters.P_Type
        when 'A' then 'New'
        when 'B' then 'Old'
        else 'Unknown'
      end                 as Status,
      $parameters.P_Field as ImportedField
}
where
  DocumentDate = $parameters.P_Date

 

You can use the following system variables and pre-assign fields with them:

 

Hint: If fields are pre-assigned default values, they are no longer mandatory and can be left out when entering data.

 

Conclusion

Parameters are mainly used in the analytics and Fiori environment, but can also be used cleverly for selects. You should now be familiar with how parameters behave and where you can use them.