ODBC- und JDBC-Schnittstelle

ODBC und JDBC sind Standards für den Zugriff auf Datenquellen, i. d. R. Datenbanken, über eine einheitliche Schnittstelle unter Windows.

Diese Dokumentation beschreibt den Zugriff auf Comarch-ERP-Enterprise-Datenbanken über die Datenbankschnittstellen ODBC und JDBC.

1              Zielgruppe

Das Dokument richtet sich an Programmierer und Berater, die Berichte entwickeln oder mit Fremdprodukten Daten aus Comarch ERP Enterprise abrufen möchten. Dabei liegt der Fokus auf dem Datenmodell der Datenbankschnittstelle von Comarch ERP Enterprise und deren Besonderheiten. Der Inhalt des Dokuments ist auch die Grundlage, um in der Systemlandschaft von Comarch ERP Enterprise Berichte erstellen zu können.

2              Begriffsbestimmungen

ERP-System-ODBC-Treiber

Der ERP-System-ODBC-Treiber ermöglicht den lesenden Zugriff auf die Daten der verschiedenen Datenbanken eines Comarch-ERP-Enterprise-Systems. Hierüber können beispielsweise Reporting-Werkzeuge oder Office-Anwendungen auf diese Daten zugreifen. Dabei werden die im Comarch-ERP-Enterprise-System definierten Berechtigungen auch für Abfragen berücksichtigt.

ERP-System-JDBC-Treiber

Der ERP-System-JDBC-Treiber ermöglicht den lesenden Zugriff auf die Daten der verschiedenen Datenbanken eines Comarch-ERP-Enterprise-Systems. Hierüber können beispielsweise Reporting-Werkzeuge oder Office-Anwendungen auf diese Daten zugreifen. Dabei werden die im Comarch-ERP-Enterprise-System definierten Berechtigungen auch für Abfragen berücksichtigt.

3              Voraussetzungen

Für die Verwendung der ODBC-Schnittstelle muss der ERP-System-ODBC-Treiber auf dem Client-Rechner installiert sein und es muss eine ODBC-Datenquelle eingerichtet sein.

Die Verwendung der JDBC-Schnittstelle erfordert die Installation des JDBC-Treibers.

Außerdem wird vorausgesetzt, dass der Leser

  • Comarch ERP Enterprise aus der Benutzerperspektive kennt,
  • mit den Grundlagen der Datenmodellierung in Comarch ERP Enterprise vertraut ist,
  • mit der Erstellung von Berichten vertraut ist und
  • Kenntnisse in der Datenmodellierung mit relationalen Datenbanken hat.

4              Unterstützte Fremdsysteme zur Erstellung von Berichten

Die ODBC-Schnittstelle wurde mit folgenden Fremdsystemen erfolgreich getestet:

  • Crystal Reports 2013
  • Microsoft Query aus Microsoft Office 2013

 

Folgende Fremdsysteme sollten mit der ODBC-Schnittstelle kompatibel sein, werden aber durch Comarch nicht mehr getestet und nicht unterstützt:

  • Crystal Reports 9, 10, 11, 2008 und 2011
  • Cognos Impromptu 7 und Powerplay
  • Cognos 8 Data Manager
  • Microsoft Query aus Microsoft Office 2007 oder höher

Warnung:
Bei der Verwendung von anderen Fremdsystemen kann es zu Inkompatibilitäten kommen.

5              Datenmodell der Datenbankschnitt­stelle

Die Datenbankschnittstelle bietet ein aufbereitetes Datenmodell an, welches sich an das Modellierungsmodell von Comarch ERP Enterprise anlehnt. Das auf der Datenbank existierende relationale Schema wird zum großen Teil verborgen. Dadurch wird z. B. die Berichtserstellung wesentlich vereinfacht, da bekannte Namen von Business Objects und deren Attributen angezeigt sowie einige modellierte Beziehungen zwischen Business Objects automatisch ausgewertet werden. Dies reduziert erheblich die Anzahl der zu modellierenden Joins im Bericht.

Für die nachstehende beschriebene Aufbereitung des relationalen Schemas wird vorausgesetzt, dass der Leser dieser Dokumentation sich mit Comarch ERP Enterprise, dessen fachlichem Datenmodell und den wichtigsten Modellierungsbegriffen, wie

  • Business Object, Business Entity, Dependent,
  • Relations,
  • Datentypen, Special-Parts,
  • Primärschlüssel und Business Key,

auseinandergesetzt hat.

Der Zugriff auf die Datenbankschnittstelle erfolgt immer im Kontext einer Organisation, die als aktive Organisation bezeichnet wird.

5.1        Tabellennamen

Die Datenbankschnittstelle stellt die in Katalogen organisierten Tabellen zu den auf der Datenbank gespeicherten Business Objects und Views zur Verfügung. Der Hauptkatalog „CISAG“ enthält alle Tabellen, die in Unterkatalogen organisiert sind.

Eine Tabelle eines Business Objects ist nach dessen Typ in einem der Unterkataloge „DEPENDENT“ oder „ENTITY“ eingeordnet. In den Unterkatalogen „VIEW“ und „VIEWOQL“ sind die Tabellen der auf der Datenbank definierten Views und OQL-Views zu finden. Der Unterkatalog „VIRTUAL“ enthält die virtuellen Tabellen, der Unterkatalog „FUNCTION“ die virtuellen Funktionen.

Wenn durch einen Partner selbst entwickelt wurde, werden neue Tabellen entsprechend ihrer Zugehörigkeit in die Unterkataloge aufgenommen.

Die nachstehende Tabelle veranschaulicht die Struktur:

Hauptkatalog Unterkataloge Inhalt
CISAG ENTITY Tabellen der Business Objects vom Typ „Business Entity”.
DEPENDENT Tabellen der Business Objects vom Typ „Dependent“.
VIRTUAL Virtuelle Tabellen
FUNCTION Virtuelle Funktionen
VIEWOQL Tabellen der OQL-Views
VIEW Tabellen der Views

Ein Tabellenname ist aus dem Namen des entsprechenden Business Objects oder Views abgeleitet. Dabei wird der Name des Namensraums um die fixen Bestandteile verkürzt, d. h. es wird „.obj“ und „com.“, bei Comarch-ERP-Enterprise-Objekten „com.cisag.“, weggelassen. Punkte werden durch Unterstriche ersetzt.

Eine Tabelle kann ein Label besitzen. Als Label-Text wird die in der Business Object- oder View-Definition hinterlegte Bezeichnung angezeigt. Die Spalten einer Tabelle sind die Attribute eines Business Objects, der Spaltenname wird aus dem jeweiligen Attributnamen verwendet. Eine Spalte kann ein Label besitzen, welches in der Data-Description des zum Attribut gehörenden logischen Datentyps definiert ist. Die eingestellte Anzeigesprache der Datenquelle bestimmt die Sprache der Labels. Die Berichtsanwendung formuliert auf diesen Tabellen SQL-Statements, um den gewünschten Bericht zu generieren.

Beispiel:
Anhand des Business Object „com.cisag.app.general.obj.Country“ wird dessen Darstellung in der Datenbankschnittstelle gezeigt.
Das Business Object ist vom Typ “Business Entity”. Die zugehörige Tabelle ist deshalb im Unterkatalog ENTITY enthalten. Die Bezeichnung der Tabelle ist somit:
app_general_Country
mit Angabe der Katalognamen, wobei „@“ als Trennzeichen benutzt wird:
CISAG@ENTITY.app_general_Country´

5.2        Spaltennamen

Als Spaltenname wird der Attributname verwendet. Es existieren spezielle Spaltennamen und Suffixe, die eine besondere Bedeutung der Spalte angeben. In den folgenden Kapiteln werden spezielle Spaltennamen aufgeführt, anhand derer der Berichtsprogrammierer Typ- oder Inhaltsinformationen ableiten kann, ohne Näheres über den konkreten Typ oder den Inhalt der Spalte zu wissen.

5.2.1    Kennzeichnung von GUID-Attributen

GUIDs (Global Unique IDentifier) werden verwendet, um eindeutige Schlüssel für Business Objects zu bilden und diese darüber zu referenzieren. Daher sind Spalten, die auf dem Datentyp GUID basieren, die wichtigsten Kandidaten, um bei der Datenmodellierung Tabellen zu verknüpfen. Um diese Spalten hervorzuheben, werden die Spaltennamen mit einem angehängten Unterstrich gekennzeichnet.

Beispiel:
Die Attribute „guid“ und „currency“ des Business Objects „com.cisag.app.general.obj.Country“ basieren auf dem Datentyp „GUID“. Die entsprechenden Spalten der Tabelle heißen in ODBC „guid_“ und „currency_“.

5.2.2    Auflösung von Array-Attributen

Für ein Array-Attribut eines Business Objects enthält die korrespondierende Tabelle der Kardinalität des Attributes entsprechend viele Spalten. Dabei wird der Index dem Attributnamen als Suffix hinzugefügt.

