1                     Themenübersicht

Business Objects können nur in einem Entwicklungssystem angelegt und verändert werden. Änderungen an Business Objects müssen mithilfe von Softwareaktualisierungen vom Entwicklungssystem über das Testsystem in das Produktivsystem übertragen werden. In den folgenden Fällen ist dieses Vorgehen zu statisch:

• Weitere Felder an Business Entitys
• Artikelmerkmale
• Produktionsparameter

Allen diesen Fällen ist gemeinsam, dass während des laufenden Betriebs neue Felder zum Schema eines Business Objects hinzugefügt werden müssen oder aber neue Business Objects angelegt werden müssen. Zu diesem Zweck unterstützt Semiramis dynamische Business Objects. Das Schema eines dynamischen Business Objects kann durch den Persistenzdienst in jedem System zu jeder Zeit angelegt und geändert werden. Der Lese- und Schreibzugriff auf den Inhalt eines dynamischen Business Objects erfolgt analog zum Zugriff auf normale Business Objects über den Persistenzdienst. Der Zugriff auf dynamische Business Objects ist ähnlich performant wie der Zugriff auf Business Object.

Semiramis kann dynamische Business Objects auf mehrere Arten speichern:

• Speicherung als Datenbanktabelle

Für jedes dynamische Business-Object-Schema werden eine oder mehrere Datenbanktabellen angelegt, in der die Instanzen des dynamischen Business Objects gespeichert werden.

• Speicherung als BLOB

Die Instanzen des dynamischen Business Objects werden in BLOBs gespeichert.

Die Typen unterscheiden sich insbesondere in den Suchmöglichkeiten und dem Speicherbedarf. Je nach Anwendungsfall muss entschieden werden, welche Art der Speicherung vorteilhafter ist.

Wenn dynamische Business Objects in Datenbanktabellen gespeichert werden, können Sie die Attribute in den anpassbaren Suchen und den individuellen Indizes verwenden.

2                     Zielgruppe

• Entwickler
• Technische Berater

3                     Begriffsbestimmung

Dynamisches Business Object

Ein dynamisches Business Object entspricht einem Business Object, kann aber im Unterschied dazu auf jedem System zu jeder Zeit erstellt und verändert werden.

Jedes dynamische Business Object wird durch sein Schema beschrieben. Das Schema enthält unter anderem Informationen, welche Attribute das dynamische Business Object besitzt und welchen Datentyp diese haben. Das Schema entspricht der Beschreibung eines Business Objects als Entwicklungsobjekt.

Eine Instanz eines dynamischen Business Objects ist eine Ausprägung des zugehörigen Schemas. Der Persistenzdienst kann Instanzen dynamischer Business Objects lesen, speichern und löschen. Zu einem Schema können beliebig viele Instanzen existieren. Die Instanzen dynamischer Business Objects können entweder in gemäß dem Schema erzeugten Datenbanktabellen oder aber auch als BLOBs gespeichert werden.

4                     Beschreibung

Die Anwendungen, die dynamische Business Objects verwenden, verwalten das Schema und die Instanzen der dynamischen Business Objects. Im Unterschied zu den Business Objects wird das Schema eines dynamischen Business Objects nicht durch eine zentrale Anwendung (wie z. B. die Anwendung „Entwicklungsobjekte“) verwaltet. Jede Anwendung, die dynamische Business Objects verwendet, verwaltet unter Umständen auch das Schema der dynamischen Business Objects.

Das Schema eines dynamischen Business Objects ist OLTP spezifisch. Das bedeutet, dass das Schema eines dynamisches Business Object nur auf genau einer OLTP-Datenbank existiert. Das Schema eines dynamischen Business Objects kann nicht mit Softwareaktualisierungen an andere Systeme ausgeliefert oder auf andere Datenbanken kopiert werden.

4.1               Unterstützte Datentypen

Dynamische Business Objects unterstützen die folgenden Datentypen als Attribute:

Jedes Attribut kann einzelner Wert oder als Werteliste angelegt werden.

4.2               Speicherung

Die Art der Speicherung der dynamischen Business Objects bestimmt die Zugriffsmöglichkeiten auf das dynamische Business Object.

4.2.1          Speicherung als Datenbanktabelle

