The virtual data model (VDM) forms the basis for all specific data models of application data in an SAP S/4HANA system: analytical models, transactional models, and API models.
All these models use the names assigned in the VDM to ensure uniformity. The understandability of names in VDM is essential for the understandability of names in other development artifacts.
For the names that are relevant in modeling and programming, English terms are used. Usually, an additional description is translated to several other languages. For the naming in VDM, the field names play a major role: the view, association, and parameter names are based on field names. We’ll walk through each in the following sections.
Field names are assigned globally in the SAP S/4HANA system; there is no separation by namespaces. Names in VDM should be close to business reality, and names in the real world have no namespaces as well. An entity (or “thing”) should be present in the model only once. Otherwise, redundancies emerge, and the consistency of the overall model is no longer guaranteed.
However, if name collisions happen when related business concepts are implemented separately in two application areas, then different names are needed. The standard approach to define these is to prefix the base name with additional terms, called qualifiers, which distinguish the names according to their specific semantics.
The most important rule for naming is to express the business semantics. The following usual naming rules apply as well:
- Precise and unambiguous
- Not too generic, but as short as possible
- Name the same things with the same name
- Name different things differently
To improve readability of names, camel case notation is used. Core data services (CDS) technology and OData support the use of uppercase and lowercase. For the runtime execution in ABAP, however, the case isn’t significant: Order, order, and ORDER are syntactically the same. Within ABAP, the names of CDS views and fields are converted to uppercase.
Field names in CDS are limited to a length of 30 characters. This enforces the use of abbreviations for proper naming of complex matters. The used abbreviations are standardized; that is, every abbreviation has exactly one expanded term. The abbreviation Qty, for example, always means Quantity.
The naming of fields considers the type of the data field or, more precisely, its representation term. The naming approach for different representation terms is presented in the following list.
An identifier field is used for the unique identification of an instance of a certain entity. A sales order number, for example, identifies a particular sales order. In this case, you choose the denomination for an instance of the entity, for example, SalesOrder. You can optionally use suffix ID in the name to emphasize the representation term; however, the suffix is omitted usually.
Universally Unique Identifier (UUID)
If a universally unique identifier (UUID) exists beside the common ID, you should use a field name with suffix UUID, for example, BusinessPartner-UUID. Other alternative identifiers can get a suffix as well, for example, WBSElementInternalID or PersonExternalID. Sometimes, the same entity is referenced by multiple fields of a view, perhaps in different roles. If so, additional qualifiers are used, for example, SenderCostCenter and ReceiverCostCenter.
A code is a value in a fixed value list that is only changed by altering the system configuration, for example, a code for languages (Language) or currencies (Currency). For these field names, suffix Code can be omitted as well. Semantic subtleties are expressed by qualifiers, for example, CompanyCurrency or CountryISOCode.
Indicators represent Boolean values. An indicator’s name is a statement that corresponds to the logical value of the field, for example, OrderIs-Released or NotificationHasLongText.
Amount and Quantity Field
The name of an amount field can contain a reference to its currency, for example, NetAmountInDisplayCurrency. As the relation to the currency is also expressed by annotations, this information can be omitted, for example, TaxAmount. Quantity fields are similar, for example, OrderQuantity or MinDeliveryQtyInBaseUnit.
Counters and Durations
For counters that specify the number of things, prefix NumberOf is used, for example, NumberOfRecipients. Durations can have a related unit field, for example, ForecastedDuration and ForecastedDurationUnit, but it’s not mandatory. In such cases, the unit should be included in the field name, for example, TripDurationInDays.
Points in Time
For points in time, DateTime is part of the field name, for example, CreationDateTime. For dates, Date is appended, and for times, Time is appended.
Rates and Ratios
In field names for rates or ratios, Percentage and Fraction are forbidden. The following combinations can be used instead: ConditionRateInPercent, UtilizationPercent, ExchangeRate, and ProbabilityRatio.
Note: Customer Namespace for Field Names
Always use your own namespace, for example, prefixes ZZ or YY, for your own custom field names when extending SAP standard views. Otherwise, name clashes are possible with names of new fields that SAP introduces in a new software version. These clashes can lead to syntax errors and issues during the upgrade to a new SAP software version.
Names of VDM Views
Three names can be assigned to a CDS view. The proper view name is the CDS view name that is specified after statement define view. This is the relevant view name, which supports camel case notation. The name of the data definition, also called the data definition language source (DDLS) name, which you must specify first when creating a CDS view, is always in uppercase. In VDM, the CDS view name is used as the data definition name as well, being transformed to uppercase. The choice of the SQL view name by annotation @AbapCatalog.sqlViewName is up to the view developer. This name is mostly hidden but plays an important role in analytic models.
CDS view names have prefixes and suffixes according to their VDM view type, as shown in the table below.
Some further suffixes are common as well:
- <ViewName>Text: A view with language-dependent texts, for example, I_TaxCodeText
- <ViewName>Cube: An analytic cube view, for example, I_SalesOrderItemCube
- <ViewName>Query: An analytic query (abbreviated Qry), for example, C_GoodsMovementQuery
- <ViewName>ValueHelp: As value help (abbreviated VH), for example, C_CustomerMaterialValueHelp.
- <ViewName>ObjPg: An overview page of an object in SAP Fiori, for example, C_InboundDeliveryObjPg.
The core of the VDM view name, which is supplemented by prefixes and suffixes, consists of a semantic designator for the result of the view or, more precisely, the business name of a result row of the view. Therefore, the view name is a term in singular; plural is used in exceptional cases only. Often such a result row has an identifier or code as a key field. Then you can directly take its field name as the core of the view name.
Some VDM views are specific for individual countries, industries, or SAP products. Their semantic name could lead to name collisions with entities of the SAP S/4HANA core product. In such cases, the specific view can get a name prefix as follows:
- For countries, the ISO country code (two letters), for example, I_BR_BusinessPlace or I_TW_TaxCode
- For industries with an industry code (three letters), for example, I_PRA_TaxRevenueProcessCode
- For SAP products with a product code (three letters), for example, I_PPM_Tasktype
Combinations of these prefixes are possible. In rare cases, these prefixes can also be used for field names. Currently, the SAP products shown in the following table use a specific prefix.
Note: Namespace for Custom Views
Use your reserved namespace /<namespace>/ or the letters Z or Y as a prefix for your own custom CDS views.
The name of a parameter of a VDM view consists of the prefix P and a semantical name, which is formed like a field name and often actually used as a field name, for example, P_DisplayCurrency.
An association of a VDM view points to another VDM view. Usually, the first letter of the target view is omitted, and the remainder is used as the association name. Association _Customer, for example, often points to view I_Customer. Alternatively, you can abbreviate the association name if it remains understandable in its context. The association from view I_SalesOrder to I_SalesOrderItem is called _Item, for example. The association from an entity view to its text view is usually called _Text. If there are multiple associations with the same target view, qualifiers are added to the association names, for example, _SenderCostCenter and _ReceiverCostCenter.
It’s important to know how to name things consistently and clearly to ensure proper functioning of your system both now and in the future when updates are made. This blog post helped define the different naming types a VDM can have.
Editor’s note: This post has been adapted from a section of the book Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik.