Für einfache Business-Entitys ist der Datenaustausch unter bestimmten Bedingungen ohne weiteren Entwicklungsaufwand möglich, da der Business Integration Service (BIS) einen generischen Import und Export unterstützt. In vielen in der Praxis vorkommenden Fällen ist jedoch eine Entwicklung eines Controllers sinnvoll und notwendig, um ein Business-Entity für den Datenaustausch verfügbar zu machen.

Dieses Dokument erläutert die grundlegenden Vorgehensweisen bei der Implementierung eines Controllers und gibt Hinweise für die Verwendung des entsprechenden API, das Semiramis hierfür bereitstellt.

1                     Zielgruppe

• Anwendungsentwickler

2                     Begriffsbestimmung

Controller

Der Controller ist eine Java-Klasse, die den Import bzw. Export eines Business Entitys realisiert. Die zugehörigen Schnittstellen sind durch die Java-Interfaces „com.cisag.pgm.bi.ImportController“ und „com.cisag.pgm.bi.ExportController“. Der Controller liefert das für den Import bzw. den Export zu verwendende Datenmodell und bestimmt damit die Menge der für das Business Entity zur Verfügung stehenden Objekte, Attribute und Beziehungen. Das Datenmodell kann dabei für den Import und für den Export unterschiedlich sein. Für einfache Business Entitys kann der Import bzw. der Export auch ohne vorhandenen Controller und kann somit generisch erfolgen.

Korrektur-Anwendung

Die Korrektur-Anwendung ist diejenige Dialog-Anwendung, die verwendet wird, um einfache Fehler-Dateien interaktiv in Semiramis zu bearbeiten. Zu einem Business Entity kann eine oder können mehrere Korrektur-Anwendungen existieren. Im Allgemeinen ist die Korrektur-Anwendung die jeweilig zum Business Entity gehörende Anwendung (z. B. die Anwendung „Partner“ für das Business Entity „com.cisag.app.general.obj.Partner“), die in einem speziellen Modus geöffnet wird. In diesem Modus können die Business-Entity-Instanzen aus der Fehler-Datei einzeln geöffnet, interaktiv bearbeitet und gespeichert werden.

3                     Entwicklung von Controllern

3.1               BIS-Controller

Ein Controller ist eine Java-Klasse, die den Import und Export für ein bestimmtes Business-Entity realisiert. Diese Java-Klasse muss eine oder beide der folgenden Interfaces implementieren:

• Ein Controller, der den Export unterstützen soll, implementiert das Interface „cisag.pgm.bi.ExportController“.
• Ein Controller, der den Import unterstützen soll, implementiert das Interface „cisag.pgm.bi.ImportController“.
• Ein Controller, der Export und Import unterstützen soll, implementiert beide Interfaces.
• Soll für ein Business-Entity der Export und Import unterstützt werden, aber der Import nur einen Ausschnitt des Datenmodells des Exports beinhalten, implementieren Sie den Import- und den Export-Controller in zwei verschiedenen Klassen, um ein unterschiedliches Datenmodell angeben zu können.

Die Java-Klassen, die diese Interfaces implementieren, müssen als Controller registriert werden. Diese Registrierung ist in Abschnitt 4.4 beschrieben.

3.2               Aufbau des BIS-Datenmodells

3.2.1          ObjectInfo

Jeder Controller definiert das BIS-Datenmodell, das beim Import bzw. Export verwendet wird. Das BIS-Datenmodell gibt die Struktur der importierten bzw. exportierten Daten vor.

Ein Controller definiert sein BIS-Datenmodell durch Implementieren der Methode

ObjectInfo getObjectInfo()

Für die Definition des BIS-Datenmodells verfolgen die Controller im Allgemeinen die Strategie, das Datenmodell soweit wie möglich anhand der Objektbeschreibung  des Business-Objekts in der Repository-Datenbank aufzubauen. Dies kann für ein Business-Entity durch die Verwendung Klasse „com.cisag.pgm.bi.model.CisObjectInfo“ erreicht werden.