Wenn ein dynamisches Business Objects als Datenbanktabelle gespeichert werden soll, dann werden für jedes Schema eine oder mehrere Datenbanktabellen angelegt. In diesen Datenbanktabellen werden die Instanzen gespeichert. Die Anzahl der Datenbanktabellen hängt von der Anzahl und der Größe der Attribute im Schema ab.

Zum Laden des dynamischen Business Objects erfolgt ein Lesezugriff auf jede zugehörige Datenbanktabelle. Wenn das dynamische Business Object sehr viele Attribute oder Wertelisten hat, so gehören entsprechend viele Datenbanktabellen zu dem dynamischen Business Object. Um den lesenden Zugriff auf die Instanzen des dynamischen Business Objects zu beschleunigen, wird das dynamische Business Object ab einer bestimmten Tabellenanzahl redundant als BLOB gespeichert. Die redundante Speicherung als BLOB ermöglicht es, das dynamische Business Object mit einem Datenbankzugriff zu laden. Beim Schreiben des dynamischen Business Objects wird jedoch ein Datenbankzugriff mehr benötigt.

Die Verteilung der Attribute auf die Datenbanktabellen hat einen großen Einfluss auf die Antwortzeiten bei Suchanfragen. Alle Tabellen, die die für eine Suchanfrage benötigten Attribute enthalten, müssen mit der Suchanfrage verknüpft werden. Um die Anzahl der Joins zu reduzieren, ist es sinnvoll, die Anzahl der für eine Suchanfrage benötigten Datenbanktabellen möglichst klein zu halten.

Jedem Attribut kann optional der Pfad einer Klassifikation (z.B. „x-y-01“) zugeordnet werden. Attribute mit der gleichen Klassifikation werden vorzugsweise in der gleichen Datenbanktabelle gespeichert. Wenn also bereits zum Generierungszeitpunkt des dynamischen Business Objects bekannt ist, welche Attribute wahrscheinlich gemeinsam genutzt werden, dann sollten diese gemeinsam genutzten Attribute die gleiche Klassifikation haben.

Beispiel:

Die Artikelmerkmale werden in dynamischen Business Objects gespeichert und jedes Merkmal ist einer Klassifikationen aus der Artikelmerkmalsklassifikation zugeordnet. Bei der Suche von Artikeln nach Artikelmerkmalen muss zunächst die Klassifikation gewählt werden. Danach kann nur nach den Merkmalen gesucht werden, die der ausgewählten Klassifikation bzw. einem Präfix davon zugeordnet sind (z.B. wenn „x-y-01“ ausgewählt wurde, dann werden auch die Merkmale der Klassifikationen „x-y“ und „x“ berücksichtigt.)

4.2.1.1      Vorteile der Speicherung als Datenbanktabelle

• Auf den Instanzen kann gesucht werden. Die Attribute können in anpassbaren Suchen verwendet werden.
• Es können Indexe zur Zugriffsoptimierung angelegt werden.
• Das dynamische Business Object kann beispielsweise für die „weiteren Felder“ als Erweiterung mit bestehenden Business Objects verknüpft werden.
• Auf die Inhalte des dynamische Business Object kann mit OQL zugegriffen werden.

4.2.1.2      Nachteile der Speicherung als Datenbanktabelle

• Erhöhter Speicherplatzbedarf auf der Datenbank.
• Erhöhter Zeitbedarf für die Generierung der Datenbanktabellen.

4.2.2          Speicherung als BLOB

Wenn ein dynamisches Business Objects als BLOB gespeichert werden soll, dann werden alle Instanzen des dynamischen Business Objects in einer Tabelle mit einem BLOB gespeichert.

4.2.2.1      Vorteile der Speicherung als BLOB

• Geringer Speicherbedarf auf der Datenbank.
• Geringer Zeitbedarf für das Neuanlage oder das Ändern eines Schemas.

4.2.2.2      Nachteile der Speicherung als Datenbanktabelle

• Keine Suchmöglichkeiten auf den Instanzen.
• Das dynamische Business Object kann nicht als Erweiterung mit bestehenden Business Objects verknüpft werden.
• Auf die Inhalte des dynamische Business Object kann nicht mit OQL zugegriffen werden.

