Für die Anwendungsentwicklung im ERP-System stehen das ERP-System-Development-Kit ( SDK) und das „Application Development Kit“ (ADK) zur Verfügung. Neben den entsprechenden Fachkenntnissen sind eine Java™ IDE mit Compiler, Editor und Debugger Voraussetzung. Als IDE wird Eclipse ab Version 3.7 empfohlen. Die IDE muss mindestens Java in der Version 7 als Entwicklungs-JDK unterstützen. Wie Sie eine Entwicklungsumgebung einrichten ist in folgender Dokumentation beschrieben: Entwicklungsumgebungen einrichten

Die Klassen sind in Packages organisiert, deren Aufteilung an die Frameworks des ERP-Systems angelehnt sind.

Die Development-Kits stellen weitere Werkzeuge zur Verfügung, die in das System integriert sind. Dazu gehören:

• Administrative Werkzeuge für die Abwicklung und Steuerung der Entwicklungsaufträge und -aufgaben
• Die Anwendung Entwicklungsobjekte zur Definition und Erweiterung von Entwicklungsobjekten wie Business Objects, QOL-Suchen, OQL-Views, Meldungen u. a.
• Werkzeuge für das Datenbank-Management (Anlage, Kopie und Verwaltung)
• Werkzeuge für den Daten-Import und -Export
• Werkzeuge für die Verwaltung von Softwareaktualisierungen

Um mit Comarch ERP Enterprise entwickeln zu können, muss der Entwickler wissen, was ein Entwicklungsauftrag, eine Entwicklungsaufgabe und ein Entwicklungsobjekt ist und wie diese drei zusammenhängen.

In einem Entwicklungsauftrag wird beschrieben, was durchgeführt werden soll. Das kann eine Neuentwicklung, aber auch eine Fehlerkorrektur sein.

Die Bearbeitung des Entwicklungsauftrags erfolgt in einer oder mehreren Entwicklungsaufgaben.

Entwicklungsobjekte sind die grundlegende Einheit bei der Anwendungsentwicklung. Entwicklungsobjekte sind Metadaten, die konkrete Größen klassifizieren und deren Eigenschaften beschreiben. Sie repäsentieren die fachlichen und technischen Größen im ERP-System. Es gibt verschiedene Typen von Entwicklungsobjekten. Entwicklungsobjekte werden grundsätzlich versioniert, d. h. nach Änderung eines Entwicklungsobjektes entsteht eine neue Version, alte Versionen werden archiviert.

In einer Entwicklungsaufgabe können mehrere Entwicklungsobjekte als Einheit bearbeitet werden.

3.1 Entwicklungsauftrag

Ein Entwicklungsauftrag unterstützt den Entwickler bei der Entwicklung im ERP-System. Der Auftrag dokumentiert den Fortschritt der Bearbeitung über den ganzen Bearbeitungszyklus.

In der Regel sind vier Benutzer an einem Entwicklungsauftrag beteiligt: ein Erfasser, ein Koordinator, ein Programmierer und ein Tester.

Ein Benutzer erfasst den Auftrag. Das kann z. B. ein Mitarbeiter aus dem Support sein. Bei der Erfassung wird festgelegt, wer sich um den Auftrag kümmert, also das weitere Vorgehen koordiniert. Der Koordinator bestimmt, wer als Programmierer den Auftrag bearbeitet und wer die beiden Tests durchführt.

Ein Entwicklungsauftrag hat immer einen aktuellen Bearbeiter. Der Bearbeiter wird aufgrund des Auftragsstatus bestimmt. In der folgenden Tabelle sind die möglichen Status und die daraus resultierenden Bearbeiter aufgelistet.

Status	Bearbeiter
Erfasst	Koordinator
Kategorisiert	Programmierer
In Bearbeitung	Programmierer
Implementiert	Tester
Im Ersttest	Tester
Ersttest erfolgt	Tester
Im Zweittest	Tester
Erledigt	Koordinator
Abgeschlossen	Koordinator
Erledigt ohne Änderung	Koordinator
Rücksprache	Ein beliebiger Partner
Zurückgestellt	Koordinator

 

Eine normale Bearbeitung durchläuft die Status Erfasst bis Abgeschlossen in der aufgeführten Reihenfolge.

Der Status „Erledigt ohne Änderung“ ist zu wählen, wenn der Auftrag nicht bearbeitet wurde bzw. keine Änderungen notwendig waren.

Werden weitere Informationen benötigt, so kann der Auftrag in den Status „Rücksprache“ versetzt werden. Hier kann ein beliebiger Benutzer eingetragen werden, der die gewünschten Informationen liefern soll.

Wird die Bearbeitung für einen längeren Zeitraum unterbrochen, kann der Auftrag in den Status „Zurückgestellt“ versetzt werden.

Alle Informationen, Arbeitschritte etc. lassen sich im Auftrag durch Texte und ggf. Anhänge dokumentieren. Die Texte sind typisiert sowie benutzer- und statusbezogen, d. h. der Tester kann z. B. im Status „Ersttest“ einen Text vom Typ „Bemerkung“ erstellen, der den durchgeführten Testablauf beschreibt.

Ein wichtiger Text ist der Softwareauslieferungstext. Dieser beschreibt, welches Problem mit diesem Auftrag behoben, bzw. welche Änderungen mit diesem Auftrag durchgeführt wurden. Dieser Text ist zu einem späteren Zeitpunkt ggf. öffentlich zugänglich und sollte entsprechend verfasst werden.

Ein Entwicklungsauftag erhält beim Erfassen, wie im ERP-System üblich, einen eindeutigen Schlüssel. Dieser besteht aus der Entwicklungsauftragsart, z. B. „SUP“, und einer  sechsstelligen Nummer. Die in Ihrem System verfügbaren Auftragsarten erfahren Sie bei Ihrem Administrator.

Ein Entwicklungsauftrag besitzt weiterhin folgende Merkmale: eine Priorität, eine Kategorie, eine Hierarchie und ein Release.

Mit der Priorität kann die Dringlichkeit der Bearbeitung festgelegt werden. Sie reicht von „Prioriät 1“ (sehr wichtig) bis „Priorität 9“ (nicht wichtig).

Mit der Kategorie wird festgelegt, welchen Bereich die Entwicklung betrifft. Folgende Kategorien sind vorhanden: Entwicklung (Neuanlage), Dokumentation, Korrektur (Bugfix), Information und Ergonomie.

Bei der Hierarchie kann die Zugehörigkeit des Auftrages zu einem fachlichen Gebiet eingetragen werden.

Mit dem Release wird eingestellt, in welchem Release die Bearbeitung erfolgen soll.

Zu einem Entwicklungsauftrag gibt es eine oder mehrere Entwicklungsaufgaben, in deren Rahmen die eigentliche Implementierung erfolgt.

Um Entwicklungsaufträge zu verwalten, muss der Entwicklungsauftragdienst für das Entwicklungssystem aktiviert sein.

3.2 Entwicklungsaufgabe

Die Bearbeitung von Entwicklungsobjekten kann nur im Rahmen einer Entwicklungsaufgabe durchgeführt werden. Die Entwicklungsaufgabe muss einem Entwicklungsauftrag zugeordent sein. Durch die Entwicklungsaufgabe werden Bearbeiter, Entwicklungsobjekte und Entwicklungsinhalte miteinander verknüpft.

Wird eine Entwicklungsaugabe erstellt, so erhält diese automatisch eine eindeutige Nummer. Die Aufgabe muss zwingend einem Entwicklungsauftrag zugeordnet werden. Der Auftrag muss zu diesem Zeitpunkt im Status „In Bearbeitung“ sein.

Bei einem System ohne Entwicklungsauftragsdienst kann im Entwicklungsauftrag ein beliebiger Text eingetragen werden.

Eine Entwicklungsaufgabe hat einen der folgenden Status:

• Offen
• In Freigabewarteschlange
• Wird gerade freigegeben
• Freigegeben
• Freigabe mit Warnungen fehlgeschlagen
• In Aktivierungswarteschlange
• Wird gerade aktiviert
• Aktiviert
• Aktiviert ohne Softwareaktualisierung

Wenn ein Entwicklungsobjekt einer Entwicklungsaufgabe hinzugefügt wird, wird das Objekt im System gesperrt. Diese Sperre wird globale Sperre genannt. Durch Setzen der globalen Sperre wird sichergestellt, das das Entwicklungsobjekt nicht parallel in einer anderen Entwicklungsaufgabe bearbeitet werden kann. Die globale Sperre wird beim Entfernen des Entwicklungsobjektes aus der Entwicklungsaufgabe oder bei Aktivierung der Entwicklungsaufgabe wieder entfernt.

Eine Entwicklungsaufgabe kann von mehreren Benutzern bearbeitet werden. Diese Benutzer müssen an der Entwicklungsaufgabe als Bearbeiter eingetragen werden. Wird ein Entwicklungsobjekt der Entwicklungsaufgabe bearbeitet, so wird dieses zusätzlich zur globalen Sperre lokal gesperrt. Dadurch wird verhindert, das mehrere Bearbeiter ein Entwicklungsobjekt gleichzeitig ändern. Der Bearbeiter muss das Entwicklungsobjekt am Ende der Bearbeitung explizit wieder freigeben. Mit der Freigabe wird die lokale Sperre entfernt.

Die Bearbeitung einer Entwicklungsaufgabe endet mit der Freigabe und Aktivierung der Aufgaben.

Das Ergebnis einer abgeschlossenen Entwicklungsaufgabe ist eine Softwareaktualisierung. Dabei werden im Normalfall die Ergebnisse der Entwicklungsaufgaben mit dem selben Entwicklungsauftrag in einer Softwareaktualisierung zusammengefasst. Entwicklungsaufgaben werden solange zusammengefasst, bis die erstellt Softwareaktualisierung freigegeben wurde. Nachfolgende Entwicklungsaufgaben mit gleichem Entwicklungsauftrag werden in einer neuen Softwareaktualisierung zusammengefasst. Die erstellte Softwareaktualisierung dient zum Transport der Änderungen in ein nachgelagertes Systemes, z. B. das Produktiv-System eines Kunden.

3.3 Prinzipieller Ablauf der Entwicklung

Bevor die Entwicklungsobjekttypen erklärt werden, soll an dieser Stelle kurz ein typischer Ablauf für eine Entwicklung dargestellt werden. Dabei wird auch auf einige Besonderheiten innerhalb der Anwendung „Entwicklungsaufgaben“ eingegangen.

1. Schritt: Entwicklungsauftrag erstellen und in Bearbeitung nehmen

Die Entwicklung beginnt mit der Erfassung eines Entwicklungsauftrages mithilfe der Anwendung „Entwicklungsaufträge“. Hierfür muss der Erfasser mindestens Bezeichnung, Release, Aufgabenbeschreibung und Koordinator erfassen.

Nach dem Speichern des Auftrags wird der Koordinator automatisch als Bearbeiter eingetragen. Der Auftrag ist nun im Status „Erfasst“.

Der Koordinator prüft nun den Entwicklungsauftrag und ergänzt bzw. korregiert die erforderlichen Daten wie Priorität, Kategorie, Hierarchie, Release und Bearbeitungsdauer. Für die weitere Bearbeitung müssen noch Programmierer und Tester eingetragen werden. Wenn erforderlich kann der Koordinator weitere Texte erfassen. Anschließend stellt er den Auftrag auf den Status „Kategorisiert“. Der Bearbeiter wechselt nun auf den Programmierer.

2. Schritt: Die Bearbeitung

Der Programmierer startet mit der Bearbeitung des Entwicklungsauftrages, indem er dessen Status auf „In Bearbeitung“ setzt. Er erstellt zu dem Entwicklungsauftrag eine Entwicklungsaufgabe mithilfe der Anwendung „Entwicklungsaufgaben“ im Framework „Software-Entwicklung“^[1].

Anschließend beginnt er mit der Bearbeitung bzw. Neuanlage der Entwicklungsobjekte in der Anwendung „Entwicklungsobjekte“. Dabei werden diese automatisch der Aufgabe hinzugefügt und global (während der Änderung zusätzlich lokal) gesperrt. Dabei erfolgt das sogenannte Auschecken. Über Tools (crtbo, crtvs, …) des SAS müssen, falls notwendig, die Sourcen zu den geänderten Entwicklungsobjekten neu generiert und die temporären Datenbank-Tabellen für die geänderten Business Objects angelegt werden. Die generierten Sourcen legt das System im Arbeitsverzeichnis der Aufgabe ab, Java-Klassen werden beim Hinzufügen zur Aufgabe ausgecheckt und ebenfalls an dieser Stelle zur Bearbeitung abgelegt. Nun erfolgt die eigentliche Programmierung.