Beispiel:
Das Array-Attribut “eans” des Business Objects “com.cisag.app.general.obj.Item” mit einer Größe von 4 wird durch die folgenden 4 Spalten in der zugehörigen Tabelle dargestellt:

  • eans_0
  • eans_1
  • eans_2
  • eans_3

Alle Spalten haben als Label das zum Attribut in der Data-Description hinterlegte Label.

5.2.3    Spezielle Spalte BusinessKey_text

Wenn zu einem Business Object bestimmte Bedingungen erfüllt sind, dann wird in dessen Tabelle die Spalte „BusinessKey_text“ hinzugefügt. Diese Spalte enthält den Instanz-String der Business-Object-Instanz. Beim Auswerten der Anfrage wird daher vom Application-Server die zugehörige Business-Object-Instanz über den Persistenzdienst geladen. Das kann bei Anfragen mit einer großen Ergebnismenge zu längeren Antwortzeiten führen.

Damit die Spalte hinzugefügt wird, müssen folgende Bedingungen erfüllt sein:

  • Das Business Object hat einen Business Key.
  • Der Primärschlüssel des Business Objects besteht aus einem Attribut.

Diese Spalte darf nur zur Anzeige verwendet werden.

5.3        Auflösung von Beziehungen

Bei bestimmten Beziehungen eines Business Objects werden automatisch der Business Key und die Beschreibung des Ziel-Objekts als Spalten in die Tabelle hinzugefügt. Damit die Spalten zur Tabelle hinzugefügt werden, muss die Beziehung bestimmte Bedingungen erfüllen:

  • Die Kardinalität der Beziehung muss 1:1 sein.
  • Das Ziel-Business-Object hat als Primärschlüssel genau ein Attribut vom Datentyp GUID.
  • Die Beziehung ist genau über ein Attribut definiert, das Zielattribut ist das Primärschlüsselattribut.
  • Quell- und Zielobjekt sind auf derselben Datenbank definiert.
  • Das Ziel-Business-Object hat einen Business Key definiert.

5.4        Einschränkungen bei mehreren Beziehungen pro Attribut

Sind für das Business Object mehrere dieser Beziehungen mit demselben Quell-Attribut aber unterschiedlichem Ziel-Attribut definiert, so dürfen die zur Spalte des Quell-Attributs erzeugten speziellen „_BK“- und „_text“-Spalten nicht im Bericht verwendet werden. In diesem Fall verhält sich die Erzeugung der Tabel-len-Metadaten nicht deterministisch. Es wird eine der Beziehungen für die Er-zeugung der speziellen Spalten verwendet, die anderen werden ignoriert. Da-durch ist es möglich, dass diese speziellen Spalten ein anderes Ziel-Business Object referenzieren als beispielsweise während der Berichtsentwicklung.

In einem solchen Fall muss die benötigte Beziehung manuell dem Bericht hin-zugefügt werden, um den benötigten Business Key und Instanz-String zu erhal-ten. Öffnen Sie über die Anwendung „Entwicklungsobjekte“ die Business-Ob-ject-Definition des Quell-Business-Objects. Der Karteireiter „Beziehungen“ zeigt die definierten Beziehungen zu anderen Business Objects. Identifizieren Sie die benötigte Beziehung, die Sie im Bericht manuell hinzufügen müssen, um den benötigten Business Key und Instanz-String zu erhalten. Verknüpfen Sie die benötigte Tabelle des Ziel-Business-Objects über die Spalte des Quell-Attributs und die Spalte des Ziel-Attributs an die Tabelle des Quell-Business-Objects. Verwenden Sie dazu einen LEFT OUTER JOIN.

Der hinzugefügte Join muss den folgenden Aufbau haben:

quell_tabelle LEFT OUTER JOIN ziel_tabelle ON quell_spalte = ziel_spalte

Benutzen Sie im Bericht anstatt der „_BK“-Spalte die entsprechende Spalte der Tabelle des Ziel-Business-Objects, die den Business Key enthält.

Benutzen Sie im Bericht anstatt der „_text“-Spalte die Spalte „Busi-ness_Key_text“ der Tabelle des Ziel-Business-Objects.

5.4.1    Instanz-String-Spalte mit Suffix _text

Wenn die voran genannten Bedingungen erfüllt sind, dann wird diese Spalte hinzugefügt. Deren Name wird aus dem Namen des Quellattributes und dem Suffix „_text“ gebildet. Als Label erhält es das Label aus der Data-Description des Quellattributes. Der Inhalt der Spalte ist der Instanz-String der Business Object-Instanzen. Beim Auswerten der Anfrage wird daher vom Application-Server die zugehörige Business-Object-Instanz über den Persistenzdienst geladen. Das kann bei Anfragen mit einer großen Ergebnismenge zu längeren Antwortzeiten führen.

Diese Spalte darf im Bericht nur für die Anzeige verwendet werden, nicht aber für die datenbankseitige Selektion (JOIN- / WHERE-Klausel), Gruppierung (GROUP BY) und Sortierung (ORDER BY-Klausel).

5.4.2    Business Key-Spalte mit Suffix _BK (BK-Spalte)

Wenn der Business Key des Ziel-Objekts aufgenommen werden soll, dann muss zusätzlich folgende Bedingung erfüllt sein: Der Business Key des Ziel-Objektes besteht aus genau einem Attribut vom Typ String.

Der Name der Spalte wird aus dem Namen des Quell-Attributes und dem Suffix „_BK“ gebildet. Das Label wird aus der Data-Description des zum Business-Key-Attribut gehörenden logischen Datentyps ermittelt.

Beispiel:
Das Business Object „com.cisag.app.general.obj.Country“ hat eine 1:1-Beziehung „Language“ zum Business Object „com.cisag.app.general. obj.Language“ über die Attribute „defaultLanguage -> guid“ definiert. Die Beziehung und das Ziel-Objekt erfüllen die genannten Bedingungen. Deshalb werden die Spalten „defaultLanguage_BK“ mit dem Label „Sprache“ und „defaultLanguage_text“ mit dem Label „defaultLanguage“ zur Tabelle hinzugefügt.

Diese Spalte darf nicht zur Formulierung von Join-Bedingungen verwendet werden. Wird eine BK-Spalte nicht nur für die Anzeige verwendet, so erfolgt keine der nachfolgend beschriebenen Statement-Optimierungen.

Optimierung des Datenbank-Statements

Beachten Sie, dass „_BK“-Spalten abhängig von der Einstellung der Option „ODBC-Zugriff“ des Application-Servers unterschiedlich aufgelöst werden. Wenn auf „_BK“-Spalten von Stammdaten zugegriffen wird, dann werden die Inhalte entweder durch den Persistenzdienst oder von der Datenbank bestimmt. Wenn der Cache des Application-Servers groß genug ist, ist die Berechnung des Inhaltes durch den Persistenzdienst günstiger als die Auflösung durch die Datenbank.

Beim beschränkten ODBC-Zugriff werden nur Stammdaten mit den Datengrößen „S“ und „M“ durch den Persistenzdienst aufgelöst. Stammdaten mit den Datengrößen „L“, „XL“ und „XXL“ werden durch die Datenbank bestimmt. Damit wird verhindert, dass beim beschränkten Zugriff durch ODBC-Zugriffe andere Business Objects aus dem Cache des Application-Servers verdrängt werden.

Beim unbeschränkten ODBC-Zugriff werden alle Stammdaten über den Persistenzdienst aufgelöst. Damit werden andere Prozesse, die auf dem Application-Server laufen, unter Umständen behindert, da von diesen benötigte Daten aus dem Cache verdrängt werden. Diese Einstellung wird für einen Application-Server empfohlen, der vorrangig ODBC-Zugriffe verarbeitet.

Sie können die Option „ODBC-Zugriff“ in der Anwendung „Systemcockpit“ für einen Application-Server einstellen.

5.4.3    Virtuelle Beziehungsspalte

Sie haben die Möglichkeit, eine Tabelle eines Business Object um eine virtuelle Spalte zu erweitern, deren Inhalt sich zur Laufzeit der Abfrage berechnet. Diese virtuelle Spalte basiert auf einer Beziehung des Business Objects zu einem konkreten Business Object.

Die Beziehung muss die folgenden Bedingungen erfüllen:

  • Die Kardinalität der Beziehung muss 1:1 sein.
  • Das Ziel-Business-Object hat als Primärschlüssel genau ein Attribut vom Datentyp „GUID“.
  • Die Beziehung ist genau über ein Attribut definiert, das Zielattribut ist das Primärschlüsselattribut.
  • Quell- und Zielobjekt sind auf derselben Datenbank definiert.

Das Ziel-Business-Object muss keinen Business Key besitzen bzw. der Business Key kann mehrteilig sein oder einen anderen Typ als String besitzen.

Wenn solch eine Beziehung bei einem Business Object existiert und für das Ziel-Business-Object eine virtuelle Spaltendefinition hinterlegt wurde, dann wird die virtuelle Spalte zu der Tabelle des Business Objects hinzugefügt.

