1              Themenübersicht

Betriebswirtschaftliche Entitys werden in Semiramis in komplexen Containern verwaltet. Diese Container erlauben den lesenden und schreibenden Zugriff auf alle Daten des Entitys. Der schreibende Zugriff umfasst auch komplexe Operationen, wie beispielsweise das Hinzufügen oder Löschen von neuen Dependents. Diese Container werden im folgenden APP-Entity genannt.

Die APP-Entitys haben eine breite Schnittstelle mit einem hohen Funktionsumfang. Es gibt nur wenige Zugriffbeschränkungen, um bestimmte Funktionen oder Daten vor dem Verwender des APP-Entitys zu schützen.

Die Hooks benötigen Datencontainer für die Kommunikation mit der Hook-Implementierung. Diese Datencontainer sollen nur eine eingeschränkte Schnittstelle besitzen:

• Häufig ist nur der Lesezugriff erlaubt.
• Berechnete Attribute stehen häufig erst beim Speichern zur Verfügung.

Die APP-Entitys stellen den transienten Zustand von den Anwendungen dar, die durch die Hooks erweitert werden sollen. Die APP-Entitys eignen sich für die Hooks aufgrund der breiten Schnittstelle nicht.

Die Objektsichten stellen eine „Sicht“ auf das APP-Entity dar. Die Objektsichten sind ein Wrapper um einen Teil eines APP-Entitys. Eine Objektsicht speichert selbst keine Daten. Im Allgemeinen wird jeder Lese- und Schreibzugriff auf eine Objektsicht vom zugehörigen Business-Objekt beantwortet, sofern keine Sonderbehandlung in der Beschreibung der Objektsicht definiert ist.

2              Zielgruppe

• Entwickler

3              Beschreibung

Jede Objektsicht basiert auf einem Business Object. Eine Objektsicht kann Attribute und Beziehungen aus diesem Business-Objekt sowie virtuelle Attribute und Beziehungen enthalten.

Zur Laufzeit besteht eine Objektsicht aus den folgenden Komponenten:

• DataView

Schnittstelle für den Lesezugriff auf die Daten der Objektsicht.

• DataAccess

Der DataAccess erweitert die Schnittstelle des DataView, um den Schreibzugriff auf die Daten der Objektsicht. Beim DataAccess wird zwischen dem eingeschränkten Zugriff und dem uneingeschränkten Zugriff unterschieden. Der eingeschränkte Zugriff erlaubt den Zugriff nur auf die Eigenschaften der Objektsicht die durch Business Object-Erweiterungen oder Objektsichterweiterungen im selben Entwicklungssystem hinzugefügt worden sind.

• DataObject

Das DataObject stellt den Zugriff auf ein Business-Objekt des APP-Entitys für den DataView und den DataAccess bereit.

Der DataView und der DataAccess bilden die Schnittstelle für den Zugriff auf ein Business-Objekt in einem APP-Entity. Die Zugriffe auf die Attribute und Beziehungen werden soweit möglich vom Business-Objekt beantwortet. Nur falls eine vom Business-Objekt abweichende Logik erforderlich ist, muss diese Logik im DataObject kodiert werden.

Die Objektsicht darf nur in demselben Entwicklungssystem wie das zugeordnete Business-Objekt erzeugt werden.

Eine Objektsicht kann in nachgelagerten Entwicklungssystemen oder Apps-Entwicklungssystemen mit einer Objektsichterweiterung um neue Attribute und Beziehungen ergänzt werden.

3.1        Objektsichten

Die Beschreibung einer Objektsicht wird als XML-Entwicklungsobjekt erfasst. Der Aufbau der XML-Datei wird anhand eines Beispiels eingeführt. Eine tabellarische Beschreibung, der in diesem Beispiel verwendeten Elemente, finden Sie in den folgenden Abschnitten.

Beispiel:

Das XML zu der Objektsicht com.cisag.app.general.item.model.Item für den Artikel könnte den folgenden Inhalt haben:

<?xml version=”1.0″ encoding=”utf-8″?>

<dataview xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xsi:noNamespaceSchemaLocation=”DataView.xsd”>

<object>

com.cisag.app.general.obj.Item

</object>

<implementation>

com.cisag.app.general.item.log.ItemObject

</implementation>

<javadoc>

Objektsicht für das Business-Objekt Artikel

in der Anwendung Artikel. Die Objektsicht ist

nur für die Basissicht des Artikels änderbar. In

den frameworkspezifischen Sichten wird nur der

nicht änderbare DataView verwendet.

</javadoc>

<viewinterface>

com.cisag.app.general.model.MasterDataView

</viewinterface>

<viewinterfacesuffix>

com.cisag.app.general.model.ItemView

</viewinterfacesuffix>

 

<!– Das Attribut „guid“ darf nicht verändert werden und –>

<!– soll ein abweichendes Label sowie ein Java-Doc haben. –>

<attribute property=“READ_ONLY“>

<name>guid</name>

<datatype>

com.cisag.app.general.model.ItemViewGuid

</datatype>

<javadoc>

Das Attribut „guid“ ist Teil der Primärschlüssel von

Item. Diese Guid ist Teil des Primärschlüssels der

frameworkspezifischen Daten des Artikels.

</javadoc>

</attribute>

 

<!– Die Beziehung ProductionItems soll nicht angezeigt –>

<!– werden. –>

<relation property=“EXCLUDED“>

<name>ProductionItems</name>

</relation>

 

<!– Die Beziehung DefaultVariantItem soll auf eine –>

<!– nur lesbare Objektsicht des Artikels zeigen. –>

<relation property=“READ_ONLY“>

<name>DefaultVariantItem</name>

<targetview>

com.cisag.app.general.model.Item

</targetview>

</relation>

 

<!– Virtuelle 1:n Beziehung für die alternativen –>

<!– Artikel. ->

<virtualrelation property=“READ_ONLY“ cardinality=“ONE_MANY“>

<name>AlternativeItems</name>

<targetview>

com.cisag.app.general.model.AlternativeItem

</targetview>

</virtualrelation>

</dataview>

3.1.1    Definition einer Objektsicht

Eine Objektsicht wird durch genau ein Element „dataview“ beschrieben. Das Element enthält weitere Elemente. Diese sind in die folgenden Gruppen aufgeteilt:

1. Daten zu der Objektsicht und deren Interfaces
2. Daten zu den Attributen der Objektsicht
3. Daten zu den Beziehungen der Objektsicht

Die folgende Tabelle erläutert alle Elemente, die die Daten der Objektsicht und deren Interfaces beschreiben:

Element	Erläuterung
object	Vollständiger Name des Business Objects mit Namensraum. Jede Objektsicht gehört zu genau einem Business Object. Dieses Element muss angegeben werden.
implementation	Vollständiger Klassenname des Data-Objects für die Objektsicht mit Namensraum. Die angegebene Klasse muss von der Klasse DataObject abgeleitet sein. Dieses Element muss angegeben werden.
javadoc	Java-Doc für den Klassenkommentar des zu der Objektsicht gehörigen DataView. Das Java-Doc muss die Aufgaben und ggf. auch die Einschränkungen einer Objektsicht beschreiben.
viewinterface	Name eines Java-Interfaces, dass der DataView erweitert. Über das optionale View-Interface kann der DataView um zusätzliche Methoden erweitert werden oder der Zugriff auf Attribute und Beziehungen unabhängig vom DataView erfolgen. Weitere Informationen enthält der Abschnitt „View-/Access-Interfaces“.
viewinterfacesuffix	Wenn das View-Interface Generic ist, so kann ein Suffix angegeben werden, um die Generic-Parameter des Interfaces auszuprägen. Sie müssen die äußeren Zeichen „<“ und „>“nicht angeben. Falls Sie im Generic-Parameter „<“ und „>“ benötigen, müssen Sie diese wie in XML üblich kodieren. Geben Sie also statt „<A,B>“ nur „A,B“ an bzw. statt „<C<D>>“ nur „C&lt;D&gt;“ an.
accessinterface	Name eine Java-Interfaces, dass der DataAccess erweitert. Das optionale Access-Interface wird analog zum View-Interface behandelt. Weitere Informationen enthält der Abschnitt „View-/Access-Interfaces“.
accessinterfacesuffix	Wenn das Access-Interface Generic ist, so kann ein Suffix angegeben werden, um die Generic-Parameter des Interfaces auszuprägen. Sie müssen die äußeren Zeichen „<“ und „>“nicht angeben. Falls Sie im Generic-Parameter „<“ und „>“ benötigen, müssen Sie diese wie in XML üblich kodieren. Geben Sie also statt „<A,B>“ nur „A,B“ an bzw. statt „<C<D>>“ nur „C&lt;D&gt;“ an.

3.1.2    Definition von Attributen

Objektsichten enthalten eine Auswahl der Attribute des zugrundeliegenden Business Objects sowie optional auch virtuelle, d.h. berechnete, Attribute:

• Mit dem Element „attribute“ können Sie die Eigenschaften eines Business-Object-Attributs verändern. Sie können beispielsweise den Lese- oder Schreibzugriff auf Business-Object-Attribute beschränken.
• Mit dem Element „virtualattribute“ können Sie ein berechnetes Attribut anlegen. Virtuelle Attribute müssen im DataObject implementiert werden. Virtuelle Attribute unterstützen keine Arrays und keine komplexen Attribute (Parts) außer Special-Parts z.B. für Hauswährungen.

Weitere Informationen zum Implementieren von virtuellen Attributen finden Sie im Abschnitt „Virtuelle Attribute im DataObject“.

Für jedes lesbare Attribut wird ein Getter im DataView erzeugt und für jedes schreibbare Attribut wird ein Setter im DataAccess erzeugt.

Die folgende Tabelle erläutert die in Business-Object-Attributen und virtuellen Attributen erlaubten Elemente und Attribute:

Element	Erläuterung
name	Attributpfad der Spalte. Bei einem Business-Object-Attribut muss eine Spalte mit dem angebenden Attributpfad existieren. Der Attributpfad ist komplex, wenn dieser Punkte „.“ oder Klammern „[]“ enthält. Zu komplexen Attributpfaden werden keine Methoden im DataView oder DataAccess erzeugt. Der Name eines virtuellen Attributs muss das Attribut eindeutig identifizieren. So dürfen zum Beispiel nicht mehrere Business-Object-Attribute mit dem gleichen Namen existieren. Virtuelle Attribute dürfen nicht komplex sein. Bei Objektsichterweiterungen muss der Name mit dem Entwicklungspräfix der Objektsichterweiterung beginnend mit einem Kleinbuchstaben und einem Unterstrich „_“ beginnen. Bei Objektsichte-Erweiterungen innerhalb von Apps folgt darauf zusätzlich der kleingeschriebene App-Name und ein weiterer Unterstrich.[1]
property	Das Attribut „property“ wird am Element „attribute“ oder „virtualattribute“ angegeben. Es steuert die Sichtbarkeit und den Zugriff auf das Business-Objekt oder virtuelle Attribut: ·         EXCLUDED Das Attribut ist zwar im Business-Objekt enthalten, soll aber in der Objektsicht weder les- noch schreibbar sein. Bei virtuellen Attributen ist diese Option nicht sinnvoll und daher nicht erlaubt. In Objektsichterweiterungen dürfen keine Attribute ausgeblendet werden. ·         READ_ONLY Das Attribut darf nur gelesen werden. Es existiert nur ein Getter aber kein Setter. In Objektsichterweiterungen dürfen nur virtuelle Attribute „nur lesbar“ sein. Attribute aus einer Business-Objekt Erweiterung sind immer veränderbar. ·         MUTABLE Das Attribut darf gelesen und verändert werden. Es existieren ein Getter und ein Setter. Bei Business-Object-Attributen ist das Attribut „property“ optional. Der Vorschlagswert ist in diesem Fall „MUTABLE“ (bis auf bestimmte Attribute, s.u.). Bei virtuellen Attributen muss das Attribut „property“ angegeben werden.
datatype	Vollständiger Name eines logischen Datentyps. Falls dem Datentyp eine Data-Description zugeordnet ist, so wird diese Data-Description verwendet, falls das Attribut über den DataView angezeigt wird. Bei Business-Object-Attributen ist der Datentyp optional und dieser ersetzt den beim Attribut hinterlegten Datentyp. Der primitive Datentyp muss in diesem Fall dem primitiven Datentyp des Attributs entsprechen. Bei virtuellen Attributen muss ein Datentyp angegeben werden, um das virtuelle Attribut vollständig zu definieren.
javadoc	Optionales Java-Doc für die Beschreibung des Attributs. Das Java-Doc wird sowohl an den Getter im DataView als auch an den Setter im DataAccess geschrieben. Komplexe Attribute haben kein Java-Doc.
targetObject	Vollständiger Name des Zielobjekts. Wenn für ein Attribut ein Zielobjekt angegeben wird, dann enthält dieses Attribut einen Fremdschlüssel des Zielobjekts. Der Primärschlüssel des Zielobjekts darf nur aus einem Attribut bestehen. Die Datentypen der beiden Attribute müssen identisch sein. Das Zielobjekt wird beispielweise für die Wahl eines passenden Entity-Fields verwendet.

Nicht-virtuelle Attribute sind als Vorschlagswert schreibbar, bis auf die im Folgenden beschriebenen Ausnahmen.

Folgende Attribute sind nur lesbar (READ_ONLY):

• Attribute des Primärschlüssels
• Attribute des Business-Keys
• validFrom
• validUntil
• updateInfo
• _timeZoneGuid
• _organization
• _currencyCombo
• _conversionDate
• _clob

Folgendes Attribut ist als Vorgabe ausgeblendet (EXCLUDED):

• managingSystem

3.1.3    Definition von Beziehungen

Objektsichten enthalten eine Auswahl der Beziehungen des zugrundeliegenden Business-Objekts sowie optional auch virtuelle, d.h. berechnete, Beziehungen:

• Mit dem Element „relation“ können Sie die Eigenschaften einer Business Object-Beziehung verändern. Sie können beispielsweise statt eines Buisness-Objects eine passende Objektsicht als Beziehungsziel verwenden.
• Mit dem Element „virtualrelation“ können Sie eine berechnete Beziehung anlegen.

Das Ziel einer Beziehung kann entweder ein Business Object, oder aber eine Objektsicht sein. Um die Attribute des Zielobjekts der Beziehung in der anpassbaren Oberfläche als Felder verwenden zu können, muss das Beziehungsziel eine Objektsicht sein.

Zum Abfragen einer Beziehung mit dem Namen <X> wird die Methode retrieve<X>() am DataView, DataAccess oder DataAccess.Full erzeugt. Wenn das Beziehungsziel nicht veränderbar ist, wird die Methode nur am DataView erzeugt. Wenn das Beziehungsziel eine Objektsicht ist, so gibt die Methode jeweils die Zugriffseinschränkung des Quellobjekts zurück. Das bedeutet die Methode gibt am DataView einen DataView, am DataAccess einen DataAccess und DataAccess.Full einen DataAccess.Full zurück.

Weitere Informationen zum Implementieren von Beziehungen finden Sie im Abschnitt „Beziehungen im DataObject“.

Die folgende Tabelle erläutert die in Business-Object-Beziehungen und virtuellen Beziehungen erlaubten Elemente und Attribute:

Element	Erläuterung
name	Eindeutiger Name der Beziehung. Bei Business Object-Beziehungen muss eine Beziehung mit diesem Namen existieren. Virtuelle Beziehungen können die Eigenschaften von Business Object-Beziehungen überschreiben. Bei Objektsichterweiterungen muss der Name mit dem Entwicklungspräfix der Objektsichterweiterung beginnend mit einem Großbuchstaben und einem Unterstrich „_“ beginnen. Bei Objektsichte-Erweiterungen innerhalb von Apps folgt darauf zusätzlich der App-Name (erster Buchstabe großgeschrieben) und ein weiterer Unterstrich. Siehe auch Erläuterungen zu Attributnamen.
property	Das Attribut „property“ wird am Element „relation“ oder „virtualrelation“ angegeben. Es steuert die Sichtbarkeit der Beziehung sowie den Zugriff auf das Beziehungsziel: ·         EXCLUDED Die Beziehung ist zwar im Business-Objekt enthalten, soll aber in der Objektsicht nicht sichtbar sein. Virtuelle Beziehungen dürfen nicht ausgeblendet werden. ·         PERSISTENT Die Beziehung ist im Business-Objekt enthalten und die Beziehung soll über den Persistenzdienst ausgewertet werden. Es gibt keine retrieve-Methode für diese Beziehung im DataObject. Virtuelle Beziehungen können nicht über den Persistenzdienst berechnet werden. Falls das Ziel der Beziehung eine Objektsicht ist, muss das DataObject der Objektsicht einen Konstruktor haben, der das Business-Objekt als einzigen Parameter hat. Weitere Informationen finden Sie im Abschnitt „Property PERISTENT“. ·         READ_ONLY Das Ziel der Beziehung wird über das DataObject berechnet. Das Ziel der Beziehung ist ein Business-Objekt oder eine Objektsicht. Im DataAccess der Objektsicht gibt es keine Methode retrieve…Access, somit ist das Ziel der Beziehung nicht veränderbar. Weitere Informationen finden Sie im Abschnitt „Property READ_ONLY“. ·         MUTABLE Das Ziel der Beziehung ist veränderbar und wird über das DataObject berechnet. Das Ziel der Beziehung muss eine Objektsicht sein. Weitere Informationen finden Sie im Abschnitt „Property MUTABLE“.
cardinality	Das Attribut „cardinality“ wird am Element „virtualrelation“ angegeben. Es gibt die Kardinalität einer virtuellen Beziehung an: ·         ONE_ONE Die Beziehung zeigt auf maximal ein Zielobjekt. ·         ONE_MANY Die Beziehung zeigt auf eine beliebige Anzahl von Zielobjekten. Weitere Informationen zu 0…n Beziehungen finden Sie im Abschnitt „OneMany bei 0…n Beziehungen“. Falls Sie eine Business-Object-Beziehung überschrieben haben, dürfen Sie die Kardinalität nicht ändern.
targetobject	Wenn das Ziel der Beziehung ein Business-Objekt ist, kann mit diesem Element der vollständige Name des Ziel-Business Objects angegeben werden.
targetview	Wenn das Ziel der Beziehung eine Objektsicht ist, kann mit diesem Element der vollständige Name der Ziel-Objektsicht angegeben werden. Wenn die Objektsicht, an der eine Beziehung abgefragt wird, eingeschränkten Zugriff hat, so haben auch alle Ziel-Objektsichten eingeschränkten Zugriff. Der Abschnitt „Eingeschränkter Zugriff“ enthält weitere Informationen.
javadoc	Optionales Java-Doc für die Beschreibung einer Beziehung. Das Java-Doc wird sowohl an die Methode zum Abfragen des DataView als auch des DataAccess geschrieben.

3.1.4    Erweiterung durch View-/Access-Interfaces

Die View- und die Access-Klassen können beliebige Interfaces erweitern. Die Methoden der Interfaces können sowohl Zugriffmethoden für Attribute und Beziehungen umfassen als auch neue Methoden ohne Bezug zu einem Attribut oder einer Beziehung enthalten.

3.1.4.1      Zugriff auf Attribute und Beziehungen

Zu einem Business-Objekt können mehrere Objektsichten unterschiedliche Verwendungen des Business-Objekts repräsentieren.

Beispiel:

Für das HashCode-Business-Objekt  AddressData existieren unterschiedliche Objektsichten für unterschiedliche Verwendungen der Adresse.

Die Java-Interfaces aller Objektsichten zu einem Business-Objekt haben von sich aus keine gemeinsame Schnittstelle. Wichtige Methoden (Zugriff auf Attribute und Beziehungen) sind jedoch allen Verwendungen gemeinsam. Diese gemeinsamen Methoden können in einem View- und/oder Access-Interface zusammengefasst werden. Die Java-Interfaces der Objektsichten können diese View- und Access-Interfaces erweitern. Algorithmen können so über das gemeinsame Super-Interface auf die unterschiedlichen Objektsichten zugreifen.

Beispiel:

Alle Objektsichten für die Adresse könnten die folgenden Methoden gemeinsam haben:

String getCity()

void setCity(String newValue)

String getPostalCode()

void setPostalCode(String newValue)

Die Get-Methoden werden in das Java-Interface AbstractAddressView und die Set-Methoden in das Java-Interface AbstractAddressAccess aufgenommen. AbstractAddressAccess erweitert AbstractAddressView.

Ein Feld zur Darstellung der Stadt und der Postleitzahl sollte, statt einer konkreten Objektsicht die Java-Interfaces AbstractAddressView und/oder AbstractAddressAccess verwenden.

3.1.4.2      Neue Methoden

Im View- oder Access-Interface können Methoden enthalten sein, die weder einen Zugriff auf ein Attribut noch auf eine Beziehung realisieren. Solche Methoden werden mit der gleichen Signatur am DataObject aufgerufen.

Beispiel:

Das Java-Interface AbstractAddressView wird als View-Interface für die Adresse enthält die Methode:

void xyz()

Das zu der Objektsicht gehörige DataObject muss die Methode void xyz() enthalten.

Wenn die Methode xyz() an der Objektsicht aufgerufen wird, so wird die entsprechende Methode am DataObject aufgerufen.

Die Metadaten enthalten keine Informationen über die Methoden der View- und Access-Interfaces. Auf die Methoden kann somit über die Metadaten (Path) nicht zugegriffen werden.

Über diese neuen Methoden können beliebig komplexe Funktionen über das DataObject am APP-Entity aufgerufen werden.

3.1.5    Eingeschränkter Zugriff

Business-Objekts können durch Business-Object-Erweiterungen beispielsweise bei einer Kundenadaptierung oder in einem Apps-Entwicklungssystem um neue Attribute erweitert werden.

Beispielsweise in einer Schnittstelle für Apps, darf eine App häufig nur die Attribute ändern, die sie selbst angelegt hat. Der eingeschränkte Zugriff gewährleistet, dass nur die Attribute der Business-Object-Erweiterungen geändert werden können, die in dem zugehörigen Apps-Entwicklungssystem angelegt worden sind. Alle anderen Attribute im Business-Objekt können und dürfen nicht verändert.

Hinweis:

In einem Entwicklungssystem mit dem Entwicklungspräfix „xyz“ dürfen bei einer eingeschränkten Objektsicht nur die Attribute mit dem Präfix „xyz_“ verändert werden.

Bei der Verwendung einer Objektsicht mit eingeschränktem Zugriff (DataAccess) in einem Hook oder in einer Objektsichterweiterung wird, die Menge der verwendbaren Setter auf die zum Entwicklungsnamensraum des Verwenders passenden Attribute eingeschränkt. Der Aufruf eines Setters eines nicht veränderbaren Attributs führt bei einem DataAccess zu einem Laufzeitfehler.

Der DataAccess einer Objektsicht bietet die Setter für alle Attribute, die durch eine Business-Object-Erweiterung hinzugekommen sind. Die Setter für die Attribute des Business-Objekts sind in dem Inner-Interface Full enthalten. Das Inner-Interface Full erbt von dem DataAccess. Verwenden Sie dieses Interface, um eine Objektsicht mit vollem Zugriff zu erzeugen.

Hinweis:

Eine Objektsicht mit vollem Zugriff wird nur dann in einer Hook-Schnittstelle verwendet, wenn wirklich alle Attribute des DataView durch die Hook-Implementierung verändert werden dürfen. Hook-Schnittstellen zum Erweitern von Standardanwendungen enthalten häufig Objektsichten mit eingeschränktem Zugriff.

Beispiel:

Erzeugen einer Objektsicht für den Artikel mit eingeschränktem Zugriff:

ItemAccess restrictedAccess = dvm.create(

ItemAccess.class, itemDataObject);

Nach der Erzeugung einer Objektsicht mit eingeschränktem Zugriff sind alle Attribute aller Business-Object-Erweiterungen veränderbar. Die veränderbaren Attribute werden bei der Verwendung des DataAccess in einem Hook oder aber bei Objektsichterweiterung weiter eingeschränkt.

Erzeugen einer Objektsicht für den Artikel mit vollem Zugriff:

ItemAccess.Full fullAccess = dvm.create(

ItemAccess.Full.class, itemDataObject);

Nach der Erzeugung einer Objektsicht mit vollem Zugriff können alle Attribute ohne Einschränkung verändert werden.

3.1.6    Implementierung des DataObject

Der DataView stellt die externe Schnittstelle eines Business-Objekts in einem APP-Entity dar.

Die Infrastruktur des DataView leitet soweit als möglich Methodenaufrufe aus dem DataView an das zugrundeliegende Business-Objekt weiter. Einige Methoden wie beispielsweise Zugriffe virtuelle Attribute oder Beziehungen können nicht durch die Infrastruktur beantwortet werden. Alle Methoden am DataView, die nicht durch die Infrastruktur definiert sind, müssen im DataObject implementiert werden.

Das DataObject bildet die Zugriffe auf den DataView oder DataAccess auf das APP-Entity ab. Das DataObject selbst ist dabei nur der Vermittler. Die Instanzen des DataObject werden teilweise beim Zugriff auf den DataView erzeugt. Zu einem Business-Objekt in einem APP-Entity kann es zu einem Zeitpunkt mehrere DataObject geben. Die Instanzen der DataObject werden häufig neugebaut und verworfen.

Die Implementierung eines DataObject muss die folgenden Bedingungen erfüllen:

• Das zugehörige Business-Objekt ist bekannt, wenn der Konstruktor aufgerufen wird.
• Ein DataObject sollte im Konstruktor keine komplexen Berechnungen durchführen.
• Ein DataObject darf keinen eigenen Zustand halten.

Bei der Definition einer Objektsicht wird die Klasse des zugehörigen DataObject angegeben. Zum Instanziieren eines DataView oder eines DataAccess wird eine Instanz des zugehörigen DataObject benötigt.

Die Aufrufreihenfolge von Retrieve-Methoden, Gettern und Settern steht beim Übertragen von Daten von und zur Oberfläche nicht fest (dataFromUI und dataToUI). Die Methoden von virtuellen Attributen und Beziehungen dürfen andere auf der Oberfläche änderbare Attribute nicht ändern.

Beispiel:

Die Attribut a und v sind auf der Oberfläche änderbar. Beim Setzen des Attributs v wird auch das Attribut a gesetzt. In diesem Fall hängt der Inhalt von a davon ab, ob erst a oder erst v von der Oberfläche übernommen wird.

Eine Lösung wäre, dass das Attribut a nicht änderbar oder nicht sichtbar wäre. Dadurch kann es  keinen Konflikt mit der Übernahme von a und v von der Oberfläche geben, da a nicht von der Oberfläche übernommen wird.

Das gleiche Problem tritt auch auf, wenn z.B. durch den Setter eines virtuellen Attributs das Zielobjekt einer Beziehung mit änderbaren Attributen geändert wird.

Beziehungen ohne änderbare Attribute und nicht änderbare Attribute können durch Setter geändert werden solange die Aufrufreihenfolge nicht relevant ist.

3.1.6.1       Virtuelle Attribute im DataObject

Die Getter und Setter von virtuellen Attributen müssen im DataObject mit den gleichen Signaturen implementiert werden wie im DataView oder DataAccess.

Hinweis:

Beachten Sie, dass ein DataObject keine eigenen Zustände halten darf. Der Zustand eines virtuellen Attributs muss im APP-Entity gespeichert werden.

Beachten Sie auch, dass Sie mit den Settern virtueller Attribute keine anderen änderbaren Attribute beeinflussen dürfen.

Beispiel:

class ItemObject extends DataObject<Item> {

…

 

public boolean isDollar() {

return getObject().getDescription().endsWith(“$“);

}

 

…

}

Besonderheiten

Wenn das virtuelle Attribut X ein Part P als Datentyp hat, so müssen im DataObject mindestens die Methoden PMutable getMutableX() und setX(PMutable v) implementiert werden. Die Methode P getX() muss nicht implementiert werden. Wenn getX() nicht implementiert wurde, so wird beim Aufruf von getX()an der Objektsicht im DataObject statt getX() getMutableX() aufgerufen. Das Ergebnis von getMutableX()wird in ein unveränderbares Part umgewandelt.

3.1.6.2      Beziehungen im DataObject

Eine Objektsicht kann Beziehungen zwischen Business-Objekts oder Objektsichten ausdrücken. Eine Objektsicht stellt häufig einen Teil eines APP-Entitys dar. Ein APP-Entity verwaltet eine Menge von transienten Business-Objekts. Die Beziehungen zwischen Business-Objekts innerhalb des APP-Entitys können nur vom APP-Entity selbst ausgewertet werden. Beziehungen auf Business-Objekts, die nicht vom APP-Entity verwaltet werden, werden mit dem Persistenzdienst berechnet. Falls die Infrastruktur der Objektsichten die Beziehung nicht generisch berechnen kann, muss die Beziehung im DataObject implementiert werden.