Zu beachten ist, dass automatisch generierte Sourcen nicht verändert werden dürfen.

Wenn die Programm-Tests durch den Entwickler erfolgreich sind, schließt sich das Einspielen der Sourcen an. Dieser Vorgang wird Check-In genannt und wird über Buttons in der Standard-Symbolleiste der Anwendung „Entwicklungsaufgaben“ durchgeführt. Die generierten und programmmierten Sourcen werden dabei ins Repository übernommen und gegen den Klassenstand des Systems kompiliert. Sollten Fehler auftreten, muss das Check-In nach Behebung der Fehler wiederholt werden.

3. Schritt:Entwicklungsaufgabe freigeben

Als nächster Schritt wird die Entwicklungsaufgabe freigegeben. Damit endet die Möglichkeit der Bearbeitung der in der Aufgabe enthaltenen Entwicklungsobjekte. Wurden mit der Entwicklungsaufgabe Änderungen an Business Objects vorgenommen, so müssen mithilfe des Kommandozeilentools „actjob“ die vorgenommenen Schemaänderungen auf der Datenbank aktiviert werden. Das Aktivieren geschieht durch den Austausch der alten, noch aktiven gegen die neuen temporären Tabellen. Das System übernimmt die Daten aus den alten Tabellen automatisch in die neuen Tabellen. Sind Datenkonvertierungen oder spezielle Initalwerte für neu hinzugekommene Attribute notwendig, so muss der Entwickler die entsprechenden Update-Programme angepasst haben.

4. Schritt: Entwicklungsaufgabe aktivieren

Die Aktivierung der Entwicklungsaufgabe stellt den letzten Schritt der Bearbeitung dar. Alle von der Entwicklungsaufgabe gehaltenen globalen Sperren werden aufgehoben. Zur Entwicklungsaufgabe wird eine Softwareaktualisierung mit den Änderungen erstellt bzw. die Änderungen werden zu einer existierenden offenen Softwareaktualisierung von einer anderen aktivierten Aufgabe mit dem selben Entwicklungsauftrag hinzugefügt. Java-Sourcen, Java-Classes, Dateien, Icons und Online-Hilfe-Dateien ersetzen ältere Versionen im Dateisystem des ERP-System-Servers. Nach dem Neustart des Servers werden die neuen Class-Dateien verwendet. Wird kein Entwicklungsauftragsdienst verwendet, endet der Entwicklungsablauf mit diesem Schritt.

Die Implementierungsphase ist abgeschlossen, wenn alle zum Entwicklungsauftrag zugehörigen Entwicklungsaufgaben aktiviert wurden. Der Bearbeiter überführt den Entwicklungsauftrag in den Status „Implementiert“. Der Bearbeiter wechselt auf den Tester.

5. Schritt: Entwicklungsauftrag testen

Ein Entwicklungsauftrag wird in zwei Stufen getestet. Der Ersttest wird auf dem Entwicklungssystem durchgeführt. War dieser Test erfolgreich, wird die Softwareaktualisierung in das Testsystem eingespielt und auf diesem der Zweittest durchgeführt.

Wenn der Tester mit dem Test beginnt, muss der den Entwicklungsauftrag auf den Status „Im Ersttest“ umstellen. Der Tester überprüft, ob die Aufgabenstellung fehlerfrei umgesetzt wurde. Wurde die Aufgabenstellung nicht vollständig oder fehlerhaft umgesetzt, so muss der Programmierer den Entwicklungsauftrag nachbearbeiten. Der Status des Entwicklungsauftrags wechselt wieder auf „Kategorisiert“.

War der Ersttest erfolgreich, so wird der Entwicklungsauftrag auf den Status „Ersttest erfolgt“ umgestellt. Anschließend wird, wie bereits beschrieben, die Softwareaktualisierung in das Testsystem eingespielt. Nun beginnt der Zweittest. Der Tester stellt den Entwicklungsauftrag auf den Status „Im Zweittest“. Treten bei diesem Test Fehler auf, so muss der Programmierer den Auftrag nachbearbeiten.

Nach erfolgreichem Zweittest wird der Entwicklungsauftrag auf den Status „Erledigt“ umgestellt. Damit ist der Test beendet.

3.4 Entwicklungsobjekte

Die Entwicklung im ERP-System basiert auf einem Mix verschiedenster Objekte. Das können zum Beispiel Java-Klassen, Icons, logische Datentypen, ValueSets, Hilfeobjekte usw. sein. Alle in der Entwicklung verwendeten Objekte werden mit dem Oberbegriff Entwicklungsobjekt bezeichnet. Das ERP-System unterstützt einen fest vorgegebenen Satz unterschiedlicher Objekttypen. Diese werden als Entwicklungsobjekttypen bezeichnet. Jedes Entwicklungsobjekt hat einen Namen und einen Namensraum. Anhand der Kombination aus Namensraum und Namen kann ein Entwicklungsobjekt identifiziert werden. Ein Entwicklungsobjekt muss innerhalb seines Entwicklungsobjekttyps eindeutig sein. Das heißt, dass es z. B. keine Java-Klassen geben darf, die die gleiche Kombination aus Namensraum und Namen aufweisen. Andererseits ist es aber durchaus möglich, dass es einen logischen Datentypen und eine Java-Klasse mit der gleichen Kombination aus Namensraum und Namen gibt. Teilweise wird sogar darauf gebaut, dass es Entwicklungsobjekte unterschiedlichen Typs mit gleichem Namensraum und Namen gibt. Ein gutes Beispiel dafür sind Valuesets. Wird ein Valueset angelegt, so wird in der Regel auch eine gleichnamige Java-Klasse erzeugt.

Alle verwendeten Entwicklungsobjekte werden im Repository versioniert abgelegt.

Im Folgenden werden zuerst die Namensräume beschrieben. Danach werden die einzelnen Entwicklungsobjekttypen erklärt. Abschließend findet sich noch ein Kapitel über Versionierung.

Namensräume

Alle Entwicklungsobjekte des ERP-Systems sind in Namensräumen organisiert. Ein Namensraum besteht aus einem oder mehreren Wörtern, die durch einen Punkt voneinander getrennt sind, z. B. „com.cisag.app“ oder „com.cisag.pgm“. Namensräume sind hierarchisch in Form eines Baumes aufgebaut, dessen Wurzel der Namensraum „com“ einnimmt. Für den Namensraum „com.cisag.app.sales.ui“ sieht die Struktur der Namensräume wie folgt aus:

com

com.cisag

com.cisag.app

com.cisag.app.sales

com.cisag.app.sales.ui

Bei der Anlage eines Namensraum kann an diesem noch ein spezielles Verhalten festgelegt werden. Ein Namensraum kann entweder als Test-Namensraum oder als interner Namensraum gekennzeichnet werden. Ein Namensraum, der als Test-Namensraum gekennzeichnet ist kann nicht ausgeliefert werden. Das betrifft auch alle darin enthaltenen Entwicklungsobjekte. Bei einem Namensraum, der als interner Namensraum gekennzeichnet ist, kann bei der Entwicklungsaufgabe von Fall zu Fall entschieden werden, ob die Entwicklungsobjekte ausgeliefert werden.

Wird eines der beiden Kennzeichen für einen Namensraum gewählt, so kann dieses nachträglich nicht mehr geändert werden. Alle Namensräume, die innerhalb des Namensraumes angelegt werden, bekommen automatisch dieses Kennzeichen nicht änderbar gesetzt.

Für Objekte innerhalb der Namensräume gelten im Wesentlichen folgende Regeln:

• Alle Entwicklungsobjekte eines Typs müssen sich innerhalb eines Namensraumes, unabhängig von Groß- und Kleinschreibung, in ihrem Namen unterscheiden.
• Objekte aus zwei verschiedenen Namensräumen sind immer verschieden, auch wenn ihre Namen übereinstimmen.

Für das Entwicklungsobjekt „Java-Klasse“ entspricht der Namensraum auch dem Java-Paket-Namen.

Durch die Regeln für Namensräume wird verhindert, dass es zu Überschneidungen bei der Vergabe von Namen für Entwicklungsobjekte kommt. Entwicklungsobjekte der Standardentwicklung können deshalb neben den Entwicklungsobjekten der Partnerentwicklung ohne Namenskonflikte existieren.

Aufbau der Namensräume

Wie bereits beschrieben besteht ein Namensraum aus einem oder mehreren durch Punkte getrennten Wörtern und ist hierarchisch aufgebaut. Die Wörter können aus dem Buchstaben „a“-„z“ bestehen und müssen klein geschrieben sein.

Die Wurzel aller Namensräume im ERP-System bildet der Namensraum „com“.

Auf der nachfolgenden Ebene befindet sich das Entwicklungspräfix. Das 3-5 Zeichen umfassende Präfix wird mit der Vergabe der Lizenz festgelegt und kann nicht geändert werden. Das Entwicklungspräfix der Standardentwicklung lautet „cisag“.

Die nächste Ebene ist ebenfalls fest vorgegeben. Es handelt sich um die drei Namensräume:

Namensraum	Erläuterung
com.<präfix>.app	Alle Entwicklungsobjekte in und unterhalb dieses Namensraumeswerden für die betriebswirtschaftlichen Anwendungen verwendet.
com.<präfix>.dbu	Zu jedem Business Object finden sich hier für jede Version die generierten Java-Klassen und ein Updateprogramm. Im Updateprogramm wird definiert, wie die Daten verändert werden müssen, um zu der jeweils nachfolgenden Version zu gelangen.
com.<präfix>.nls	Unterhalb dieses Namensraumes befinden sich für die sprachspezifischen Attribute der Business Objecte spezielle, generierte Java-Klassen, die den Zugriff auf die Datenbank ermöglichen.

 

Die Namensraumstruktur unterhalb von com.<präfix>.app ist fachlich motiviert und orientiert sich an den im ERP-System definierten Frameworks. Weitere Abstufungen sind ebenfalls möglich.

Die unterste Ebene des Namensraum bildet in der Regel ein Verbund aus bis zu sechs Namensräumen:

com.<präfix>.app.<fachliche Abstufung>

com.<präfix>.app.<fachliche Abstufung>.obj

com.<präfix>.app.<fachliche Abstufung>.log

com.<präfix>.app.<fachliche Abstufung>.ui

com.<präfix>.app.<fachliche Abstufung>.gui

com.<präfix>.app.<fachliche Abstufung>.res2d

com.<präfix>.app.<fachliche Abstufung>.hook

com.<präfix>.app.<fachliche Abstufung>.model

com.<präfix>.app.<fachliche Abstufung>.rest

Jeder der Namensräume besitzt eine bestimmte Bedeutung. Die Entwicklungsobjekttypen, wie Sie in Kapitel „Entwicklungsobjekttypen“ auf Seite 25 beschrieben werden, werden nach bestimmten Regeln, bzw. Kriterien auf diese Namensräume verteilt. Dabei unterliegen einige Entwicklungsobjekttypen einer Konvention: Sie müssen in genau diesem Namensraum liegen. Dies trifft z. B. für Business Objects zu, die immer in einem Namensraum liegen müssen, der auf „.obj“ endet. Andere Typen werden eher nach Art der Verwendung den Namensräumen zugeordnet.

Besondere Namensräume der Standardentwicklung

Unterhalb des Namensraumes com.cisag befinden sich drei spezielle Namensräume.:

Namensraum	Erläuterung
com.cisag.pgm	In diesem Namensraum liegt das Application Programming Interface (API) gegen welches die Anwendungen im ERP-System programmiert werden. Es sind zumeist Wrapper-Klassen oder Interfaces, deren Implementierung durch Klassen im Namensraum com.cisag.sys erfolgt.
com.cisag.sys	Dieser Namensraum enthält die System-Engine, weitere Systemkomponenten und das Data-Dictionary.
com.cisag.archive	Dieser Namensraum enthält das Data-Dictionary, welches die Metadaten der Versionen aller Entwicklungsobjekte speichert.

 

3.5 Entwicklungsobjekttypen

Das ERP-System basiert auf einem festgelegten Satz von Entwicklungsobjekttypen. Jeder Entwicklungsobjekttyp hat eine spezielle Bedeutung und Verwendung. Im Folgenden sind einige Typen aufgelistet. Zu jedem der Typen finden Sie nähere Informationen im jeweiligen Unterkapitel.

• Action
• Anwendung
• Bericht
• Business-Entity-Gruppe
• Business Object
• Data-Description-LDT und Data-Description-Column
• Data-Description-LDT und Data-Description-Column
• Datei
• Ereignis
• Extension
• Framework
• Fähigkeit
• Funktion
• Hilfe-Objekt
• Icon
• Java-Klasse
• Lizenzschlüssel
• Logischer Datentyp
• Meldung
• Meldungsklasse
• Namensraum
• OQL-Suche
• OQL-View
• Part
• Stringtable
• Terminus
• Testlauf
• Text
• Valueset