Für die virtuelle Spalte ist ein Klasse zu implementieren, die den Spalteninhalt für jede Tabellenzeile berechnet. Als Eingabeparameter für die Berechnung wird der Primärschlüssel der jeweiligen Instanz des Ziel-Business-Objects übergeben.

Der Name der virtuellen Spalte wird aus dem Namen des Quellattributes mit einem frei wählbaren Suffix gebildet. Der Name muss innerhalb der erweiterten Tabelle eindeutig sein.

Die virtuelle Spalte darf nur zur Anzeige verwendet werden.

Über diese Speziallösung kann eine „_BK“-Spalte nachgebildet werden, wenn das Ziel-Business-Object die Bedingungen an den Business Key für eine automatisch hinzugefügte „_BK“-Spalte nicht erfüllt.

Beispiel: Business Object UnitOfMeasure

Existiert eine Beziehung zu dem Business Object com.cisag.app.general.obj.Unit­OfMeasure, wird trotzdem die „_BK“-Spalte hinzugefügt, obwohl dieses Business Object einen mehrteiligen Business Key besitzt. Das ist ein Spezialfall, der unter Benutzung einer virtuellen Beziehungsspalte implementiert wurde. Diese „_BK“-Spalte darf nur zur Anzeige verwendet werden.

5.5        Auflösung von Valueset-Attributen

Ein Attribut eines Business Objects, dessen logischer Datentyp auf einem Valueset basiert, wird von der Datenquelle durch zwei Spalten repräsentiert. Eine der Spalten hat als Bezeichnung den Attributnamen und enthält den Valueset-Wert, der dem Konstantennamen entspricht. Der Name der anderen Spalte setzt sich aus dem Attributnamen und dem Suffix „_text“ zusammen. Diese Spalte beinhaltet die zum Valueset-Wert zugehörige Bezeichnung in der zur Datenquelle eingestellten Anzeigesprache. Beiden Spalten bekommen das in der zum logischen Datentyp des Attributs gehörenden Data-Description hinterlegte Label als Spalten-Label zugewiesen.

Beispiel:
Das Attribut „status“ des Business Objects „com.cisag.app.sales.obj.
SalesOrder“, welches auf dem Valueset „com.cisag.app.general.
OrderStatus“ basiert, ist in der korrespondierenden Tabelle „CISAG@ENTITY.app_sales_SalesOrder“ zu den beiden Spalten „status“ und „status_text“ aufgelöst. Die Spalte „status“ enthält als Werte die Konstantennamen (z. B. „ORDER_COMPLETED“). Die Spalte „status_text“ enthält als Werte die zugehörigen Bezeichnungen (z. B. „Erledigt“).

Wenn in einem Bericht auf ein Valueset-Attribut programmiert wird oder auf diesem Selektionen oder Bedingungen angegeben werden, muss immer der Konstantenname verwendet werden. So bleibt der Bericht unabhängig von Änderungen in der Bezeichnung der Valueset-Einträge und unabhängig von der gewählten Anzeigesprache. Berichtsparameter, die aus Valuesets stammen, werden von Comarch ERP Enterprise in dieser Darstellung an die Berichtsanwendung übergeben.

Die „_text“-Spalte darf nur zum Anzeigen verwendet werden.

Selektionen dürfen nur auf der Konstantenspalte mit gültigen Value-Set-Konstanten erfolgen.

Undefinierter Wert

Spalten, die auf Valuesets basieren, können auch undefiniert sein. Um dieses im Bericht festzustellen, muss eine Prüfung auf die leere Zeichenkette für den Konstantennamen erfolgen. Die zugehörige Valueset-Bezeichnung ist in diesem Fall ebenfalls die leere Zeichenkette.

Ungültiger Wert

Der Wert <invalid> für die Valueset-Bezeichnung ist ein Sonderfall. Dieser Wert wird immer dann von der Datenquelle zurückgegeben, wenn ein nicht im Valueset enthaltener Wert in den Datensätzen gefunden wird. Das deutet in der Regel auf eine mögliche Problematik bei zugrunde liegenden Altdatenübernahmen hin. Auf ungültige Werte kann nicht selektiert werden.

5.6        Darstellung besonderer betriebswirtschaftlicher Datentypen (Special-Parts)

Comarch ERP Enterprise bietet spezielle Datentypen, die komplexe, betriebswirtschaftlich motivierte Strukturen haben. Amounts (Beträge) und Quantities (Mengen) sind dabei die Wichtigsten. Diese werden in der Datenbankschnittstelle besonders behandelt.

5.6.1    Auflösung von Attributen des Typs „Foreign Amount“

Ein Attribut, welches auf dem Special-Part „com.cisag.general.obj.
ForeignAmount“ basiert, wird in der zum Business Object korrespondierenden Tabelle durch mehrere Spalten repräsentiert. Diese entsprechen den Part-Attributen und weiteren von der Datenbankschnittstelle hinzugefügten Attributen. Die Namen der Spalten werden aus dem Attributnamen und dem entsprechenden Suffix gebildet. Eine Übersicht gibt die folgende Tabelle.

Spaltennamen-Suffix Bedeutung
_amount Eingabebetrag
_currency_ GUID der Eingabewährung
_currency_BK Business Key der Eingabewährung (z. B. „EUR“). Es gelten die Einschränkungen für BK-Spalten.
_currency_text Beschreibung zur Eingabewährung. Darf nur zu Anzeige verwendet werden.

Beispiel:
Für das Attribut „totalValues.discountValue“ des Business Objects “com.cisag.sales.obj.SalesOrder” werden in der Tabelle die folgenden Spalten erzeugt:

  • totalValues_discountValue_amount
  • totalValues_discountValue_currency_
  • totalValues_discountValue_currency_BK
  • totalValues_discountValue_currency_text

5.6.2    Auflösung von Attributen des Typs „Domestic Amount“

Ein Attribut, welches auf dem Special-Part „com.cisag.general.obj.DomesticAmount“ basiert, wird in der zum Business Object korrespondierenden Tabelle durch mehrere Spalten repräsentiert. Die Namen der Spalten werden aus dem Attributnamen und dem entsprechenden Suffix gebildet.

Eine Übersicht gibt die folgende Tabelle:

Spaltennamen-Suffix Bedeutung
_amount1 Betrag in Währung 1 des Domestic Amounts.
_amount2 Betrag in Währung 2 des Domestic Amounts.
_amount3 Betrag in Währung 3 des Domestic Amounts.
_amountCorporate Betrag in der Leitwährung der aktiven Organisation oder undefinierter Inhalt.
_amountOrganization Betrag in der Leitwährung der aktiven Organisation, entweder ist das der Wert aus dem Domestic Amount oder errechnet aus Währung 1.
_amount2_text Währungsbezeichnung für Währung 2 des Domestic Amounts. Darf nur zu Anzeige verwendet werden.
_amount3_text Währungsbezeichnung für Währung 3 des Domestic Amounts. Darf nur zu Anzeige verwendet werden.
_exact Index der Währung, die vom Benutzer exakt erfasst wurde.

Alle anderen Währungen wurden gemäß den zum Erfassungszeitpunkt gültigen Wechselkursen aus dem eingegebenen exakten Betrag umgerechnet.

Der Wert 1 bedeutet, _amount1 ist exakt, 2 bedeutet, _amount2 ist exakt und 3 bedeutet, _amount3 ist exakt. Der Wert 0 bedeutet, keiner der drei Währungsbeträge ist ein exakter Wert.

Hinweis:

Die Spalten mit den Suffixen _amount1, _amountCorporate und _amountOrganization dürfen nicht zusammen in der ORDER BY-Klausel zur Sortierung verwendet werden.

Beispiel:
Für das Attribut „totalValues.discountValueDomestic“ des Business Objects “com.cisag.sales.obj.SalesOrder” werden in der Tabelle die folgenden Spalten erzeugt:

  • totalValues_discountValueDomestic_amount1
  • totalValues_discountValueDomestic_amount2
  • totalValues_discountValueDomestic_amount3
  • totalValues_discountValueDomestic_amountCorporate
  • totalValues_discountValueDomestic_amountOrganization
  • totalValues_discountValueDomestic_amount2_text
  • totalValues_discountValueDomestic_amount3_text
  • totalValues_discountValueDomestic_exact

5.6.2.1      Verwendung der Spalten mit den Suffixen _amountCorporate und _ amountOrganization

Bei der Benutzung eines Attributes vom Typ „Domestic Amount“ in einem Bericht muss in Zusammenhang mit Multi-Site und der Ausgabe des Betrages in der Leitwährung der Organisation auf folgendes geachtet werden:

Single-Site: Erstellung eines Berichts

Die Spalte „_amountCorporate“ enthält den Betrag der Währung 1, 2 oder 3 des Domestic Amounts entsprechend des Leitwährungsindexes des Mandanten. Die Spalte „_amountOrganization“ enthält dasselbe wie die Spalte _amountCorporate.

Hinweis:
Wenn der Bericht auch in Muli-Site-Umgebungen korrekt sein soll, dann muss das Feld „_amountOrganization“ benutzt werden, um den Leitwährungsbetrag anzuzeigen.