One-Many bei 0…n Beziehungen

0…n Beziehungen können beliebig viele Instanzen der Zielobjekte zurückgeben. Die Berechnung der Zielobjekte erfolgt abhängig von der Beziehung im DataObject oder aber in der Infrastruktur der Objektsichten.

Der Inhalt 0…n Beziehung wird als One-Many-Objekt von der Objektsicht zurückgegeben. Das One-Many-Objekt enthält im Allgemeinen entweder die transienten Instanzen der Zielobjekte oder aber die Schlüssel, um die Zielobjekte vom Persistenzdienst zu laden. Die Menge der Schlüssel muss festgelegt werden, wenn das One-Many-Objekt erzeugt wird. Nach der Erzeugung des Objekts dürfen sich die Schlüssel nicht mehr verändern. Die Zielobjekte werden abhängig vom One-Many-Objekt erst beim Zugriff geladen.

Hinweis:

Vermeiden Sie in Objektsichten 0…n Beziehungen mit einer unbegrenzten Anzahl von Zielobjekten.

Für jedes Zielobjekt in einem One-Many-Objekt wird mindestens der Schlüssel im Hauptspeicher gehalten. Beachten Sie also beim Entwurf einer Objektsicht, dass alle 0…n Beziehung eine hohe, aber begrenzte Anzahl von Zielobjekten haben.

Beachten Sie, dass die Zielobjekte eines One-Many-Objekts durchaus „null“ sein können.

Das One-Many-Objekt erlaubt einen wahlfreien Zugriff auf die Zielobjekt. Durch das One-Many-Objekt wird für den Verwender der Objektsicht verborgen, ob die Zielobjekte transient im APP-Entity oder aber über den Persistenzdienst berechnet werden.

Diverse Implementierungen des One-Many-Interfaces erleichtern die Verwendung:

• Die Klasse OneManyBase ist die Basis-Klasse für eigene Implementierungen des One-Many-Interfaces.
• Die Klasse OneManyObjectIterator implementiert ein One-Many-Objekt auf den Ergebnissen eines ObjectIterators.
• Die Klasse OneManyCollection implementiert ein One-Many-Objekt auf einer Collection von CisObject.

Wenn das Ergebnis der One-Many-Klassen eine Objektsicht ist, so können die obigen One-Many-Klassen zu einem DataObject oder Business-Objekt die Objektsicht erzeugt werden. Sofern das zu der Objektsicht gehörige DataObject nur das Business-Objekt als Parameter im Konstruktor hat, ist keine besondere Implementierung erforderlich. Falls der Konstruktor vom DataObject mehr oder andere Parameter hat, muss dieser Konstruktor in einer Implementierung des inneren Interfaces OneManyBase.DataObjectBuilder aufgerufen werden.

Weitere Informationen zu der Implementierung von Objektsichten finden Sie im Java-Doc der Klasse com.cisag.pgm.base.OneMany.

Beispiel:

public OneMany<AlternativeItemObject> retrieveAlternativeItems() {

CisObjectIterator iter = om.getObjectIterator(

“SELECT FROM com.cisag.app.general.obj.Item o “+

“WHERE o:alternativeItem=?“);

iter.setGuid(1,getObject().getGuid());

return new OneManyCisObjectIterator(iter,

new OneManyBase.DataObjectBuilder<Item> {

DataObject build(Item item) {

return new AlternativeItemObject(entity,item);

}

});

}

Property MUTABLE

Wenn das Ziel der Beziehung aus einem DataAccess verändert werden darf (Property „MUTABLE“), dann muss diese Beziehung im DataObject implementiert werden. Im Allgemeinen verwaltet in diesem Fall das APP-Entity die änderbare und transiente Instanz des Business-Objekts.

Der Entwickler muss für eine änderbare Beziehung mit dem Namen {RelationName} und dem Business-Objekt {BusinessObject} die folgende retrieve-Methode implementieren:

0:1 Beziehung

DataObject<{BusinesObject}> retrieve{Relationname}()

0:n Beziehung

OneMany<DataObject<{BusinesObject}>> retrieve{Relationname}()

 

Wenn ein DataAccess einen eingeschränkten Zugriff hat, werden beim Abfragen einer Beziehung auch alle Zielobjekte mit eingeschränktem Zugriff erstellt. Bei der Ziel-Objektsicht (Element targetview) kann für eine Beziehung angegeben werden, dass die Ziel-Objektsicht unabhängig von der Quell-Objektsicht keinen eingeschränkten Zugriff haben soll.

Beispiel:

public ItemObject retrieveDefaultVariantItem() {

return new ItemObject(entity, entity.getDefaultVariantItem());

}

Property READ_ONLY

Wenn das Ziel der Beziehung eine Objektsicht ist, die nicht verändert werden darf (Property „READ_ONLY“) und nicht über den Business–Object-Mapper des Quellobjekts ermittelt werden kann, muss die Beziehung im DataObject implementiert werden. Dies ist beispielsweise dann der Fall, wenn diese so komplex ist, dass die Beziehung nicht in den Meta-Daten des Business-Objekts ausgedrückt werden kann.

Die Implementierung im DataObject erfolgt analog zu einer Beziehung mit der Property „MUTABLE“.

Property PERSISTENT

Für Beziehungen, die über den die Business–Object-Mapper ausgewertet werden sollen (Property „PERSISTENT“), darf keine Implementierung im DataObject existieren. Falls bei diesen Beziehungen als Ziel eine Objektsicht angegeben wurde (Element „targetview“), dann muss sich diese Objektsicht nur mit einem Business-Objekt erzeugen lassen. Das DataObject der Ziel-Objektsicht muss in diesem Fall einen Konstruktur mit dem zugehörigen Business-Objekt als einzigen Parameter haben. Wenn ein solcher Konstruktor nicht existiert, dann kommt es zu einem Laufzeitfehler beim Abfragen der Beziehung.

Beispiel:

Wenn im Business-Objekt SalesOrder bei der Beziehung Type die Ziel-Objektsicht SalesOrderTypeView angegeben wurde, so muss das DataObject SalesOrderTypeObject der Objektsicht SalesOrderTypeView den folgenden Konstruktor haben:

SalesOrderTypeObject(SalesOrderType soType)

3.1.7    Übersetzbare Attribute (NLS)

Übersetzbare Attribute (NLS) werden in Objektsichten anders als andere normale Zeichenketten behandelt. Die Daten eines übersetzbaren Attributs werden normalerweise vom APP-Entity in der Klasse NLSData verwaltet. Erstellen Sie einen Getter mit dem Suffix „$NLS“ für den Zugriff auf das NLSData im APP-Entity.

Beispiel:

public NLSData getDescription$NLS() {

return …;

}

Alternativ zum obigen Mechanismus können NLSData auch mit dem Interface DataObject.GenericNLS bereitgestellt werden.

Beispiel:

public NLSData getNLSData(String attributePath) {

return entity.getNLSData(attributePath);

}

Unabhängig von dem Interface DataObject.GenericNLS wird das NLSData falls eine $NLS-Methoden existiert, über diese Methode bestimmt.

Hinweis:

Wenn das DataObject das Interface DataObject.GenericNLS nicht implementiert, so müssen Sie für alle übersetzbaren Attribute $NLS-Methoden erstellen.

3.2        Java-Klassen generieren

Der DataView und der DataAccess werden pro Objektsicht generiert. Das Generieren erfolgt mit dem Tool-Shell-Kommando „crtdv“. Das Tool-Shell-Kommando hat die in der Entwicklung üblichen Parameter „-j“ für eine Entwicklungsaufgaben und „-o“ für ein Entwicklungsobjekt.

Wenn eine Objektsicht aus einer Entwicklungsaufgabe entfernt werden soll, ist es notwendig das Toll-Shell-Kommando „crtdv“ mit dem Parameter
„-‍resetState“ aufzurufen.

Beim Generieren des zugrundeliegenden Business-Objekts (mittels crtobj) werden die Java-Klassen für die Objektsicht ebenfalls generiert. Wenn ein DataView beim Generieren einer Business-Object-Erweiterung automatisch in der Entwicklungsaufgabe aufgenommen wurde, dann wird der DataView bei rmvbo automatisch entfernt.

3.3        CisDataViewManager

Über den CisDataViewManager können Objektsichten erzeugt und die Metadaten der Objektsichten abgefragt werden. Der CisDataViewManager wird vom CisEnvironment abgefragt.

3.3.1    Objektsichten erzeugen

Eine Objektsicht kann mit dem gewünschten Interface des DataView oder DataAccess und einem dazu passenden DataObject erzeugt werden.

<O extends CisObject,

V extends DataView<O>, D extends DataObject<O>>

V create(Class<V> dataClass, D dataObject)

Falls das DataObject einen Konstruktor besitzt, der das Business-Objekt als einzigen Parameter hat, so kann der DataViewManager mit dem Business-Objekt das passende DataObject selbst erzeugen. In diesem Fall kann auch die folgende Methode verwendet werden:

<O extends CisObject, V extends DataView<O>>

V create(Class<V> dataClass, O object)

In dem Parameter dataClass wird das Interface angegeben, für das eine Objektsicht erzeugt werden soll.

Beispiel:

Erzeugung einer nicht änderbaren Objektsicht:

ItemView view =

dvm.create(ItemView.class, dataObject);

Erzeugung einer eingeschränkten Objektsicht:

ItemAccess access =

dvm.create(ItemAccess. class, dataObject);

Erzeugung einer änderbaren Objektsicht:

ItemAccess.Full access =

dvm.create(ItemAccess.Full.class, dataObject);

3.3.2    Metadaten der Objektsichten abfragen

Die Metadaten einer Objektsicht können am DataViewManager abgefragt werden. Die Metadaten werden für den generischen Zugriff auf Objektsichten benötigt. Der Abschnitt „Pfade“ enthält weitere Informationen zum generischen Zugriff.

Die Metadaten einer Objektsicht können Sie mit der folgenden Methode abfragen:

<O extends CisObject, V extends DataView<O>>

CisDataViewMetaData getMetaData(Class<V> dataClass);

Um generisch auf Business-Objekts zuzugreifen, können die Metadaten einer Objektsicht mit den folgenden Methoden auch für ein Business-Objekt ermittelt werden:

<O extends CisObject>

CisDataViewMetaData getObjectMetaData(

Class<O> businessObjectClass);

 

CisDataViewMetaData getObjectMetaData(byte[] classGuid);

3.3.3    Attribute kopieren

Der CisDataViewManager bietet zwei Hilfsroutinen, mit denen Attribute eines DataView in einen DataAccess kopiert werden können. Die Methoden können nur mit dem DataView und DataAccess der gleichen Objektsicht aufgerufen werden. Es steht eine Methode zum Kopieren aller Attribute zur Verfügung. Zusätzlich können auch nur ausgewählte Attribute kopiert werden. Die Methoden sind:

copyTo( DataView<?> sourceView,

DataFullAccess<?> targetFullAccess);

copyTo( DataView<?> sourceView,

DataFullAccess<?> targetFullAccess,

AttributeFilter attributeFilter);

3.4        Pfade

Ein Pfad beschreibt im Allgemeinen ausgehend von einer Objektsicht A den Zugriff auf ein Attribut A oder einer anderen Objektsicht, die durch eine Kette von 0…1 Beziehungen ausgehend von A erreicht werden kann. Pfade erfüllen die folgenden Aufgaben:

• Ein Feld in einer interaktiven Anwendung ist mit einem Pfad verknüpft:
• Fehlermeldungen können über den Pfad mit den zugehörigen Feldern verknüpft werden (rote Ecken)
• Die Daten werden über den Pfad automatisch zwischen der Objektsicht und dem Feld in der interaktiven Anwendung ausgetauscht.
• Mithilfe der Metadaten der Objektsicht und der Pfad, ist ein generischer Zugriff auf die Daten einer Objektsicht möglich.

Im Anwendungsprogramm müssen Pfade erstellt z.B. zum Absenden einer Meldung erstellt werden. Damit ein Pfad so sicher wie möglich erstellt werden kann, werden die Identifikationen der Beziehungen und der Spalten als Enum im DataView erzeugt.

An der Klasse com.cisag.pgm.base.Path können unter anderem mit der folgenden Methode Pfade abfragt werden:

Path getInstance(Enum<?>… attributeOrRelation)

Die Klasse Path hat weitere Methoden, um Pfade aus den Metadaten einer Objektsicht oder aus einer Zeichenkette zu erzeugen. Diese Methoden sind im Java-Doc der Klasse beschrieben.

Beispiel:

public interface ItemView {

public static enum Attribute {

$guid,

$number,

…

}

 

public static enum Relation {

$DefaultVariantItem,

$AlternativeItems,

…

}

}

Mit den Enum im DataView können Pfade erstellt werden:

Path numberPath = Path.getInstance(ItemView.Attribute.$number);

Path variantGuidPath = Path.getInstance(

ItemView.Relation.$DefaultVariantItem,

ItemView.Attribute.$number);

Die Pfade können im Message-Manager zum Senden von Meldungen verwendet werden, um die Meldung einem oder mehreren Feldern zuzuordnen:

mm.setProgramMessageDataViewPaths(numberPath);

mm.sendMessage(“XYZ“,4711,“abc“);

Mit einem Pfad können Sie generisch auf die Daten einer Objektsicht zugreifen:

DataView view = ….

String number = (String)view.getValue(numberPath);

 

DataFullAccess fullAccess = ….

fullAccess.setValue(variantGuidPath, variantGuid);

Das Java-Doc der Klassen com.cisag.pgm.base.DataView, com.cisag.pgm.base.DataAccess und com.cisag.pgm.base.DataFullAccess enthalten eine vollständige Beschreibung aller Methoden für den generischen Zugriff auf die Daten einer Objektsicht.

3.5        Objektsichterweiterung

Semiramis kann in nachgelagerten Entwicklungssystemen oder Apps-Entwicklungssystemen um neue Funktionen erweitert werden. Zu diesem Zweck sind unter anderem auch Datenmodelländerungen notwendig. Die APP-Entitys aus dem Standard müssen das durch die neuen Funktionen erweiterte Datenmodell berücksichtigen. Für die Erweiterung der APP-Entitys werden entsprechende Hook-Contract-Definitionen und Schnittstellen bereitgestellt.