Siehe auch die Dokumentation „Entwicklungsobjekte“, in der alle Entwicklungsobjekttypen beschrieben sind.

3.5.1 Action

Actions werden im ERP-System für die Oberflächenprogrammierung verwendet. Sie werden benötigt, um Buttons, Karteireiter, Menüs und Kontextmenüs aufzubauen.

Bei einer Action kann ein Label, ein Tooltip, eine Tastenkombination, ein kleines und ein großes Icon eingetragen werden.

Actions können von anderen Actions erben, d. h. es kann eine Action eingetragen werden, von der das Label, der Tooltip etc. übernommen wird. Welche der Attribute übernommen werden kann, über eine Auswahlliste pro Attribut entschieden werden. Zur Auswahl stehen „Aus Vererbung“ und „Benutzerdefiniert“.

Actions können nur in den Namensräumen, die auf „.gui“ oder „.ui“ enden, angelegt werden. Actions werden in anderen Actions für die Vererbung oder in Java-Klassen verwendet. Die Entscheidung, ob „.ui“ oder „.gui“ als Namensraum verwendet wird, sollte in Abhängigkeit zur Java-Klasse geschehen. Üblicherweise liegt die Action im gleichen Namensraum wie die verwendende Java-Klasse.

Der Name einer Action sollte so gewählt sein, dass an diesem schon eine Zugehörigkeit zu einer Anwendung, zu einem Dialog oder einer UI-Komponente erkennbar ist. Dies kann dadurch erreicht werden, dass der Name der Action mit dem Namen der Anwendung etc. beginnt.

Weiterhin sollte am Namen der Action erkannt werden können, ob diese für einen Button, einen ToggleButton, einen Karteireiter oder ein Popupmenü verwendet wird.

Nachfolgend werden die möglichen Verwendungen von Actions und die Muster für die Namensvergabe beschrieben.

3.5.1.1 Actions für Buttons

Das Muster für Actions, die für Buttons genutzt werden, ist:

<Klassenname><ActionName>[Button]

Der Klassenname ist der Name der Klassenname der Anwendung oder des Dialogs oder der Komponente. Das Suffix Button ist optional und wird nur zur Verdeutlichung hinzugenommen.

Beispiele:
Die Anwendung Lizenzen enthält einen Button zum Hinzufügen von Einträgen. Die Action wird unter folgendem Namensraum und Namen angelegt:

Namensraum: com.cisag.app.internal.ui

Name: LicenceDefinitionMaintenanceAddEntry

Alternativer Name: LicenceDefinitionMaintenanceAddEntryButton

3.5.1.2 Actions für ToogleButtons

Das Muster für Actions, die für ToogleButtons genutzt werden, ist:

<Klassenname>Toggle<ActionName>

Der Klassename ist der Name der Anwendung, des Dialogs oder der Komponente. Danach kommt das Wort „Toggle“gefolgt vom Namen der Action.

Beispiele:
ie Anwendung Lizenzen enthält einen ToggleButton zum Ein- und Ausblenden von Details in der Liste. Die Action wird unter folgendem Namensraum und Namen angelegt:

Namensraum: com.cisag.app.internal.ui

Name: LicenceDefinitionMaintenanceToogleDetails

Bei ToggleButtons ist im Tooltip auf beide Funktionen hinzuweisen (z. B. Navigationsbereich einblenden/ausblenden).

3.5.1.3 Actions für Karteireiter

Das Muster für Actions, die für Karteireiter genutzt werden, ist:

<Klassenname><ActionName>Tab

Der Klassename ist der Name der Anwendung, des Dialogs oder der Komponente. Danach kommt der Name der Action gefolgt von „Tab“.

Beispiele:
Die Anwendung Lizenzen enthält einen Karteireiter für Erweiterungen. Die Action wird unter folgendem Namensraum und Namen angelegt:

Namensraum: com.cisag.app.internal.ui

Name: LicenceDefinitionMaintenanceExtensionTab

3.5.1.4 Actions für Kontextmenüs

Das Muster für Actions, die für Kontextmenüs genutzt werden, ist:

<Klassenname>Popup<ActionName>

Der Klassename ist der Name der Anwendung oder des Dialogs oder der Komponente. Danach kommt das Wort „Popup“gefolgt vom Namen der Action.

Beispiele:
Die Anwendung Lizenzen enthält einen Karteireiter für Erweiterungen. Die Action wird unter folgendem Namensraum und Namen angelegt:

Namensraum: com.cisag.app.internal.ui

Name: LicenceDefinitionMaintenanceExtensionTab

3.5.1.5 Vorlagen

In com.cisag.pgm finden sich einige Actions, die bei gleicher Verwendung als Vorlage für eigene Actions genutzt werden sollten. Die Actions dürfen nicht direkt genutzt werden. Statt dessen können die eigenen Actions von diesen erben und dadurch Shortcuts, Icons etc. erhalten.

Für die Verwendung in der Standardsymbolleiste:

com.cisag.pgm.gui.coolbar.Execute

com.cisag.pgm.gui.coolbar.ExecuteList

com.cisag.pgm.gui.coolbar.ExecuteMenu

Für die Verwendung in Symbolleisten:

com.cisag.pgm.gui.coolbar.Add (“Neu”)

com.cisag.pgm.gui.coolbar.AddDuplicate (“Duplizieren”)

com.cisag.pgm.gui.coolbar.AddFromSearch (“Suchen und hinzufügen”)

com.cisag.pgm.gui.coolbar.Remove  (“Löschkennzeichen setzen/entfernen”)

com.cisag.pgm.gui.coolbar.ToggleDetails(“Details”)

com.cisag.pgm.gui.coolbar.FilterEntries (“Einträge filtern”)

com.cisag.pgm.gui.coolbar.Find (“Suchen”)

com.cisag.pgm.gui.coolbar.ShowDetailsDialog (“Eigenschaften”)

Für die Tastatursteuerung:

com.cisag.pgm.gui.Enter

3.5.2 Anwendung

Anwendungen werden im ERP-System für verschiedenste Aufgaben verwendet. Grundsätzlich wird zwischen Dialog-Anwendung, Hintergrund-Anwendung, Dialog-Datenaktualisierung, Automatischer Hintergrund-Datenaktualisierung, Manueller Hintergrund-Datenaktualisierung, Dienst, Reorganisation und Tool unterschieden.

3.5.2.1 Dialog-Anwendung

Dialog-Anwendungen sind die Anwendungen, mit denen der Benutzer im ERP-System normalerweise arbeitet. Dabei handelt es sich um Anwendungen wie z. B. die Vertriebsaufträge oder das Vertriebscockpit.

Dialog-Anwendungen müssen in einem Namensraum angelegt werden, der auf „.ui“ endet. Der Name einer Dialog-Anwendung unterliegt keinen Regeln. Folgende Hinweise sollten aber berücksichtigt werden. Normale Verwaltungsanwendungen enden auf „Maintenance“. Abfrageanwendungen und Cockpits enden auf „Inquiry“ oder „Cockpit“.

Eine Dialog-Anwendung benötigt eine Bezeichnung, welche im Navigator und in der Titelzeile angezeigt wird. Die Anwendung wird allerdings nur im Navigator eines Benutzters angezeigt, wenn die Anzeige- und Wartungseinstellung auf „Anzeige, Wartung“ steht, der Benutzer über die notwendigen Berechtigungen für die Anwendung verfügt und die Funktion, sofern angegeben, im Customizing eingeschaltet ist.

Wenn die Anwendung organisationstypspezifisch angezeigt werden soll, muss die Java-Klasse „com.cisag.app.multiorg.log.ApplicationRegistry“ anpasst werden.

Die Anwendung muss vom Typ „Dialog“ sein. Die Besondere Verwendung muss leer bleiben. Im Navigator wird die Anwendung, sofern sichtbar etc., in das anzugebende Framework eingeordnet. Die Java-Klasse beinhaltet das zu startende Programm bei Aufruf der Anwendung. Üblicherweise sind Namensraum und Name der Java-Klasse gleich dem Namensraum und Namen der Anwendung.

Soll die Anwendung im Kontextmenü eines Business Entitys angezeigt werden, so muss als minimale Voraussetzung eine Aktion „Load“ mit einem Parameter vom Typ Business Object erfasst werden. Als Business Objekt muss das gewünschte Business Entity eingetragen werden.

Eine der Anwendungen im Kontextmenü eines Business Entitys wird als Standardanwendung hervorgehoben. Die Ermittlung dieser Anwendung erfolgt nach bestimmten Regeln. Neben den beschriebenen minimalen Voraussetzungen für die Anzeige im Kontextmenü können weitere Angaben gemacht werden, die eine Anwendung „höher bewerten“.

Zum einen kann der Parametername der Aktion „Load“ dem Namen des Business Entitys entsprechen.

Beispiel:
Für das Business Entity com.cisag.app.general.obj.Partner kann der Parametername „Partner“ benutzt werden.

Zum andern kann ein primäres Business Entity eingetragen werden. Dieses muss dann dem Business Object des Parameters entsprechen.

Für die Ermittlung der bevorzugten Anwendung im Kontexmenü ergibt sich folgende aufsteigende Reihenfolge in der Gewichtung:

• Aktion
• Aktion und Parametername
• Aktion und primäres Business Entity
• Aktion, primäres Business Entity und Parametername

Sind mehrere Anwendungen auf der Ebene der höchsten Gewichtung vorhanden, so wird die Anwendung ausgewählt, die in alphabetischer Reihenfolge als erstes kommt.

Mithilfe der abstrakten Klasse „CisEntityMenuFilter“ kann die Anwendung programmtechnisch im Kontextmenü ausgeblendet werden. Dazu muss eine Java-Klasse erstellt werden, die von „CisEntityMenuFilter“ erbt und deren abstrakte Methode implementiert. Am „CisInitializer“ muss diese Java-Klasse registiert werden.

Als benötigte, aktive Datenbank wird für eine Dialog-Anwendung „OLTP-Datenbank“ und in seltenen Fällen „OLAP-Datenbank“ ausgewählt. „Repository-Datenbank“ und „Konfigurations-Datenbank“ werden bei Dialog-Anwendungen nur für die ERP-System-Systementwicklung benötigt.

3.5.2.2 Hintergrund-Anwendung

Hintergrund-Anwendungen werden entweder in den Verarbeitungsaufträgen benutzt oder aber über einen Batch Submit Dialog gestartet. Hintergrund-Anwendungen werden benutzt, um zeitaufwendige Aktionen und Verabeitungen im Hintergrund durchführen zu lassen. Für die Verarbeitung ist keine weitere Benutzerinteraktion notwendig und während der Verarbeitung kann der Benutzer seinen normalen Tätigkeiten im ERP-System nachgehen.

Hintergrund-Anwendungen müssen in einem Namensraum angelegt werden, der auf „.log“ oder „.print“ endet. Die Anwendung muss vom Typ „Hintergrund“ sein. Die Besondere Verwendung muss leer bleiben.

Die Java-Klasse beinhaltet das zu startende Programm bei Aufruf der Anwendung. Üblicherweise sind Namensraum und Name der Java-Klasse gleich dem Namensraum und Namen der Anwendung.

3.5.2.3 Dialog-Datenaktualisierung

Dialog-Datenaktualisierungen werden erstellt, wenn eine Datenaktualisierung benötigt wird, bei der der Benutzer zusätzliche Angaben machen muss. Die Datenaktualisierung kann aus der Anwendung Datenaktualisierungen abfragen gestartet werden. Die Direkthilfe der Anwendung wird angezeigt und ,wenn vorhanden, eine Eingabemaske, in der der Benutzer zusätzliche, von der Datenaktualisierung benötigte, Daten eingeben kann.

Dialog-Datenaktualisierungen müssen in einem Namensraum angelegt werden, der auf „.ui“ endet. Der Name einer Dialog-Anwendung unterliegt keinen Regeln. Oft wird der Name aber aus „UPD“ und dem Entwicklungauftrag zusammengesetzt, z. B. UPDSUP12345.

Die Anwendung muss vom Typ „Dialog“ sein. Die Besondere Verwendung muss auf „Datenaktualisierung“ eingestellt werden. Dialog-Datenaktualisierungen werden in der Regel dem Framework com.cisag.pgm.Update zugeordnet.

3.5.2.4 Automatische Hintergrund-Datenaktualisierung

Eine automatische Hintergrund-Datenaktualisierung wird bei der Installation der Softwareaktualisierung, die diese Datenaktualisierung enthält, ausgeführt. Diese Datenaktualisierung wird benötigt, wenn z. B. ein Business Object geändert wurde und die Datenbestände deshalb angepasst werden müssen.