CisObjectInfo info= new CisObjectInfo(<BusinessObject>.class);

Diese Objekt-Info kann nun noch abgeändert werden. Es ist möglich, Attribute oder Beziehungen zu entfernen, Nicht-Dependent-Beziehungen zu Dependent-Beziehungen zu machen, neue Descriptoren zu registrieren, und die Reihenfolge der Attribute oder Beziehungen zu ändern. Die Methoden hierfür sind an der Oberklasse „com.cisag.pgm.bi.model.DefaultObjectInfo“ der Klasse „CisObjectInfo“ definiert.

Beachten Sie beim Erzeugen bzw. Abändern des BIS-Datenmodells folgendes:

• Nicht benötigte Attribute und Beziehungen sollten unbedingt aus dem Datenmodell entfernt werden. Damit wird das Datenmodell kleiner und leichter verständlich.
  Beispielsweise entstehen durch Verwendung der Klasse „CisObjectInfo“ häufig rückwärtige Beziehungen von Dependent zum Hauptobjekt. Diese werden vom BIS nicht gebraucht und sollten daher entfernt werden.
• Jede nachträgliche Änderung an der Objekt-Info ist eine Änderung am BIS-Datenmodell und muss auf Kompatibilität zum vorigen Stand des Datenmodells geprüft werden muss. Dies trifft auch für Änderungen an Business-Objekten zu.

3.2.2          DataViewBIS

Ein DataViewBIS ist ein Zusatz an einem Objekt-Info-Knoten, und ermöglicht die Erweiterung des Controllers durch Controller-abhängige BIS-Hooks.

Hierzu kann ein Knoten wie folgt mit einem DataViewBIS versehen werden:

DataViewBIS.create( info);

Der DataViewBIS muss auch in der Export- bzw. Importverarbeitung des Controllers berücksichtigt werden. Beachten Sie hierzu die Hinweise in den nächsten Abschnitten.

3.3               Export und Import

3.3.1          Ablauf eines Exports

In einem Exportvorgang werden die zu exportierenden Business-Entity-Instanzen durch die gewählte Eingrenzung bestimmt, die entweder durch eine OQL-Suche oder einer OQL-Anweisung erfolgt.

Der Controller wird für den Export jeder Business-Object-Instanz die Methode

boolean process(Target target, Object obj)

aufgerufen. Mit dem Parameter „target“ wird ein Ziel-Objekt (Interface „com.cisag.pgm.bi.Target“) übergeben, mit dem Daten in die Ziel-Datei geschrieben werden können. Im Parameter „obj“ wird eine Instanz des Hauptobjekts übergeben, in der die Attribute des Primärschlüssels und des Business Key gefüllt sind. Mit Hilfe der Werte in diesen Attributen muss der Controller die Business-Entity-Instanz öffnen. Die Werte die Nicht-Schlüssel-Attribute sind undefiniert, und sollten nicht verwendet werden.

Die Implementierung der Methode „process()“ im Controller muss alle Objekte, die zur Business-Entity-Instanz gehören, in das übergebene „target“ schreiben. Hierfür wird eine Instanz der Klasse „DefaultSerializer“ („com.cisag.pgm.bi.helper.DefaultSerializer“) verwendet.

Die Verarbeitung, die der Controller in einem Aufruf der Methode „process()“ durchführen muss, folgt dem Muster in folgendem Java-Quellcode. Dabei wird vorausgesetzt, dass der Controller eine Instanz „serializer“ der Klasse „DefaultSerializer“ erzeugt hat und die Objekte „target“ und „obj“ Parameter der Methode „process()“ sind. Eine Erläuterung folgt weiter unten.

CisObject loadedObject;

Map lodedObjectNLS;

// Öffen des Objektes und seiner NLS-Daten durch CisObjectManager.
// Die Werte der Schlüsselattribute sind im Parameter obj enthalten

…

// Schreiben des Objekte