4.2.3          Wahl der Speicherung

Die Entscheidung, wie ein dynamisches Business Object gespeichert wird, hängt vom konkreten Anwendungsfall ab. Aus diesem Grund werden, die im Standard relevanten Anwendungsfälle nach den folgenden Kriterien klassifiziert:

Klassifikation der Anwendungsfälle gemäß den oben genannten Kriterien:

Aus diesen Kriterien kann ableitet werden, ob ein dynamisches Business Object als Datenbanktabelle oder als BLOB gespeichert werden soll. Insbesondere ist entscheidend, ob auf den Instanzen gesucht werden soll. Suchen ist nur möglich, wenn das dynamische Business Object in Datenbanktabellen gespeichert wird.

Die Anzahl der Schemata in Kombination mit der Anzahl der Attribute und Instanzen ergibt den maximal benötigten Speicherplatzbedarf. Bei der Speicherung als Datenbanktabelle wird insbesondere bei einer geringen Ausprägungsdichte dieser Speicher nicht optimal genutzt, da auch Speicher für die nicht ausgeprägten Attribute einer Instanz benötigt wird. Bei der Speicherung als BLOB benötigen nicht ausgeprägte Attribute keinen Speicherplatz.

Die „weiteren Felder“ und die „Artikelmerkmale“ werden als Datenbanktabelle gespeichert und die Parameter für die Produktion als BLOB.

4.3               Einbindung in das System

Dynamische Business Objects sind ein Teil der System-Engine von Semiramis und werden durchgehend unterstützt:

Weitere Informationen zu der Unterstützung von dynamischen Business Objects entnehmen Sie der Dokumentationen zu diesen Bereichen.

4.4               Programmierung in Anwendungen

Das Schema eines dynamischen Business Objects enthält nur die für den Persistenzdienst notwendigen Daten. Für die Programmierung in betriebswirtschaftlichen werden weitere Informationen für die Darstellung an der Oberfläche sowie für die Konsistenzprüfung der Eingaben benötigt.

In dem Namensraum „com.cisag.app.general.extension“ finden Sie, die für den Zugriff auf dynamische Business Objects, notwendigen Klassen.

Der Schemaname des dynamischen Business Objects, das die weiteren Felder speichert, leitet sich aus dem Namen des Business Objects ab. Der Schema-name beginnt mit „EXT“, gefolgt vom Namen des Business Objekcs ohne des-sen Namensraum. Wenn das Business Object in einem anderen Namensraum als com.cisag liegt, dann wird der zweite Teil des Namensraums in Großbuch-staben zwischen EXT und dem Business Object-Namen eingefügt.

Beispiele:

Wenn die weiteren Felder mit einem Semiramis 4.2-System mit einem Stand älter als PC-01 angelegt wurden, dann kann statt Präfixes EXT auch das Präfix EXTCISAG verwendet worden sein. Der Schemaname beispielsweise für das Business Object com.cisag.app.general.obj.Item kann somit statt EXTItem in einigen wenigen Fällen auch EXTCISAGItem lauten.

4.5               Schnittstelle zum Persistenzdienst

Die Programmierschnittstelle zum Persistenzdienst ist unterteilt in die Verwaltung der Schemata der dynamischen Business Objects und in den Zugriff auf die Instanzen. Meist wird in Anwendungen die Persistenzdienst-Schnittstelle nicht direkt verwendet, sondern die Schnittstelle im Namensraum „com.cisag.app.general.extension“.

Der direkte Zugriff auf den Persistenzdienst liefert zwar wegen der fehlenden Zwischenschicht eine bessere Performance, hat aber den Nachteil, dass keine Informationen zur Darstellung oder Prüfung der Attribute hinterlegt werden können.

4.5.1          Schemata anlegen, ändern und löschen

Zur Verwaltung der Schemata dienen die folgenden Klassen im Namensraum „com.cisag.pgm.appserver“:

Beim Ändern und Löschen eines Schemas wird die komplette Ausprägung des Schemas gesperrt. Alle anderen Sessions, die während der Änderung auf die Instanzen des dynamische Business Object lesend oder schreibend zugreifen wollen, warten auf die Sperre. Da je nach System und Größe des dynamischen Objektes die Änderung des Schemas einige Zeit dauern kann, können die wartenden Sessions eine Timeout-Exception bekommen.

