Core-Datentypen und aggregierte Datentypen 
Allgemeines
Die Entwicklung von Core-Datentypen und aggregierten Datentypen bei SAP folgt einem Vereinheitlichungs- und Standardisierungsprozess, der im wesentlichen die folgenden Schritte beinhaltet:
Datentyp-Entwicklung auf Basis von CCTS und XML NDR
Die Modellierung von Core-Datentypen und aggregierten Datentypen richtet sich nach UN/CEFACT Core Component Technical Specification, kurz: CCTS (siehe auch: ISO 15000-5). Diese Methodologie des UN/CEFACT-Gremiums UN/CEFACT-Gremiums definiert auf eine syntaxfreie Art semantische Bausteine (core component types), die aktuelle Anforderungen für die generische Beschreibung von Geschäftsdaten berücksichtigen. Die Umsetzung dieser Methodologie erleichtert insbesondere die Implementation von unternehmensübergreifenden Prozessen.
Die Beschreibung der modellierten Datentypen als XML Schema im ES Repository richtet sich nach den Richtlinien von und UN/CEFACT XML Naming and Design Rules for CCTS (kurz: XMLNDR), welches die eindeutige XML Schema Serialisierung der auf CCTS basierenden Datentypen beschreibt. Der Datentyp-Editor für Core-Datentypen enthält zu diesem Zweck Attribute, mit denen sich die Entwickler auf die semantischen Bausteine von CCTS beziehen (pro Core-Datentyp einen sogenannten „Representation-Term“). Im Vergleich zu frei modellierten Datentypen enthalten Core-Datentypen also zusätzlich weitere Informationen zur Semantik eines Datentyps.
HinweisDer Representation-Term am Core-Datentyp definiert noch keine betriebswirtschaftliche Semantik mit einem konkreten Bezug zu Geschäftsprozessen, aber eine Semantik zur genaueren Charakterisierung des Typs. Beispielsweise legt die Charakterisierung eines Datentyps mit dem Representation-Term
Amountunmittelbar fest, dass der Wert eines solchen Typs zusätzlich über eine Währung genauer spezifiziert werden muss. Bei der freien Modellierung eines solchen Datentyps als XSD-Typ (beispielsweisexsd:decimal) fehlt eine solche obligatorische Charakterisierung.Ende des Hinweises.
Auf Grund der zusätzlichen Attribute von Core-Datentypen wird beispielsweise die Entwicklung von Oberflächenelementen wie Eingabe- und Wertehilfen in nachgelagerten Entwicklungsschritten vereinfacht. Die Proxy-Generierung berücksichtigt die semantischen Eigenschaften von Core-Datentypen, so dass in der weiteren Implementierung darauf zugegriffen werden kann.
Kurzeinführung in die Datentyp-Entwicklung nach CCTS
Allgemeines
Im folgenden wird das bei SAP praktizierte Konzept zur Datentypentwicklung etwas genauer vorgestellt. Auf diese Weise soll der Zusammenhang zwischen den Objekttypen im ES Repository und CCTS veranschaulicht werden.
Grundlage für alle Datentypen sind die vom W3C verabschiedeten und in XML Schema enthaltenen eingebauten XSD-Typen, also beispielsweise xsd:string. Diese Datentypen legen auf rein technischer Ebene die Eigenschaften eines Elements oder eines Attributes fest, also beispielsweise welchen Wertebereich eine ganze Zahl hat. Aufbauend auf diesen W3C-Typen entwickelt SAP in aufeinander aufbauenden Stufen Datentypen, die auf jeder Stufe genau charakterisiert sind:
Core Data Type (CDT)
Wie W3C-Typen sind CDTs noch ohne Business-Semantik. Ein CDT definiert SAP-weit genau eine „primäre Komponente“ (man spricht auch von „Content-Komponente“) und optional ein oder mehrere „ergänzende Komponenten“. Über einen „Representation-Term“ (beispielsweise
Amount) wird der Charakter des CDT festgelegt.Zu mit Hilfe von CCTS modellierten CDTs legt SAP im ES Repository Datentypen mit der Klassifikation Core-Datentypan. Die Namensgebung ist dabei abhängig vom Representation-Term. Für jeden Representation-Term gibt es einen gleichnamigen Core-Datentypen
Global Data Type (GDT)
GDTs haben Business-Semantik, basieren auf CDTs und sind SAP-weit die Grundlage für anwendungsspezifische Datentypen. Im Gegensatz zu letzteren ist ihre Definition aber noch nicht auf eine konkrete Verwendung zugeschnitten. Im Gegenteil. Ein GDT ist darauf ausgerichtet, später in vielen Anwendungsszenarien wiederverwendet werden zu können. Es handelt sich also eher um 'große' Datentypen, die in einer konkreten Anwendung verfeinert werden sollen. CDTs selbst sind noch nicht anwendungsspezifisch und werden daher auch als kontextfrei bezeichnet.
Einen GDT legt SAP als Core-Datentyp oder als aggregierter Datentyp im ES Repository an, je nachdem, ob der CDT lediglich einen CDT um Business-Semantik erweitert oder ob CDTs und optional bereits vorhandene aggregierte Datentypen in einem neuen aggregierten Datentypen verwendet werden.
Kontext-Datentyp
Kontext-Datentypen leitet SAP aus GDTs für ein anwendungsspezifisches Szenario ab, beispielsweise über Projektion; sie sind also kontextspezifisch und haben ebenso wie GDTs Business-Semantik.
Wie GDTs legt SAP Kontextdatentypen als Core-Datentypen oder als aggregierte Datentypen im ES Repository ab.
Die folgende Grafik gibt einen Überblick über die verschiedenen Stufen der Datentyp-Entwicklung. Als Beispiel für einen Anwendungskontext dient ein Service-Interface für eine B2B-Kommunikation:.
CCTS-Datentypentwicklung mit Hilfe von Core-Datentypen und aggregierten Datentypen
Einige Namenskonventionen
Bei der Entwicklung von GDTs sind eine Reihe von Regeln einzuhalten, die den Rahmen dieser Dokumentation sprengen würden. Um dennoch einen Eindruck über die CCTS Methodologie zu vermitteln, beschränkt sich der folgende Abschnitt auf Regeln zur Namensgebung.
Hinweis
Eine Übersicht über die Verwendung von CCTS-Standards für die Service-Entwicklung finden Sie im Software Developer NetWork (SDN-User erforderlich) unter der Internet-Adresse 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“).
Für die Wiederverwendung von GDTs ist es essentiell, dass der Name eines GDTs die Semantik des GDTs eindeutig wiedergibt. Um dies sicherzustellen, beachtet SAP Namensregeln von CCTS, die wiederum auf dem ISO-Standard 11179-5 basieren. Nach diesem Standard besteht ein Datenelementname aus drei Teilen:
Hinweis
„Datenelement“ ist im Kontext von ISO 11179-5 ein allgemeine Bezeichnung unabhängig von einem technischen Objekttyp. Bezogen auf das Enterprise Services Repository wird ein „Datenelement“ über einen GDT realisiert, der entweder als Core-Datentyp oder als aggregierter Datentyp im ES Repository angelegt ist.
Objektklasse („object class“)
Eine Menge von Konzepten, Abstraktionen oder Dingen der realen Welt. Eine Objektklasse lässt sich klar von anderen Objektklassen abgrenzen und hat charakteristische Eigenschaften und ein Verhalten, das einheitlichen Regeln folgt. (Beispiele: Automobil, Person, Auftrag).
Eigenschaft („property“)
Eine charakteristische Eigenschaft aller Instanzen einer Objektklasse. (Beispiele: Farbe, Alter, Einkommen, Adresse).
Repräsentation („representation“)
Beschreibt, wie die Daten dargestellt werden (Datentyp und Wertebereich).
Jeder Bestandteil des Namens dient dazu, die Semantik des GDT eindeutig einzugrenzen und kann zusätzlich genauer qualifiziert werden (dieser Namensbestandteil wird dann vorangestellt). Es geht also primär um korrekte Begriffe. Man bezeichnet die drei Namensbestandteile daher auch als „object class term“, „property term“ und „representation term“. Der Representation-Term ist ein Attribut von Core-Datentypen im ES Repository.
Nach ISO 11179-5 bleibt es dem Ersteller der Namenskonvention überlassen, ob im Namen Trennzeichen verwendet werden. Um einen GDT der Objektklasse BusinessTransactionDocument, der Eigenschaft Type und der Repräsentation Code zu bezeichnen, könnte man beispielsweise folgenden Namen verwenden:
BusinessTransactionDocument. Type. Code
Während dies im Enterprise Services Repository nicht möglich ist (weil dort solche Sonderzeichen nicht erlaubt sind), sollte die GDT-Dokumentation die verschiedenen Namensanteile voneinander trennen, beispielsweise über die Darstellung in einer Tabelle.
Hinweis
Auch CDTs folgen der hier dargestellten Namenskonvention.