serializer.write(target, loadedObject, lodedObjectNLS);

// Dependent-Beziehungen des Filters durchgehen

AssiciationDescriptor[] assocs= target.getAssociations();

for (int i = 0; i < assocs.length; i++) {

AssociationDescriptor assoc = assocs[i];

if(DEPENDENT1.equals(assoc.getName())) {

// Dependent-Beziehung schreiben

Iterator it= …

while( it.hasNext()) {

Object childObj= it.next();

Map childNLS= …

Target child= target.child(DEPENDENT1);

serializer.write( child, childObj, childNLS);

// Hier evtl. untergeordnete Dependents schreiben

}

} else if(…) ….

// Hier nächste Dependent-Beziehung schreiben

}

Beachten Sie hierbei Folgendes:

• Zunächst muss der Controller das Hauptobjekt schreiben, danach die Dependents, sofern das BIS-Datenmodell des Business-Entitys Dependents enthält.
• Für die Unterstützung des mehrsprachigen Exports müssen Instanzen der Klasse „NLSData“ bereitgestellt werden.
• Die Benutzung der Klasse „DefaultSerializer“ ist in einem eigenen Abschnitt beschrieben.
• Einfach-Beziehungen zu Nicht-Dependent-Objekten dürfen nicht vom Controller selbst geschrieben werden, da dies bereits von der Klasse „DefaultSerializer“ erledigt wird.

Speziell für Dependent-Beziehungen ist Folgendes zu beachten:

• Die Dependent-Beziehungen müssen immer in derselben Reihenfolge geschrieben werden, in der sie im Datenmodell des Controllers auftreten, und dürfen nur dann geschrieben werden, wenn sie im Filter ausgewählt sind. Beides wird durch die „for“- Schleife erreicht.
• Bei Mehrfach-Dependents werden die einzelnen Instanzen nacheinander geschrieben. Der Controller gibt hierbei die Reihenfolge vor, in der die Dependent-Instanzen in der Ziel-Datei stehen. Dies wird durch die „while“-Schleife erreicht.
• Für jede zu schreibende Dependent-Instanz muss eine neue Instanz von „Target“ mit der Methode „child()“ erzeugt werden.
• Falls ein Dependent selbst wieder Dependents besitzt, müssen diese nach dem Aufruf der Methode „write()“ des Dependents geschrieben werden.

Unterstützung von Hooks:

• Falls ein DataViewBIS vorhanden ist, sollte eine Objektsicht auf das zu exportierende Objekt als Kontextwert am DataViewBIS gesetzt werden. Ein Beispiel finden Sie in der Klasse SingleObjectEntityController.
• Falls ein DataViewBIS vorhanden ist und der DependentAssociationHook unterstützt werden soll, muss die Verarbeitung von Dependents an der Klasse „DataViewBIS“ aufgerufen werden (Methoden isExtensionDependent() und processDependentExport()). Ein Beispiel findet sich ebenfalls im SingleObjectEntityController.

3.3.2          Ablauf eines Imports

In einem Importvorgang wird für jede zu importierende Business-Entity-Instanz aus der Quell-Datei die Methode

boolean process(Source source)

am Controller aufgerufen. Mit dem Parameter „source“ wird ein Quell-Objekt (Interface „com.cisag.pgm.bi.Source“) übergeben welches die Daten der zu importierenden Business-Entity-Instanz beinhaltet.

Der Controller muss die in dem Quell-Objekt enthaltenen Objekte zunächst einlesen und sie prüfen. Hierbei wird analog zum Export zunächst das Hauptobjekt eingelesen, und danach die Dependents. Konnte die gesamte Business-Entity-Instanz erfolgreich geprüft werden, wird sie in die Datenbank geschrieben. Beachten Sie, dass der genaue Ablauf auch vom Business-Entity abhängt.

Für die Erweiterbarkeit des Controllers durch Hooks gilt sinngemäß dasselbe wie beim Export.