Das Hinzufügen neuer Attribute kostet abhängig von der Anzahl der Instanzen zu dem Schema deutlich mehr Zeit, wenn ein Defaultwert für das neue Attribut hinterlegt wurde. Schemaänderungen dauern bei der Speicherung als Datenbanktabelle länger als bei der Speicherung als BLOB.

Es gibt die folgenden Typen von dynamischen Business Objects:

Wenn das Schema in Datenbanktabellen gespeichert wird und zu viele Datenbanktabellen benötigt werden, so wird der Inhalt des dynamischen Business Objects einmalig pro Schema beim Generieren in den redundanten BLOB umkopiert.

Sofern bei Attributen Klassifikationen angegeben worden sind und das dynamische Business Object redundant in einem BLOB gespeichert wird, wird beim Generieren des Schemas geprüft, auf wie viele Datenbanktabellen Attribute mit der gleichen Klassifikation verteilt werden. Wenn die Attribute unnötigerweise auf zu viele Datenbanktabellen verteilt worden sind, werden die Datenbanktabellen gelöscht, die Attribute neu verteilt und der Inhalt der Datenbanktabellen aus dem redundanten BLOB erneut aufgebaut.

Das Dokument Semiramis-Properties beschreibt Properties mit denen Sie die Schwellwerte zur Verwendung des redundanten BLOBs und zur Neugenerierung aufgrund der Verteilung der Attribute einstellen können.

4.5.1.1      Ablauf zum Ändern eines Schema

Der Ablauf beim Ändern eines Schemas ist wie folgt:

1. Schema vom Schema-Manager zum Ändern laden oder neu erzeugen.

Verwenden Sie eine der Methoden getSchema, createSchema oder createExtensionSchema, um ein Schema zu laden bzw. neu zu erzeugen.

2. Schema verändern oder erweitern.

Sie können das Schema direkt modifizieren. Die Modifikation des Schemas wird erst mit dem Generieren persistent.

3. Schema mit dem Schema-Manager generieren.

Generieren Sie das Schema mit der Methode update am Schema-Manager. Das Schema wird in einer eigenen Top-Level-Transaktion generiert. Sie können erst nach der Schema-Generierung Instanzen mit dem neuen Schema erzeugen oder ändern.

4.5.1.2      Beispiel für die Neuanlage eines Schemas

Beispiel für die Neuanlage eines Schemas für ein dynamisches Objekt mit dem Attribut NAME vom Typ „Zeichenkette ohne Defaultwert“:

CisEnvironment env =

CisEnvironment.getInstance();

CisDynamicObjectSchemaManager dosm =

env.getDynamicObjectSchemaManager();

// create schema

CisDynamicObjectSchema schema = dosm.createSchema(

“TestSchema”,

CisDynamicObjectSchema.DataKind.MASTER_DATA,

CisDynamicObjectSchema.StorageType.STORAGE_BLOB,

CisDynamicObjectSchema.CacheStrategy.LRU);

// add attribute

schema.addColumn(

“NAME”,

CisDynamicObjectSchema.DataType.STRING,

CisDynamicObjectSchema.Cardinality.VALUE,

(short)20,

null);

// generate schema

dosm.updateSchema(schema);

4.5.2          Zugriff auf Instanzen

Die Instanzen dynamischer Business Objects können analog zu den Instanzen von Business Objects über den CisObjectManager mit den Methoden getObject bzw. getObjectArray geladen, mit putObject geschrieben und deleteObject gelöscht werden.

Zum Zugriff auf die Instanzen von dynamischen Business Objects dienen die folgenden Klassen im Namensraum „com.cisag.pgm.datatype“:

Damit Änderungen an dynamischen Business Objects im Änderungsjournal aufgezeichnet werden können, muss die geänderte Instanz des dynamischen Business Objects einer Business Entity Instanz zugeordnet werden können. Bei Objekterweiterungen zu Business Entitys kann diese Beziehung automatisch hergestellt werden. In allen anderen Fällen muss die Beziehung beim Ändern des dynamischen Business Objects explizit gesetzt werden. Die Beziehung wird mit Hilfe der Methode