Automatische Hintergrund-Datenaktualisierungen sollten im Namensraum com.<präfix>.app.update.log angelegt werden. Der Name einer Dialog-Anwendung unterliegt keinen Regeln. Oft wird der Name aber aus „UPD“ und dem Entwicklungauftrag zusammengesetzt, z. B. UPDSUP12345.

Die Anwendung muss vom Typ „Hintergrund“ sein. Die besondere Verwendung muss auf „Datenaktualisierung“ eingestellt werden. Datenaktualisierungen werden in der Regel dem Framework com.cisag.pgm.Update zugeordnet.

Üblicherweise sind Namensraum und Name der Java-Klasse gleich dem Namensraum und Namen der Anwendung. Die Java-Klasse zu einer Hintergund-Datenaktualisierung muss die abstrakte Klasse com.cisag.pgm.base.CisUpdateBatchApplication implementieren.

3.5.2.5 Manuelle Hintergrund-Datenaktualisierung

Eine manuelle Hintergrund-Datenaktualisierung unterscheidet sich von der automatischen dadurch, dass sie nicht während der Installation von Softwareaktualisierungen ausgeführt wird. Die manuelle Hintergrund-Datenaktualisierung kann zu einem beliebigen Zeitpunkt mit einem Verarbeitungsauftrag ausgeführt werden.

Die Anwendung muss vom Typ „Hintergrund“ sein. Die Besondere Verwendung muss auf „Datenaktualisierung im Hintergrund“ eingestellt werden.

3.5.2.6 Tool

Tools werden im ERP-System in der Toolshell über die Angabe der Java-Klasse aufgerufen. Die Java-Klasse muss dabei eine main-Methode enthalten.

Beispiel:

public class TestTool {

public static void main(String[] argv) {

….

}

}

Tools werden in einem Namensraum, der auf „.tools“ endet erfasst. Der Typ muss auf „Tool“ eingestellt werden. Die besondere Verwendung muss leer sein.

3.5.3 Bericht

Berichte dienen der Erstellung von Berichts- oder Belegdokumenten mithilfe des ERP-System-Output-Managers. Das Layout und die Parameter eines Berichtes werden mithilfe von Crystal Reports gestaltet.

Die fertigen Berichtsdateien können ins ERP-System importiert  und mit weiteren Daten ergänzt werden. Zu diesen Daten zählen beispielsweise Labels für Parameter und Textkonstanten im Bericht.

3.5.4 Business-Entity-Gruppe

Business-Entity-Gruppen werden für die Berechtigungsfestlegung verwendet.

3.5.5 Business Object

Ein Business Object ist die technische Definition zu einer fachlichen Größe, zu der konkrete Ausprägungen (Instanzen) in der Datenbank in einer eigenen Tabelle gespeichert werden. Ein Business Object (BO) stellt im Wesentlichen einen Datencontainer ohne fachliche Logik da. Es hat einen Namensraum und einen aussagekräftigen Namen. Die zu speichernden Daten werden durch eine oder mehrere Attributdefinitionen (kurz Attribute) beschrieben. Ein Business Object kann Attribute von einer Part-Definition erben.

Ein Business Object ist eine technische Größe, die der Persistenzdienst des ERP-Systems lesen, speichern und löschen kann. Dabei erfolgt die Konvertierung zwischen dem in der Anwendung benutzten objektorientierten Datenmodell und dem relationalen Datenmodell der Datenbank. Weitere anzugebende Eigenschaften sind die Datenart, erwartete Datengröße und die Cache-Strategie. Das dient vor allem dem System zur Leistungsoptimierung und Minimierung der Datenbankzugriffe.

Ein Business Object, auch Business-Object-Definition genannt, ist 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 sowie Hilfstabellen mit den Zugriffsstrukturen aus den hinterlegten Indexdefinitionen generiert.

3.5.5.1 Attribute

Ein Attribut ist kein eigenständiger Entwicklungsobjekttyp, sondern Teil der Definition eines Business Objects, eines Parts oder einer Extension.

Ein Attribut hat einen im Entwicklungsobjekt (z. B. Business Object) eindeutigen Attributnamen. Es hat einen Typ, welcher durch den zugeordneten logischen Datentyp bestimmt wird. Ein Attribut kann auch als Array eines bestimmten Typs definiert werden. In der zum Business Object generierten Java-Klasse werden die Attribute zu Variablen, die die fachlichen Werte enthalten. Wie bei Java-Klassen üblich kann man ihre Werte mit einer get-Methode (bei boolean is-Methode) abfragen und mit einer set-Methode ändern.

3.5.5.2 NLS-Attribute

NLS steht für National Language Support. Ein NLS-Attribut ist ein mehrsprachiges Attribut, das auf dem primitiven Typ String basiert, bei dem das Merkmal „Mehrsprachigkeit möglich“ gesetzt wurde. Wenn ein Attribut so einen lokalisierbaren logischen Datentyp zugeordnet hat, kann der Wert in mehreren Übersetzungen vorliegen. Die Übersetzungen eines Attributes werden in einem eigenen NLS-Business-Object gespeichert. Dessen Name setzt sich aus dem Namen des Business Objects, welches das lokalisierbare Attribut enthält, und dem Namen der Datenbank-Tabellenspalte des lokalisierbaren Attributes zusammen. Das NLS-Business-Object wird automatisch in einem NLS-Package angelegt, das sich vom ursprünglichen Package dadurch unterscheidet, dass nach dem Systemkürzel im Namensraum der String „nls” eingefügt wird, z. B. „com.cisag.nls“. Zu einer Datenbank (Mandant) sind immer eine Hauptsprache und evtl. mehrere Nebensprachen zugeordnet. Der Wert in der Hauptsprache eines Attributes wird in der Tabelle des zugehörigen Business Objects gespeichert und kann damit performant abgefragt werden. Die Werte der Nebensprachen eines Attributes, die Übersetzungen, werden in einer separaten Tabelle, der des NLS-Objektes, gespeichert. Aus Sicht des Anwendungsentwicklers geschieht der Zugriff auf ein NLS-Attribut weitestgehend transparent.

Die nachstehende Abbildung zeigt als Beispiel das Business Object com.cisag.app.edu.obj.Book mit dem mehrsprachigen Attribut description. Das vom System erstellte NLS-Business-Object com.cisag.nls.app.edu.obj.Book_DESCRIPTION nimmt die eventuell weiteren Nebensprachen zu dem Attribut auf.

UML-Diagramm zum Business Object Book.

3.5.5.3 Indizes

 

Ein Index ist eine Zugriffsstruktur auf gespeicherte Business-Object-Instanzen. Dabei erfolgt die Identifikation einer Instanz über die Werte speziell ausgezeichneter Attribute, so genannter Schlüsselattribute.

Zwischen folgenden Indizes wird unterschieden:

• Primary key
• Business key
• Secondary key
• Non unique index

Ein Business Object hat normalerweise immer einen Primary key und einen Businessk ey, welches eindeutige Indizes sind. Ein Index hat innerhalb des Business Objects einen eindeutigen Namen. In der Business-Object-Klasse wird zu jedem definierten Index eine Methode der Form buildIndexnameKey(…) generiert, die zu dem Primärschlüsselwert einer Business-Object-Instanz den technischen Schlüssel für den Persistenzdienst liefert, der damit die Instanz von der Datenbank laden kann.

Generell werden mit Indizes Lesezugriffe beschleunigt aber Schreibzugriffe (create, update, delete) verlangsamt, da zusätzlicher Aufwand für die Indexverwaltung anfällt.

Primary key

Der Primary key mit dem festen Namen „Primary“ basiert auf eindeutigen Primärschlüsselwerten. Der Primärschlüssel eines Business Objects besteht meist nur aus einem Attribut, das auf einem logischen Datentyp vom primitiven Typ „guid“ basiert. Er ist ein künstlich eingeführter Schlüssel und kann auch als Objektidentität bezeichnet werden. Er ermöglicht die Identifizierung einer Business-Object-Instanz und den performanten Zugriff aufgrund seiner kurzen Länge. Er identifiziert die Business-Object-Instanz auch dann, wenn sich der fachliche Schlüssel ändert. Alle Attribute im Primärschlüssel sind automatisch Pflichtfelder. Dieser Index wird als primärer Tabellenindex auf der Datenbank benutzt.

 

Business key

Der Business key stellt einen eindeutigen fachlichen Schlüssel dar und ist in der Regel lesbar, z. B. Artikelnummer, Ländercode. Dieser wird in den fachlichen Anwendungen normalerweise zur Indentifikation einer Business Object Instanz benutzt. Der Name von einem Business key sollte mit dem Präfix „By“ beginnen. Ist zum Beispiel bei einem Business Object der fachliche Schlüssel das Attribut „code“, sollte der Index „ByCode“ heißen. Besteht der fachliche Schlüssel aus mehreren Attributen, ist eine  geeignete Bezeichnung zu wählen. Für die Datenbank-Tabelle wird über die Schlüsselattribute ein Unique-Index erstellt.

Secondary key

Es kann ein zusätzlicher Sekundärindex definiert werden, der auf einem weiteren eindeutigen Schlüssel basiert. Für die Datenbanktabelle wird über die Schlüsselattribute ein Unique-Index erstellt. Die Namensvergabe sollte analog zur Namensvergabe von Business keys erfolgen.

Non unique index

Der Non unique index basiert auf Attributen, deren Werte mehrdeutig sein können. Auf der Tabelle wird für die enthaltenen Attribute ein Index erstellt (Duplikate sind also erlaubt), wobei ein Zugriff eine Menge von Instanzen liefern kann.

Als Beispiel dient das Business Object com.cisag.app.general.obj.Item

In dem Beispiel werden in der Klasse „com.cisag.app.general.obj.Item“ folgende Methoden zu den Indizes unter Verwendung der Indexnamen generiert:

public static byte[] buildPrimaryKey(byte[] guid)

public static byte[] buildByNumberKey(String number)

Für den Non unique index wird keine Methode erzeugt.

3.5.5.4 Beziehungen

 

Eine Beziehung ist eine fachliche Verbindung zwischen zwei Business Objects^[2]. Um die fachliche Verbindung darzustellen, wird bei einem Business Object eine Beziehungsdefinition (kurz Beziehung) angegeben. Im ERP-System sind Beziehungen immer unidirektional, d. h. sie führen nur von der Quelle zum Ziel. Benötigt man beide Richtungen, so muss man die andere Beziehung separat anlegen. Eine Beziehung kann die Kardinalität „1-1“ oder „1-n“ haben. Optionale Beziehungen werden nicht extra modelliert und sind in der Kardinalitätsangabe implizit enthalten. Eine Beziehung ist Teil der Business-Object-Definition. Sie hat einen eindeutigen Namen und gibt die Zuordnung der Quellattribute zu den Zielattributen an. In der zum Business Object gehörenden Java-Klasse wird für jede angegebene Beziehung eine Methode retrieveBeziehungsname (…) generiert.

„1-1“- Beziehung

Eine Beziehung mit der Kardinalität „1-1“ ordnet einer Business-Object-Instanz maximal eine andere Business-Object-Instanz zu. Ausgehend von den Werten der Quellattribute wird nach denselben Werten in den Zielattributen gesucht, um das Ziel der Beziehung zu identifizieren.

Um die Eindeutigkeit der Beziehung zu gewährleisten, muss auf den Zielattributen ein eindeutiger Index, also Primary key, Business key oder Secondary key, definiert sein. Referenzielle Integrität wird vom System nicht geprüft.

„1-n“-Beziehung

Eine Beziehung mit der Kardinalität „1-n“ ordnet einer Business-Object-Instanz keine, eine oder mehrere Business-Object-Instanzen desselben Business Objects zu. Ausgehend von den Werten der Quellattribute wird nach denselben Werten in den Zielattributen gesucht. Der Name so einer Beziehung sollte im Plural angegeben werden, um die Kardinalität zu kennzeichnen.

Beispiele:

Die folgende Abbildung zeigt ein Beispiel für Beziehungen zwischen den Business Objects Country und Region.

Im ERP-System würden die Beziehungen aus dem Beispiel wie folgt modelliert werden:

Ein Land hat viele Regionen:

Beziehungsname	Regions
Quellobjekt	com.cisag.app.general.obj.Country
Zielobjekt	com.cisag.app.general.obj.Region
Kardinalität	1-n
Attributmapping	Country.guid auf Region.country

 

In der Klasse des Business Objects „com.cisag.app.general.obj.Country” wird folgende Methode für die Beziehung generiert:

public CisObjectIterator retrieveRegions()

 

Eine Region gehört genau zu einem Land:

Beziehungsname	Country
Quellobjekt	com.cisag.app.general.obj.Region
Zielobjekt	com.cisag.app.general.obj.Country
Kardinalität	1-1
Zielmapping	Primary
Attributmapping	Region.country auf Country.guid

 