Multi-Site: Erstellung eines Berichtes

Die Spalte „_amountCorporate“ enthält den Betrag der Währung 1, 2 oder 3 des Domestic Amounts entsprechend des Leitwährungsindexes der aktiven Organisation. Dies kann ein Betragswert bzgl. einer anderen Währung sein, wenn der auszugebende Domestic Amount nicht aus der aktiven Organisation stammt.

Die Spalte „_amountOrganization“ enthält den Währungsbetrag der Leitwährung der aktiven Organisation. Dieser wurde aus der Währung 1 (Konzernwährung) des Domestic Amounts mit einem Umrechnungsfaktor errechnet. Dieser Wert ist errechnet und kann nicht die Qualität eines exakten Wertes haben.

Hinweis:
Für einen organisationsübergreifenden Bericht muss die Spalte „_amountOrganizatio“n benutzt werden, da nur diese Spalte garantiert den Betrag in der Leitwährung der aktiven Organisation enthält (berechnet aus der Währung 1).

Bei der Erstellung eines organisationsinternen Berichts, in dem nur Domestic Amounts mit gleichen Währungsbelegungen verwendet werden, ist immer das Feld „amountCorporate“ dem Feld „_amountOrganization“ vorzuziehen, da dieses den Wert aus dem Domestic Amount enthält und nicht aus der Konzernwährung errechnet wird.

5.6.2.2      Tabellen-globale Spalten

Wenn ein Business Object mindestens ein Attribut vom Typ „Domestic Amount“ enthält, dann werden der zugehörigen Tabelle folgende Spalten hinzugefügt:

Spaltenname Bedeutung
currencyCorporate1_ GUID der Währung 1 der aktiven Organisation. Diese Spalte darf nur in der SELECT-, FROM- oder WHERE-Klausel des SQL-Statements verwendet werden.
currencyCorporate2_ GUID der Währung 2 der aktiven Organisation. Diese Spalte darf nur in der SELECT-, FROM- oder WHERE-Klausel des SQL-Statements verwendet werden.
currencyCorporate3_ GUID der Währung 3 der aktiven Organisation. Diese Spalte darf nur in der SELECT-, FROM- oder WHERE-Klausel des SQL-Statements verwendet werden.
currencyCorporate_ GUID der Leitwährung der aktiven Organisation. Diese Spalte darf nur in der SELECT-, FROM- oder WHERE-Klausel des SQL-Statements verwendet werden.
currencyCorporate1_text Währungsbezeichnung für Währung 1 der aktiven Organisation. Diese Spalte darf nur zu Anzeige verwendet werden.
currencyCorporate2_text Währungsbezeichnung für Währung 2 der aktiven Organisation. Diese Spalte darf nur zu Anzeige verwendet werden.
currencyCorporate3_text Währungsbezeichnung für Währung 3 der aktiven Organisation. Diese Spalte darf nur zu Anzeige verwendet werden.
currencyCorporate_text Währungsbezeichnung für die Leitwährung der aktiven Organisation. Diese Spalte darf nur zu Anzeige verwendet werden.

5.6.3    Auflösung von Attributen des Typs Quantity

Ein Attribut, welches auf dem Special-Part „com.cisag.general.obj.Quantity“ basiert, wird in der zum Business Object korrespondierenden Tabelle durch mehrere Spalten repräsentiert. Diese entsprechen den Part-Attributen und weiteren von der Datenquelle hinzugefügten Attributen. Die Namen der Spalten werden aus dem Attributnamen und dem entsprechenden Suffix gebildet.

Eine Übersicht gibt die folgende Tabelle.

Spaltennamen-Suffix Bedeutung
_amount Betrag
_uom_ GUID der Einheit
_uom_BK Business Key der Einheit (z. B. „kg“). Diese Spalte darf, abweichend von anderen „_BK“-Spalten, nur zur Anzeige verwendet werden.
_uom_text Beschreibung der Einheit. Diese Spalte darf nur zu Anzeige verwendet werden.

Beispiel:
Für das Attribut „totalValues.grossWeight“ des Business Objects „com.cisag.sales.obj.SalesOrder“ werden in der Tabelle die folgenden Spalten erzeugt:

  • totalValues_grossWeight_amount
  • totalValues_grossWeight_uom_
  • totalValues_grossWeight_uom_BK
  • totalValues_grossWeight_uom_text

5.7        Spezielle Spalte link_text

Wenn es sich bei einer Tabelle um die eines Business Entitys handelt, welches als Primärschlüssel genau eine GUID hat, wird eine zusätzliche Spalte mit dem Namen „link_text“ zur Tabelle hinzugefügt. Diese Spalte enthält eine URL, über welche die zugehörige Business Object-Instanz mittels der Default-Anwendung zum Anzeigen/Bearbeiten geöffnet werden kann.

In einem Bericht kann der Wert eines Feldes so einer Spalte als Hyperlink festgelegt werden. Somit kann das durch den Hyperlink adressierte Business Entity aus dem Bericht heraus mittels Browser in Comarch ERP Enterprise geöffnet werden.

Diese Spalte darf nur zur Anzeige verwendet werden.

5.8        Unterstützung von Blob-Attributen

Die Datenbankschnittstelle unterstützt keine Attribute von Business Objects, die auf den -Datentypen „Blob“, „SBlob“ und „Text“ basieren. Solche Attribute haben keine entsprechende Spalte in der Tabelle des Business Objects.

Ausnahmen

Standardmäßig werden aber die Blob-Attribute der Business Objects „com.cisag.app.general.obj.Text“ und „com.cisag.app.general.obj.LongText“ unterstützt. Diese sind für die Aufnahme von Texten vorgesehen, welche komprimiert in der Datenbank gespeichert werden. Einem Business Object kann über eine Beziehung auf diese Weise ein Textbaustein zugewiesen werden.

Es werden die Blob-Attribute der virtuellen Tabellen „com.cisag.app.general.
ItemImage“ und „com.cisag.app.general.PartnerImage“ unterstützt. Diese enthalten die Binärdaten zu den entsprechenden Bildern.

Um die Unterstützung eines Blob-Attributes für ein Business Object oder eine virtuelle Tabelle hinzuzufügen, muss dieses registriert werden. Dazu dient der Hook „com.cisag.pgm.appserver.hook.ODBCRegistryHook“, welcher im Hook Contract „com.cisag.pgm.appserver.Server“ definiert ist. Über eine eigene Implementierung dieses Hooks können die Blob-Attribute konfliktfrei registriert werden.

Ein Blob-Attribut darf nur zur Anzeige verwendet werden. Die maximale Blob-Größe beträgt 16 MB.

5.9        Auflösung von Datums- und Zeitstempel-Attributen

Comarch ERP Enterprise stellt verschiedene Zeitstempel- und Datumstypen zur Verfügung. Alle Datums- und Zeitstempelwerte werden grundsätzlich als ein Zeitstempel bezüglich der Zeitzone GMT auf der Datenbank gespeichert. Wenn der Datentyp auch eine Zeitzoneninformation enthält, wird zusätzlich die GUID der Zeitzone auf der Datenbank gespeichert.       Weitere Informationen zu den Zeitstempel- und Datumstypen finden Sie in der Dokumentation „Datentypen des Typsystems“.

Ein Zeitstempel- oder Datumswert wird unter Beachtung seiner Zeitzoneninformation ausgegeben. Besitzt der auszugebende Wert keine eigene Zeitzoneninformation, wird die Zeitzone aus dem Anmelde-Kontext verwendet. Im interaktiven ODBC-Betrieb entscheidet die Zeitzone der beim Erfassen der Datenquelle angegebenen Organisation darüber, welche Zeitzone als Kontext verwendet wird. In einer Single-Site-Umgebung wird automatisch die Zeitzone des Mandanten verwendet. Bei der Ausgabe von Berichten über den SOM wird die Zeitzone der Organisation des angemeldeten Benutzers verwendet. Konnte die Zeitzone zu einer Organisation nicht ermittelt werden, wird als Fallback die Zeitzone des Comarch-ERP-Enterprise -Systems verwendet.

Die Datenbankschnittstelle stellt alle Zeitstempel- und Datumswerte in der Zeitzone GMT und in der Zeitzone des Anmelde-Kontextes zur Verfügung. Deshalb wird ein Attribut, welches auf einen Zeitstempel- oder Datumstyp basiert, in mehrere Spalten aufgelöst.

5.9.1    Zeitstempel ohne Zeitzoneninformation

Für ein Attribut, welches auf dem primitiven Datentyp „TimeStamp“ basiert, werden die folgenden zwei Spalten zur Tabelle des Business Objects hinzugefügt:

Spaltenname Inhalt
Attributname Zeitstempelwert bzgl. der Zeitzone der Organisation des ODBC-Kontextes. Diese Spalte darf nur zur Anzeige verwendet werden.
Attributname + „_gmt“ Zeitstempelwert bzgl. der Zeitzone GMT. Diese Spalte muss für Selektionen, Sortierungen, Parameterübergaben usw. verwendet werden.
Beispiel