Ein Beispiel für eine Implementierung der Methode „boolean process(Source source)“ steht im Java-Quellcode sich in der Klasse „com.cisag.app.general.log.SingleObjectEntityController“ zur Verfügung.

3.3.2.1      Einlesen eines Objekts

Der allgemeine Ablauf für das Einlesen eines Objekts ist wie folgt:

1. Der Controller besitzt oder erzeugt eine transiente, leere Instanz einer Unterklasse des Klasse „CisObject“ für das einzulesende Objekt.
2. Mit einer Instanz der Klasse „DefaultSerializer“ werden die Daten aus der Instanz der Schnittstelle „Source“ in das Objekt eingelesen, um die Schlüssel-Attribute zu erhalten.
3. Der Controller muss nun feststellen, ob es sich bei dem Import um eine Neuanlage oder Aktualisierung handelt. Falls es sich um eine Aktualisierung handelt, lädt er die bisher vorhandenen Daten von der Datenbank.
4. Mit der Instanz der Klasse „DefaultSerializer“ werden die Daten erneut der Instanz der Schnittstelle „Source“ in das Objekt eingelesen, um die mit dem Import zu ändernden Daten zu erhalten. Das Objekt hat nun den Zustand erreicht, der später in die Datenbank geschrieben wird.

Die Benutzung der Klasse „DefaultSerializer“ ist in Abschnitt 4.2.3 näher erläutert.

Beachten Sie hierbei Folgendes:

• Der Importmodus, der durch die Instanz der Schnittstelle „Source“ vorgegeben wird, muss beachtet werden. Abhängig vom Modus ist es beispielsweise nicht erlaubt, Neuanlagen oder Aktualisierungen durchzuführen.
  Der Importmodus wird mit der Methode „int Source.getMode()“ abgefragt, die Konstanten für die unterschiedlichen Importmodi sind in der Klasse „cisag.pgm.bi.Mode“ definiert.
• Nach dem zweimaligen Einlesen des Objekts muss für ein neu zu erzeugendes Objekt für alle mehrsprachigen Attribute die Methode
  „applyDefaults( CisObject obj ) “
  aufgerufen werden. Hiermit werden nicht angegebene Sprachen in mehrsprachigen Attributen mit einem angegebenen Wert einer anderen Sprache vorbelegt. Für ein mehrsprachiges Attribut einer Instanz „obj“ einer Unterklasse der Klasse „CisObject“ ist und einer Instanz „nlsData“ der Klasse „NLSData“ ist der Ablauf somit:
  if (!obj.is_persistent()) {
  nlsData.applyDefaults( obj);
  }
• Ist durch den Importmodus das Löschen des Objekts oder der Business-Entity-Instanz vorgegeben worden, ist Schritt 4 nicht erforderlich.

3.3.2.2      Prüfungen und Fehlerbehandlung

Beim Import ist die vollständige Fehlerbehandlung unbedingt durchzuführen. Dies liegt in der Verantwortung des Import-Controllers.

Folgende Prüfungen müssen ausgeführt werden:

• Falls nach dem Aufruf der Methode der Klasse „DefaultSerializer“ die Programm-Message-Queue einen Fehler oder unbestätigte Warnung enthält, liegt ein Importfehler vor.
• Falls die mit dem Importmodus vorgegebene Aktion nicht durchgeführt werden kann, liegt ein Importfehler vor. Der Controller muss in diesem Fall zusätzlich eine Fehlermeldung senden.
• Nach dem Einlesen des Objekts durch die Klasse „DefaultSerializer“ muss der Schritt „Verify“ ausgeführt werden. Dieser Schritt realisiert zusätzliche Prüfungen, die von den AttributeDescriptor-Implementierungen vorgegeben werden. Falls dieser Schritt fehlschlägt, liegt ein Importfehler vor.
• Danach muss die Business-Entity-spezifische Prüfung („Validation“) aufgerufen werden. Dies sind die Prüfungen, die auch beim Speichern in der entsprechenden Dialog-Anwendung durchgeführt werden. Diese Prüfung bezieht sich in Abhängigkeit vom Controller entweder auf das gesamte Busines-Entity oder auf einzelne Objekte. Ist der Aufruf der Prüfung nicht erfolgreich, liegt ein Importfehler vor.

