Show TOC

Adding Metadata to Data ModelLocate this document in the navigation structure

This topic demonstrates how you can expand the syntax of the CDS view to include metadata with the aim of providing some additional list reporting capabilities.

Adding the List Title

You have the option to work with a title in your result list. For this, add the @UI.headerInfo annotation to the CDS view and specify the header information in singular form for a single instance (single sales order item) and in plural form for multiple instances of sales order items.

	@UI.headerInfo: { typeName: 'Sales Order Item', typeNamePlural: 'Sales Order Items' }
	define view ZDEMO_CDS_SalesOrderItem_A as
	...
				

Preview:

List title for multiple items– header information in plural form
Figure 1: List title for multiple items – header information in plural form
Adding a Standard Search Filter

If a CDS view is annotated as @Search.searchable, the UI runtime automatically takes this is into consideration, so that no additional UI annotations are required to expose a standard search field. However, for a meaningful search, at least one field must be defined as the default search field by annotating this field as @defaultSearchElement: true. The search is then initiated solely effected by those fields that are defined as default search fields. In the listing below, the ProductCategory is defined as the default search field.

	@Search.searchable: true
	define view ZDEMO_CDS_SalesOrderItem_A as 
	...
	@Search.defaultSearchElement: true
	Item.Product              as Product,
	...
	
			

Preview:

To facilitate finding the desired data, you can provide the standard filter for the list reporting UI.
Figure 2: To facilitate finding the desired data, you can provide the standard filter for the list reporting UI.
Adding a Filter Bar for Field-Specific Selection

You can use the following UI annotations to enable specific elements for selection, for example, when providing a filter bar:

The first filter allows the end user to search for Sales Order IDs. As the second filter, the customer’s Company search field is defined. In addition, the Company field should be considered as the default search field in the standard search filter.

Note If an element is annotated as SelectionField and has a value-help, the value-help is exposed automatically to the UI. This is independent from the @Search.searchable annotation.
	
				
     @UI.selectionField.position: 10    
     key Item.SalesOrder                         as SalesOrderID, 
	...

	@UI.selectionField.position: 20
	@Search: { defaultSearchElement: true, fuzzinessThreshold: 0.7 }
	Item._SalesOrder._Customer.CompanyName  as CompanyName,
	...
	
							

Preview:

Filter bar with predefined position of search fields
Figure 3: Filter bar with predefined position of search fields
Positioning and Prioritizing UI Elements

Now you can specify which field should be displayed in the list report and at which position.

To define the order of fields in the UI, you can use the position property of dataField-like annotations. Only the positioning order is relevant, so you can use any decimal number as the value for the positioning property.

To define the priority of elements, you can use the importance property of dataField-like annotations. This information, in particular, is relevant for adaptive UIs. If an UI is displayed on a small screen, elements with low priority can automatically be hidden. To define importance, you can choose the following values:

  • #HIGH
  • #MEDIUM
  • #LOW
  • None (Default)

It is not required for the ItemPosition field to appear as a separate field in the result Sales Order list. Therefore, this field should be hidden in the list and therefore not available for the personalization settings dialog.

	...
	@UI.hidden: true
	key Item.SalesOrderItem                     as ItemPosition, 
	...			
			

In the list, the Sales Order ID field should get a specific label (Sales Order) and be displayed at the first position within the result list.

	...
	@UI.lineItem: { importance: #HIGH, label: 'Sales Order', position: 10 }
	key Item.SalesOrder 	                as SalesOrderID,
	...
		
			

The order of fields is continued with currency and both amount fields:

	...
	@UI.lineItem.position: { position: 40, importance: #HIGH }  
	Item.GrossAmountInTransacCurrency        as GrossAmount, 
   
	@UI.lineItem.position: 50
	Item.NetAmountInTransactionCurrency      as NetAmount, 
   
	@UI.lineItem.position: 60
	Item.TaxAmountInTransactionCurrency      as TaxAmount
	...
				

The customer’s Company name should also appear in the list:

	...
	@UI.lineItem.position: 20
	Item._SalesOrder._Customer.CompanyName  as CompanyName,
	...
								

The Product appears as third field in the list:

	...
	@UI.lineItem.position: 30
	Item.Product 					  as Product,
	...
						

Preview:

Positioning of fields in the result list
Figure 4: Positioning of fields in the result list
Specifying Metadata for Currency Field

It is not required for the currency field to appear as a separate field in the result list. The currency code has only to be displayed in connection with the amount data instead. This is implemented by the annotation @Semantics.currencyCode: true. The annotation @Semantics.amount.currencyCode: 'CurrencyCode' defines each amount element as a currency field.

The @DefaultAggregation: #SUM annotation is used for analytical capabilities: The annotated amount fields are specified as so-called measures, that is, fields that can be aggregated.

Note If no @DefaultAggregation annotation is assigned to an element, the engine assumes no aggregation takes place.
	...
	@Semantics.currencyCode: true
	Item.currency_code    as CurrencyCode, 
	...   
	@Semantics.amount.currencyCode: 'CurrencyCode'
     @DefaultAggregation: #SUM
	Item.GrossAmountInTransacCurrency        as GrossAmount, 
	...   
	@Semantics.amount.currencyCode: 'CurrencyCode'
	@DefaultAggregation: #SUM
	Item.NetAmountInTransactionCurrency      as NetAmount
	...
	@Semantics.amount.currencyCode: 'CurrencyCode'
	@DefaultAggregation: #SUM
     Item.TaxAmountInTransactionCurrency      as TaxAmount,
	...
						

Preview:

The currency is displayed in connection with the amount data
Figure 5: Currency is displayed in connection with the amount data

The aggregated fields display the sum - given that all amount elements are lineked to one and the same currency:

Aggregated fields
Figure 6: The aggregated fields display the sum

Apart from that, the aggregation does not work if the amount elements of a currency field are linked to various currencies:

Aggregated fields
Figure 7: The 'aggregated' fields do not display the sum
Implementing Currency Conversion for Fields to be Aggregated

In order for the amount elements of a currency field to be aggregated, an unitary currency is required. ABAP CDS provides the currency conversion function that we can use for that purpose. In our example, EURO is specified as the taget currency. The value 'EUR' is passed to the formal paramter taget_currency to be linked with the amount value of the conversion function. In the case of an error, for example when a currency does not exist, the result is set to null value.

	...
	
	@Semantics.currencyCode: true
	cast( 'EUR' as abap.cuky ) as TargetCurrency,
	
	@UI.lineItem:{ label: 'Gross Amount in EUR', position: 45 }
	@DefaultAggregation: #SUM
	
	@Semantics.amount.currencyCode: 'TargetCurrency'
	
	CURRENCY_CONVERSION(
	amount             => Item.GrossAmountInTransacCurrency,
	source_currency    => Item.TransactionCurrency,
	target_currency    => cast( 'EUR' as abap.cuky ),
     exchange_rate_date => cast( '20160101' as abap.dats ),
     error_handling     => 'SET_TO_NULL' )      as ConvertedGrossAmount 
    ...	
    
			

Preview:

Aggregated fields for target currency
Figure 8: The aggregated fields display the sum for the traget currency