Weist z. B. das Attribut „updateTime“ der Änderungsinformation den Wert „10.01.2007 13:45:33“ auf und die Zeitzone des Anmelde-Kontextes ist MEZ (Mitteleuropäische Zeit), dann überträgt die Datenbankschnittstelle für die zum Attribut gehörenden Spalten die folgenden Werte:

Spalte Wert
updateTime 10.01.2007 13:45:33
updateTime_gmt 10.01.2007 12:45:33

5.9.2    Zeitstempel oder Datum mit Zeitzoneninformation

Für ein Attribut, welches auf einem speziellen logischen Datentyp für Zeitstempel oder Datum basiert, werden die folgenden drei Spalten zur Tabelle des Business Objects hinzugefügt:

Spalte Inhalt
Attributname Zeitstempel- oder Datumswert bzgl. der gespeicherten Zeitzone. Darf nur zur Anzeige verwendet werden.
Attributname + „_gmt“ Zeitstempel- oder Datumswert bzgl. der Zeitzone GMT. Diese Spalte muss für Selektionen, Sortierungen, Parameterübergaben usw. verwendet werden.
Attributname + „_timeZone“ Kürzel der Zeitzone. Weicht die gespeicherte Zeitzone von der Zeitzone des ODBC-Kontextes ab, dann wird auch das Kürzel der gespeicherten Zeitzone übertragen, ansonsten ist die Spalte leer. Darf nur zur Anzeige verwendet werden.
Beispiel

Weist z. B. das Attribut „date“ in einer Ausgangsrechnung den Wert „21.12.2006 00:00:00 MSK“ (Moskauer Normalzeit) auf und die Zeitzone des Anmelde-Kontextes ist eine andere, z. B. MEZ (Mitteleuropäische Zeit), dann überträgt die Datenbankschnittstelle für die zum Attribut gehörenden Spalten die folgenden Werte:

Spalte Wert
date 21.12.2006 00:00:00
date_gmt 20.12.2006 21:00:00
date_timeZone MSK

Wird die Ausgangsrechnung dagegen bzgl. der Zeitzone MSK (Moscow Standard Time) ausgegeben, dann würde die Datenbankschnittstelle die folgenden Attribute übertragen:

Spalte Wert
date 21.12.2006 00:00:00
date_gmt 20.12.2006 21:00:00
date_timeZone (leere Zeichenfolge)

 

Hinweis:
Die Beispiele setzen voraus, dass der Zeitunterschied zwischen der Zeitzone GMT und den Zeitzonen MEZ und MSK 1 bzw. 3 Stunden beträgt. Eventuelle durch die Sommerzeit bedingte Unterschiede wurden nicht berücksichtigt.

5.9.3    Wertebereich von Zeitstempeln

In der Datenbankschnittstelle werden für Zeitstempel- und Datumswerte die folgenden symbolischen Werte verwendet:

  • undefinierter Wert:

Der Wert „01.01.1000 00:00.000“ bzgl. der Zeitzone GMT repräsentiert einen nicht definierten Zeitstempel. Zum Beispiel liefert die Spalte „updateInfo_deleteTime_gmt“ diesen Wert, wenn das Löschkennzeichen für das Business Object nicht gesetzt ist.

  • minimaler Wert:

Der Wert „31.12.1000 00:00.000“ bzgl. der Zeitzone GMT repräsentiert den kleinsten Zeitstempel der in der Datenbankschnittstelle verarbeitet werden kann. Alle Zeitstempel, die kleiner sind als dieser, werden auf diesen Zeitstempel abgebildet. Davon ausgenommen ist der Wert für den undefinierten Zeitstempel.

  • maximaler Wert:

Der Wert „31.12.4712 00:00:00.000“ bzgl. der Zeitzone GMT repräsentiert den größten Zeitstempel, der in der Datenbankschnittstelle verarbeitet werden kann. Ein größerer Zeitstempel wird bei der Übertragung zum Application-Server auf diesen Zeitstempel abgebildet. Soll ein größerer Zeitstempel als dieser vom -Server ausgegeben werden, so wird der Wert „31.12.9999 00:00.000“ bzgl. der Zeitzone GMT zurückgegeben.

Hinweis:
In Crystal Reports muss ein gültiges Datum zwischen den Werten „01.01.0100“ und „31.12.9999“ liegen.

5.9.4    Zeitangaben

Um auch reine Zeitangaben, wie zum Beispiel „02:15“, von der Zeitzone unabhängig berechnen zu können, werden diese in Comarch ERP Enterprise mit dem Datum „01.01.1970“ bzgl. der Zeitzone GMT gespeichert. Die Datenbankschnittstelle überträgt solche Zeitangaben zusammen mit dem Datum nach Crystal Reports. Möchten Sie in einer Berichtsvorlage eine Zeitangabe verwenden, dann sollten Sie entweder dieses Datum von dem übertragenen Wert abziehen oder das Datum im Ausgabefeld wegblenden.

5.10    Auflösung der Änderungsinformation eines Business Object

Wenn zu einem Business Object festgelegt wurde, dass das System Änderungsinformationen pflegt (Option „Benutzer und Zeitpunkt protokollieren“ in der Anwendung „Entwicklungsobjekte“), werden in die Tabelle des Business Objects dafür spezielle Spalten aufgenommen.

In der nachstehenden Tabelle sind die Spalten und ihre Bedeutung aufgeführt:

Spaltenname Spalteninhalt
updateInfo_createTime Erstellungszeitpunkt einer Business-Object-Instanz in der Zeitzone der aktiven Organisation. Darf nur zur Anzeige verwendet werden.
updateInfo_createTime_gmt Erstellungszeitpunkt einer Business-Object-Instanz in der Zeitzone GMT.
updateInfo_createUser_ Primärschlüssel (die GUID) des Benutzers, der die Business-Object-Instanz erstellt hat.
updateInfo_createUser_text Name des Benutzers, der die Business-Object-Instanz erstellt hat. Darf nur zur Anzeige verwendet werden.
updateInfo_deleteTime Löschzeitpunkt einer Business-Object-Instanz in der Zeitzone der aktiven Organisation. Darf nur zur Anzeige verwendet werden.
updateInfo_deleteTime_gmt Löschzeitpunkt einer Business-Object-Instanz in der Zeitzone GMT.
updateInfo_deleteUser_ Primärschlüssel (Typ GUID) des Benutzers, der die Business-Object-Instanz gelöscht hat.
updateInfo_deleteUser_text Name des Benutzers, der die Business-Object-Instanz gelöscht hat. Darf nur zur Anzeige verwendet werden.
updateInfo_updateTime Änderungszeitpunkt einer Business-Object-Instanz in der Zeitzone der aktiven Organisation. Darf nur zur Anzeige verwendet werden.
updateInfo_updateTime_gmt Löschzeitpunkt einer Business-Object-Instanz in der Zeitzone GMT.
updateInfo_updateUser_ Primärschlüssel (Typ GUID) des Benutzers, der die Business-Object-Instanz geändert hat.
updateInfo_updateUser_text Name des Benutzers, der die Business-Object-Instanz geändert hat. Darf nur zur Anzeige verwendet werden.

5.11    Unterstützung von benutzerdefinierten Feldern

Wenn die benutzerdefinierten Felder auf einer Object Extension basieren, d. h. diese werden in einer eigenen Datenbanktabelle und nicht in einer Blob-Datenstruktur gespeichert, können diese über die Datenbankschnittstelle abgefragt werden. Die Datenbanktabelle des zugehörigen Business Objects wird automatisch um die Spalten für die benutzerdefinerten Felder erweitert.

Die benutzerdefinierten Felder zu Business Objects können wie andere Attribute über die Datenbankschnittstelle abgefragt und benutzt werden. Der Name der dem Attribut entsprechenden Spalte in der Tabelle setzt sich aus dem Attributnamen und dem Suffix „_ext“ zusammen. Ein benutzerdefiniertes Feld wird je nach Datentyp zu mehreren Spalten in der Tabelle aufgelöst. Die Auflösung erfolgt analog zu einem normalen Business-Object-Attribut. Als Spalten-Label wird das bei der Anlage des benutzerdefinierten Feldes festgelegte Label angezeigt.

Datentyp „Auswahlfeld“

Der Datentyp „Auswahlfeld“ eines benutzerdefinierten Feldes wird ähnlich dem -Datentyp „Valueset“ aufgelöst. Die folgende Tabelle zeigt die entsprechenden Spalten.

Spalte Bedeutung
attributeName_ext Diese Spalte enthält die ID-Nummer des entsprechenden Eintrages als Zeichenkette.

Diese Spalte wurde auf „deprecated“ gesetzt. Statt dieser sollte die Spalte „attributeName_ext_name“ verwendet werden.
attributeName_ext_name Diese Spalte enthält den Konstantennamen des entsprechenden Eintrages.
attributeName_ext_text Diese Spalte enthält die Bezeichnung des entsprechenden Eintrages.

Darf nur zur Anzeige verwendet werden.

5.12    Zeitabhängige Business Objects