Schlägt eine dieser Prüfungen fehl, muss das im Parameter „source“ übergebene Quell-Objekt durch Aufruf der Methode „invalidate()“ als fehlerhaft markiert werden und danach der Import durch Verlassen der Methode „process(Source)“ mit dem Rückgabewert „false“ und entsprechenden Fehlermeldungen in der Programm-Message-Queue abgebrochen werden.

Erst wenn diese Prüfungen erfolgreich sind, darf die Business-Entity-Instanz in die Datenbank geschrieben werden.

3.3.2.3      Behandlung von Dependents

Nachdem das Hauptobjekt eingelesen und geprüft wurde (aber evtl. vor dem Aufruf der Validation, siehe unter „Prüfungen und Fehlerbehandlung“), müssen die Dependents eingelesen und geprüft werden. Ein Beispiel eines komplexen Business-Entitys mit vielen Dependents finden Sie in der Klasse „com.cisag.app.general.item.log.ImportExport“ in der Methode
„void process(BaseItemEntity base, Target target)“.

3.3.2.4      Schreiben in die Datenbank

Das Schreiben der zu importierenden Business-Entity-Instanzen kann entweder einzeln oder blockweise erfolgen. In beiden Fällen erfolgt die Implementierung hierfür durch den Controller. Das einzelne Schreiben von Business-Entity-Instanzen ist einfacher zu realisieren, während mit blockweisem Schreiben eine bessere Performance bei Massendaten-Importen erreichen lässt.

Erst beim Schreiben in die Datenbank werden nicht-transiente Instanzen einer Unterklasse der Klasse „CisObject“ verwendet.

Einzelnes Schreiben

Einzeln geschrieben wird eine Business-Entity-Instanz immer am Ende der aufgerufenen Methode process( Source) am Import-Controller. Hierfür muss eine eigene Transaktion verwendet werden.

Blockweises Schreiben

Für blockweises Schreiben wird jede Business-Entity-Instanz wie oben beschrieben im jeweiligen Aufruf der Methode „process()“ bearbeitet, jedoch noch nicht in die Datenbank geschrieben. Stattdessen sammelt der Controller die zu schreibenden Daten und schreibt sie erst, wenn eine genügend große Anzahl an Objekte gesammelt wurde ist.

Zum Schreiben eines Blocks von Instanzen muss der Controller eine neue Toplevel-Transaktion öffnen. Zu beachten ist hier, dass der Controller erst alle zu löschenden Instanzen löschen muss, bevor er die zu erzeugenden oder zu aktualisierenden Instanzen schreibt.

3.3.3          Benutzung der Klasse „DefaultSerializer“

Mit Hilfe der Klasse „DefaultSerializer“ werden einzelne Java-Objekte in ein Ziel-Objekt (Interface „Target“) geschrieben, oder aus einem Quell-Objekt (Interface „Source“) in ein Java-Objekt eingelesen.

Die Klasse „DefaultSerializer“ enthält Unterstützung für den mehrsprachigen Export von mehrsprachigen String-Attributen. Beachten Sie, dass ein Controller niemals unterscheiden muss, ob er einen einsprachigen oder einen mehrsprachigen Export durchführt. Er stellt stattdessen immer die für den mehrsprachigen Export benötigten zusätzlichen Daten zur Verfügung.

3.3.3.1      Objekt schreiben

Zum Schreiben eines Objekts beim Export gibt es die folgenden beiden Signaturen der Methode „write()“

void write(Target target, Object obj, Map<String,NLSData> nlsDatas)

void write(Target target, Object obj)

mit denen das übergebene Objekt „obj“ in das übergebene Ziel-Objekt „target“ geschrieben wird.

