1 Themenübersicht
Die Anwendung „Entwicklungsobjekte“ dient der Erfassung und Ansicht von Entwicklungsobjekten verschiedenster Typen. In dieser Dokumentation wird der Typ „Business Object“ beschrieben.
Allgemeine Informationen zur Anwendung „Entwicklungsobjekte“, beispielsweise die Beschreibung der anwendungsbezogenen Aktionen oder des Identifikationsbereichs, finden Sie in dieser Dokumentation „Entwicklungsobjekte“.
2 Beschreibung: Karteireiter „Editor“
Ein Business Object ist die technische Definition zu einer fachlichen Größe, deren konkrete Ausprägungen (Instanzen) in einer Datenbanktabelle gespeichert werden. Ein Business Object stellt im Wesentlichen einen Datencontainer ohne fachliche Logik dar. Die zu speichernden Daten werden durch ein oder mehrere Attributdefinitionen beschrieben.
Eine Instanz eines Business Objects ist eine technische Größe, die der Persistenzdienst von Comarch ERP Enterprise lesen, speichern und löschen kann. Dabei erfolgt die Konvertierung zwischen dem in der Anwendung benutzten objektorientierten Datenmodell und dem relationalen Datenmodell der Datenbank.
Business Objects sind die Grundlage für die Klassen- und Tabellengenerierung. Die generierten Java-Klassen kapseln die Datenbankbenutzung und bieten dem Anwendungsprogramm den Zugriff auf die Daten einer Business-Object-Instanz. Zu einem Business Object werden eine Haupttabelle und Hilfstabellen mit den Zugriffsstrukturen aus den hinterlegten Indexdefinitionen generiert.
Bei der Generierung des Business Objects werden verschiedene Java-Klassen generiert, die den Zugriff auf die Instanzen des Business Objects ermöglichen. Diese sind in drei Gruppen unterteilt: die aktiven Mapper, die versionisierten Mapper und das Updateprogramm.
Eine Beschreibung der Java-Klassen erfolgt im Dokument „Code-Generierung“. Außerdem werden auf der Datenbank die Tabellen und Indizes erzeugt. Weitere Informationen finden Sie in der Dokumentation „Datenbankänderungen“.
Die Felder im Einzelnen:
| Feld | Erläuterung |
| Basisobjekt | Erfassen Sie ein Entwicklungsobjekt des Typs „Part“ als Basisobjekt. Alle Attribute und Beziehungen werden übernommen (die Vererbungshierarchie im Basisobjekt wird komplett aufgelöst). Als Basisobjekte können ausschließlich Parts verwendet werden.
Das Business Object wird im Verwendungsnachweis des Parts aufgenommen. |
| Bezeichnung | Die Bezeichnung dient als zusätzliches Erkennungsmerkmal. Sie kann aus frei wählbarem Text bestehen und darf maximal 80 Zeichen umfassen. Erfassen Sie eine aussagekräftige und möglichst eindeutige Bezeichnung, damit die Suche danach erleichtert wird.
Hinweis: Bitte beachten Sie bei der Verwendung von Sonderzeichen, dass diese in einer zu suchenden Zeichenkette aus technischen Gründen in folgende Platzhalter umgewandelt werden: · Stern (*) zu Unterstrich (_) · Fragezeichen (?) zu Prozentzeichen (%) Die Verwendung eines Unterstriches in einem Suchmerkmal würde nicht nur nach dem Unterstrich, sondern nach einem beliebigen Zeichen suchen. Gleichermaßen wird das Prozentzeichen ausgewertet, welches dann keinem, einem oder mehreren Zeichen entspricht. Die Verwendung von Unterstrichen und Prozentzeichen in Zeichenketten sollte deshalb möglichst vermieden werden, da möglicherweise andere und mehr Objekte gefunden werden als beabsichtigt. |
| Typ | Der „Typ“ dient der fachlichen Strukturierung von Business Objects. Dabei wird zwischen dem Haupt-Business-Object, d. h. dem Business Entity, und abhängigen Business Objects in Form von Dependents, Supplements oder Managed Supplements unterschieden.
· Business Entity Dieser Eintrag kennzeichnet das Business Object als Haupt-Business-Object und damit als Business Entity, zu dem Dependents oder Supplements sowie Managed Supplements bestehen können. · Dependents Die Dependents zu einem Business Entity besitzen eine speziell ausgewiesene Beziehung mit dem Namen „_entity“ und der Kardinalität „1 zu 1“. Spezielle Methoden erlauben das Öffnen aller Dependents zu einem Business Entity. · Supplements Supplements sind Business Objects, die automatisch vom zugehörigen Business Entity mitverwaltet werden. Die Supplements zu einem Business Entity besitzen eine speziell ausgewiesene Beziehung mit dem Namen „_businessObject“ und der Kardinalität „1 zu 1“. Sie dienen demselben Zweck wie eine Extension, ohne die Tabelle des Haupt-Business-Objects zu erweitern. · Managed Supplements Managed Supplements sind Business Objects, die automatisch vom zugehörigen Business Entity mitverwaltet und nur auf Level-7-Systemen erzeugt werden. Diese „Managed Supplements“ sind benutzerdefinierte Attribute, die benutzerdefinierte Felder ersetzen können. Benutzerdefinierte Attribute haben den Vorteil, dass sie von einem Produktiv-Testsystem in ein Produktivsystem mithilfe der Softwarelogistik transportiert werden können. Die Auswahl der Attributtypen ist eingeschränkt. Beachten Sie auch die Anwendungsdokumentation „Benutzerdefinierte Attribute“. |
Buttons „Basisobjekt“ und „Extension“
Die Buttons „Basisobjekt“ und „Extensions“ stehen in verschiedenen Symbolleisten zur Verfügung. In den jeweiligen Kapiteln dieser Dokumentation wird auf die folgende Beschreibung verwiesen:
| Button | Erläuterung |
| Basisobjekt | Anzeige aller Attribute, Indizes und Beziehungen, die im angegebenen Basisobjekt erfasst sind. |
| Extensions | Anzeige aller Attribute, Indizes und Beziehungen einer Extension, die dem Business Object zugeordnet sind. |
2.1 Unterer Karteireiter „Attribute“
Die Karteikarte „Attribute“ enthält eine Liste, in der Sie die Attribute erfassen.
Listen-Spalten
Die Spalten im Einzelnen:
| Spalte | Erläuterung |
| Attribut | Name des Attributs.
Der Name muss mit einem kleinen Buchstaben beginnen und eindeutig sein. Danach sind kleine und große Buchstaben, Zahlen sowie der Unterstrich („_“) möglich. |
| Logischer Datentyp | Angabe des Logischen Datentyps mit vollständigem Entwicklungsobjektnamen.
Komplexe Typen werden bei der Generierung vollständig aufgelöst. Die Attribute aus dem verwendeten Part werden in das Business Object eingebunden und dadurch sind sie Bestandteil des Business Objects. Binäre logische Datentypen dürfen nicht mehr als 2000 bytes enthalten. |
| Datentyp | Anzeige des Datentyps des Attributs. |
| Arraygröße | Verwendung des Attributs als Feld. Die maximale Anzahl von Feldern beträgt 64. |
| Kommentar | Erfassen Sie bei Bedarf einen Kommentar zum Attribut. Der Text darf maximal 1000 Zeichen lang sein. Der Text ist nicht übersetzbar.
Die Kommentare werden in die generierten Java-Sourcen übernommen. Damit kann zum Beispiel ein Attribut als „@deprecated“ gekennzeichnet werden. |
Listen-Symbolleiste
In der Listen-Symbolleiste finden Sie neben den allgemeinen Buttons für eine neue Zeile, für das Löschen und das Sortieren mit den Pfeil-Buttons folgende weitere Elemente:
- Feld „Attribut“
Mit dem Feld „Attribut“ und dem zugehörigen Filter-Button können Sie die Menge der anzuzeigenden Attribute in der Liste steuern. Erfassen Sie dazu den Namen eines Attributs im Feld und nutzen Sie Platzhalter bei Bedarf.
Der Filter wird angewendet, wenn Sie den Button „Filter anwenden/entfernen“ aktivieren. Dafür können Sie auch die Eingabetaste drücken. Wenn der Filter angewendet wird, dann werden in der Liste nur solche Attribute angezeigt, die dem eingegebenen Filtermerkmal entsprechen. Sie entfernen den Filter, indem Sie den Button „Filter anwenden/entfernen“ deaktivieren.
- Button „Attributpfade“
Mithilfe des Detail-Buttons „Attributpfade“ wird eine weitere Überschriftenzeile eingeblendet. Sie erhalten Informationen über die Attributstruktur und die darin vorhandenen Attribute.
Die Spalten im Einzelnen:
| Spalte | Erläuterung |
| Attributpfad | Anzeige des Attributnamens im Attributpfad aus dem komplexen Logischen Datentyp. |
| Logischer Datentyp | Anzeige des verwendeten Logischen Datentyps. |
| Primitiver Datentyp | Anzeige des Datentyps des Attributs. |
- Button „Basisobjekt“
Siehe dieses Kapitel: Buttons „Basisobjekt“ und „Extension“
- Button „Extensions“
Siehe dieses Kapitel: Buttons „Basisobjekt“ und „Extension“
- Button „OQL-Anweisung“
Mithilfe dieses Buttons wird die Anwendung „OQL-Anweisungen“ mit einer OQL-Anweisung für das Business Object geöffnet.
Ist kein Attribut in der Tabelle markiert, dann werden alle Attribute in die OQL-Anweisung aufgenommen. Wenn einzelne Attribute markiert werden, dann werden nur diese in die OQL-Anweisung aufgenommen. Nur die Attribute sollten markiert werden, die für die Abfrage interessant sind, ansonsten ist das Ergebnis der OQL-Abfrage nicht überschaubar (Anzeige von zu vielen Spalten).
- Button „Diagramme“
Mithilfe dieses Buttons wird die Anwendung „Datenmodell-Diagramme“ im Kontext des Business Objects geöffnet und darin zum Business Object bestehende Datenmodell-Diagramme zur Auswahl angeboten, wenn diese bereits bestehen.
NLS-Attribute
Eine Besonderheit stellen die mehrsprachigen Attribute (National Language Support, NLS) dar. Diese enthalten in separaten Business Objects die Übersetzungen der Attribute. Diese Business Objects werden bei der Generierung des übergelagerten Business Objects automatisch erzeugt. Für jedes übersetzbare Attribut wird ein weiteres Business Object im NLS-Namensraum erzeugt.
Weitere Informationen finden Sie in der Dokumentation „Datenbankänderungen“.
2.2 Unterer Karteireiter „Indizes“
Der Index stellt die Zugriffsstruktur auf eine Business-Object-Instanz dar. Die Identifikation erfolgt über bestimmte Attribute. Ein Business Object besitzt einen primären Index und einen ausgezeichneten optionalen Sekundärindex. Jeder identifiziert eine Business-Object-Instanz eindeutig. Ein Index in Comarch ERP Enterprise entspricht dem Index auf der Datenbank.
Hinweis:
Mit SQL erzeugte Indizes werden bei einer Datenmodelländerung wieder gelöscht.
Die Karteikarte „Indizes“ enthält eine Liste, in der Sie die Indizes erfassen.
Listen-Spalten
Die Spalten im Einzelnen:
| Spalte | Erläuterung |
| Typ | In dieser Spalte legen Sie den Indextyp fest. Wählen Sie zwischen folgenden Einträgen:
· Primärschlüssel Mit diesem Eintrag legen Sie den eindeutigen Primärindex fest. In der Regel besteht dieser nur aus einem Attribut, das auf einem primitiven Logischen Datentyp „GUID“ basiert. Jedes Business Object muss genau einen Index dieses Typs haben. Für neue Business Objects wird dieser automatisch vorgeschlagen. · Business Key Mit diesem Eintrag legen Sie eine lesbare eindeutige fachliche Identifikation fest. Dieser Index dient in den fachlichen Anwendungen der Identifikation einer Business-Object-Instanz. Dieser Indextyp kann nur einmal pro Entwicklungsobjekt festgelegt werden. · Sekundärschlüssel Zusätzlicher Index, der auf einer eindeutigen Identifikation basiert. Dieser Typ kann für ein Business Object mehrfach erfasst werden. · Non unique index Zusätzlicher Index auf einem beliebigen Attribut. Dieser Typ kann für ein Business Object mehrfach erfasst werden. |
| Index | Der Primärindex besitzt den festen Namen „Primary“ und kann nicht geändert werden.
Der Name eines Sekundärindexes sollte mit dem Präfix „By“ beginnen und mit dem Namen des Attributs enden, auf den sich der Index bezieht. Der Name darf maximal 80 Zeichen lang sein. |
| Kommentar | Erfassen Sie bei Bedarf einen Kommentar zum Index. Der Text darf maximal 1000 Zeichen lang sein. Der Text ist nicht übersetzbar. |
Listen-Symbolleiste
In der Listen-Symbolleiste finden Sie neben den allgemeinen Buttons für eine neue Zeile und für das Löschen folgende weitere Elemente:
- Button „Attribut dem Index hinzufügen“
Mithilfe dieses Buttons fügen Sie dem zuvor markierten Index ein weiteres Indexattribut hinzu. Wenn der Index durch eine Beziehung verwendet wird, dann kann dieser nicht geändert werden.
Hinweis:
Beachten Sie bitte, dass ein Indexattribut zu den Details gehört. Drücken Sie bei Bedarf auf den Button „Details“, um diese einzublenden und die hinzugefügte Zeile zu sehen.
- Button „Nach oben“
Mithilfe dieses Buttons verschieben Sie innerhalb eines Indexes ein markiertes Indexattribut um eine Zeile nach oben und können somit die Indexattribute sortieren. Die Indexattribute können nur einzeln verschoben werden (keine Mehrfachauswahl).
- Button „Nach unten“
Mithilfe dieses Buttons verschieben Sie innerhalb eines Indexes ein markiertes Indexattribut um eine Zeile nach unten und können somit die Indexattribute sortieren. Die Indexattribute können nur einzeln verschoben werden (keine Mehrfachauswahl).
- Button „Details“
Mithilfe des Buttons „Details“ steuern Sie die Anzeige einer weiteren Überschriftenzeile für Indexattribute. Blenden Sie diese Überschriftenzeile ein, wenn Sie Indexattribute erfassen möchten.
Die Spalten im Einzelnen:
| Spalte | Erläuterung |
| Attribut | In dieser Spalte wählen Sie ein Indexattribut zum Index. Zu einem Index können mehrere Indexattribute erfasst werden.
Die Auswahl der Indexattribute erfolgt über die Wertehilfe. Diese zeigt die für den Index gültigen Attribute an. Komplexe und mehrsprachige Attribute sowie Arrays können nicht als Indexattribute verwendet werden. |
| Datentyp | Anzeige des Datentyps des Indexattributs. |
- Button „Extensions“
Siehe dieses Kapitel: Buttons „Basisobjekt“ und „Extension“
2.3 Unterer Karteireiter „Beziehungen“
Beziehungen stellen die fachliche Verbindung zweier Business Objects dar. Diese sind immer unidirektional, führen also nur von der Quelle zum Ziel. Werden beide Richtungen benötigt, dann muss eine weitere Beziehung erfasst werden. Eine Beziehung kann die Kardinalität „1 zu 1“ oder „1 zu n“ haben.
Eine „1 zu 1“-Beziehung zwischen zwei Business Objects ordnet einer Instanz des ersten Business Objects genau eine Instanz des zweiten Business Objects zu. Die Eindeutigkeit der Beziehung wird gewährleistet, indem die Ziel-Attribute einem eindeutigen Index zugeordnet sind. Die referenzielle Integrität wird nicht geprüft. Alle Felder des Indexes müssen in der Beziehung enthalten sein.
Eine „1 zu n“-Beziehung zwischen zwei Business Objects ordnet eine Instanz des ersten Business Objects mehrere Instanzen des zweiten Business Objects zu. Auch in diesem Fall wird die referenzielle Integrität nicht geprüft.
Beim Löschen von Business-Object-Instanzen eines Business Entitys werden die referenzierten Daten in den Abhängigkeiten nicht automatisch gelöscht. Das muss explizit erfolgen.
Die Karteikarte „Beziehungen“ enthält eine Liste, in der Sie die Beziehungen erfassen.
Listen-Spalten
Die Spalten im Einzelnen:
| Spalte | Erläuterung |
| Beziehung | In dieser Spalte erfassen Sie den Namen als Identifikation der Beziehung. Der Name darf maximal 80 Zeichen lang sein. |
| Ziel-Objekt | In dieser Spalte legen Sie das Ziel-Objekt fest, auf das die Beziehung zeigt. Erfassen Sie dazu den vollqualifizierten Entwicklungsobjektnamen.
Das Business Object wird im Verwendungsnachweis des Ziel-Objekts aufgenommen. |
| Kardinalität | · In dieser Spalte legen Sie die Kardinalität und damit die Art der Beziehung fest. Drücken Sie dazu in der Spalte auf die Zelle in der Zeile der Beziehung. Dadurch wechselt die Kardinalität zwischen folgenden Bedeutungen:
· „1-1“-Beziehung zwischen den Business Objects Wenn Sie die „1-1“ wählen, dann können Sie in der Spalte „Ziel-Objektindex“ den Index auswählen. Die zugehörigen Indexattribute werden daraufhin automatisch als Ziel-Attribute hinzugefügt. · „1-n“-Beziehung zwischen den Business Objects |
| Ziel-Objektindex | Ist für die Beziehung die Kardinalität „1-1“ festgelegt, dann können Sie in dieser Spalte einen Index des Ziel-Objektes auswählen. Nach der Auswahl eines entsprechenden Indexes werden automatisch die Indexattribute als Ziel-Attribute hinzugefügt. |
| Kommentar | Erfassen Sie bei Bedarf einen Kommentar zur Beziehung. Der Text darf maximal 1000 Zeichen lang sein. Der Text ist nicht übersetzbar. |
Listen-Symbolleiste
In der Listen-Symbolleiste finden Sie neben den allgemeinen Buttons für eine neue Zeile und für das Löschen folgende weitere Elemente:
- Button „Attribut der Beziehung hinzufügen“
Mithilfe dieses Buttons fügen Sie der zuvor markierten Beziehung ein weiteres Quell- und Ziel-Attribut hinzu.
Hinweis:
Beachten Sie bitte, dass ein Indexattribut zu den Zuordnungsdetails gehört. Drücken Sie bei Bedarf auf den Button „Zuordnung“, um diese einzublenden und die hinzugefügte Zeile zu sehen.
- Button „Zuordnung“
Mithilfe des Buttons „Zuordnung“ steuern Sie die Anzeige einer weiteren Überschriftenzeile für Indexattribute. Blenden Sie diese Überschriftenzeile ein, wenn Sie Indexattribute erfassen möchten. Jede Zeile, bestehend aus den Daten „Quell-Attribut“ und „Ziel-Attribut“, bildet eine Zuordnung zwischen einem Attribut aus dem Quell-Business-Object und einem Attribut aus dem Ziel-Business-Object.
Die Spalten im Einzelnen:
| Spalte | Erläuterung |
| Quell-Attribut | In dieser Spalte wählen Sie aus den verfügbaren Attributen das Quell-Attribut aus, das Sie einem Ziel-Attribut zuordnen möchten. |
| Ziel-Attribut | In dieser Spalte wählen Sie aus den verfügbaren Attributen des Ziel-Objektes das Ziel-Attribut aus, das Sie dem Quell-Attribut zuordnen möchten. Das Quell-Attribut wird im Verwendungsnachweis des Ziel-Objekts aufgenommen. |
- Button „Basisobjekt“
Siehe dieses Kapitel: Buttons „Basisobjekt“ und „Extension“
- Button „Extensions“
Siehe dieses Kapitel: Buttons „Basisobjekt“ und „Extension“
2.4 Unterer Karteireiter „Einstellungen“
Die Karteikarte „Einstellungen“ enthält Rubriken, die in folgenden Kapiteln beschrieben sind:
- Rubrik „Datenbank- und Cache-Einstellungen“
- Rubrik „Sonstige Einstellungen“
Rubrik „Datenbank- und Cache-Einstellungen“
In der Rubrik „Datenbank- und Cache-Einstellungen“ stellen Sie Folgendes ein:
| Datenbank | Erläuterung |
| OLTP-Datenbank
(Checkbox) |
Wenn Sie diese Funktion aktivieren, dann legen Sie damit fest, dass sich das Entwicklungsobjekt auf der OLTP-Datenbank befindet. In dieser Datenbank werden Stamm- und Bewegungsdaten für betriebswirtschaftliche Anwendungen geführt. Das Erfassen ist in jedem System möglich. |
| OLAP-Datenbank
(Checkbox) |
Wenn Sie diese Funktion aktivieren, dann legen Sie damit fest, dass sich das Entwicklungsobjekt auf der OLAP-Datenbank befindet. Diese Datenbank dient der Analyse betriebswirtschaftlicher Daten. Das Erfassen ist in jedem System möglich. |
| Repository-Datenbank
(Checkbox) |
Wenn Sie diese Funktion aktivieren, dann legen Sie damit fest, dass sich das Entwicklungsobjekt auf der Repository-Datenbank befindet. In der Repository-Datenbank sind alle Entwicklungsobjekte hinterlegt (System– und Archivtabellen). Auch die Softwarelogistik wird in dieser Datenbank geführt. Das Erfassen ist in jedem System möglich. |
| Konfigurations-Datenbank
(Checkbox) |
Wenn Sie diese Funktion aktivieren, dann legen Sie damit fest, dass sich das Entwicklungsobjekt auf der Konfigurations-Datenbank befindet. In der Konfigurations-Datenbank werden Informationen über die Comarch-ERP-Enterprise-Systemkonfiguration abgelegt. In dieser Datenbank dürfen Objekte nur durch die Comarch-ERP-Enterprise-Standardentwicklung erfasst werden. |
Neben der Festlegung der Datenbank bestimmen Sie auch die Cache-Strategie, separat pro Datenbank:
| Feld | Erläuterung |
| Strategie
(pro Datenbank einstellbar) |
In diesem Feld legen Sie die Cache-Strategie für die Entwicklungsobjekte in der jeweiligen Datenbank fest.
Wählen Sie aus folgenden Einträgen: · LRU (least recently used) Die Objekte werden im „Shared Cache“ mit der LRU-Strategie geführt. Mit der LRU-Strategie wird zuerst das am längsten nicht mehr benutzte Business Object ersetzt. Abhängig von der Datenart und der Datenbank, werden die LRU-Listen in unterschiedlichen Cache-Partitionen mit beschränkter Größe geführt. · Alle Instanzen beim ersten Zugriff öffnen Beim ersten Zugriff auf ein Objekt dieses Typs werden alle Objekte von der Datenbank in den Shared Cache geladen. Durch diesen Zugriff bekommt der Shared Cache die Information, welche Objekte „nicht“ existieren und kann diese Anfragen ohne Datenbank-Zugriff beantworten. · Keine Der Shared Cache wird beim Lesen nicht benutzt. Wenn sich das Objekt nicht im „Transaction Cache“ befindet, wird immer direkt von der Datenbank gelesen. |
Rubrik „Sonstige Einstellungen“
In der Rubrik „Sonstige Einstellungen“ stellen Sie Folgendes ein:
| Feld | Erläuterung |
| Business-Entity-Gruppe | Anzeige der Business-Entity-Gruppe, der das Business Object zugeordnet ist. |
| Java-Klasse | Erfassen Sie in diesem Feld die Java-Klasse, die vom aktiven Mapper erbt. Dadurch ist möglich, das Verhalten des Mappers zu ändern, indem die Methoden überschrieben werden. Die Methoden des Mappers sollten niemals geändert werden, da diese Änderungen bei der nächsten Generierung verloren gehen.
Das Business Object wird im Verwendungsnachweis der Java-Klasse aufgenommen. |
| Schnittstelle | Durch die Schnittstellendefinition ist möglich, dass Business Objects, in denen bestimmte Attribute identisch sind, dieselbe Schnittstelle implementieren. Die angegebene Schnittstelle wird automatisch in den generierten Mapper eingebunden.
Das Business Object wird im Verwendungsnachweis der Java-Klasse aufgenommen. Beispiel: Interface com.cisag.app.sales.pricing.log.Calculable implementiert von com.cisag.app.sales.obj.CustomerInvoiceDetail, com.cisag.app.sales.obj.ConfirmationDetail genutzt in com.cisag.app.sales.pricing.log.Calculation genutzt von com.cisag.app.sales.invoicing.log.DefaultUpdate (Rechnungsgenerierung), com.cisag.app.sales.confirmation.log.ConfirmationEntity (Auftragsbestätigung) |
| Datenart | – Damit der Shared Cache geeignet gefüllt werden kann, legen Sie in diesem Feld die Änderungsfrequenz der Daten für das Business Object fest.
Wählen Sie zwischen folgenden Einträgen: · Stammdaten Die Daten ändern sich kaum. Die Größe ist auf verschiedenen Systemen unterschiedlich. Beispiele: – Artikel-Stammdaten – Partner-Stammdaten · Konfigurations-Stammdaten Die Daten ändern sich kaum. Die Größe ist begrenzt und auf verschiedenen Systemen ähnlich. Beispiele: – Hauswährungskombinationen – Belegdokument-Vorlagen · Bewegungsdaten Die Daten ändern sich oft. Das Datenvolumen wächst sehr schnell. Beispiele: – Vertriebsaufträge – Materialbuchungen · Temporäre Daten Die Daten ändern sich oft. Das Datenvolumen variiert. Die Daten existieren nur kurze Zeit. Beispiel: Hilfs-Business-Objects für temporäre Daten · Individuelle Oberflächentexte (Anzeigesprache) Die Daten ändern sich kaum und betreffen Oberflächentexte und deren Anzeigesprache. Übersetzbare Texte können in allen Anzeigesprachen des Systems erfasst werden. Das sind z. B. Partner-Beziehungstypen, für die standardmäßig OLTP-Inhalte ausgeliefert werden und zu denen ein „National Language Support“ benötigt wird. Weitere Beispiele: – Kommunikationsarten – benutzerdefinierte Felder, deren Feldbezeichnungen individuell festlegbar sind |
| Erwartete Datengröße | Legen Sie fest, welche Datenmenge Sie für das Business Object erwarten. Diese Angabe ist eine subjektive Einschätzung.
Wählen Sie zwischen folgenden Einträgen: · Small z. B. Auftragsarten, Länder, Währungen · Medium z. B. Ausgabeeinstellungen im Vertrieb · Large z. B. Partner, Artikel · Extra Large z. B. Aufträge, Auftragspositionen · Extra Extra Large z. B. Buchungen |
| Zeitabhängig | Bei der Generierung des Business Objects werden zwei Attribute hinzugefügt (validFrom und validUntil). Durch diese Attribute ist möglich, auf dem aktuell gültigen Datensätzen zu arbeiten. In diesem Feld legen Sie fest, wie und damit zu welchem Zeitpunkt diese Attributdaten berechnet werden.
Wählen Sie zwischen folgenden Einträgen: · Immer neuen Datensatz einfügen Jede Änderung am Business Object erzeugt eine neue Version (Attribute validFrom und validUntil werden vom Persistenzdienst berechnet). · Immer aktuellen Datensatz schreiben Die Anwendung oder Logik, die das Business Object verwendet, bestimmt, ob eine neue Version erzeugt wird (Attribut validFrom wird vom Persistenzdienst berechnet). · Gesteuert durch Anwendung Die Anwendung oder Logik, die das Business Object verwendet, übernimmt die vollständige Versionsführung. · Datum mit Zeitzone durch Anwendung Die Anwendung oder Logik, die das Business Object verwendet, bestimmt, ob eine neue Version erzeugt wird (Attribut validFrom wird vom Persistenzdienst berechnet). Die Attribute validFrom und validUntil müssen gültige Datumsangaben enthalten und im Attribut _timstamp wird die zugehörige Zeitzone gespeichert. · Zeitpunkt mit Zeitzone durch Anwendung Die Anwendung oder Logik, die das Business Object verwendet, bestimmt, ob eine neue Version erzeugt wird (Attribut validFrom wird vom Persistenzdienst berechnet). Die Attribute validFrom und validUntil müssen gültige Zeitpunkte enthalten und im Attribut _timstamp wird die zugehörige Zeitzone gespeichert. · Keine Weitere Informationen finden Sie in dieser Dokumentation: Persistenzdienst |
| Benutzer und Zeitpunkt protokollieren
(Checkbox) |
Mithilfe dieser Funktion legen Sie fest, ob das System automatisch den Änderer (Benutzer) und den Änderungszeitpunkt protokollieren soll, wenn das Entwicklungsobjekt geändert wird.
Ist die Funktion aktiv, dann wird das Attribut „updateInfo“ eingefügt. In diesem komplexen Attribut werden Erfassungsdatum, Änderungsdatum und Löschdatum (mit dem zugehörigen Benutzer) automatisch über den Persistenzdienst geschrieben. |
3 Anwendungsbezogene Aktion: Dependent oder Supplement erzeugen…
Mithilfe der Aktion „Dependent oder Supplement erzeugen…“ unter dem Menü-Button „Zusätzliche Objekte erzeugen“ in der Standard-Symbolleiste können Sie eines der Entwicklungsobjekte „Dependent“ oder „Supplement“ weitestgehend automatisiert zum geöffneten Business Object erzeugen lassen. Drücken Sie auf diese Aktion, dann öffnet sich ein Dialogfenster, in dem Sie zunächst den Typ wählen, der erzeugt werden soll. Entsprechend werden Ihnen dazu benötigte Daten vorgeschlagen.
Weitere Informationen zu Supplements finden Sie in dieser Dokumentation: Referenzhandbuch: Supplements
Hinweis:
Diese Aktion ist ausschließich für den Entwicklungstyp „Business Object“ verfügbar. Die Beschreibung weiterer anwendungsbezogener Aktionen finden Sie in dieser Dokumentation: Entwicklungsobjekte
Dialogfenster „Dependent oder Supplement erzeugen““
Die Felder im Einzelnen:
| Feld | Erläuterung |
| Typ | In diesem Feld legen Sie den Typ des abhängigen Business Objects fest, der erzeugt werden soll. Entsprechend werden Ihnen die weiteren Daten vorgeschlagen.
Wählen zwischen folgenden Einträgen: · Dependent Die Dependents zu einem Business Entity besitzen eine speziell ausgewiesene Beziehung mit dem Namen „_entity“ und der Kardinalität „1 zu 1“. Spezielle Methoden erlauben das Öffnen aller Dependents zu einem Business Entity. · Supplement Supplements sind Business Objects, die automatisch vom zugehörigen Business Entity mitgeführt werden. Die Supplements zu einem Business Entity besitzen eine speziell ausgewiesene Beziehung mit dem Namen „_businessObject“ und der Kardinalität „1 zu 1“. Sie dienen demselben Zweck wie eine Extension, ohne die Tabelle des Business Entitys zu erweitern. |
| Name | · In diesem Feld wird Ihnen in Abhängigkeit des gewählen Typs der vollqualifizierte Name des zu erzeugenden Entwicklungsobjektes vorgeschlagen. Der Vorschlag besteht aus dem vollqualifizierten Namen des geöffneten Business Objects und einem der folgenden Zusätze:
· Supplement · Dependent |
| Bezeichnung | In diesem Feld wird Ihnen in Abhängigkeit des gewählen Typs die Bezeichnung des zu erzeugenden Entwicklungsobjektes vorgeschlagen. Der Vorschlag besteht aus der Bezeichnung des geöffneten Business Objects und einem der folgenden Zusätze:
· Supplement · Dependent Die Bezeichnung dient als zusätzliches Erkennungsmerkmal. Sie kann aus frei wählbarem Text bestehen und darf maximal 80 Zeichen umfassen. Erfassen Sie eine aussagekräftige und möglichst eindeutige Bezeichnung, damit die Suche danach erleichtert wird. Hinweis: Bitte beachten Sie bei der Verwendung von Sonderzeichen, dass diese in einer zu suchenden Zeichenkette aus technischen Gründen in folgende Platzhalter umgewandelt werden: · Stern (*) zu Unterstrich (_) · Fragezeichen (?) zu Prozentzeichen (%) Die Verwendung eines Unterstriches in einem Suchmerkmal würde nicht nur nach dem Unterstrich, sondern nach einem beliebigen Zeichen suchen. Gleichermaßen wird das Prozentzeichen ausgewertet, welches dann keinem, einem oder mehreren Zeichen entspricht. Die Verwendung von Unterstrichen und Prozentzeichen in Zeichenketten sollte deshalb möglichst vermieden werden, da möglicherweise andere und mehr Objekte gefunden werden als beabsichtigt. |
| Schnittstelle | Durch die Schnittstellendefinition ist möglich, dass Business Objects, in denen bestimmte Attribute identisch sind, dieselbe Schnittstelle implementieren. Die angegebene Schnittstelle wird automatisch in den generierten Mapper eingebunden.
Das Business Object wird im Verwendungsnachweis der Java-Klasse aufgenommen. |
Beispiel: Business Object und Dependent
Im folgenden Beispiel werden mithilfe zweier Business Objects die Daten zu Ländern und Regionen gespeichert. Über die festgelegten Beziehungen sind einem Land mehrere Regionen zugeordnet. Eine Region ist genau einem Land zugewiesen.
Attribute
Country:guid Primärschlüssel
Country:isoCode Länderkürzel (z. B.: DE, GB)
Country:description Beschreibung (z. B.: Deutschland, Großbritannien)
Country:language Sprache (z. B.: de, en)
Region:guid Primärschlüssel
Region:code Regionkürzel (z. B.: NS, BA)
Region:description Beschreibung (z. B.: Niedersachsen, Bayern)
Region:country GUID des zugehörigen Landes
Indizes
Business Entity „Country“
Primary Key: guid
Business Key: isoCode
Dependent „Region“
Primary Key: guid
Business Key: code, country
Beziehungen
Business Entity „Country“
Name: Regions (frei wählbar)
Ziel-Objekt: Dependent Region
Ziel-Attribut: Region:country
Quell-Attribut: Country:guid
Kardinalität: 1-n
Dependent „Region“
Name: _entity (vorgegeben)
Ziel-Objekt: Business Entity Country
Ziel-Attribut: Country:guid
Quell-Attribut: Region:country
Kardinalität: 1-1
Ziel-Objektindex: Primary
Beispiel: Business Object und Supplement
Im folgenden Beispiel werden mithilfe zweier Business Objects die Daten zu Ländern und deren Hauptstadt gespeichert. Eine Hauptstadt ist genau einem Land zugewiesen.
Attribute
Country:guid Primärschlüssel
Country:isoCode Länderkürzel (z. B.: DE, GB)
Country:description Beschreibung (z. B.: Deutschland, Großbritannien)
Country:language Sprache (z. B.: de, en)
ExtCountry:guid Primärschlüssel
ExtCountry:capital Hauptstadtname (z. B. Berlin)
Indizes
Supplement „ExtCountry”
Primary Key: guid (vorgegeben, wie Business Entity)
Business Key: nicht erlaubt
Beziehungen
Supplement „ExtCountry”
Name: _businessObject (vorgegeben)
Ziel-Objekt: Business Entity „Country”
Ziel-Attribute: Country:guid
Quell-Attribut: ExtCountry:guid
Kardinalität: 1-1
Ziel-Objektindex: Primary