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.

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:

• 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:

• [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.

Unterer Karteireiter Attribute

Der Karteireiter Attribute enthält eine Liste, in der Sie die Attribute erfassen.

Listen-Spalten

Die Spalten im Einzelnen:

• 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:
• 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.

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är­index. Jeder identifiziert eine Business-Object-Instanz eindeutig. Ein Index in Comarch ERP Enterprise entspricht dem Index auf der Datenbank.

Der Karteireiter Indizes enthält eine Liste, in der Sie die Indizes erfassen.

Listen-Spalten

Die Spalten im Einzelnen:

• 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:
  • 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.

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.

Der Karteireiter Beziehungen enthält eine Liste, in der Sie die Beziehungen erfassen.

Listen-Spalten

Die Spalten im Einzelnen:

• 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:
  • 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.

Unterer Karteireiter Einstellungen

Der Karteireiter 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:

• 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:

• 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:

• 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.
    
    Beispiel

    • Artikel-Stammdaten
    • Partner-Stammdaten

  • Konfigurations-Stammdaten – Die Daten ändern sich kaum. Die Größe ist begrenzt und auf verschiedenen Systemen ähnlich.
    Beispiel

    • Hauswährungskombinationen
    • Belegdokument-Vorlagen

  • Bewegungsdaten – Die Daten ändern sich oft. Das Datenvolumen wächst sehr schnell.
    Beispiel

    • 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.
    Beispiel

    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 (validFromund 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 validFromwird 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 _timstampwird 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 updateInfoeingefügt. In diesem komplexen Attribut werden Erfassungsdatum, Änderungsdatum und Löschdatum (mit dem zugehörigen Benutzer) automatisch über den Persistenzdienst geschrieben.

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.

Dialogfenster Dependent oder Supplement erzeugen

Die Felder im Einzelnen:

• 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ählten 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ählten 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