Falls das zu schreibende Objekt mehrsprachige String-Attribute enthält und der Controller den mehrsprachigen Export unterstützt, muss die erste Signatur verwendet werden, wobei der Parameter „map“ für jedes mehrsprachige String-Attribut eine Instanz der Klasse „NLSData“ („com.cisag.pgm.datatype.NLSData“) enthält. Die Instanzen der Klasse „NLSData“ müssen zu diesem Zeitpunkt gefüllt sein.

Falls das zu schreibende Objekt keine mehrsprachigen String-Attribute enthält, oder der mehrsprachige Export nicht unterstützt wird, wird die untere Signatur verwendet.

Ein Aufruf einer der Signaturen der Methode „write()“ schreibt das Objekt und Einfach-Beziehungen von Nicht-Dependent-Objekten dieses Objekts, nicht jedoch die anderen Beziehungen.

3.3.3.2      Objekt einlesen

Zum Lesen eines Objekts beim Import gibt es die beiden Signaturen der Methode „read()“

void read(Source source, Object obj, Map<String,NLSData> nlsDatas)

void read(Source source, Object obj)

mit denen die Daten eines Objekts aus dem übergebenen Quell-Objekt „source“ in das übergebene Objekt „obj“ eingelesen wird. Für den Parameter „obj“ sollte eine entsprechende transiente Instanz der Unterklasse „CisObject“ verwendet werden.

Falls das zu lesende Objekt mehrsprachige String-Attribute enthält und der Controller den mehrsprachigen Export unterstützt, muss die erste Signatur verwendet werden. Hier muss der Controller zusätzlich eine Instanz des Interface „java.util.Map“ übergeben, die für jedes mehrsprachige String-Attribut dieses Objekts eine Instanz der Klasse „NLSData“ („com.cisag.pgm.datatype.NLSData“) enthält. Diese Instanzen der Klasse „NLSData“ brauchen nicht gefüllt zu sein. Mehrsprachige Attribute werden in der Inhaltssprache der Session in das Objekt „obj“ eingelesen und in allen anderen Sprachen in die zugehörige Instanz der Klasse „NLSData“.

Die untere Signatur wird verwendet, falls ein Objekt keine mehrsprachigen String-Attribute enthält, oder wenn der mehrsprachige Import vom Controller nicht unterstützt wird.

Zusätzlich kann die untere Signatur auch in einem mehrsprachigen Import verwendet werden, wenn nur die Identifikation eines Objekts eingelesen werden soll. Im Sprachmodus „Mehrsprachig“ werden hierbei allerdings mehrsprachige Attribute nicht eingelesen. Durch dieser Möglichkeit muss keine Instanzen der Klasse „NLSData“ bereitzustellen, wenn er die Identifikation des Objektes noch nicht kennt.

3.4               BIS-Hooks

Im Hook-Vertrag „com.cisag.pgm.bi.Controller“ stehen Hooks für die Modifikation von BIS-Controllern zur Verügung.

Ein Teil der Hooks ist Controller-abhängig: Sie können nur in Controllern verwendet werden, deren BIS-Datenmodell einen DataViewBIS enthält. Näheres dazu ist im Abschnitt 4.2.2 beschrieben.

3.4.1          BIS-Datenmodell verändern

Der ObjectInfoExtensionHook bietet die Möglichkeit, Attribute und Beziehungen aus einer ObjectInfo zu entfernen, neue Attribute einzufügen, oder einen AttributeDescriptor zu ersetzen. Eine Hook-Implementierung aus einem Entwicklungssystem kann nur „eigene“ Attribute verändern (Attribute des eigenen Entwicklungspräfix, oder beliebige Attribute innerhalb komplexer Attribute des eigenen Entwicklungspräfix).

