1 Themenübersicht
Die Anwendung „Entwicklungsobjekte“ dient der Erfassung und Ansicht von Entwicklungsobjekten verschiedenster Typen. In dieser Dokumentation wird der Typ „OQL-Suche“ beschrieben.
Allgemeine Informationen zur Anwendung „Entwicklungsobjekte“, beispielsweise die Beschreibung der anwendungsbezogenen Aktionen oder des Identifikationsbereichs, finden Sie in dieser Dokumentation „Entwicklungsobjekte“.
2 Beschreibung
OQL-Suchen dienen dem Auffinden von Objekten in der Datenbank. Die Verwendung von Suchen erfolgt in Form von Wertehilfen an Feldern, als Anwendungswertehilfe im Navigationsbereich oder in Anwendungen (z. B. Abfrageanwendungen). Detaillierte Informationen finden Sie in der Dokumentation Refererenzhandbuch: Suchen.
Die Suche ist eine mehrteilige OQL-Anweisung der Form „SELECT“ (siehe Dokumentation OQL-Syntax). Die Ergebnismenge des Selects ist das Suchergebnis. Dabei kann die OQL-Anweisung in mehrere Fragmente unterteilt werden. Im Basisfragment befindet sich das eigentliche „SELECT“ auf ein Business Object oder ein OQL-View, das durch Joins beliebig verknüpft werden kann. In den Zusatzfragmenten befinden sich weitere Joins, die nur bei Bedarf in die Selektion aufgenommen werden (siehe Unterer Karteireiter OQL).
2.1 Unterer Karteireiter Allgemeines
Unter diesem Karteireiter erfolgt die Definition der Eigenschaften der OQL-Suche:
| Feld | Erläuterung |
| Bezeichnung | Name der Suche, der bei der Visualisierung angezeigt wird. |
| Darstellung | Definition der Visualisierungsart, wenn die Suche als Feldwertehilfe verwendet wird:
· Combobox: Das Suchergebnis wird in einer kleinen Box am unteren Feldrand dargestellt. Eine Eingabe von Selektionsparametern ist nicht möglich. Diese Visualisierungsart eignet sich nur für kleine Ergebnismengen. · Dialog: Das Suchergebnis wird in einem Dialogfenster dargestellt. Über die Selektionsparameter kann das Suchergebnis eingeschränkt werden. Diese Visualisierungsart eignet sich für große Ergebnismengen. |
| Hook | Angabe einer Klasse, mit der über definierte Hooks in die Ausführung und Darstellung der Suche eingegriffen wird (z. B. Manipulation von Anfrageparametern, Manipulation von Ergebnismengen oder Darstellung von Selektionsfeldern).
Dazu muss der Hook bestimmte Interfaces implementieren. Die OQL-Suche wird im Verwendungsnachweis der Java-Klasse aufgenommen. |
In der Rubrik „Datenbank“ stehen folgende Felder zur Verfügung:
| Feld | Erläuterung |
| OLTP-Datenbank | Die verwendeten Business Objects und OQL-Views befinden sich auf der OLTP-Datenbank.
Die in der OQL-Anweisung verwendeten Objekte müssen alle auf derselben Datenbank angelegt sein. |
| OLAP-Datenbank | Die verwendeten Business Objects und OQL-Views befinden sich auf der OLAP-Datenbank.
Die in der OQL-Anweisung verwendeten Objekte müssen alle auf derselben Datenbank angelegt sein. |
| Repository-Datenbank | Die verwendeten Business Objects und OQL-Views befinden sich auf der Repository-Datenbank.
Die in der OQL-Anweisung verwendeten Objekte müssen alle auf derselben Datenbank angelegt sein. |
| Konfigurations-Datenbank | Die verwendeten Business Objects und OQL-Views befinden sich auf der Konfigurations-Datenbank.
Die in der OQL-Anweisung verwendeten Objekte müssen alle auf derselben Datenbank angelegt sein. |
In der Rubrik „OQL-Anweisung“ stehen folgende Felder zur Verfügung:
| Feld | Erläuterung |
| Distinct(Checkbox) | Doppelte Ergebnisse werden entfernt. Dabei ist zu beachten, dass die Sortierparameter, die der Suche implizit hinzugefügt werden, im Feld „Select“ aufgenommen werden.
Dadurch wird die Ergebnismenge verändert. Das gezeigte Suchergebnis muss nicht dem erwateten Suchergebnis entsprechen. |
| SELECT | Anzeige der Rückgabeparameter der OQL-Anweisung. |
| GROUP BY | Angabe einer GROUP-BY-Klausel. Normalerweise lassen Sie dieses Feld leer, damit die GROUP-BY-Klausel automatisch berechnet wird. |
| HAVING | Angabe einer HAVING-Klausel. |
| ORDER BY | Anzeige der festgelegten Standardsortierung. |
Die Felder stehen außerdem zur Verfügung:
| Feld | Erläuterung |
| Basisobjekt | Definition des Basisobjekts der Suche.
Bei der Verwendung der Suche im Navigationsbereich wird der Ergebnismenge ein spezieller Rückgabewert hinzugefügt. Der Name des Rückgabewertes entspricht dem Namen des Basisobjekts. Er enthält den technischen Schlüssel, über den die Instanz aus dem Basisobjekt geladen wird. Über die Schlüsselzuordnungen erfolgt die Definition des Rückgabewertes. Die OQL-Suche wird im Verwendungsnachweis des Basisobjekts aufgenommen. |
| Schlüsselzuordnungen | Zuweisung von Rückgabeparametern der Suche, die dem Primärindex des Basisobjekts entsprechen. |
2.2 Unterer Karteireiter OQL
Unter diesem Karteireiter erfolgt die Definition der OQL-Anweisung. Die OQL-Anweisung wird dabei in Fragmente unterteilt:
- Basisfragment (erste Zeile in der Liste) und in
- optionale Zusatzfragmente unterschieden.
Über den Button „Fragmente“ werden die Spalten angezeigt, in denen die Bestandteile der OQL-Anweisungen der OQL-Suche definiert werden. Die folgenden Felder stehen zur Verfügung:
| Spalte | Erläuterung |
| FROM | Definition der From-Klausel des OQL-Ausdrucks.
Im Basisfragment wird das Business Objekt oder die OQL-View, auf dem die Suche erfolgt, angegeben. Durch die Verwendung von Joins kann die Suche auf andere Objekte ausgeweitet werden. Der Klausel wird ein Name zugewiesen, der in den Zusatzfragmenten benutzt wird. Die Syntax im Basisobjekt ist: {<Name> = <OQL-Ausdruck>}.Das Zusatzfragment wird im Bedarf der OQL-Anweisung hinzugefügt. Dabei wird die From-Klausel des Basisobjekts um eine Join erweitert. Die Syntax im Zusatzfragment ist: {<Name>} JOIN <OQL-Ausdruck>. Im Verwendungsnachweis der in der OQL-Anweisung verwendeten Business Objects und OQL-Views wird die OQL-Suche aufgenommen. |
| WHERE | Definition der WHERE-Klausel der OQL-Anweisung.
Durch diese Angabe kann die Ergebnismenge der Suche statisch eingeschränkt werden. Die WHERE-Klausel wird ohne das Schlüsselwort „where“ erfasst. |
Über den Button „Parameter“ werden weitere Spalten angezeigt, in denen die Erfassung der Suchattribute erfolgt sowie deren Eigenschaften definiert werden.Die folgenden Felder stehen zur Verfügung:
| Spalte | Erläuterung |
| Attribut | Angabe eines Attributs eines Business Objects oder einer OQL-View aus der From-Klausel.
Der Name muss über den angegebenen Alias referenziert werden. Syntax: „Alias:Attributname“ oder „Funktion(Alias:Attributname)“. Sie können die Aggregationsfunktionen „AVG“, “MIN“, “MAX“, “SUM“ verwenden. Beachten Sie, dass Attribute mit Aggregationsfunktionen nicht als Suchmerkmal verwendet werden können. Das Attribut wird im Verwendungsnachweis des Business Objects oder der OQL-View aufgenommen.
|
| Name | Frei wählbarer Name für den Parameter.
Dieser wird für das Setzen der Selektionsparameter und die Abholung der Suchergebnisse genutzt. Der Name muss innerhalb der Suchdefinition eindeutig sein. Wird ein neuer Parameter zu einer OQL-Suche hinzugefügt, die nicht im eigenen Entwicklungsnamensraum liegt, muss der Name mit dem Entwicklungspräfix des aktuellen Systems beginnen. In diesem Fall wird das Präfix bei der Neuanlage automatisch vorgeblendet. |
| Primitiver Datentyp | Anzeige des Datentyps des Attributs. |
| Suchmerkmal | Festlegung des Attributes als Suchmerkmal in der Suche.
Über das Feld kann der Benutzer die Suchergebnismenge einschränken. Die Nummerierung bestimmt die Position des Suchmerkmalfelds in der Anzeige. Sie beginnt für das erste Feld bei „0“. Die GUI-Eigenschaften werden über die Data-Description des Attributs gesteuert. Erfolgt eine Einschränkung der Suche durch ein Suchmerkmal aus einem Zusatzfragment, dann wird die QOL-Anweisung um das Zusatzfragment erweitert. Beachten Sie, dass Attribute mit Aggregationsfunktionen nicht als Suchmerkmal verwendet werden können.
|
| Anzeige | Darstellung der Instanzen des Attributs in der Ergebnismenge der Suche.
Die Nummerierung bestimmt die Position in der Liste (0 ist die erste Spalte in der Liste). Die GUI-Eigenschaften werden über die Data-Description des Attributs gesteuert. Wenn keine Nummer angegeben wird, dann wird das Feld nicht in der Ergebnismenge dargestellt. Hinweis: |
| Spezialverhalten | Definition eines Spezialverhalten des Attributs:
· Identifikation: Übernimmt den Wert aus Feldern mit einer Feldwertehilfe in das Attribut. Ist kein Wert in dem Feld erfasst, startet die Suche automatisch. Wird ein Ergebnis aus der Suche übernommen, wird der Inhalt in das aufrufende Feld zurückgeschrieben. Es kann nur ein Identifikationsfeld pro Suchdefinition angegeben werden. · Bezeichnung: Wird nur bei einem ExtendedTextField verwendet. Ist die Suchergebnismenge als ComboBox visualisiert, werden die Inhalte von Code und Text nebeneinander dargestellt. Bei einer Übernahme eines Suchergebnisses wird der Inhalt des Text-Attributs in den hinteren Teil des ExtendedTextField übernommen. · Unsichtbar: Das sind versteckte Abfrageparameter. Diese Felder werden erzeugt und der Oberfläche hinzugefügt. Anschließend werden die Felder auf nicht sichtbar umgeschaltet. Das Spezialverhalten ist nur für die Abfrage nutzbar. · Löschkennzeichnung: Kann nur auf einem Timestamp basieren. In der Regel handelt es sich dabei um das Attribut deleteTime des UpdateInformation-Parts eines Business Objects. Zusätzlich muss der Parameter als Abfrage- und Anzeigefeld markiert sein. Innerhalb einer Suche kann nur einem Parameter das Spezialverhalten „Löschkennzeichen“ zugeordnet sein. · Suchkontext: Es werden keine Selektionsfelder erzeugt. Sie werden ausschließlich für den Suchkontext benutzt. Hinweis: |
| Rückgabe | Attribut ist in der Rückgabemenge des Suchergebnisses enthalten.
Die Nummerierung bestimmt die Position in Rückgabemenge (0 ist die erste Position in der Rückgabemenge). Hinweis: |
| Schlüssel | Kennzeichnung der eindeutigen Schlüsselattribute.
Diese wird zum Wiederaufsetzen der Suche benötigt. Dies ist vor allem bei großen Ergebnismengen gewünscht. Die Datensätze werden seitenweise geladen. Der letzte Datensatz der Seite wird gemerkt und die Suche bei diesem wieder aufgesetzt. Die Schlüsselattribute sollten immer ausgezeichnet werden. Hinweis: |
| Sortierbar nach | Angabe, ob das Attribut als Sortierparameter zur Verfügung steht. Der Benutzer entscheidet, ob nach diesen Attribut sortiert wird.
Wenn ein Attribut aus dem Zusatzfragment durch den Benutzer in die Sortierung der Suche aufgenommen wird, wird die OQL-Anweisung um das Zusatzfragment erweitert. |
| Sortiermerkmalposition | Das Attribut wird in die Sortierung aufgenommen.
Die Nummerierung bestimmt die Position in der Sortierung (in der „ORDER BY“-Klausel). Zusatzfragmente, in denen ein Attribut als Sortiermerkmal in der Sortierung enthalten ist, werden immer in die OQL-Anweisung aufgenommen. |
| Sortierrichtung | Legt die Richtung der Sortierung fest (aufsteigend, absteigend). |
Über die Buttons „Data-Description-LDT“ werden weitere Spalten eingeblendet, in der die GUI-Eigenschaften der Suche beeinflusst werden. Folgende Felder stehen zur Verfügung:
| Spalte | Erläuterung |
| Logischer Datentyp (Suchmerkmal) | Logischer Datentyp, mit dem die GUI-Eigenschaften des Selektions-Feldes bestimmt werden.
Die OQL-Suche wird im Verwendungsnachweis des Logischen Datentyps aufgenommen. |
| Logischer Datentyp (Anzeige) | Die OQL-Suche wird im Verwendungsnachweis des Logischen Datentyps aufgenommen.
Die OQL-Suche wird im Verwendungsnachweis des Logischen Datentyps aufgenommen. |
Beispiel: OQL-Suche
Bei der Suche nach erfassten Regionen kann die Selektion nach bestimmten Regionskürzel und Beschreibungen eingeschränkt werden. Optional kann die Selektion auf ein bestimmtes Land beschränkt werden.
- OQL-Suche:
com.cisag.app.<…>.obj.Region
- Basisobjekt:
Business Object com.cisag.app.<…>.obj.Region
- Schlüsselzuordnung:
guid (Business Object Region) – guid (OQL-Suche Region)
Hauptfragment:
FROM: {REGION = com.cisag.app.<…>.obj.Region r}
Attribute:
| Spalte | Name | Selektion | Anzeige | Ergebnisfeld | Rückgabe | Key | Sortierung | Def. Sort. | Sort. Rhf. |
| r:description | description | 1 | 1 | Bezeichnung | 2 | – | ja | 1 | Aufst |
| r:country | country | – | – | Kein | 3 | – | – | – | – |
| r:code | code | 0 | 0 | Idendifikation | 1 | – | ja | 0 | Aufst |
| r:guid | guid | – | – | Kein | 0 | ja | – | – | – |
Def. Sort. – Defaultsortierung; Sort. Rhf. – Sortierreihenfolge
Nebenfragment:
FROM: {REGION} join com.cisag.app.<…>.obj.Country c on c:guid = r:country
Attribute:
| Spalte | Name | Selektion | Anzeige | Ergebnisfeld | Rückgabe | Key | Sortierung | Def. Sort. | Sort. Rhf. |
| c:isoCode | isoCode | 2 | – | ja | – | ||||
Def. Sort. – Defaultsortierung; Sort. Rhf. – Sortierreihenfolge
2.3 Unterer Karteireiter Layout
Standardmäßig wird das Suchergebnis einer OQL-Suche in einem Grid visualisiert. Über diesen Karteireiter kann das Layout des Suchergebnisses definiert werden. Das Grid bietet hierfür verschiedene Layoutfunktionen an, wie z.B. mehrzeilige Darstellung, Formatierung von Spalten, usw. Weil die OQL-Suchen sowohl als Dialogsuche als auch als Suche im Navigationsbereich verwendet werden können, wird in dem Karteireiter für diese beiden Fälle jeweils ein Grid dargestellt. Das Grid für die Suche im Navigator-Bereich hat dabei die Breite, wie sie später zur Darstellung des Suchergebnisses zur Verfügung hat. Es kann somit für beide Fälle das Layout unabhängig von einander definiert werden.
Hinweis:
Über Hooks kann definiert werden, das die Darstellung des Suchergebnisses in einer Liste statt in einem Grid erfolgen soll. In diesem Fall greifen die Änderungen am Layout in diesem Karteireiter nicht sondern das Layout muss über das Hook ausprogrammiert werden. Werden in diesem Fall trotzdem auf diesem Karteireiter Änderungen am Layout vorgenommen, so werden diese nicht berücksichtigt.
Es besteht die Möglichkeit, über Hooks dem Suchergebnis Spalten hinzuzufügen, welche nicht in der OQL-Suche definiert wurden. Die Java-Klasse, die den Hook implementiert, wird geladen, um die darin enthaltenen Informationen auszuwerten. Zum Laden der Hook-Java-Klasse stehen die folgenden Möglichkeiten zur Verfügung:
- mit Work-Ordner
Wenn der Work-Ordner beim Laden der Java-Klasse berücksichtigt wird, dann wird die Klasse direkt aus dem Classes-Ordner im Benutzer- oder Common-Ordner des Work-Ordners geladen. Die Klasse kann jederzeit wiederholt geladen werden, ein Neustart des Application-Servers ist dazu nicht notwendig.
Wenn das Laden und/oder die Auswertung der Klasse mit dem Work-Ordner nicht möglich ist, so muss die Klasse ohne den Work-Ordner geladen werden.
- ohne Work-Ordner
Wenn der Work-Ordner beim Laden der Java-Klasse nicht berücksichtigt wird, dann wird die Klasse über den Klassenpfad des Application-Servers geladen. Wenn die Klasse sich ändert, dann muss der Application-Server neu gestartet werden. Wenn der Application-Server in einer Entwicklungsumgebung läuft, die das Austauschen der Klassen zur Laufzeit erlaubt, so kann die Klasse auch über diesen Mechanismus erneut geladen werden.
Die Anwendung berücksichtigt diese Hooks und fügt diese Spalten den Grids hinzu. Dadurch kann das Aussehen dieser Spalten ebenfalls durch die Layoutfunktionen des Grid definiert werden.
Hinweis
Wenn die Java-Klasse des Hooks gesperrt und in Bearbeitung ist, so muss diese sich in derselben Aufgabe befinden, wie die OQL-Suche. In diesem Fall findet der in Bearbeitung befindliche Hook Berücksichtigung bei der Darstellung der Grids. Ist der Hook in einer anderen Aufgabe gesperrt, so muss diese erst freigegeben und aktiviert werden. Andernfalls können Effekte auftreten, wie z.B. dass Spalten im Hook dem Grid hinzugefügt werden, aber die Anwendung diese Spalten im Karteireiter Layout nicht anzeigt.
Im Kopfbereich des Karteireiters befindet sich eine Symbolleiste mit folgenden Schaltflächen:
| Name | Beschreibung |
| Neues Layout aus Work-Ordner erzeugen | Erzeugt das Grid mit den in der OQL-Suche definierten Ergebnisspalten. Wenn für die Suche ein Hook verwendet wird, so wird die Klasse des Hooks aus dem Work- Ordner geladen. Da die geänderte Hook-Klasse nicht im Klassenpfad des Application-Servers sein muss, sondern direkt aus dem Work- Ordner geladen wird, kann diese Funktion auf jedem Application-Server des Systems verwendet werden. |
| Neues Layout ohne Work-Ordner erzeugen | Erzeugt das Grid mit den in der OQL-Suche definierten Ergebnisspalten. Wenn für die Suche ein Hook verwendet wird, so wird die Klasse geladen, ohne den Work-Ordner speziell zu berücksichtigen. Wenn Sie die Hook-Klasse verändert haben, stellen Sie sicher, dass die geänderte Klasse im Klassenpfad des Application-Servers ist. |
| Layout aus Work-Ordner laden | Lädt die vorhanden Layouts der Suche. Wenn für die Suche ein Hook verwendet wird, so wird die Klasse des Hooks aus dem Work-Ordner geladen. Da die geänderte Hook-Klasse nicht im Klassenpfad des Application-Servers sein muss, sondern aus direkt aus dem Work-Ordner geladen wird, kann diese Funktion auf jedem Application-Server des Systems verwendet werden. |
| Layout ohne Work-Ordner laden | Lädt die vorhanden Layouts der Suche. Wenn für die Suche ein Hook verwendet wird, so wird die Klasse geladen, ohne der Work-Ordner speziell zu berücksichtigen. Wenn Sie die Hook-Klasse verändert haben, stellen Sie sicher, dass die geänderte Klasse im Klassenpfad des Application-Servers ist. |
| Layout löschen | Löscht die vorhandenen Layouts der Suche. |