Wenn ein Business-Objekt im APP-Entity mit einer Business-Object-Erweiterung um neue Attribute und Beziehungen erweitert wird, so werden alle diese Attribute und Beziehungen automatisch in die zugehörigen Objektsichten aufgenommen.

Wenn die Eigenschaften der neuen Attribute verändert werden sollen oder aber das APP-Entity beispielsweise um neue Dependents erweitert wird, sind für diese Erweiterung zusätzliche Metadaten erforderlich. Diese Erweiterung wird als Objektsichterweiterung bezeichnet.

Hinweis:

Da alle Attribute und Beziehungen einer Business-Object-Erweiterung automatisch in alle zum Business-Objekt gehörigen Objektsichten aufgenommen werden, ist es häufig nicht notwendig eine Objektsichterweiterung anzulegen.

Eine Objektsichterweiterung besteht aus den Metadaten der Attribute und den Metadaten der Beziehungen. Die Namen der Attribute und Beziehungen müssen der aus dem Entwicklungsnamensraum der Objektsichterweiterung abgeleiteten Namenskonvention genügen.

Beispiel:

Alle Attribute in der Objektsichterweiterung com.xyz.app.general.model.ItemView müssen mit dem Prefix „xyz_“ beginnen.

Alle Beziehung in der Objektsichterweiterung com.xyz.app.general.model.ItemView müssen mit dem Prefix „Xyz_“ beginnen

In einem Apps-Entwicklungssystem können unter Umständen mehrere Apps entwickelt werden. Eine Objektsichterweiterung darf nur die Attribute und Beziehungen aus der gleichen App verändern. Die Namen der virtuellen Attribute und Beziehungen müssen über alle in diesem System entwickelten Apps eindeutig sein.

Hinweis:

Die Eigenschaften von Attributen und Beziehungen, die außerhalb des Entwicklungsnamensraums und/oder der App angelegt wurden, können und dürfen nicht verändert werden.

Die Beschreibung einer Objektsichterweiterung wird als XML-Entwicklungsobjekt erfasst. Der Aufbau des XMLs wird anhand eines Beispiels eingeführt. Eine tabellarische Beschreibung der in diesem Beispiel verwendeten Elemente finden Sie in den folgenden Abschnitten. Die Elemente für Attribute und Beziehung wurden bereits bei der Objektsicht beschrieben.

Beispiel: com.xyz.app.general.model.Item

<?xml version=”1.0″ encoding=”utf-8″?>

<dataviewextension

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xsi:noNamespaceSchemaLocation=”DataView.xsd”>

<dataview>

com.cisag.app.general.item.model.Item

</dataview>

<implementation>

com.xyz.app.general.log.ItemExtension

</implementation>

 

<virtualattribute property=“READ_ONLY“>

<name>xyz_derivedState</name>

<datatype>

com.xyz.app.general.model.ItemDerivedState

</datatype>

<javadoc>

Der abgeleitete Zustand wird aus dem Zustand

des Artikels berechnet.

</javadoc>

</virtualttribute>

 

<!– Die Beziehung Xyz_TopSalesOrders soll nicht angezeigt –>

<!– werden. –>

<relation property=“EXCLUDED“>

<name>Xyz_TopSalesOrders</name>

</relation>

 

<!– Die Beziehung Xyz_ItemFashionExtension zeigt auf ein –>

<!– Dependent im APP-Entity des Artikels. –>

<relation property=“MUTABLE“>

<name>Xyz_ItemFashionExtension</name>

<targetview>

com.xyz.app.general.model.ItemFashionExtension

</targetview>

<javadoc>

Alle Erweiterungen für die Fashion-Lösung werden

über diese Beziehung implementiert.

</javadoc>

</relation>

</dataviewextension>

3.5.1    Definition einer Objektsichterweiterung

Eine Objektsichterweiterung wird durch genau ein Element „dataviewextension“ beschrieben. Das Element enthält weitere Elemente. Diese sind in die folgenden Gruppen aufgeteilt:

1. Daten zu der Objektsichterweiterung
2. Daten zu den Attributen der Objektsichterweiterung
3. Daten zu den Beziehungen der Objektsichterweiterung

Die folgende Tabelle erläutert alle Elemente, die die Daten der Objektsichterweiterung beschreiben:

Element	Erläuterung
dataview	Vollständiger Name der Objektsicht mit Namensraum. Dieses Element muss angegeben werden.
implementation	Vollständiger Klassenname der DataExtension für die Objektsichterweiterung mit Namensraum. Die angegebene Klasse muss von der Klasse DataExtension abgeleitet sein. Dieses Element muss angegeben werden.

Die Definition von Attributen und Beziehungen in einer Objektsichterweiterung ist identisch mit der Definition in Objektsichten. Die Namen aller Attribute und Beziehungen müssen analog zu den Business-Object-Erweiterungen mit dem Entwicklungspräfix der Objektsichterweiterung beginnen.

Beispiel:

In der Objektsichterweiterung com.xyz.app.general.model.Item müssen die Namen aller Attribute mit „xyz_“ und aller Beziehungen mit „Xyz_“ beginnen.

Weitere Informationen finden Sie den Abschnitten „Definition von Attributen“ und „Definition von Beziehungen“.

3.5.2    Implementierung der DataExtension

Die DataExtension implementiert die durch eine Objektsicherweiterung erweiterte Funktionalität eines DataView.

Die Infrastruktur der DataView leitet soweit als möglich Methodenaufrufe für Attribute und Beziehungen einer Business–Objekt-Erweiterung vom DataView an das zugrundeliegende Business-Objekt weiter. In folgenden Fällen ist jedoch eine Programmierung in der DataExtension nötig:

• Zugriff auf virtuelle Attribute
• Zugriff auf übersetzbare (NLS-) Attribute
• Zugriff auf virtuelle oder berechnete Beziehungen,
• Zugriff auf Beziehungen auf eine Objektsicht anstatt auf ein Business-Objekt
• Steuerung der Sichtbarkeit und der Änderbarkeit von Feldern in der anpassbaren Oberfläche.

Die Implementierung dieser Zugriffe in der DataExtension erfolgt analog zur Implementierung im DataObject, wie in Abschnitt „Implementierung des DataObject“ beschrieben..

Die DataExtension hat über den DataView oder DataAccess Zugriff auf die Attribute des Business-Objekts inklusive der Attribute der Business-Object-Erweiterungen. Die Infrastruktur der DataView stellt sicher, dass der Schreibzugriff nur auf die Attribute der Business-Object-Erweiterungen im eigenen Entwicklungsnamensraum möglich ist.

Hinweis:

Die DataExtension hat keinen Zugriff auf die transiente Instanz des Business-Objekts.

Wenn in der Objektsichterweiterung Beziehungen mit der Property READ_ONLY oder MUTABLE oder virtuelle Attribute definiert werden, dann dürfen die zugehörigen Methoden am DataView oder DataAccess in der Implementierung der DataExtension nicht verwendet werden. Falls diese Methoden dennoch verwendet werden, kommt es zu einem Laufzeitfehler.

Das APP-Entity kann durch Hooks um neue Funktionen erweitert werden. Beispielsweise werden neue Dependents im APP-Entity meist in einem zustandsbehafteten Hook verwaltet. Die Instanz dieses zustandsbehafteten Hooks kann bei vielen Objektsichten im DataView mit einem Getter abgefragt werden.  Wenn dieser Getter in der DataExtension verwendet wird, so wird vom Getter der zu dem Entwicklungsnamensraum der DataExtension gehörige zustandsbehaftete Hook zurückgegeben.