Einige Business Objects können zeitabhängig sein (z. B. Business Object „com.cisag.app.general.obj.Partner“). Bei der Abfrage von Daten von zeitabhängigen Business Objects werden wie in Comarch ERP Enterprise üblich nur die zum aktuellen Zeitpunkt gültigen Versionen berücksichtigt.

Zeitabhängige Business Objects besitzen die Attribute „validFrom“ und „validUntil“. Wenn man diese Attribute in die Abfrage explizit einbezieht, d. h. als Rückgabespalte, Selektions-, Sortierkriterium oder zwecks Gruppierungen benutzt, werden alle Versionen der Business-Object-Instanzen berücksichtigt.

5.13    Virtuelle Tabellen

Eine virtuelle Tabelle existiert nicht auf der Datenbank, sondern wird vom SAS emuliert. Prinzipiell kann auf solch eine Tabelle wie auf eine Datenbank-Tabelle zugegriffen werden. Der Inhalt einer virtuellen Tabelle wird zur Laufzeit der Abfrage bezüglich der Eingabeparameter berechnet. Das Ergebnis kann aus 0 bis n Zeilen bestehen. Durch Joins zu Tabellen von anderen Business Objects können diesem Ergebnis zusätzliche Spalten hinzugefügt werden. Die Anzahl der Ergebniszeilen wird aber allein durch die virtuelle Tabelle bestimmt. Die Ergebnisse für Spalten aus den gejointen Tabellen werden über den Persistenzdienst des SAS ermittelt und nicht direkt über ein Datenbankstatement.

Für die Komplexität der Abfrage gelten erhebliche Einschränkungen:

  • Als Join-Typen sind nur LEFT OUTER und RIGHT OUTER zulässig. Dabei muss die virtuelle Tabelle immer die Hauptseite des Joins bilden, d.h. beim LEFT-Join die linke Seite bzw. bei einem RIGHT-Join die rechte Seite. Die Joinbedingung muss über den Primärschlüssel oder den Business Key des zur gejointen Tabelle gehörenden Business Objects formuliert sein. Als Operator ist nur „=“ zulässig und alle Teilbedingungen müssen mit „AND“ verknüpft sein. Diese Einschränkungen gelten auch für Joins, die von einer Tabelle, welche an eine virtuelle Tabelle gejoint ist, ausgehen. Spalten von den gejointen Tabellen dürfen nur zur Anzeige verwendet werden.Daraus folgt auch, dass eine virtuelle Tabelle nicht mit einer anderen virtuellen Tabelle gejoint werden darf.
  • Eine Tabelle eines Views oder OQL-Views darf nicht mit einer virtuellen Tabelle gejoint werden oder von dieser abhängig sein, da deren Inhalt auf der Datenbank bestimmt werden muss.
  • Die Spalten der virtuellen Tabelle dürfen nur zur Anzeige, zur Sortierung und zur Formulierung von Join-Bedingungen verwendet werden. Zusätzlich dürfen Spalten, die Eingabeparameter der virtuellen Tabelle sind, auch in der WHERE-Klausel zur Parameterübergabe verwendet werden.
  • Die Verwendung von Aggregat- sowie sonstige SQL-Funktionen, GROUP BY-, HAVING-Klauseln sind nicht zulässig.

5.13.1       Sortierung des Ergebnisses

Die Unterstützung der in der ORDER BY-Klausel angegebenen Sortierung ist abhängig vom Programmierer der konkreten virtuellen Tabelle. In der Regel wird es eine vom Programmierer festgelegte Sortierung geben, die angegebene Sortierreihenfolge wird dann ignoriert. Details zur Unterstützung von Sortierungen sind der Dokumentation zu der konkreten virtuellen Tabelle zu entnehmen.

5.13.2       Zuweisen der Eingabeparameter

Über die WHERE-Klausel können die Werte für mögliche Eingabeparameter der virtuellen Tabelle gesetzt werden. Der Name einer Spalte, die als Eingabeparameter benutzt werden kann, beginnt mit dem Präfix „in_“. Dementsprechend sind bei der Programmierung der virtuellen Tabelle die Spaltennamen zu wählen. Mehrere zu setzende Eingabeparameter müssen über AND verknüpft werden. Als Operation ist zum Setzen des Parameterwertes nur „=“ zulässig.

Andere Bedingungen darf die WHERE-Klausel nicht enthalten.

Beispiel

Der Eingabeparameter „in_number“ vom Typ String bekommt den Wert A0010 zugewiesen.

… WHERE in_number = ’A0010’

Um Crystal Reports und dessen Besonderheit bei der Selektion auf TimeStamp-Spalten zu unterstützen (fehlende Unterstützung von Millisekunden), gibt es für Eingabeparameter, die auf dem -Datentyp „TimeStamp“ basieren, eine Ausnahme. In einem solchen Fall ist auch ein Intervall als Bedingung in der folgenden Form zulässig:

in_timeStampAttr >= dateValue1 AND timeStampAttr < dateValue2

Der virtuellen Tabelle wird für den Eingabeparameter in_timeStampAttr  der Wert dateValue1 übergeben, die andere Teilbedingung wird ingnoriert.

5.14    Virtuelle Funktionen

Eine virtuelle Funktion ist eine spezielle Tabelle, die zu einer Menge von Eingabewerten eine Ergebniszeile zurückgibt, welche zur Laufzeit der Abfrage berechnet wird. Sie existiert nicht auf der Datenbank, sondern wird vom SAS emuliert. Sie dient typischerweise zur Erweiterung des Abfrageergebnisses um zusätzliche Spalten.

Eine virtuelle Funktion wird normalerweise über einen Join vom Typ LEFT OUTER an eine andere Datenbank-Tabelle gejoint. Über die Join-Bedingung wird die Zuordnung der Werte für die Eingabeparameter der virtuellen Funktion angegeben. Enthält eine Abfrage einen Join, wird das Abfrageergebnis zuerst ohne Berücksichtigung der virtuellen Funktion auf der Datenbank ermittelt. Anschließend werden für jede Ergebniszeile die Werte der Spalten der virtuellen Funktion berechnet. Dabei berechnet der SAS für die durch die Join-Bedingung festgelegte Wertebelegung der Eingangsparameter, die Werte der Ausgabe-Spalten der virtuellen Funktion. Eine Spalte, die als Eingangsparameter verwendet werden kann, beginnt mit dem Präfix „in_“. Die Joinbedingung darf keine weiteren Teilbedingungen enthalten.

Eine virtuelle Funktion darf nur wie nachfolgend dargestellt in Joins verwendet werden:

Datenbanktabelle A LEFT OUTER JOIN virtuelle Funktion VF ON A:columnName1 = VF:columnName1 [AND A:columnName2 = VF:columnName2]*

virtuelle Funktion VF RIGHT OUTER JOIN Datenbanktabelle A ON A:columnName1 = VF:columnName1 [AND A:columnName2 = VF:columnName2]*

Es ist zulässig, an eine Datenbanktabelle mehrere virtuelle Funktionen zu joinen. Eine virtuelle Funktion kann auch mit einer anderen virtuellen Funktion gejoint werden.

Eine virtuelle Funktion darf auch die Hauptseite eines Joins bilden. In diesem Falle gelten dieselben Einschränkungen wie für Joins mit virtuellen Tabellen.

Zusätzlich ist es möglich, Werte für Eingangsparameter einer virtuellen Funktion über die WHERE-Klausel (analog zur virtuellen Tabelle) anzugeben. Ein so gesetzter Wert überschreibt die Wertzuweisung aus einer Join-Bedingung. Es gelten dieselben Regeln für die Parameterzuweisung wie bei der virtuellen Tabelle.

Eine Tabelle eines Views oder OQL-Views darf in einem Join mit einer virtuellen Funktion nur auf der Hauptseite des Joins verwendet werden, da deren Inhalt auf der Datenbank bestimmt werden muss.

Eine virtuelle Funktion kann auch für sich allein stehend analog zur virtuellen Tabelle verwendet werden. Allerdings liefert sie maximal eine Ergebniszeile.

Die Spalten der virtuellen Funktion dürfen nur zur Anzeige und zur Formulierung von Join-Bedingungen verwendet werden. Zusätzlich dürfen Spalten, die Eingabeparameter der virtuellen Funktion sind, auch in der WHERE-Klausel zur Parameterübergabe verwendet werden.

5.15    Automatische Optimierung von Datenbankanweisungen

Die über die Datenbankschnittstelle des Application Servers abgesetzten Datenbankanweisungen werden (soweit möglich) optimiert, bevor diese auf der Datenbank ausgeführt werden. Das Ziel der Optimierung besteht darin, Daten, von denen angenommen werden kann, dass diese vom Application-Server gecacht sind, nicht von der Datenbank zu lesen, sondern diese aus dem Cache des Application-Servers zu laden. Deswegen wird versucht, Tabellen von Stammdaten-Business-Objects aus der Datenbankanweisung zu entfernen, da diese im Cache gehalten werden. Die vereinfachte Datenbankanweisung wird dann auf der Datenbank ausgeführt. Danach werden über den Persistenzdienst unter Ausnutzung des Shared Cache die benötigten Stammdaten geladen und zum Ergebnis hinzugefügt. Durch Einhaltung bestimmter Regeln beim Festlegen der Joins zwischen Datenbanktabellen kann so die Geschwindigkeit der Berichtsausführung gesteigert und die Datenbanklast gesenkt werden.