In der Klasse des Business Objects „com.cisag.app.general.obj.Regions“ wird folgende Methode für die Beziehung generiert:

public Country retrieveCountry()

Abhängigkeiten zwischen Business Objects

Normalerweise sind die Business Objects bzw. die dadurch modellierten fachlichen Größen eigenständig, d. h. die Existenz eines Business Objects ist nicht an die Existenz eines anderen gekoppelt.

Manche fachlichen Größen existieren nicht eigenständig, sie sind abhängig von einer anderen. Gehört eine Auftragsposition zu genau einem Auftragskopf, darf sie nicht ohne einen zugeordneten Auftragskopf existieren. Die beiden fachlichen Größen Auftragskopf und Auftragsposition bilden zusammen eine logische Einheit, den Auftrag. Der Auftragskopf ist Stellvertreter für den Auftrag und besitzt als Eigenschaften alle für den Auftrag relevanten Daten. Um solche Abhängigkeiten zu modellieren, haben Business Objects einen Typ.

3.5.5.5 Business-Object-Typen

Oftmals liegen Business Objects in normalisierter Form vor. Dabei kann es vorkomen, dass die eigentliche fachliche Größe durch mehr als ein Business Object beschrieben wird. Dennoch gibt es immer ein Haupt-Business-Object, den Business-Entity-Kopf. Alle anderen Business Objects dieser Gruppe, die Supplements und Dependents, sind von diesem Haupt-Business-Object abhängig. Die gesamte Gruppe bildet das Business Entity. Der Business-Entity-Kopf, die Supplements und die Dependents bilden eine hierarchische Struktur mit eindeutiger Zugehörigkeit.

Bei der Definition eines Business Objects wird festgelegt, ob es sich um ein Supplement handelt (zugewiesener Typ: Supplement), um ein Dependent (zugewiesener Typ: Dependent) oder um ein Haupt-Business-Object (zugewiesener Typ: Business Entity).

Business Entity

Ein Business Object vom Typ „Business Entity“ ist der ausgezeichnete Repräsentant einer Gruppe von Business Objects, von dem die anderen Business Objects (Supplements und Dependents) abhängen. Die gesamte Gruppe beschreibt das modellierte Business Entity (die fachliche Größe). Ein häufiger Spezialfall ist, dass ein Business Entity nur mit einem Business Object modelliert wird.

Supplement

Ein Business Object vom Typ „Supplement“ ist eine Ergänzung zu einem Business-Entity-Kopf. Ein Supplement besitzt eine speziell ausgezeichnete Beziehung mit dem Namen „_businessObject“, die auf den zugehörigen Business-Entity-Kopf zeigt (Kardinalität „1-1“) und damit die Zugehörigkeit angibt. Diese (technische) Beziehung benötigt der Persistenzdienst des ERP-Systems, um das Modifikationsjournal und die Änderungsinformationen führen zu können. Wird ein Supplement geändert, so werden diese Daten beim Business-Entity-Kopf und beim Supplement eingetragen.

Supplements dienen demselben zweck wie Extensions. Mit Supplements können Business Objects mit Attributen erweitert werden, ohne jedoch die Tabelle des Haupt-Business-Objects zu erweitern. Empfohlen wird deshalb die Verwendung von Supplements anstatt Extensions.

Die folgende Abbildung zeigt als Beispiel das Business Entity „Country“ mit zwei Supplements „ExtCountry“, die das Haupt-Business-Object jeweils um ein Attribut erweitern..

Dependent

Ein Business Object vom Typ „Dependent“ ist eine Ergänzung zu einem Business-Entity-Kopf. Ein Dependent besitzt eine speziell ausgezeichnete Beziehung mit dem Namen „_entity“, die auf den zugehörigen Business-Entity-Kopf zeigt (Kardinalität „1-1“) und damit die Zugehörigkeit angibt. Diese (technische) Beziehung benötigt der Persistenzdienst des ERP-Systems, um das Modifikationsjournal und die Änderungsinformationen führen zu können. Wird ein Dependent geändert, so werden diese Daten beim Business-Entity-Kopf und beim Dependent eingetragen.

Die folgende Abbildung zeigt als Beispiel das Business Entity „Partner“ mit den ausgewählten Dependents „CommunicationData“ und „FiscalInformation“. Weiterhin ist eine Beziehung vom Dependent „CommunicationData“ zu dem Business Entity „CommunicationMethod“ dargestellt, welches keine Dependents hat.

3.5.5.6 ERP-System-Funktionalitäten für Business Objects

 

Ein Business Entity ist ein zentrales Element für viele Funktionalitäten. Es gibt meist genau eine Anwendung zur Verwaltung pro Business Entity. Das System pflegt automatisch spezielle Attribute wie Ersteller und Erstellungszeitpunkt, letzter Bearbeiter, Zeitpunkt der letzten Änderung und Originalsystem. Auf Ebene der Business Objects erfolgt die Instanz-Versionierung und zeitabhängige Gültigkeitsdefinitionen. Mit dem Modifikationsjournal bietet das System an, eine Historie über Änderungen an den Daten eines Business Objects zu führen. Berechtigungen werden ebenfalls auf Basis der Business Entitys festgelegt.

An den Entity-Feldern der GUI, die ein Business Entity in der Anwendungsoberfläche repräsentieren, werden spezielle Funktionen angeboten. Es ist mithilfe von Drag & Drop möglich, eine konkrete Business-Object-Instanz in den Favoriten zu speichern oder durch Ablegen auf einem Symbol die sich dahinter verbergende Funktionalität mit dem Entity als Übergabeparameter zu starten. Im Kontextmenü des Entity-Feldes kann man zu den passenden Anwendungen navigieren und hat auf weitere Eigenschaften des Business Entitys Zugriff.

3.5.5.7 Generierte Java-Klassen

Aus der Business-Object-Definition werden vom System mindestens drei Java-Klassen generiert, die Haupt-, State- und Mapper-Klasse. Die Java-Klassen werden in dem zum Namensraum korrespondierenden Java-Package unter dem Namen des Business Objects (bzw. mit Suffix „_State“ oder „_Mapper“) gespeichert.

Die Hauptklasse verwendet der Entwickler in der Anwendung zum Zugriff auf Instanzen des Business Objects während die State- und Mapperklassen vom Persistenzdienst benötigt werden, um die Datenbankzugriffe zu realisieren. Die Hauptklasse enthält die get…()-, set…()- bzw. is…()-Methoden (bei Boolean) für den Zugriff auf die Attribute des Business Objects. Zu den festgelegten Indizes werden die entsprechenden build..Key()-Methoden generiert, die zum Lesen einer Instanz über eindeutige Schlüsselwerte mit dem Persistenzdienst dienen. Zu den angegebenen Beziehungen werden die retrieve…()-Methoden generiert, über welche die zugeordneten Business Objects ermittelbar sind.

3.5.5.8 Datums- und Zeitstempel-Attribute

Die im ERP-System gespeicherten Datums- bzw. Zeitpunktangaben, die sogenannten CisDates, beziehen sich immer auf eine Zeitzone. Diese Zeitzone bestimmt die Anwendung zum Erfassungszeitpunkt. Die Erfassungszeitzone zu einer Datums- bzw. Zeitpunktangabe ist nicht mehr änderbar. Der Datums-  bzw. Zeitpunktanteil wird immer bezüglich der Zeitzone GMT in der Datenbank gespeichert.

Eine Datumsangabe wird bezüglich der Erfassungszeitzone immer auf 0:00 Uhr normiert gespeichert. Das Normieren erfolgt durch das entsprechende GUI-Feld (CisDateField) und nicht automatisch durch den Persistenzdienst. Ansonsten hat der Entwickler dafür Sorge zu tragen. Es gibt die Datumstypen CisObjectDate, CisAttributeDate, CisObjectDateUntil und CisAttributeDateUntil (siehe Namensraum com.cisag.pgm.datatype).

Eine Zeitpunktangabe ist eine Festlegung von einem Datum und einer Uhrzeit. Es gibt die Zeitpunkttypen CisObjectTimeStamp und CisAttributeTimeStamp.

Die Visualisierung erfolgt immer bezüglich der Erfassungszeitzone über das entsprechende GUI-Feld (CisDateField). Nur wenn die Erfassungzone von der Zeitzone des Laufzeitkontextes abweicht, wird die Erfassungszeitzone angezeigt.

CisDate-Typen CisObjectDate, CisObjectTimeStamp

Ein Attribut vom Typ CisObjectDate speichert ein auf 0:00 Uhr normiertes Datum bezüglich der zum Erfassungszeitpunkt gültigen Zeitzone. Der logische Datentyp des Attributes muß immer von dem logischen Datentyp com.cisag.pgm.datatype.CisObjectDate abgeleitet sein.

Ein Attribut vom Typ CisObjectTimeStamp speichert eine Zeitangabe bezüglich der zum Erfassungszeitpunkt gültigen Zeitzone. Der logische Datentyp des Attributes muß immer von dem logischen Datentyp com.cisag.pgm.datatype.CisObjectTimeStamp abgeleitet sein.

Enthält ein Business Object ein Attribut dieser Typen, wird automatisch das Attribut _timeZoneGuid zum Business Object hinzugefügt. Dieses speichert die GUID der Erfassungszeitzone für alle Attribute vom Typ CisObjectDate und CisObjectTimeStamp. Daraus ergibt sich, dass diese Attribute sich alle auf dieselbe Zeitzone beziehen müssen. Gefüllt wird das Attribut _timeZoneGuid von der Anwendung. Nach dem ersten Speichern der Business-Object-Instanz kann der Wert dieses Attributes nicht mehr verändert werden.

CisDate-Typen CisAttributeDate, CisAttributeTimeStamp

Ein Attribut vom Typ CisAttributeDate speichert ein auf 0:00 Uhr normiertes Datum bezüglich einer Zeitzone. Der logische Datentyp des Attributes muß immer von dem logischen Datentyp com.cisag.pgm.datatype.CisAttributeDate abgeleitet sein.

Ein Attribut vom Typ CisAttributeTimeStamp speichert eine Zeitangabe bezüglich einer Zeitzone. Der logische Datentyp des Attributes muß immer von dem logischen Datentyp com.cisag.pgm.datatype.CisAttributeTimeStamp abgeleitet sein.

Die logischen Datentypen basieren auf dem speziellen Part com.cisag.sys.kernel.obj.CisDate, welches neben der Zeitangabe auch die GUID der zugehörigen Zeitzone aufnimmt. Daraus ergibt sich, das sich diese Attribute eines Business Objects auf unterschiedliche Zeitzonen beziehen können, da sie jeweils ihre eigene Erfassungszeitzone gespeichert haben.

CisDate-Typen CisObjectDateUntil, CisAttributeDateUntil

Ein Attribut vom Typ CisObjectDateUntil ist ein spezielles CisObjectDate. Der logische Datentyp des Attributes muß immer von dem logischen Datentyp com.cisag.pgm.datatype.CisObjectDateUntil abgeleitet sein.

Ein Attribut vom Typ CisAttributeDateUntil ist ein spezielles CisAttributeDate. Der logische Datentyp des Attributes muß immer von dem logischen Datentyp com.cisag.pgm.datatype.CisAttributeDateUntil abgeleitet sein.

Diese Typen werden zur Deklaration eines „Bis-Datums“ eines Zeit-Intervalls verwendet. Auf das angegebene Datum wird ein Tag automatisch addiert und dieser Wert in der Datenbank gespeichert. Für die Visualisierung wird wieder ein Tag von dem gespeicherten Datumswert abgezogen, sodass der Benutzer keinen Unterschied bemerkt.

Ein Beispiel:
Das geschlossene Zeitintervall 1.1.2003 bis 31.12.2003 wird auf der Datenbank als 1.1.2003 0:00 bis zum 1.1.2004 0:00 gespeichert. Damit wird die datenbankseitige Auswertung von Selektionen über dieses Intervall ermöglicht.

Java-Klasse CisDate

Ein Attribut vom Typ CisObjectDate, CisObjectTimeStamp, CisAttributeDate oder CisAttributeTimeStamp hat in den generierten Java-Klassen des Business Objects den Typ com.cisag.pgm.datatype.CisDate. Eine Instanz von CisDate repräsentiert den konkreten Wert des Attributes. Über die Methoden getTimeZoneGuid() kann auf die GUID der Erfassungszeitzone und mit der Methode getDate() auf den TimeStamp-Wert zugegriffen werden.

Für die Anwendungsentwicklung stehen spezielle GUI-Felder (com.cisag.pgm.gui.CisDateField usw.), die direkt mit CisDate-Instanzen umgehen können, zur Verfügung.