Die DataExtension ist anlog zum DataObject nur ein Vermittler. Die Instanzen der DataExtension werden teilweise beim Zugriff auf die DataView erzeugt. Zu einem Business-Objekt in einem APP-Entity kann es zu einem Zeitpunkt mehrere DataObject mit mehreren DataExtension geben. Die Instanzen der DataExtension werden häufig neugebaut und verworfen.

Die Implementierung eines DataExtension muss die folgenden Bedingungen erfüllen:

• Die DataExtension muss einen Konstruktor ohne Parameter haben.
• Ein expliziter Konstruktor ist nicht notwendig.
• Keine komplexen Berechnungen im Konstruktor erlaubt.
• Die DataExtension darf keinen eigenen Zustand halten.
• Die DataExtension darf keine Methoden am DataView aufrufen, die in der gleichen DataExtension implementiert werden.

Bei der Definition einer Objektsichterweiterung wird die Klasse der zugehörigen DataExtension angegeben.

Beispiel:

Das Beispiel implementiert das virtuelle Attribut und die nicht-virtuelle Beziehung für die Objektsichterweiterung.

Die nicht-virtuelle Beziehung braucht eine Implementierung in der DataExtension, da das Business-Objekt ItemFashionExtension logisch ein Dependent innerhalb des Business-Entitys ist.

class ItemExtension extends DataExtension<ItemView, ItemAccess> {

 

public short getXyz_derivedState() {

return

getView().getSalesStatus()*100+

getView().getInventoryStatus();

}

 

DataObject<FashionExtension> retrieveXyz_ItemFashionExtension() {

XyzItemEntityState state =

(XyzItemEntityState)getView().getEntityState();

return new DataObject<FashionExtension>

(state.getFashionExtension());

}

}

 

3.5.3    DataDescriptionModification

Die Sichtbarkeit und Änderbarkeit von Feldern der anpassbaren Oberfläche wird in einer DataExtension oder in einem DataObject per DataDescriptionModification gesteuert. Wenn mehrere Quellen für das gleiche Feld unterschiedliche DataDescriptionModifications erzeugen, so werden diese automatisch zusammengeführt.

3.5.3.1      DataDescriptionModification für die aktuelle Objektsicht

Um die DataDescriptionModification für Attribute der Objektsicht zu verändert, zu der das DataObject oder die DataExtension gehört, müssen Sie Methode die getDataDescriptionModification(Enum) überschrieben. Diese Methode soll die DataDescriptionModification für ein Attribut der aktuellen Objektsicht identifiziert bestimmen.

In der Implementierung muss beachtet werden, dass diese Methode für alle Attribute, auch für Attribute aus fremden Extensions, aufgerufen wird.

Sollen nur bestimmte Felder beeinflusst werden, kann folgendes Muster verwendet werden:

public DataDescriptionModification getDataDescriptionModification(Enum attribute) {

 

switch (((CountryView.Attribute) attribute)) {

case $ado_countryEuroCurrency:

if (!getView().isEuMember()) {

return DataDescriptionModification.READ_ONLY;

}

break;

}

return super.getDataDescriptionModification(attribute);

}

Um alle eigenen Felder zu beeinflussen, aber keine fremden Felder, kann über die Methode isAssociated() abgefragt werden, ob ein Attribut aus der eigenen App bzw. Adaptierung stammt.

public DataDescriptionModification getDataDescriptionModification(Enum attribute) {

 

if ( !isAssociated(attribute)) {

return super.getDataDescriptionModification(attribute);

 

} else if ( !isEnabled()) {

return DataDescriptionModification.EXCLUDED;

}

if (attribute==Item.Attribute.$xyz && isX()) {

return DataDescriptionModification.READ_ONLY;

} else {

return DataDescriptionModification.UNMODIFIED;

}

}

3.5.3.2      DataDescriptionModification für entfernte Objektsichten

Um die DataDescriptionModification für Attribute von Objektsichten zu verändert, die über 1:1 Beziehungen ausgehend von der aktuellen Objektsicht erreicht werden können, müssen Sie das Interface DataObject.DataDescriptionModificationProvider mit der Methode getDataDescriptionModification(Path) implementieren. Diese Methode soll die DataDescriptionModification für einen Pfad ausgehend von der aktuellen Objektsicht bestimmen.

Bei der Implementierung der Methode getDataDescriptionModification(Path) müssen Sie analog zu der Methode getDataDescriptionModification(Enum) beachten, dass Sie die Eigenschaften fremder Attribute beeinflussen können.

Beachten Sie, dass Pfade nicht unbedingt eindeutig sind. Mehrere unterschiedliche Pfade können ausgehend von der gleichen Objektsicht zum gleichen Ziel führen. Vergleichen Sie daher möglichst nur die relevanten Teile eines Pfades, aber nicht den vollständigen Pfad. Der Pfad bietet hierfür die Methoden startsWith, endsWith und contains an.

public DataDescriptionModification getDataDescriptionModification(Path path) {

if ((! isMyAddressEnabled()) &&

path.contains(Relations.$MyAddress)) {

return DataDescriptionModification.DISABLED;

}

return DataDescriptionModification.UNMODIFIED;

}

3.6        Weitere Möglichkeiten

3.6.1    GUI-Komponenten

In der anpassbaren Oberfläche können auch GUI-Komponenten zur Verfügung gestellt werden. GUI-Komponenten können Views mit mehreren Feldern, oder auch eine Tabelle oder Liste sein. Im Designmodus wird die GUI-Komponente als Ganzes auf der Oberfläche der Anwendung platziert.

In der Objektsicht wird die GUI-Komponente durch ein virtuelles boolean-Attribut repräsentiert, wie im folgenden Beispiel. Der logische Datentyp des virtuellen Attributs muss dabei auf dem Datentyp „boolean“ basieren.

<virtualattribute property=”READ_ONLY”>

<name>xyz_address</name>

<datatype>com.xyz.ext.app.addon1.AddressComponent</datatype>

</virtualattribute>

Im DataObject bzw. DataExtension müssen Zugriffsmethoden für das virtuelle Attribut pro forma implementiert werden. Die GUI-Komponenten erhalten ihre Daten nicht durch diese Zugriffsmethoden, sondern durch die Objektsicht, die im AttriubteContext in der GUI-Komponente zur Verfügung steht.

Tabellen oder Listen, in denen Daten einer 1:n-Beziehung dargestellt werden sollen, können mit den PGM-Klassen “CisObjectContainer“ (Datenhaltung) und „ContainerTableEditor“ (GUI-Komponente) realisiert werden.

[1] Mit Semiramis 5.0-PC-02 wurden Prüfungen verschärft. Falls Objektsichten oder Objektsicht-Erweiterungen existieren, die nicht diese Namenskonvention verwenden, sollten sie darauf umgestellt werden.
Ist eine Umstellung nicht möglich, kann die Objektsicht oder Objektsicht-Erweiterung weiterhin editiert werden, in dem auf dem Entwicklungssystem die System Property
com.cisag.sys.development.repository.dataview.acceptShortNames.<Entwicklungsobjekt>=true gesetzt wird.