Eine Tabelle eines Business Objects wird aus der Datenbankanweisung entfernt, wenn folgende Bedingungen erfüllt sind:

  • Die Datenart des Business Objects ist „Stammdaten“, „Konfigurations-Stammdaten“ oder „Konfigurations-Stammdaten (Anzeige)“.
  • Die erwartete Datengröße des Business ‚Objects ist „Small“ oder „Medium“. Arbeitet der Application-Server im Modus „unbeschränkter ODBC-Zugriff“ wird die Datengröße nicht beachtet.
  • Die Join-Bedingung wurde ausschließlich über alle Attribute des Primärschlüssels oder des Business Keys des Business Objects formuliert.
  • Die Spalten der Tabelle werden nur zur Anzeige verwendet.
  • Bei einem zeitabhängigen Business Object wird nur auf die aktuelle Version zugegriffen.
  • Die Property „com.cisag.sys.odbc.DisableJoinOptimization” ist nicht angeschaltet. Diese Property dient zum Abschalten der Optimierung und ist standardmäßig nicht gesetzt.

6              Konfiguration des Application-Servers

In der Konfiguration eines Application-Servers im Systemcockpit können für den Zugriff über die Datenbankschnittstelle relevante Einstellungen vorgenommen werden. Da der Zugriff auf die Datenbankschnittstelle über JDBC jüngeren Datums ist, sind die Konfigurationsmöglichkeiten mit dem Namen „ODBC“ versehen. Sie gelten aber ebenso für den JDBC-Zugriff.

6.1        Einstellung „ODBC-Zugriff“

Über das Feld „ODBC-Zugriff“ kann für einen Application-Server eingestellt werden, ob dieser Zugriffe über die Datenbankschnittstelle verarbeiten soll und wenn ja, in welchem Zugriffsmodus er arbeiten soll. Zur Verfügung stehen die Modi „unbeschränkter“ und „beschränkter“ ODBC-Zugriff. Diese Modi betreffen das Verhalten des Application-Servers bezüglich der Belegung von Datenbankverbindungen und des Hauptspeicherverbrauches bei der automatischen Optimierung von Datenbankanweisungen, die über die Datenbankschnittstelle abgesetzt werden.

Ein Application-Server, der als Hauptaufgabe Datenbankschnittstellen-Zugriffe ausführt, sollte im unbeschränkten Modus betrieben werden.

Limitierung der verwendbaren Datenbankverbindungen

Die Anzahl der für die Datenbankschnittstellen-Zugriffe gleichzeitig verwendeten Datenbankverbindungen kann begrenzt werden.

Im beschränkten Modus werden maximal 50 % der möglichen Datenbankverbindungen für Datenbankschnittstellen-Zugriffe gleichzeitig verwendet. Damit wird sichergestellt, dass andere Nutzer interaktiv mit dem Application-Server arbeiten können. Im unbeschränkten Modus werden, wenn nötig, alle verfügbaren Datenbankverbindungen für die Datenbankschnittstellen-Zugriffe verwendet. Dadurch kann es vorkommen, dass Benutzer nicht mehr interaktiv arbeiten können.

Für Business Entitys wird die spezielle Spalte „link_text“ zur entsprechenden Tabelle hinzugefügt. Diese enthält die URL, um das Business Entity in Comarch ERP Enterprise anzuzeigen. Zur Generierung der URL muss der Application-Server, der die Datenbankschnittstellen-Anfrage bearbeitet, entsprechend konfiguriert werden.

Bei den Application-Server-Einstellungen in der Anwendung „Systemcockpit“ muss im Feld „Ziel-Server für Link-Attribute“ der Application-Server angegeben werden, auf dem die Default-Anwendung mit der Business-Object-Instanz als Parameter geöffnet werden soll. Dies kann ein anderer Application-Server sein als der, der die Datenbankschnittstellen-Anfrage verarbeitet. Er muss aber auf dieselbe Datenbank zugreifen können.

7              Berechtigungen

Berechtigungen für den Zugriff über die Datenbankschnittstelle können auf Benutzer- und Business-Entity-Ebene festgelegt werden.

7.1        Berechtigung auf Benutzerebene

Um die Verwendung der Datenbankschnittstelle für einen Benutzer zu erlauben oder zu verbieten, stehen folgende Fähigkeiten zur Verfügung:

Fähigkeit Framework Beschreibung
com.cisag.sys.odbc.UseODBC System-Management ODBC verwenden
com.cisag.sys.odbc.UseOqlViews System-Management OQL-Views in ODBC verwenden

7.2        Berechtigung auf Business-Entity-Ebene

Zusätzlich zu den Fähigkeiten werden beim Zugriff über die Datenbankschnittstelle auch die Berechtigungen auf Business-Entity-Ebene ausgewertet. Tabellen von Business Entitys und deren Dependents, auf denen der angemeldete Benutzer nicht die Berechtigung für den Zugriff über die Datenbankschnittstelle hat, sind für ihn nicht sichtbar. Virtuelle Tabellen und virtuelle Funktionen sind meist jeweils einem Business Entity zugeordnet und erben damit dessen Berechtigungen.

8              Modellierungshinweise

Der Programmierer von Berichten erhält nachfolgend Hinweise zur Nachbildung von Datenmodellen in Comarch ERP Enterprise und zur Vermeidung von Modellierungsfehlern.

8.1        Namenskonventionen der Datenquellen

Die Standard-Berichte sind mit in den in der Tabelle angegebenen Standard-Datenquellen verbunden:

Datenquelle Bemerkung
Semiramis OLTP Stamm- und Bewegungsdaten
Semiramis OLAP Statistiken und betriebswirtschaftliche Auswertungen
Semiramis Repository Systemweite Daten und Beschreibungen
Semiramis Configuration Konfigurationseinstellungen

Dementsprechend müssen die zugehörigen Datenquellen auf dem Client-Rechner eingerichtet sein. Alternativ kann die für einen Bericht zu verwendende Datenquelle in der Berichtsanwendung umgestellt werden. Detaillierte Informationen zur der Anwendung „Berichte“ finden Sie in der Dokumentation „Berichte“.

8.2        Einschränkungen bei der Abfrage mehrerer OLTP-Datenbanken

Aus technischen Gründen kann beim interaktiven ODBC-Zugriff, d. h. innerhalb einer externen Anwendung wie z. B. Crystal Reports, eine einmal gewählte ERP-System-Datenquelle für eine OLTP-Datenbank nicht gewechselt werden. D. h., soll eine andere OLTP-Datenbank abgefragt werden, muss die Berichtsanwendung beendet und neu gestartet werden. Alternativ kann auch eine zweite Anwendungsinstanz geöffnet werden.

Ein Bericht kann bei der Ausführung über den interaktiven ERP-System-ODBC-Treiber somit nicht mehrere OLTP-Datenbanken abfragen. Ein Bericht kann aber gleichzeitig eine OLTP-, die Repository- oder Konfigurationsdatenbank sowie die zur OLTP-Datenbank gehörende OLAP-Datenbank abfragen. Als (allerdings wenig praktikable) Umgehung des Problems könnte ein Bericht auf zwei OLTP-Datenquellen gleichzeitig zugreifen, die auf unterschiedliche Application-Server verweisen.

Diese Einschränkung gilt nur für den interaktiven Zugriff, nicht aber für die Berichtsausgabe mittels ERP-System-Output-Manager (SOM).

8.3        Visualisierung des Datenmodells

Um sich über das Datenmodell zu einem Business Object zu informieren ist es hilfreich, die Metadaten des Business Objects nachzuschlagen. Dazu dient die Anwendung „Entwicklungsobjekte“ im Framework „Software-Entwicklung“. Eine weitere Möglichkeit, um die Metadaten zu einem Business Object anzuzeigen, bietet das Kontextmenü, Menüpunkt „Entwicklungsobjekt“, eines Entity-Feldes.

Die Metadaten enthalten im Wesentlichen die Informationen zu den Attributen, Datentypen, Indizes, Beziehungen und weiteren Eigenschaften eines Business Objects.

Um eine grafische Darstellung des Datenmodells zu einer Menge von Business Objects zu erhalten kann die Anwendung „Datenmodelldiagramme“ verwendet werden. Detaillierte Informationen finden Sie in der Dokumentation „Datenmodell-Diagramme“.

8.4        Datenmodell des Berichtes

