Show TOC

Background documentationCore Data Types and Aggregated Data Types Locate this document in the navigation structure

 

General

The development of core data types and aggregated data types at SAP follows a governance process that involves the following main steps:

This graphic is explained in the accompanying text.

Data Type Development on the Basis of CCTS and XML NDR

  1. Core data types and aggregated data types are modeled according to UN/CEFACT Core Component Technical Specification, or CCTS for short (ISO 15000-5). The UN/CEFACT committee methodology defines semantic modules without syntax (core component types) that take into account the latest requirements for describing business data generically. Applying this methodology simplifies the implementation of cross-company processes, in particular.

  2. The description of the modelled data types as XML schema in the ES Repository complies with the guidelines of UN/CEFACT XML Naming and Design Rules for CCTS (XMLNDR), which describes the unique XML schema serialization of data types based on CCTS. For this purpose, the data type editor for core data types contains attributes that enable developers to reference the semantic modules of CCTS (one “representation term” for each core data type). Like freestyle data types, core data types also contain additional information about the semantics of a particular data type.

    Note Note

    The representation term for the core data type does not yet define any business semantics with a specific reference to business processes, but rather semantics for the more precise characterization of the type. For example, the characterization of a data type with the Amount representation term defines that the value of such a type must also be specified further by means of a currency. If you model such a data type freely as an XSD type (for example xsd:decimal), this obligatory characterization is missing.

    End of the note.

Due to the additional attributes of core data types, the development of user-interface elements such as input and value helps is simplified in follow-on development steps. Proxy generation includes the semantic properties of core data types so that you can access this information in later implementation steps.

Short Introduction to Data Type Development According to CCTS
General

The following explains how data types are developed at SAP in more detail. This will help to illustrate how the object types in the ES Repository and CCTS are related.

The basis for all data types are the built-in XSD types contained in XML schema and approved by W3C, for example xsd:string. These data types define the properties of an element or attribute on a purely technical level, for example what value range a whole number has. Using these W3C types as a basis, SAP develops data types in levels that are each based on the level before, and the data types are characterized exactly on each level:

  • Core Data Type (CDT)

    W3C types are CDTs that do not yet have any business semantics. A CDT defines - SAP-wide - exactly one “primary component” (also known as a “content component”) and optionally more or more “enhancing components”. The character of the CDT is defined by a “representation term” (for example, Amount).

    SAP creates data types with the classification core data type in the ES Repository for CDTs modeled using CCTS. The naming depends on the representation term in this case. A core data type of the same name exists for each representation term.

  • Global Data Type (GDT)

    GDTs have business semantics, are based on CDTs, and are the basis for application-specific data types SAP-wide. Unlike the latter, a GDT's definition has not been tailored for use in a particular way. On the contrary. A GDT is designed so that it can be reused in many different scenarios. It should therefore rather be seen as a 'big' data type that can be refined for use in a specific scenario. CDTs themselves are not yet application-specific and are therefore referred to as context-free.

    SAP creates a GDT as either a core data type or aggregated data type in the ES Repository, depending on whether the CDT merely enhances a CDT with business semantics, or whether CDTs and possibly existing aggregated data types are used in a new aggregated data type.

  • Context Data Type

    SAP derives context data types from GDTs for an application-specific scenario, for example using a projection; they are context-specific and have business semantics like GDTs.

    Like GDTs, SAP saves context data types as core data types or as aggregated data types in the ES Repository.

The following figure provides an overview of the different levels of the data type development. A service interface for B2B communication is an example of where they could be applied.

This graphic is explained in the accompanying text.

CCTS Data Type Development Using Core Data Types and Aggregated Data Types

Naming Conventions

When developing GDTs there are many different rules that you must adhere to and it is beyond the scope of this documentation to explain them all here. To nevertheless give you an impression of the CCTS methodology, the follow section covers rules for naming only.

Note Note

An overview of using CCTS standards for service development is available on Software Developer Network (SDN user required) at https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30d35ece-5c67-2910-64aa-cb331726ee1c (“How to Solve the Business Standards Dilemma # The CCTS Standards Stack”).

End of the note.

To ensure that GDTs can be reused, the name of the GDT must indicate what the semantics of the GDT are. To ensure this is the case, SAP complies with the naming conventions for CCTS, which are in turn based on ISO-Standard 11179-5. According to this standard, a data element name comprises three parts:

Note Note

In the context of ISO 11179-5, a “data element” is a general name that is not dependent on a technical object type. With regard to the Enterprise Services Repository, a “data element” is realized by means of a GDT that is created in the ES Repository either as a core data type or as an aggregated data type.

End of the note.

  • Object class

    A set of concepts, abstractions, or things in the real world. An object class is easy to delimit from other object classes, has characteristic properties, and behaves according to uniform rules. (examples: car, person, sales order).

  • PropertyProperty

    A characteristic property of all instances of an object class. (examples: color, age, income, address).

  • Representation

    Describes how the data is represented (data type and value range).

Each part of the name serves to identify the semantics of the GDT uniquely, and can also be qualified more precisely (this part is then put at the front of the name). It is therefore primarily a question of correct terms. For this reason, the three parts of the name are also known as “object class term”, “property term” and “representation term”. The representation term is an attribute of core data types in the ES Repository.

According to ISO 11179-5, it is up to the creator of the naming convention to decide whether to use separators in the name. A GDT in the object class BusinessTransactionDocument, property Type, and representation Code could be given following name:

BusinessTransactionDocument. Type. Code

Although this is not possible in the Enterprise Services Repository (because special characters are not permitted), the GDT documentation should divide up the different parts of the name, for example by using a table.

Note Note

CDT use the same naming convention.

End of the note.