Globale Datentypen
Einführung
Die Modellierung von Geschäftsanwendungen orientiert sich an Business-Objekten (BOs): Ein BO definiert einen Teil der Daten, mit denen ein Geschäftsbereich arbeitet. BOs werden überlappungsfrei modelliert (weitere Informationen: Grundlagen ).
Um später innerhalb eines Geschäftsbereichs mit den Daten eines BOs arbeiten zu können, muss dessen konkrete Datenstruktur mit Hilfe von Datentypen im Enterprise Services Repository festgelegt werden. Trotz der Überlappungsfreiheit der BOs gibt es Datenstrukturen, die man immer wieder in unterschiedlichen Geschäftsbereichen benötigen wird, beispielsweise zur Beschreibung von Adressdaten (Lieferadresse, Kundenadresse, Rechnungsadresse, und so weiter). Um einen hohen Wiederverwendungsgrad von Datentypen zu erreichen, definiert SAP globale Datentypen (GDTs), deren Semantik zunächst unabhängig von deren Verwendung in einer speziellen Anwendung ist. Bezogen auf das Beispiel mit den Adressdaten heißt das, dass es einen GDT Address gibt, der sowohl für eine Lieferadresse, einen Kundenadresse oder eine Rechnungsadresse wiederverwendet werden kann.
Um Address zu verwenden und anwendungsspezifisch anzupassen (beispielsweise den Datentypnamen) kopiert ihn die Anwendung in einen anwendungsspezifischen Namensraum. Dort kann er noch anwendungsspezifisch angepasst werden, etwa wenn bestimmte Felder nicht benötigt werden.
Wenn für die gleiche Art von Daten in unterschiedlichen Komponenten eines Unternehmens oder unternehmensübergreifend unterschiedliche Datenstrukturen definiert werden, führt das zu erhöhten Kosten für die Integration der Anwendungen. Die Entwicklung von GDTs nach internationalen Standards ist daher essentiell für einen effektive und kostenreduzierende Entwicklung. Bei SAP wird dies durch einen Vereinheitlichungs- und Standardisierungsprozess (governance process) sichergestellt. Der gesamte Prozess hat im wesentlichen zwei Schritte:
-
Die Modellierung des GDT. Die Modellierung erleichtert während des Vereinheitlichungs- und Standardisierungsprozesses Diskussionen und Reviews über den Aufbau des GDT. Nach Verabschiedung eines GDT dokumentiert das Modell selbst und zusätzlich Attribute und Eigenschaften der modellierten Elemente die Verwendung des GDTs.
-
Die Spezifikation des GDT im ES Repository als Core-Datentyp beziehungsweise aggregierten Datentyp als Voraussetzung.
Weitere Informationen: Core-Datentypen und aggregierte Datentypen
SAP liefert beide Beschreibungen der GDTs als ESR-Content an Kunden aus. Kunden können eigene Datentypen im ES Repository anlegen und GDTs von SAP verwenden.
Die folgenden Abschnitte beschreiben die Konzepte für die Modellierung von GDTs, um Kunden das Verständnis der ausgelieferten GDTs zu erleichtern.
Übersicht über die Modellierung globaler Datentypen
In der Modellierungsumgebung gibt es folgende Modelltypen für die Modellierung von globalen Datentypen:
-
SAP Data Type Model
Dient der Modellierung von globalen Datentypen (GDTs). Man unterscheidet zwischen „Core-Datentypen“ , „grundlegenden GDTs“ und „aggregierten GDTs“ .
-
SAP Qualifier List
Dient der Zuweisung von „Qualifiern“ , um unterschiedliche Verwendungen des gleichen globalen Datentyps zu beschreiben.
-
SAP Code List
Dient der Zuweisung einer Liste von „Codes“ , die als sprachenunabhängige Werte für Variablen zu einem globalen Datentyp zugelassen sind.
Die folgende Grafik gibt eine Übersicht darüber, welche Modellelemente in welchen Modelltypen modelliert werden und wie die Modellelemente zueinander in Beziehung stehen.
Ein globaler Datentyp wird mit Attributen, Elementen, Qualifier-Listen und Code-Listen modelliert. Qualifier-Listen und Code-Listen verweisen auf Modelle, in denen die Qualifier beziehungsweise Codes des globalen Datentyps gespeichert sind. Für die meisten Verbindungstypen zwischen den Modellierungselementen ist eine Kardinalität angeben:
|
Ziel-Kardinalität |
Bedeutung |
|---|---|
|
1 |
Obligatorische Beziehung. Die Zielentität gibt es genau ein Mal. |
|
C |
Optionale Beziehung. Die Zielentität darf es ein Mal geben. |
|
CN |
Optionale Beziehung. Die Zielentität darf es mehrmals geben. |
|
N |
Obligatorische Beziehung. Die Zielentität darf es mehrmals geben, jedoch mindestens ein Mal. |
Die grafische Darstellung der Kardinalitäten entspricht der Darstellung im Data Modeler der ABAP Workbench.
Die folgenden Abschnitte gehen auf Core-Datentypen, die jeweiligen Spezialisierungen eines globalen Datentyps ein und welche Modellelemente jeweils relevant sind. Alle diese Typen werden mit dem folgenden Symbol dargestellt:
|
|
Abgesehen von der jeweiligen Semantik, die weiter unten im Detail beschrieben wird, lassen sich die Datentypen folgendermaßen charakterisieren:
|
Core-Datentyp
Jeder Core-Datentyp gehört zu einem Representation-Term, der aus der Core Component Technical Specification (CCTS) stammt. Core-Datentypen sind also nicht SAP-spezifisch und legen noch keine Business-Semantik fest. Bisher gibt es die folgenden Representation-Terms, zu denen jeweils ein Core-Datentyp modelliert ist: Amount, Attachment, BinaryObject, Code, Date, DateTime, Description, Duration, Graphic, Identifier, Indicator, Measure, Name, Note, Numeric, Percent, Picture, Quantity, Ratio, Sound, Text, Time, URI, Value, Video.
Für einige dieser Core-Datentypen gibt es Varianten, um unterschiedliche Formate der gleichen Daten bereits in der Modellierung unterscheiden zu können. Beispielsweise gibt es zum Core-Datentyp Duration die Variante YEAR_Duration. Solche Varianten sagen ebenso noch nichts über deren Verwendung in einem Business-Kontext aus.
Die folgende Grafik gibt ein Beispiel:
|
|
Ein Attribut ist ein benannter Wert oder eine Beziehung, die es für einige oder alle Instanzen einer Entität gibt und direkt dieser Instanz zugeordnet ist. Nur Core-Datentypen oder grundlegende GDTs können Attribute haben. Aggregierte Datentypen haben keine Elemente mit Attributen, sondern verweisen statt dessen auf bereits vorhandene Core-Datentypen oder grundlegende GDTs. |
Grundlegende GDTs
Der Name eines Core-Datentyp ist für dessen Verwendung in einem aggregierten Datentypen oft zu wenig aussagekräftig. Für SAP-Anwendungen werden daher spezifischere GDTs angelegt, die über eine Projektionsverbindung zum Ursprungs-Core-Datentyp modelliert werden (Verbindungstyp: is projection of). Solche sogenannten „grundlegenden GDTs“ haben einen eigenen Namen, eigene Qualifier- und Code-Listen, und dürfen auf Attribute des ursprünglichen Core-Datentypen verzichten, wenn diese nicht benötigt werden. Für einen grundlegenden GDT können weder zusätzliche Attribute modelliert werden noch Attribute des ursprünglichen Core-Datentypen umbenannt werden.
Die folgende Grafik gibt ein Beispiel:
Code-Listen
|
Symbol |
Verwendung |
Für |
|---|---|---|
|
|
Code-Listen beschreiben die sprachenunabhängigen gültigen „Codes“ für einen grundlegenden GDT. Auf diese Weise brauchen später Sprachabhängigkeiten einer jeweiligen Übersetzung (Englisch, Deutsch, Französisch, Japanisch und so weiter) nicht im Programmkode berücksichtigt werden. |
Grundlegende GDTs |
Die Code-Liste für CountryCode enthält die in SAP-Anwendungen üblichen Länderkürzel:
Qualifier-Listen
|
Symbol |
Verwendung |
Für |
|---|---|---|
|
|
Liste mit Qualifiern, die für einen globalen Datentyp verwendet werden können. Die Daten, die über einen globale Datentypen beschrieben werden, sind sehr allgemein gehalten, um einen hohen Wiederverwendungsgrad sicherzustellen. Dies gilt auch für den Namen des globalen Datentyps. Für unterschiedliche Verwendungen des globalen Datentyps arbeitet SAP mit unterschiedlichen Qualifiern. Jeder Qualifier besteht aus einem Prefix zur Eingrenzung der Verwendung und dem ursprünglichen Namen des globalen Datentyps. Auf diese Weise müssen nicht mehrere globale Datentypen mit unterschiedlichen Namen angelegt werden, die eigentlich die gleiche Datenstruktur haben. |
Core-Datentypen, grundlegende GDTs und aggregierte GDTs |
Für den grundlegenden GDT CountryCode gibt es eine Qualifier-Liste, die beispielsweise die Qualifier BankCountryCode und BirthCountryCode enthalten:
Aggregierte GDTs
Aggregierte GDTs sind aus Elementen aufgebaut, die auf andere aggregierte GDTs, grundlegende GDTs und Core-Datentypen verweisen. Aggregierte GDTs haben keine Attribute und keine Code-Listen. Aggregierte Datentypen sind also strukturiert.
Das Ziel der Datentyp-Modellierung ist es, möglichst viele Core-Datentypen, grundlegende GDTs und aggregierte GDTs in anderen aggregierten GDTs wiederverwenden zu können.
|
|
Element eines aggregierten GDTs. Ein Element verweist entweder auf einen grundlegende GDT, einen Core-Datentypen oder auf einen anderen aggregierten Datentyp. |
Die folgende Grafik gibt ein Beispiel: Der aggregierte GDT Address hat elf Elemente. Das Element PhysicalAddress verweist auf einen weiteren gleichnamigen aggregierten GDT (die Grafik zeigt nur einen Ausschnitt von PhysicalAddress):