Das Datenmodell von Comarch ERP Enterprise ist komplex und folgt objektrelationalen Entwurfsprinzipien. Daraus resultiert für das Erstellen von Berichten, dass der Programmierer schnell mit einer großen Anzahl von Tabellen konfrontiert wird, auf die ein Bericht zugreift. Neben der Unübersichtlichkeit kann dies auch zu Performanceproblemen führen, da eine Join-Operation zwischen Tabellen eine teure Datenbankoperation ist. Deshalb sollte die Komplexität eines Berichtes möglichst gering sein. Des Weiteren sollte darauf geachtet werden, dass die Joins zwischen den Tabellen so formuliert sind, dass die automatische Join-Optimierung das resultierende SQL-Statement vereinfachen und dadurch der Cache des Application-Servers genutzt werden kann.

8.4.1    Verwendung der speziellen Spalten

Wenn man explizit alle benötigten Tabellen heranziehen würde, um eine Abfrage zu formulieren, dann könnte das schnell zu einem komplexen Modell von 10-15 Tabellen führen. Z. B. unterhält eine Vertriebsauftragsbasis (CISAG@ENTITY.app_sales_SalesOrder) ca. 90 Referenzen auf andere Tabellen. Ein Großteil dieser Referenzen zeigt auf allgemein verwendete Business Objects wie Währungen, Auftragsarten, Einheiten usw. Hier sollte immer geprüft werden, ob die durch die Datenbankschnittstelle zur Tabelle hinzugefügten Spalten für Bezeichnungen (Suffixe „_txt“ bzw. „_BK“) im Bericht verwendet werden können, anstatt einen Join zur entsprechenden Tabelle zu formulieren.

8.4.2    Denormalisierte Business Objects

Comarch ERP Enterprise denormalisiert an einigen Stellen das Datenmodell, d. h. unterhält Kopien. Gründe dafür sind in der Leistungsfähigkeit im Zugriff auf die Daten und in der Archivierbarkeit von Bewegungsdaten zu suchen (z. B. Kundenstammdaten in der Auftragsbasis).

Hinweis:
Empfohlen wird, sofern die entsprechenden Attribute in der Kopie existieren, mit der Kopie zu arbeiten, um das Datenmodell so einfach wie möglich zu halten.

9              Fehlermeldungen

Aufgetretene Fehler während des Zugriffs über die Datenbankschnittstelle werden mittels Fehlermeldungen protokolliert. Dies kann an verschiedenen Stellen geschehen und erfolgt im SOM-Betrieb sowie bei der interaktiven Verwendung der Datenbankschnittstelle.

Fehler, die im Application-Server aufgetreten sind, werden in das System-Protokoll des Application-Servers, der die Datenbankschnittstellen-Zugriffe ausführt, geschrieben und gehören der Meldungsklasse ODS an. Mittels der Anwendung „Meldungsprotokolle“ kann dieses eingesehen werden.

Weiterhin sendet der SAS alle aufgetretenen Fehlermeldungen an die Datenbankschnittstelle. Der ERP-System-ODBC-Treiber trägt die vom SAS empfangenen Meldungen sowie Meldungen zu im Treiber selbst aufgetretenen Fehlern in das Windows-Ereignis-Protokoll ein. Im Treiber auftretende Fehler sind normalerweise Meldungen, die auf Kommunikationsfehler mit dem ODBC-Server hinweisen. Der JDBC-Treiber gibt Fehler in Form von SQL-Exceptions aus.

Im SOM-Betrieb werden zusätzlich die Fehlermeldungen in den Statusmeldungen des zugehörigen Ausgabeauftrages eingetragen, so direkt am Ausgabeauftrag ein Hinweis auf die Fehlerursache sichtbar ist. Dies sollte die erste Anlaufstelle sein, um eine Fehlerursache zu ermitteln.

Im interaktiven Betrieb werden der ODBC-Anwendung (z. B. Crystal Reports) über die ODBC-API die Fehlermeldungen zur Verfügung gestellt, so dass diese mittels Dialog-Fenstern direkt in der Anwendung angezeigt werden.

Häufige Fehlerursachen

Viele Fehler treten aufgrund einer nicht zustande gekommenen oder abgebrochenen Kommunikation zwischen den beteiligten Servern auf. Gründe hierfür sind häufig: das System wurde falsch konfiguriert, der Application-Server läuft nicht oder wurde während der Berichtsausgabe neu gestartet, oder ein Zertifikat ist ungültig. Im interaktiven Betrieb sind auch veraltete ODBC-Datenquellen eine mögliche Ursache. Kommunikationsfehlermeldungen werden nicht in den Meldungsprotokollen des ODBC-SAS protokolliert, da zum Zeitpunkt, zu dem der Fehler auftritt, keine Verbindung besteht.

Andere Fehler haben ihre Ursache in fehlenden ODBC-Berechtigungen des für den ODBC-Zugriff verwendeten Benutzers oder auf dem Application-Server, der für den ODBC-Zugriff verwendet wird, ist kein ODBC-Zugriff erlaubt.

Viele Fehlermeldungen, die bei der Berichtsentwicklung auftreten, beziehen sich auf die in diesem Dokument beschriebenen Einschränkungen bzgl. der Verwendung der speziellen Spalten der Business Objects und Datentypen sowie der virtuellen Tabellen/Funktionen.

10         JDBC-Treiber

Der JDBC-Treiber ist neben dem ODBC-Treiber eine weitere Schnittstelle zu den Datenbanken eines Comarch-ERP-Enterprise-Systems. Der JDBC-Treiber bietet das gleiche Datenmodell wie der ODBC-Treiber an, dieses ist ebenfalls für den rein lesenden Zugriff gedacht. Sämtliche Einstellungen, die in der Anwendung „Systemcockpit“ für den ODBC-Zugriff konfiguriert werden, gelten auch für den JDBC-Zugriff.

10.1    Installation des JDBC-Treibers

Der JDBC-Treiber wird als Dateiauslieferung „com.cisag.sys.delivery.Install-JDBC-Driver“ in Form einer „zip“-Datei ausgeliefert und aktualisiert. Entpacken Sie Datei „files/install/jdbc/jdbc-driver.zip“ mit einem entsprechenden Archivierungsprogramm vom Dateiserver-Ordner des Comarch-ERP-Enterprise-Systems. Alle entpackten „jar“-Dateien müssen in den Klassenpfad aufgenommen werden. Die Implementierung des JDBC-Treibers befindet sich in der Datei „semiramisjdbc.jar“.

10.2    Konfiguration einer JDBC-Verbindung

Der JDBC-Treiber kommuniziert mit dem Application-Server über das Protokoll HTTPS. Damit der JDBC-Treiber eine Verbindung aufbauen kann, muss eine Keystore-Datei erstellt werden, die folgende Information enthält:

  • Public Key von Comarch ERP Enterprise enthält (der Stammzertifizierungsstelle)
  • Zertifikat eines Benutzers

Die Keystore-Datei kann mit dem Java-Kommandozeilentool „keytool“ erstellt werden oder mit einer Wizard-Anwendung, wie z. B. KeyStore Explorer, und muss vom Typ „JKS“ sein.

Die Java-Schnittstelle zum Aufbau einer JDBC-Verbindung (java.sql.Connection) erwartet zwei Angaben: die Verbindungs-URL und die Angabe von Propertys.

Die Verbindungs-URL muss mit dem Protokoll-Präfix „jdbc:semiramis:“ beginnen, gefolgt von der URL zum SAS. Die URL ist dieselbe, die auch zur Konfiguration einer ODBC-Datenquelle verwendet wird. Sie kann somit aus dem Dialog zum Anlegen einer ODBC-Datenquelle kopiert werden.

Beispiel: jdbc:semiramis:https://sas.company.com?db=02E01C3889C4281092CAAC1BA84F0000&ou=00001E493E981F109F59846496160000&cl=de

Die Propertys sind Schlüssel-Werte-Paare für erforderliche Konfigurationsangaben. Folgende Properties kennt der JDBC-Treiber:

Schlüssel Beschreibung Erforderlich
keystore.file Vollständiger Pfad zur Keystore-Datei Ja
keystore.password Passwort zum Öffnen des Keystores Ja
certificate.password Password des Benutzerzertifikats im Keystore Ja
loglevel Loglevel, falls das Logging im JDBC-Treiber aktiviert werden soll. Mögliche Werte: INFO, WARNING, CONFIG, SEVERE, FINE, FINER, FINEST. Standard ist INFO. Nein
logname Präfix für die Logdatei. Wird vor dem Dateinamen geschrieben, wenn einer angegeben wurde. Die Logdatei wird in das Home-Verzeichnis des Benutzers geschrieben. Falls mehrere Anwendungen eine JDBC-Verbindung aufbauen, kann mittels Präfix die jeweilige Log-Datei der Anwendung zugeordnet werden. Nein
user Benutzername für die Anmeldung per Benutzername/Passwort statt Zertifikat. Dies ist der Comarch-ERP-Enterprise-Benutzername. Nur, wenn kein Benutzerzertifikat im Keystore hinterlegt ist, weil die Anmeldung per Benutzername/Passwort erfolgen soll
password Passwort des Benutzers. Nur, wenn die Anmeldung mit Benutzername/Passwort erfolgen soll

Czy ten artykuł był pomocny?

Wyślij opnie