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, in particular OData services and data interfaces.
For naming, all these models use the names assigned in the VDM to ensure uniformity. Names in VDM focus on business semantics and understandability. They are based on English terms that are combined according to an UpperCamelCase schema.
SAP object types form the business nucleus of VDM. Their names follow strict rules and an approval process. The names of SAP object node types use the object type name (or an abbreviation) as a prefix.
Names must not be too generic, otherwise collisions with similar but still different objects occur. Therefore, names are often prefixed with qualifiers to distinguish, for example, a SalesOrder from a PurchaseOrder. VDM deliberately doesn’t use a separation by name spaces but defines unique names for business concepts.
For country-specific or industry-specific objects and some SAP products, however, standardized prefixes are applied. For country-specific objects, the country ISO code is used, for example, TW_TaxCode, and for industries or products, a three-character abbreviation is used such as OIL for the oil and gas industry, or ACM for SAP Agricultural Contract Management.
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 abbreviations are standardized; that is, every abbreviation has exactly one expanded term. The abbreviation Qty, for example, always means Quantity. This allows you to always expand the full name from an abbreviated one.
The base name of an entity is usually derived from the related SAP object node type and describes an instance of that entity.
Field Names
Field names are defined in the same way as the names of object node types. There are, however, many more data fields with individual semantics, each of which gets a unique field name. Uniqueness allows the recognition of relations between different CDS entities from the field names. This option is particularly helpful in analytical scenarios when data from different sources are combined. The uniqueness is technically supported by enforcing different field names for fields with different data types in the ABAP Data Dictionary.
Fields not only identify instances of an entity or of an SAP object node type but also denote quantities, amounts, times or dates, texts, and so on. These different categories are distinguished by the representation term of a field name. The naming approach for different representation terms is presented in the following list.
Identifier Field
An identifier field is used for the unique identification of an instance of a certain entity or of the corresponding SAP object node type. 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.
Code
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
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.
The name of a parameter of a VDM view consists of prefix P_ and a semantical name, which is formed like a field name and often actually used as a field name, for example, parameter 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.
Note: Names Reserved for Customers and Partners
When you define your own SAP object types, object node types, or CDS entities, use your reserved namespace /<namespace>/ or the letters ZZ or YY as a prefix. When you extend an SAP standard view, also use your namespace or prefixes ZZ or YY for your own custom field names. 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.
Conclusion
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.
Comments