Die Hilfsklasse com.cisag.pgm.util.CisDateUtility stellt Methoden zur Verfügung, um CisDate-Instanzen zu erzeugen und Operationen wie Runden und Verschieben auf CisDates durchzuführen.

Primitiver Datentyp TimeStamp

Technische bzw. absolute Zeitangaben benötigen nicht die Festlegung einer Zeitzone, wie z. B. Schranken von Gültigkeitsintervallen, oder technische Zeitpunkte, wie z. B. Änderungszeitpunkt eines Entitys. Solche Attribute basieren auf dem primitiven ERP-System-Datentyp TimeStamp und besitzen keine Zeitzoneninformation. Die Zeitangabe wird direkt in die Zeitzone des Laufzeitkontextes umgerechnet und ohne Angabe einer Zeitzone visualisiert.

So ein Attribut hat in den generierten Java-Klassen des Buisness Objects den Typ java.util.Date.

3.5.5.9 Zeitabhängigkeit

Die Attribute validFrom und validUntil eines zeitabhängigen Business Objects können auf Datums- bzw. Zeitpunktangaben unter Berücksichtigung einer Zeitzone basieren. Im Punkt „Zeitabhängig“ eines Business Objects kann festgelegt werden, welcher Datumstyp für diese Attribute benutzt wird:

• Datum mit Zeitzone durch Anwendung: Die Attribute sind vom Typ CisObjectDate.
• Zeitpunkt mit Zeitzone durch Anwendung: Die Attribute sind vom Typ CisObjectTimeStamp.

Diese Einstellungen sind für ein Business Object entsprechend zu wählen, wenn die Zeitzone bei der Darstellung des Gültigkeitszeitraumes beachtet werden muß. Die Attribute validFrom und validUntil werden in den Java-Klassen als java.util.Date generiert.

3.5.6 Data-Description-LDT und Data-Description-Column

Bei der Data-Description werden zwei Entwicklungsobjekttypen unterschieden:

• Data-Description-LDT
• Data-Description-Column.

Diese besitzen zwar die gleichen Eigenschaften, aber unterschiedliche Bezugsebenen. Die Data-Description-LDT bildet eine Einheit mit einem Logischen Datentyp (identischer Namensraum und Entwicklungsobjektname). Sie beschreibt das Verhalten von Logischen Datentypen auf der Benutzeroberfläche. Durch die Verwendung von Logischen Datentypen vom Typ „logisch“ wird implizit eine Vererbungshierarchie auf den zugehörigen Data-Descriptions abgebildet. Dazu muss für die Logischen Datentypen eine Data-Description-LDT definiert werden. In dieser wird dann bestimmt, ob die Werte über der Vererbung aufgelöst oder explizit angegeben werden.

 

 

Eine Data-Description-Column ist genau einem konkreten Attributpfad eines Business Objects, eines Parts oder einer Extension zugeordnet und beschreibt ebenfalls das Verhalten auf der Benutzeroberfläche. Sie kann von der Data-Description-LDT erben, die zum Logischen Datentyp des Attributs gehört. Den visuellen Elementen kann der Pfad zum Attribut übergeben werden. Über diesen wird die Data-Description-Column aufgelöst und dargestellt. Ist keine Data-Description-Column für das Attribut definiert, wird die Data-Description-LDT vom Logischen Datentyp des Attributs verwendet.

Der Entwicklungsobjektname der Data-Description-Column ist wie folgt zusammengesetzt:

<Busisness Object Namensraum>.<Business Object Name>:<Attributname>

Beispiel:

com.cisag.app.obj.BusinessObject:description

Existieren für ein Attribut eines Business Objects beide Data-Description-Typen, hat die Data-Description-Column Vorrang.

3.5.7 Datei

Durch das Entwicklungsobjekt „Datei“ können unterschiedliche Dateien in der Repository-Datenbank abgelegt werden. Diese Dateiobjekte können z. B. Vorlagen für Dokumente etc. sein.

Zugreifen kann man auf die Dateiobjekte über die PGM-Schnittstelle com.cisag.pgm.util.FileLogic.

3.5.8 Ereignis

Das Entwicklungsobjekt „Ereignis“ findet im Workflow Verwendung. Ereignisse werden verwendet, damit Aktivitätsdefinitionen, die für bestimmte Ereignisse erstellt werden, beim Eintreten der jeweiligen Ereignisse Aktivitäten erzeugen. Das Entwicklungsobjekt „Ereignis“ kann aufgrund eines bestimmten Zustandes einer Anwendung ein Ereignis auslösen, das vom Workflow verarbeitet wird. Die Ereignisse sind im Repository registriert und werden beim Entwickeln von Anwendungen festgelegt. Über eine Programmierschnittstelle können die Ereignisse ausgelöst werden. Im Interface com.cisag.pgm.appserver.CisSystem-Manager existieren Methoden mit dem Namen fireEvent mit unterschiedlichen Parametern, mit denen die Ereignisse ausgelöst werden. Ereignisse haben immer einen Bezug zu einer Datenbank.

3.5.9 Extension

Alternativ zu Extensions können Business Objects vom Typ „Supplement“ verwendet werden. Supplements dienen demselben Zweck wie Extensions, ohne jedoch die Tabelle des Business-Objects aus dem Standard zu erweitern.

Eine Extension dient dazu, Modifikationen an Business Objects bzw. Parts aus dem Standard (d. h. im Namensraum com.cisag) durch Partner zu ermöglichen. Jede Extension kann eine von der Comarch Software und Beratung AG erstellte Part- oder Business-Object-Definition um zusätzliche Attribute erweitern. Die generierten Java-Sourcen enthalten dann nicht nur die von der Comarch Software und Beratung AG definierten Attribute, sondern zusätzlich noch die Attribute aller zugehörigen Extensions. Dabei werden die Sourcen des erweiterten Business Objects durch die neuen Sourcen ersetzt, d.h. im Source-Verzeichnis im Pfad „com.cisag” werden Änderungen vorgenommen. Beim Hinzufügen von Attributen wird eine Namenskonvention eingehalten, um Konflikte durch doppelte Attributnamen aus verschiedenen Extensions zu vermeiden. Dem Namen des neuen Attributes wird das Entwicklungspräfix vorangestellt, d.h. im nachfolgenden Beispiel das Kürzel „ABC_”. Extensions selbst sind in Namensräumen organisiert und haben innerhalb eines Namensraumes einen eindeutigen Namen. Der Namensraum einer Extension liegt außerhalb von „com.cisag…” im Namensraum des Entwicklungspräfixes.

Beispiel:

Der Part „com.cisag.app.general.obj.Part1″ soll bei der Firma „ABC” um ein Attribut c zusätzlich zu den von der Comarch Software und Beratung AG definierten Attributen a und b erweitert werden. Dazu wird die Extension „com.abc.app.general.obj. ExtensionPart1“ angelegt, die auf dem zu erweiternden Part „com.cisag.app.general.obj.Part1“ basiert. Der Extension wird das Attribut mit dem Namen „abc_c“ hinzugefügt. In den generierten Part-Klassen sieht es so aus, als hätte schon die Comarch Software und Beratung AG das Attribut abc_c definiert. Der erweiterte Part ist voll kompatibel zum Basis-Part. Alle Stellen in einer Anwendung, die die Attribute a und b benutzen, funktionieren weiterhin. Der Partner muss sich nur um die Stellen kümmern, wo das Attribut c eine Rolle spielt. Diese Stellen liegen außerhalb der Packages „com.cisag…”, es ist die vom Partner anzupassende Anwendung, die in dem Namensraum mit dem Entwicklungspräfix „abc“ liegt.

 

Bei Anlage bzw. Löschen einer Extension wird die Versionsnummer des Basis-Business-Objects bzw. -Parts erhöht und es wird in die Entwicklungsaufgabe aufgenommen, um dessen Java-Sourcen neu zu generieren.

3.5.10 Framework

Frameworks dienen der thematischen Zusammenfassung von Anwendungen. Im Navigationsbereich werden alle lizenzierten Frameworks angezeigt. Unter den Frameworks befinden sich die zugeordneten Anwendungen.

3.5.11 Fähigkeit

Eine Fähigkeit wird genutzt, um im ERP-System bestimmte Aktionen, Ansichten etc. auf programmtechnischer Ebene zu berechtigen.

Beispiel:

Die Fähigkeit, Aktivitäten im Workflow löschen zu können.

CisSystemManager sm = CisEnvironment.getInstance()

.getSystemManager();

if (!sm.isAuthorized(“com.cisag.sys.workflow.DeleteActivities.cap”)){

mm.sendMessage(“WFL”, 250);

return;

}

3.5.12 Funktion

Um Abläufe im ERP-System ohne Änderungen an Anwendungen anpassen zu können, können Funktionen definiert werden. In der Anwendung „Customizing“ können diese Funk-tionen je System, je OLTP-Datenbank oder je Organisationseinheit aktiviert und parametrisiert werden. Anwendungen verwenden diese Einstellungen dann als Vorschlags–werte oder blenden nicht benötigte Elemente aus, wenn die Funktion deaktiviert ist.

3.5.13 Hilfe-Objekt

Erfassung der Hilfedateien, die in der ERP-System-Online-Hilfe angezeigt werden. Das Entwicklungsobjekt umfasst sowohl die Quell- als auch die Zieldateien.

3.5.14 Icon

Definition der Eigenschaften von Icons, die in einem visuellen Element oder einer Action verwendet werden. Die Neuanlage sollte in einem .res oder .res2d Namensraum erfolgen, diese Regel wird nicht geprüft. Im Gegensatz zu allen anderen Entwicklungsobjekten beginnt der Entwicklungsobjektname mit einem kleinen Buchstaben und enthält die Größenangabe des Icons (z. B. -16×16). Das System prüft weder den Namensraum noch den Entwicklungsobjektnamen auf die genannten Einschränkungen. Diese sind optional und dienen der Übersichtlichkeit.

3.5.15 Java-Klasse

Das Entwicklungsobjekt „Java-Klasse“ verwaltet die Java-Quellen und Java-Klassen.

3.5.16 Lizenzschlüssel

Lizenzschlüssel dienen dazu, eine Funktion oder eine Menge von Funktionen zu deaktivieren. Wenn bei einer Funktion ein Lizenzschlüssel eingetragen ist, der nicht lizenziert ist, ist die Funktion in der Anwendung „Customizing“ nicht sichtbar und kann nicht verwendet werden.

3.5.17 Logischer Datentyp

Das Typsystem des ERP-Systems basiert auf logischen Datentypen. Ein logischer Datentyp entspricht (grob) einem typedef in C bzw. einer Domäne im Datenbankbereich. Logische Datentypen sind in Namensräumen organisiert und haben innerhalb eines Namensraumes einen eindeutigen Namen. Ein logischer Datentyp hat immer eine fachliche Bedeutung, die sich auch im Namen ausdrücken sollte. Logische Datentypen gibt es in den Typen primitiv, komplex und logisch. Der Datentyp jedes Attributs eines Business Objects wird durch einen logischen Datentyp definiert.

3.5.17.1 Logischer Datentyp vom Typ primitiv

Ein logischer Datentyp vom Typ primitiv basiert auf primitiven ERP-System-Typen, die jeweils nur einen elementaren Wert aufnehmen können. In generierten Javaklassen werden diese Datentypen durch passende Java-Datentypen ersetzt. Wird ein logischer Datentyp mit dem Typ „primitiv” direkt für eine Attributdefinition benutzt, so entspricht ein Attribut genau einer Tabellenspalte in der Datenbank.

Beispiel:

Das Attribut number (Artikelnummer) des Business Objects com.cisag.app.general.obj.Item (Artikel) wird durch den logischen Datentyp com.cisag.app.general.Item definiert. Dieser ist vom primitiven Typ String mit der maximalen Länge 25. Die fachliche Bedeutung des logischen Datentyps drückt sich auch in seinem Namen aus. Die generierte Klasse enthält ein Attribut item mit der Deklaration „java.lang.String”. Die zum Attribut zugehörige Spalte in der Datenbanktabelle des Business Objects hätte beispielsweise unter dem DBMS Oracle den Typ „NVARCHAR2“.

3.5.17.2 Logischer Datentyp vom Typ logisch

Ein logischer Datentyp vom Typ logisch ist eine fachliche Verfeinerung (Spezialisierung) eines anderen logischen Datentyps. Er kann auf allen Typen (primitiv, komplex, logisch) basieren, dabei muss die Vererbungsbeziehung zyklenfrei sein. Er  übernimmt die Eigenschaften des zugrunde liegenden logischen Datentyps. Die Vererbungsbeziehung wird weiterhin für die Definition von GUI-Eigenschaften durch Zuordnung einer Data Description benutzt.

Beispiel:

Das Attribut orderCustomerNumber des Business Objects com.cisag.app.sales.obj.CustomerInvoice wird durch den logischen Datentyp com.cisag.app.general.CustomerNumber definiert und speichert den Business Key des Kunden. Der logische Datentyp ist abgeleitet von dem logischen Datentyp com.cisag.app.general.PartnerNumber und übernimmt dessen Eigenschaften.

Die folgende Abbildung illustriert die Vererbungsbeziehungen zwischen den logischen Datentypen. Der primitive logische Datentyp Partnernummer wird durch die logischen Datentypen Lieferantennummer und Kundennummer jeweils verfeinert.

3.5.17.3 Logischer Datentyp vom Typ komplex

Ein logischer Datentyp vom Typ komplex basiert auf einer Part-Definition, die eine Datenstruktur beschreibt. Damit sind komplexe Attribute eines Business Objects realisierbar.

Beispiel:

Das Attribut „intrastat“ des Business Objects com.cisag.app.general.obj.ItemCountryData wird durch den komplexen logischen Datentyp com.cisag.app.general.IntrastatItemData definiert, welcher auf dem Part com.cisag.app.general.obj.IntrastatItemData basiert. Üblicherweise enthält der Name des logischen Datentyps den Namen des Parts.

3.5.18 Meldung

Eine Meldung ist eine Nachricht an den Benutzer. Sie liefert das Ergebnis einer Aktion oder eine Information über einen bestimmten Zustand der Anwendung. Der Entwicklungsobjektname ist eine Meldungsnummer, die bei der Neuanlage automatisch oder durch den Anwender vergeben wird. Die Meldungsnummer muss in der Meldungsklasse eindeutig sein.

Im Quell-Code werden die Meldungen über den MessageManager aufgerufen. Über die Meldungsklasse und Meldungsnummer werden die Meldungen im System ermittelt und angezeigt. Zusätzlich können noch bis zehn Parameter übergeben werden.

Beispiel:

CisEnvironment env = CisEnvironment.getInstance();

CisMessageManager mm = env.getMessageManager();

mm.sendMessage(„APP“, 100, „Parameter1“, „Parameter2“);

3.5.19 Meldungsklasse

Eine Meldung wird in eine Meldungsklasse eingeordnet, welche die Zugehörigkeit der Meldung angibt. Eine Meldungsklasse hat einen Namensraum. So gibt es die Meldungsklasse APP (Application), zu der allgemeine Meldungen zu Anwendungen gehören, die Meldungsklasse SYS (System) für Systemmeldungen oder die Meldungsklasse EDU (Education) für Schulungsanwendungen.

Eine Meldungsklasse hat einen Namensraum und einen Namen zur Identifikation. Der Name besteht normalerweise aus drei Großbuchstaben. Weiterhin kann eine Beschreibung des Kontextes angegeben werden. Man kann eine Meldungsklasse auch als Alias für einen Namensraum auffassen. Deswegen kann ein Name nur einmal vergeben werden.

3.5.20 Namensraum

Eine ausführliche Beschreibung des Entwicklungsobjekttyps Namensraum finden Sie im Kapitel „Namensräume“ auf Seite 23.

3.5.21 OQL-Suche

OQL-Suchen werden hauptsächlich als Wertehilfen an Eingabefeldern verwendet. Bei kleinen Datenmengen wird in der Regel eine Auswahlliste, bei großen Datenmengen ein Dialog dargestellt.

Neben dieser Verwendung können OQL-Suchen für Abfrageanwendungen direkt in Programmen etc. eingesetzt werden, um Daten anhand festgelegter Kriterien aus der Datenbank auszulesen.

Wie alle anderen Entwicklungsobjekttypen wird auch eine OQL-Suche über die Kombination aus Namensraum und Namen identifiziert.

Eine OQL-Suche definiert nur die Metadaten für die Suche. Erst zur Laufzeit wird aus den Metadaten das OQL für die Suche erstellt.

Die Metadaten einer OQL-Suche umfassen die verwendeten Business Objects, die Definition der Beziehung zwischen den Business Objects, die benutzten Attribute der Business Objects, sowie einschränkende Kriterien für die Suche. Zu den einzelnen Attributen der Suche kann definiert werden, ob diese als Suchmerkmal, für die Anzeige, für die Rückgabe oder für die Sortierung benutzt werden sollen. Die Attribute werden pro Eigenschaft durch Nummerierung sortiert. Besitzt ein Attribut keine Nummer zu einer Eigenschaft, so wird dieses Attribut auch nicht für die Eigenschaft verwendet. Für die Verwendung als Suchmerkmal und als Anzeigeattribut kann je ein logischer Datentyp angegeben werden, der für die jeweilige Visualisierung verwendet wird.

Aus Leistungsgründen ist eine OQL-Suche in ein Basisfragment und beliebig viele Nebenfragmente aufteilbar. Nebenfragmente werden nur im OQL berücksichtigt, wenn mindestens ein darin enthaltenes Attribut als Suchmerkmal oder für die Sortierung verwendet wird.

Über eine Hook-Java-Klasse kann die Suche programmtechnisch manipuliert werden. Zur Manipulation stehen Interfaces im Namensraum com.cisag.pgm.objsearch zur Verfügung. Durch Implementierung dieser Interfaces kann z. B. die Darstellung des Suchergebnisses als Liste anstelle der üblichen Tabelle ausgegeben werden.

Wird die Suche in einem Programm verwendet, werden die logischen Datentypen, der Hook etc. ggf. nicht verwendet.

3.5.22 OQL-View

Dieser Entwicklungsobjekttyp wird nicht mehr unterstützt. Sie können lediglich bereits vorhandene Entwicklungsobjekte des Typs “OQL-View” betrachten und bearbeiten, aber keine neuen Entwicklungsobjekte dieses Typs erfassen.

Oftmals benötigt man ein Business Object mit ergänzenden Daten aus anderen referenzierten Business Objects in Anwendungen mehrfach. Statt Laden des Business Objects, Laden der referenzierten Business Objects über die Beziehungen und Auswahl der interessanten Attribute oder der Verwendung eines immer gleichen OQL-Statements, ist es einfacher, eine Sicht (View) auf die gewünschten Informationen anzulegen. Diese Sicht lässt sich in der Anwendung wie ein normales Business Object verwenden, mit der Einschränkung, dass die Daten nur gelesen werden können. Änderungen können so an zentraler Stelle vorgenommen werden. Die Sicht auf die Daten wird in Form eines OQL-Statements angegeben. Dabei gibt es keine Einschränkungen bezüglich der Verwendung von Joins und WHERE-Klauseln, sodass komplexe Anfrage-Statements möglich sind.

Eine OQL-View-Definition hat einen Namensraum und Namen, die den OQL-View identifiziert. Die Beschreibung des zu liefernden Ergebnisses erfolgt mithilfe eines SELECT-Statements in OQL-Schreibweise, welches der Entwickler formulieren muss. Das OQL-Statement kann man mit der Anwendung OQL-Anfragen im Framework Software-Entwicklung interaktiv ausprobieren.

Aus der OQL-View-Definition werden vom System (Tool crtbo) drei Java-Klassen generiert, die Haupt-, State- und Mapper-Klasse. Die Java-Klassen werden in dem zum Namensraum korrespondierenden Java-Package unter dem Namen des OQL-Views (bzw. mit Suffix „_State“ oder „_Mapper“) gespeichert. Die Hauptklasse verwendet der Entwickler in der Anwendung zum Zugriff auf Instanzen des OQL-Views, während die State- und Mapper-Klassen vom Persistenzdienst benötigt werden, um die Datenbankzugriffe zu realisieren.

Die Hauptklasse enthält für den Zugriff auf die Attribute des Views die get…()- bzw. is…()-Methoden (bei Boolean) und die Methode buildPrimaryKey() zum Laden einer Instanz über den Primärschlüssel. In der Anwendung verhält sich der View ähnlich einem Business Object, allerdings sind nur Lesezugriffe möglich.

Auf der Datenbank wird der zugehörige Datenbank-View angelegt, wobei das OQL-Statement vom System in ein SQL-Statement konvertiert wird, welches den Datenbank-View verwendet, um die virtuelle Datenbanktabelle zu erstellen.

Die nachstehende Abbildung zeigt ein Beispiel für einen OQL-View. Er liefert zu einer JobDescription den Business Key der Organisationseinheit (Fremdschlüssel zu Business Object Partner). Den Ergebnisattributen wird über das Kürzel as bzw. askey ein eindeutiger Name zugewiesen. Die Attribute, die den Primärschlüssel des OQL-Views bilden, werden mit askey ausgezeichnet.

3.5.23 Part

Eine Part-Definiton (kurz Part) dient der Realisierung von komplexen Attributen von Business Objects. Es definiert eine Datenstruktur, die eine Attributgruppe unter einer aussagekräftigen Bezeichnung zusammenfasst. Komplexe Attribute haben keinen eigenen Schlüssel, sondern sind Teil eines Business Objects. Parts ermöglichen die Wiederverwendung von einmal modellierten Datenstrukturen bei verschiedenen Business Objects. In einer Part-Definition kann man auch Beziehungen zu anderen Business Objects angeben, ein Part kann allerdings nie das Ziel einer Beziehung sein. Bei der Modellierung eines Parts kann man auch einen anderen Part angeben, von dem der Part die Attribute erben soll. Eine Business-Object-Definition kann ebenfalls Attribute von einem Part erben.

Ein Part hat einen Namensraum und Namen, ihm können ein oder mehrere Attribute zugeordnet sein. Er besitzt keine eigene Datenbanktabelle. Die Part-Attribute werden in der Tabelle des Business Objects gespeichert.

Zu einer Part-Definition werden mehrere Java-Klassen generiert, die zum Zugriff auf eine Part-Instanz in der Anwendung dienen:

• Über die Immutable-Klasse kann nur lesend auf die Attribute des Parts zugegriffen werden.
• Über die Mutable-Klasse kann lesend und schreibend auf die Attribute des Parts zugegriffen werden.

Beispiel:

Die Part-Definition com.cisag.app.general.obj.BankInfo beschreibt die Struktur einer Bankinformation.

Es sind die folgenden Attribute definiert:

Attribut	Logischer Datentyp	Primitiver Datentyp
bankCountry	..BankInfoBankCountry	guid
bankCode	..BankInfoBankCode	guid
bankBranch	..BankInfoBankBranch	guid
bankAccount	..BankInfoBankAccount	str(30)
iban	..BankInfoIban	str(40)
swift	..BankInfoSwift	str(11)
accountHolder	..BankInfoAccountHolder	str(80)

 

Weiterhin besitzt die Part-Definition die folgenden Beziehungen:

Beziehung	Ziel-BO	Kardinalität
Bank bankCode	com.cisag.app.general.obj. Bank guid	1-1
BankBranch bankBranch	com.cisag.app.general.obj. BankBranch guid	1-1
BankCountry bankCountry	com.cisag.app.general.obj. Country guid	1-1

 

Es wird eine Immutable-Klasse „com.cisag.app.general. obj.BankInfo” generiert, die nur Methoden zum Lesen der Attribute hat, zum Beispiel getBankCountry(), getBankCode() usw. Es gibt keine Methoden zum Ändern von Attributwerten. Durch die Beziehungen des Parts gibt es zusätzlich die Methoden zu den Beziehungen, zum Beispiel die Metohde retrieveBank().

Es gibt außerdem die Mutable-Klasse „com.cisag.app. general.obj.BankInfoMutable”, die zusätzlich die Methoden zum Ändern der Attribute hat, wie die Methoden setBankCountry(), setBankCode() usw.

3.5.24 Stringtable

Eine Stringtabelle ist ein spezielles Entwicklungsobjekt, das zum Entkoppeln von Texten und Source-Code dient. Es sollte vermieden werden, Texte fest in den Source-Code zu schreiben, da hart codierte Texte schwer übersetzbar sind und man die Texte nicht ohne Neukompilieren der Sourcen ändern kann. Eine Stringtabelle verwaltet die von einer Anwendung benutzten Texte^[3]. Es werden jeweils zu einer Konstante Texte zugeordnet. Dabei erfolgt die Erfassung eines Textes zu einer Konstante in der aktuell eingestellten Entwicklungssprache, d. h. es ist ein Text pro Sprache zu einer Konstante erfassbar. Um einen Text in einer anderen Entwicklungssprache zu erfassen, muss diese erst in den Benutzereinstellungen geändert werden. Normalerweise gibt es eine vorgegebene Entwicklungssprache, z. B. deutsch. Im Source-Code wird statt des konkreten Textes die entsprechende Konstante der Stringtabelle angegeben. Der Text wird zur Laufzeit aus den hinterlegten Einträgen entsprechend der aktuell eingestellten Anzeigesprache ermittelt.