Eine Hook-Implementierung wirkt sich auf alle BIS-Controller aus, und beeinflusst dabei die Knoten des BIS-Datenmodells vom Typ eines bestimmten Business-Objekts, das als Hook-Einschränkung angegeben wird. Der Hook wird sowohl für die Business-Entity-Hülle als auch für Fremdbeziehungen aufgerufen; die Hook-Implementierung kann jeweils abfragen, ob der zu verändernde Knoten des BIS-Datenmodells zur Business-Entity-Hülle gehört oder eine Fremdbeziehung ist.

Beispiel: Durch die Hook-Vertrags-Implementierung com.cisag.app.bi.log.PartnerTaxIdentificationNumberAttributeDescriptor wird ein virtuelles Attribut in Knoten des Business Object „Partner“ eingefügt.

Attribute und Beziehungen in Parts des Business-Objekts können ebenfalls verändert werden. Es ist jedoch nicht möglich, in untergeordnete Business-Objekte zu navigieren. Stattdessen muss hierfür eine eigene Hook-Implementierung verwendet werden.

Dependent-Beziehungen können mit diesem Hook, sondern nur mit dem  DependentAssociationHook eingefügt werden.

Hinweis für mehrsprachige String-Attribute aus Business-Objekt-Erweiterungen: In Fremdbeziehungen werden diese Attribute vom BIS automatisch unterstützt. Befinden sie sich jedoch innerhalb des Business-Entitys, so ist entweder eine generische Unterstützung aller mehrsprachigen String-Attribute im Controller erforderlich, oder der Controller muss adaptiert werden. Der Hook kann in diesem Fall nicht verwendet werden.

Den gleichen Zweck hat der DataViewBISHook, der jedoch Controller-abhängig ist. Im Unterschied zum ObjectInfoExtensionHook wirkt er sich nur auf einen einzigen BIS-Controller aus und kann nur Objekte aus der Business-Entity-Hülle. Er bietet aber den Zugriff auf Kontextvariablen, die vom Controller gesetzt werden.

Der DataViewBISHook muss per Hook-Einschränkung auf einen Knoten des BIS-Datenmodells festgelegt werden, der mit einem DataViewBIS versehen sein muss.

Welche Kontextvariablen zur Verfügung stehen, ist abhängig von Controller. In der Regel stellt der Controller eine Objektsicht auf das Objekt als Kontextvariable zur Verfügung, dessen Knoten mit einem DataViewBIS versehen wurde.

3.4.2          AttributeDescriptor ersetzen

Durch den Hook BISRegistryHook kann für die BIS-Registry ein AttributeDescriptor für einen Logischen Datentyp registriert werden. Der AttributeDescriptor wird dann für alle Attribute des logischen Datentyps verwendet. Der logische Datentyp muss dabei aus demselben Entwicklungssystem wie die Hook-Implementierung stammen.

Dieser Hook entspricht der Methode registerAttributeDescriptors(Map<String, String>) der BIS-Registry-Java-Klasse, vermeidet aber Konflikte beim Einspielen von Softwareaktualisierungen.

3.4.3          Dependents hinzufügen

Mit dem DependentAssociationHook kann ein Dependent in das BIS-Datenmodell eines Controllers hinzugefügt werden, sofern der Controller dies unterstützt. Dependents können jedoch nur an Knoten hinzugefügt werden, dessen ObjectInfo mit einem DataViewBIS versehen wurde.

Jede Implementierung dieses Hooks erzeugt einen Dependent, legt den Namen, Kardinalität und die ObjectInfo fest. Sie enthält Methoden zum Schreiben und Lesen des Dependents. Die Verwendung ist im Javadoc der Klasse com.cisag.pgm.bi.hook.DependentAssociationHook dokumentiert.

Der DependentAssociationHook transportiert Daten zwischen einem zustandsbehafteten Hook und der Export-/Importdatei. Zum Laden, Prüfen und Speichern des Dependents ist ein Hook auf Business-Entity-Ebene und eine Implementierung des Hooks erforderlich.

3.5               Die BIS-Registry

Die BIS-Registry enthält Controller, sowie andere Entwicklungsobjekte, die von Controllern verwendet werden. Hierzu ist die BIS-Registry die Gruppen unterteilt, die in der folgenden Tabelle dargestellt sind.

