1 Themenübersicht
Die Anwendung „Entwicklungsobjekte“ dient der Erfassung und Ansicht von Entwicklungsobjekten verschiedenster Typen. In dieser Dokumentation wird der Typ „Extension“ beschrieben.
Allgemeine Informationen zur Anwendung „Entwicklungsobjekte“, beispielsweise die Beschreibung der anwendungsbezogenen Aktionen oder des Identifikationsbereichs, finden Sie in dieser Dokumentation „Entwicklungsobjekte“.
2 Beschreibung
Hinweis:
Alternativ zu Extensions können Business Objects vom Typ „Supplement“ verwendet werden. Supplements dienen demselben Zweck wie Extensions, ohne jedoch die Tabelle des Business Objects aus dem Standard zu erweitern. Wir empfehlen deshalb, Business Objects, für die noch keine Extensions vorhanden sind, mithilfe von Supplements zu erweitern. Dadurch können Sie den Aufwand für die Konfliktbearbeitung verringern, die nach dem Installieren von Softwareaktualisierungen erforderlich sein kann.
Extensions dienen der Erweiterung von Business Objects und Parts, die nicht im aktuellen System angelegt wurden. Zu einem Business Object oder Part können mehrere Extensions existieren. Der vollständige Entwicklungsobjektname der Extensions und der vollständige Entwicklungsobjektname des Business Objects oder Parts unterscheiden sich nur durch das Entwicklungspräfix im Namensraum. Dadurch kann eine Extension zu einem Business Object oder Part aus dem Standardentwicklungssystem in einem Branchenentwicklungssystem und in einem Kundenentwicklungssystem liegen.
Das Basisobjekt wird automatisch in die Aufgabe, in der die Extension bearbeitet wird, aufgenommen. Dabei wird eine neue Version des Basisobjekts erzeugt. Das kann zu einem Konflikt führen (siehe Dokumentation „Entwicklungsobjekte“, Kapitel „Versionierung“). Bei der Generierung wird das Basisobjekt um die in der Extension definierten Attribute, Indizes und Beziehungen erweitert.
Mit einer Extension können Stringattribute des Basisobjekts erweitert werden. Dies ist notwendig, wenn das Stringattribut im Basisobjekt zu wenig Zeichen zur Verfügung stellt und somit längere Texte nicht gespeichert werden können, aber die Logiken nicht auf die Verwendung eines neuen Attributs umgestellt werden können.
Für die Erweiterung eines Attributs gelten folgende Voraussetzungen:
Es können nur Attribute erweitertet werden deren logischer Datentyp vom Typ String ist. Es können auch mehrsprachige Attribute vergrößert werden. Es ist jedoch nicht erlaubt die Mehrsprachigkeit eines Attributs zu verändern, z. B. darf bei einem Attribut, das nicht mehrsprachig war, kein mehrsprachiger logischer Datentyp verwendet werden.
Das erweiterte Attribut in der Extension muss mit dem Präfix „*=“ beginnen und den gleichen Namen besitzen wie das Attribut im Basisobjekt. Der verwendete Logische Datentyp muss vom Typ String sein und länger sein als der verwendete Logische Datentyp im Basisobjekt. Wenn das erweiterte Attribut in der Extension gelöscht wird, wird wieder das Attribut aus dem Basisobjekt verwendet.
Hinweis:
Extensions können nicht gelöscht werden.
Die folgenden Felder stehen zur Verfügung:
| Feld | Erläuterung |
| Basisobjekt | Angabe des Basisobjekts, das durch die Extension erweitert wird. Als Basisobjekte können nur Parts oder Business Objects verwendet werden. Die Extension wird im Verwendungsnachweis des Business Objects oder des Parts aufgenommen. |
| Bezeichnung | Fachliche Beschreibung der Extension. Die Eingabe ist auf 80 Zeichen beschränkt und übersetzbar. |
Der Button „Basisobjekt“ steht unter den Karteireitern „Attribute“, „Indizes“ und „Beziehungen“ zur Verfügung und hat folgende Funktion:
| Funktion | Erläuterung |
| Basisobjekt | Anzeige aller Attribute, Indizes und Beziehungen, die im angegebenen Basisobjekt erfasst sind. |
Die Erfassung der Attribute, Indizes und Beziehungen ist analog der Erfassung der Business Objects (siehe Dokumentation „Entwicklungsobjekt: Business Object“). Die Namen müssen mit „<Entwicklungspräfix>_“ beginnen. In Extensions innerhalb von Apps folgt darauf zusätzlich der App-Name (erster Buchstabe großgeschrieben) und ein weiterer Unterstrich. Der Entwicklungspräfix und der App-Name werden klein geschrieben, jedoch wird bei Beziehungen jeweils der erste Buchstabe groß geschrieben.[1] Das entsprechende Präfix wird bei einer Neuanlage vorgegeben und darf nicht verändert werden.
Hinweis:
Mithilfe von Extensions ist es möglich, einen Index aus den Attributen des Basisobjektes anzulegen. Dabei sollte es sich um einen Secondary (non unique) Index handeln.
Beispiel einer Extension:
Das Basisobjekt com.cisag.app.….obj.Country wird in einem Partner- bzw. Kundensystem um die Angabe eine Kontinents erweitert.
xyz – Partnerkürzel
Attribute:
Country:xyz_continent Abkürzung des Kontinents (z. B.: EU)
Country:xyz_contDesc Beschreibung (z. B.: Europa)
Indizes:
Secondary non unique:
Name: Xyz_<Name>
Attribute: xyz_continent
Secondary non unique:
Name: Xyz_<Name>
Attribute: language
[1] Mit der Supportauslieferung CIS500PC-Fix02 wurden Prüfungen verschärft. Beziehungen in Extensions aus Apps, die nicht diese Namenskonvention verwenden, sollten darauf umgestellt werden. Ist eine Umstellung nicht möglich, kann die Extension weiterhin bearbeitet werden indem für das Entwicklungssystem die folgende System Property gesetzt wird:
com.cisag.sys.development.repository.extension.acceptShortNames.<Entwicklungsobjekt>=
true