Eine Stringtabelle hat einen Namensraum und Namen. Es wird ein Hauptnamensraum gewählt, wenn die Stringtabelle für ein zusammenhängendes Themengebiet genutzt wird, d. h. es werden Texte zu einem Themengebiet hinterlegt. Der konkrete Name leitet sich oft aus dem verwalteten Business Entity ab:

Stringtable com.cisag.app.sales.BonusAgreement

Eine Stringtabtable wird in einem Unternamensraum angelegt, wenn sie als Ergänzung zu einer bzw. mehreren konkreten zusammengehörenden Java-Klassen, z. B. von einer Anwendung, im selben Namensraum dient.

Beispiele:

Java-Klasse com.cisag.app.crm.ui.OpportunityMaintenance

Stringtable com.cisag.app.crm.ui.OpportunityMaintenance

Beispiel:

Nachfolgend ist die Stringtable com.cisag.app.general.partner.ui.PartnerIdentArea abgebildet. Sie hat mehrere Konstanten, zu denen die Texte in den Entwicklungssprachen (Deutsch, Englisch, …) hinterlegt sind.

Konstante	Text (de)	Text (en)
ORGANIZATIONADDRESS	Geschäfts-a&dresse	&Business address
PRIVATEADDRESS	Privata&dresse	Home address
…

 

Zur Abfrage des Textes zu einer Konstante in der aktuell eingestellten Anzeigesprache dient die Methode getText() der Klasse com.cisag.pgm.util.RepositoryInfo, die die folgenden Signaturen hat:

public static String getText(String absPath);

public static String getText(String path, String constant);

Beispiel – getText()

Abfrage des Textes über den absoluten Pfad:

RepositoryInfo.getText(“com.cisag.app.general.partner.ui.PartnerIdentArea:PRIVATEADDRESS.txt”);

Abfrage des Textes mit relativem Pfad:

RepositoryInfo.getText(“com.cisag.app.general.partner.ui.PartnerIdentArea”, “PRIVATEADDRESS”);

An GUI-Elemente wird meist nicht der Text übergeben, sondern der Stringtable-Pfad. So wird bzw. eine GroupBox wie folgt erzeugt:

GroupBox box = new GroupBox(“0060…8010″,”absoluteStringTablePath”);

Und nicht so:

GroupBox box = new GroupBox((“0060…8010″, getText(” absoluteStringTablePath “));

3.5.25 Terminus

Das Entwicklungsobjekt „Terminus“ ermöglicht die Übernahme und Verwendung von in Trados-Multiterm geführten Termini. Die Termini werden mit der Anwendung „Termini importieren“ in das Repository importiert. Das Entwicklungsobjekt ist nur über Trados-Multiterm bearbeitbar. Termini werden immer im Namensraum „com.cisag.app.terminus“ erzeugt. Der Entwicklungsobjektname wird durchnummeriert (00001 …).

3.5.26 Testlauf

Ein Testlauf ist die Definition eines wiederholbaren Szenarios, um Anwendungen zu testen. Zwei verschiedene Definitionsmöglichkeiten für Testläufe existieren:

• Generische Definition: Bei einer generischen Definition kann ein Namensraum angegeben werden. Zum Ausführungszeitpunkt des Testlaufes werden alle Anwendungen berücksichtigt, die unterhalb des angegebenen Namensraums definiert sind. Diese Art von Definition dient dazu, die generelle Funktionalität von Anwendungen zu überprüfen.
• Konkrete Definition: Eine konkrete Definition enthält alle Anwendungen und Tests direkt. D. h. die Menge der Anwendungen und Tests ist beim Erfassen dieselbe wie bei der Ausführung. Diese Definition kann auch die speziellen Tests, die bei einer Anwendung definiert werden können, enthalten.

3.5.27 Text

Zu jedem Entwicklungsobjekt, das einen übersetzbaren Text enthält, existiert genau ein weiteres Entwicklungsobjekt vom Typ Text. Das Textobjekt enthält alle erfassten Texte in allen jeweiligen Sprachen. Der Namensraum ist identisch mit dem des zugehörigen Entwicklungsobjekts. Der Entwicklungsobjektname enthält den Texttyp und den Entwicklungsobjektnamen des zugehörigen Entwicklungsobjekts (<Texttyp>_<Entwicklungsobjektname>). Ein Textobjekt wird bei der Neuanlage des zugehörigen Entwicklungsobjekts automatisch angelegt. Wenn der Text in einem Entwicklungsobjekt geändert wird, dann wird automatisch das Textobjekt geändert und ebenfalls in der aktuellen Aufgabe gesperrt. Texte können über das Redaktionscockpit auch außerhalb der Repository über-arbeitet werden.

3.5.28 Valueset

Ein Valueset ist eine benannte Wertaufzählung und ähnelt dem type-Konstrukt, welches es z. B. in Pascal gibt. Es wird um Value-Set-Elemente ergänzt, die die konkreten Ausprägungen der Aufzählung enthalten.

Jedes Element besteht aus einem short-Wert, einem Namen und einer Bezeichnung. Standardmäßig wird zu jedem Value Set eine zugehörige Java-Klasse generiert, in der die Konstanten (static final short) definiert sind. Der Name eines Valueset-Elementes wird als Konstantenname und der short-Wert als Konstantenwert benutzt. Die Bezeichnung wird für die GUI-Darstellung eines Elementes benutzt und ist übersetzbar.

Die zu verwendenden Nummern für die ID sind festgelegt. Ein Partnerentwicklungssystem darf nur den Bereich von 3001 bis 3999 und ein Kundenadaptierungssystem nur den Bereich von 6001 bis 6999 verwenden, um Überschneidungen bei Erweiterungen des Value Sets zu vermeiden.

Die Konstanten sollten nicht für bit-Operationen benutzt werden, da der Partner dann keine Chance hat, das ValueSet zu erweitern.

Die Tabelle zeigt das Value Set com.cisag.app.general.CommunicationMedia als Beispiel:

ID	Konstante	Bezeichnung
1	EMAIL	E-Mail
2	TELEFAX	Fax
3	TELEPHONE	Telefon
4	TELEX	Telex
5	URL	WWW

 

Zu einem Value Set muss die zugehörige Java-Klasse generiert werden. Dazu dient das Tool crtvs, welches auf der Kommandozeile des SAS ausgeführt wird. Über Angabe des Parameters „-j:nummer“ werden alle in der Entwicklungsaufgabe enthaltenen Value Sets generiert:

crtvs –j:nummer

Die generierte Klasse liegt im zum Namensraum des Value Sets korrespondierenden Package, im Arbeitsverzeichnis der Entwicklungsaufgabe und hat den Namen des Value Sets.

3.5.29 Versionen von Entwicklungsobjekten

Bei der Bearbeitung eines Entwicklungsobjektes im Rahmen einer Entwicklungsaufgabe wird immer eine neue Version erstellt. Bei der Neuanlage eines Entwicklungsobjektes entsteht immer die erste Version. Solange die Aufgabe nicht abgeschlossen wurde, ist diese Version noch nicht im System aktiv, sondern existiert nur in der Entwicklungsaufgabe. Deshalb kann diese Version auch wieder gelöscht werden, ohne sie zu archivieren. Mit der Aktivierung der Entwicklungsaufgabe wird die neue Version im System zur aktiven Version. Beim Löschen eines Entwicklungsobjektes entsteht eine neue Version, die mit dem Zeichen „+“ am Ende der Versionsnummer als gelöscht gekennzeichnet wird.

Ein Entwicklungsobjekt hat eine sechsteilige Versionsnummer. Im Anschluss daran wird, durch einen Doppelpunkt getrennt, der Systemname angegeben, in dem die Version entstanden ist. Der Typ des ERP-Systems, in dem das Entwicklungsobjekt erfasst bzw. geändert wurde, bestimmt, welcher Teil der Versionsnummer erhöht wird. Für die Schreibweise gilt, dass rechtsseitige Nullen weggelassen werden. Bei äteren Versionen kann es zudem vorkommen, dass der Systemname noch nicht Teil der Versionsnummer ist. Es gibt folgende Systemtypen:

• Internes Entwicklungssystem (Stufe 1): Das System bei der Comarch Software und Beratung AG, in dem die nächste Auslieferungsversion entwickelt wird. Bei den Entwicklungsobjekten wird bei Neuanlage bzw. Änderung der erste Teil der Versionsnummer erhöht.
• Internes Korrektursystem (Stufe 2): In einem internen Korrektursystem werden die Korrekturen zu einem ausgelieferten System eingearbeitet. Zu jeder Auslieferungsversion gibt es ein Korrektursystem, solange die Wartung für diese Auslieferungsversion bei der Comarch Software und Beratung AG läuft. Bei den Entwicklungsobjekten wird bei Neuanlage bzw. Änderung der zweite Teil der Versionsnummer erhöht.
• Partner-Branchenlösung (Stufe 3): Ein Partner-Branchenlösungssystem ist eine Weiterentwicklung für eine konkrete Branche. Bei den Entwicklungsobjekten wird bei Neuanlage bzw. Änderung der dritte Teil der Versionsnummer erhöht.
• Partner-Branchen-Korrektursystem (Stufe 4): In einem Partner-Branchen-Korrektursystem werden die Korrekturen zu einer Auslieferungsversion einer Partner-Branchenlösung eingepflegt. Bei den Entwicklungsobjekten wird bei Neuanlage bzw. Änderung der vierte Teil der Versionsnummer erhöht.
• Kundenadaptionssystem (Stufe 5 oder 6): Ein Kundenadaptionssystem enthält konkrete Anpassungen einer Partner-Branchenlösung oder einer Auslieferungsversion der Comarch Software und Beratung AG an die konkreten Bedürfnisse eines Kunden. Bei den Entwicklungsobjekten wird bei Neuanlage bzw. Änderung der sechste Teil der Versionsnummer erhöht.
• Produktivsystem (Stufe 7): Ein Produktivsystem ist ein beim Kunden vor Ort eingesetztes System. In einem Produktivsys-tem können keine Entwicklungsobjekte angelegt oder geändert werden.

Die folgende Tabelle zeigt den Aufbau der Versionsnummer im Überblick:

Pos.	Benutzt vom System des Typs	Objektversion
1	Entwicklungssystem der Comarch Software und Beratung AG	Hauptversionsnummer
2	Korrektursystem der Comarch Software und Beratung AG	Korrekturversionsnummer
3	Partner-Branchenlösungs-System	Hauptversionsnummer
4	Partner-Branchenlösungs-Korrekur-System	Korrekturversionsnummer
5	Kundenadaptionssystem	Kundenadaptionsversionsnummer
6	Kundenadaptionssystem	Kundenadaptionsversionsnummer

(Ohne die Angabe des Systems)

Zur Veranschaulichung folgt ein Beispiel für die Versionszählung bei einem Business Object:

• Nach der Erstellung des Business Objects im Entwicklungssystem der Comarch Software und Beratung AG besitzt es die Versionsnummer 1.0.0.0.0.0 (kurz 1) und wird ausgeliefert.
• Ein Partner entwickelt nun auf Basis dieser Auslieferung eine Branchenlösung und passt das Business Object an. Damit hat es in der entwickelten Branchenlösung des Partners die Versionsnummer 1.0.1.0.0.0 (kurz 1.0.1).
• Nach zwei Korrekturen der Erweiterung durch den Partner im Branchenlösung-Korrektursystem zur ausgelieferten Branchenlösung hat das Business Object die Versionsnummer 1.0.1.2.0.0 (kurz 1.0.1.2)
• .
• Im Kundenadaptionssystem für einen konkreten Kunden, dass auf der Partner-Branchenlösung basiert, wird das Business Object nochmals geändert. Damit hat es in diesem System die Versionsnummer 1.0.1.2.0.1.
• Im Kundenadaptionssystem für einen konkreten Kunden, das auf der Standardauslieferung der Comarch Software und Beratung AG basiert, wird ein Business Object geändert. Damit hat es in diesem System die Versionsnummer 1.0.0.0.0.1.

 

^[1]Besteht kein Entwicklungsauftrags-Dienst, startet der Entwicklungsablauf mit diesem Schritt.

 

^[2]Eine Beziehung kann als Quelle außer einem Business Object auch einen Part, einen View oder eine Extension haben. Zur Vereinfachung werden Beziehungen nur zwischen Business Objects beschrieben.

 

^[3]Stringtables sind eine von mehreren Möglichkeiten diese Aufgabe im ERP-System zu erledigen. Nach Möglichkeit sollten die spezialisierten Entwicklungsobjekte wie logische Datentypen, Actions und Value Sets benutzt werden. Stringtables sollten nur eingesetzt werden, wenn die anderen Möglichkeiten ungeeignet sind.