Registry-Gruppen, in denen Entwicklungsobjekte mit einem Business-Objekt als Schlüssel registriert sind, werden im Entwicklungsobjekttyp „Objekt-Beschreibung-Zusatz“ erfasst. In anderen Fällen gibt es einen Hook zur Erfassung der Registry.

Zusätzlich können Entwicklungsobjeke in der Registry-Java-Klasse „com.cisag.app.bi.Registry“ erfasst werden. Die Erfassung im Entwicklungsobjekt hat jedoch Vorrang vor der Registry-Java-Klasse, die in Semiramis 5.0 nur noch verwendet werden sollte, wenn es keine andere Möglichkeit gibt.

Die Erfassung im Entwicklungsobjekt vermeidet Konflikte durch Softwareaktualisierungen, wie sie mit der zentral vorhandenen Registry-Java-Klasse vorkommen. Innerhalb einer App ist nur die Erfassung im Entwicklungsobjekt möglich.

Zur Migration der Registry-Java-Klasse zum Entwicklungsobjekttyp „Objekt-Beschreibung-Zusatz“ kann der Toolshell-Befehl „crtoda“ verwendet werden.

In den folgenden Abschnitten sind einige Registry-Gruppen genauer beschrieben. Eine Beschreibung des Entwicklungsobjekttyps „Objekt-Beschreibung-Zusatz“ finden Sie in der Dokumentation „Entwicklungsobjekte“.

3.5.1          Controller

Controller-Implementierungen müssen registriert werden, um vom BIS verwendet zu werden. Hierbei sind Export und Import zu unterscheiden.

Im Entwicklungsobjekt des Typs Objekt-Beschreibung-Zusatz geben Sie den Export-Controller und den Import-Controller getrennt an, auch wenn es sich um dieselbe Implementierungsklasse handelt. Der Objekt-Beschreibung-Zusatz heißt grundsätzlich genauso wie das Business-Objekt, dass durch den Controller exportiert bzw. importiert wird.

In der Registry-Java-Klasse gibt es folgende Möglichkeiten: In der Methode

public static void registerControllers(Map<String,String> ctrls)

können Sie Controller registrieren, wenn entweder nur ein Export- oder nur ei Import-Controller vorhanden ist, oder wenn beide Controller in der gleichen Klasse implementiert sind.

Demgegenüber können Sie mit den Methoden

public static void registerExportControllers(Map<String,String> eCtrls)

public static void registerImportControllers(Map<String,String> iCtrls)

auch Controller registrieren, die für ein Business-Entity in zwei getrennten Klassen implementiert sind.

Fügen Sie zum Registrieren einen Eintrag in die übergebene Instanz von „java.util.Map“ ein, der den Namen des Business-Entitys als Schlüssel, und den Namen der Controller-Klasse als Wert hat.

3.5.2          OQL-Suchen

Sie können für ein Business-Entity OQL-Suchen registrieren, die für die Eingrenzung beim Export zur Verfügung stehen. Die registrierten Suchen stehen in der Anwendung „Daten exportieren“ auf dem Karteireiter „Eingrenzung“ zur Verfügung.

Falls für ein Business-Entity keine OQL-Suchen registriert sind, ermittelt der BIS selbstständig passende OQL-Suchen. Es wird aber empfohlen, OQL-Suchen zu registrieren.

3.5.3          Korrektur-Anwendungen

Sie können für ein Business-Entity eine Korrektur-Anwendung registrieren. Falls für ein Business-Entity keine Korrektur-Anwendung registriert ist, ermittelt der BIS selbständig die möglichen Korrektur-Anwendungen anhand der Parameter der existierenden Dialog-Anwendungen. Es wird jedoch empfohlen, eine Korrektur-Anwendung zu registrieren, da in den meisten Fällen die automatische Ermittlung auch Anwendungen findet, die nicht als Korrektur-Anwendung verwendet werden können.