void set_entityKey(byte[] entityTimeDependentKey)

hergestellt. Wenn das Entity zeitabhängig ist, muss der zeitabhängige, ansonsten der normale Primärschlüssel am dynamischen Business Object gesetzt werden. Genauso kann bei einem dynamischen Business Object auch der Instanz-String gesetzt werden:

void set_instanceString(String instanceString)

Der Entity-Key und der Instanzstring müssen an der Instanz des dynamischen Business Objects gesetzt werden, bevor die Instanz mit putObject an Transaction-Manager übergeben wird.

4.5.3          Zugriff mit OQL

Auf Objekterweiterungen können Sie über den Persistenzdienst mit OQL zugreifen. Wird in diesem Abschnitt von Dynamischen Business Objects gesprochen, so sind Objekterweiterungen gemeint.

Dynamische Business Objects werden in OQL ähnlich zu normalen Business Objects behandelt. Eine Left-Outer-Join zwischen dem Business Object und einem Dynamischen Business Object können Sie mit dem OQL-Schlüsselwort DYNAMIC_OBJECT herstellen. In der ON-Klausel werden jeweils nur die Aliase verglichen.

Sie können nur das Business Object mit der zu diesem Business Object gehörigen Objekterweiterung mit einem Join verknüpfen. Sie können beispielsweise com.cisag.app.general.obj.Partner mit der Objekterweiterung EXTPartner verknüpfen aber nicht mit der Objekterweiterung EXTCustomer, die zu dem Business Object com.cisag.app.sales.obj.Customer gehört.

Die technischen Namen der Attribute eines dynamischen Business Objects können Sie direkt in OQL verwenden. Wenn ein Attribut des dynamischen Business Objects vom Typ Primärschlüssel ist, so können Sie auf die Primärschlüsselattribute des referenzierten Business Entitys mit <Feldname>.<Primärschlüsselattribut> in OQL zugreifen, z. B. PARTNER.guid. Wenn ein Attribut einen Part (Menge, Betrag…) als Datentyp hat, so können Sie auf die Attribute des Parts wie üblich mit <Feldname>.<Part-Attribut> in OQL zugreifen, z. B. QUANTITY.amount.

Bei Wertelisten können Sie beim Join den Namen des Wertelisten-Feldes in Klammern hinter den Namen des dynamischen Business Objects schreiben. In diesem Fall wird nicht die Tabelle des dynamische Business Objects, sondern die Tabelle der Werteliste mit dem Business Entity verknüpft. Das Attribut „_code“ enthält den Code der Werteliste. Über den Code kann beispielsweise sortiert werden. Die Werte können wie bei Attributen vom Typ Wert abgefragt werden, das „_code“-Attribut muss in Anführungszeichen gesetzt werden.

Weitere Informationen finden Sie in dem Dokument OQL-Syntax.

Beispiel:

Das dynamische Business Object EXTPartner enthält die weiteren Felder des Business Entitys Partner. EXTPartner hat die folgenden Felder:

Sie können auf die Attribute vom Typ Wert wie folgt zugreifen:

SELECT p:guid, pe:MY_STR, pe:MY_PARTNER.guid, pe:MY_QUANTITY.amount

FROM com.cisag.app.general.Partner p DYNAMIC_OBJECT JOIN

EXTPartner pe ON p=pe

Sie können auf die Attribute vom Typ Werteliste wie folgt zugreifen:

SELECT p:guid, pe:“_code“, ep:MY_STR_LIST

FROM com.cisag.app.general.Partner p DYNAMIC_OBJECT JOIN

EXTPartner(MY_STR_LIST) pe ON p=pe

SELECT p:guid, pe:“_code“, pe:MY_PARTNER_LIST.guid

FROM com.cisag.app.general.Partner p DYNAMIC_OBJECT JOIN

EXTPartner(MY_PARTNER_LIST) pe ON p=pe

SELECT p:guid, pe:“_code“,

pe:MY_QUANTITY_LIST.uom, pe:MY_QUANTITY_LIST.amount

FROM com.cisag.app.general.Partner p DYNAMIC_OBJECT JOIN

EXTPartner(MY_QUANTITY_LIST) pe ON p=pe