SearchCronTask
Die SearchCronTask-API ermöglicht die Abfrage von Daten aus Lobster Data Platform / Orchestration über eine Suche oder Tupel-Suche, ausgehend von einem Lobster_data-Profil vom Typ Cron-Job. Das Suchergebnis definiert dabei die Eingangsdaten des Profils, so dass weitere Verarbeitungsschritte unmittelbar folgen können.
Die auszuführende Suche oder Tupel-Suche wird über eine Konfigurationsdatei für den Eingangsagenten (Phase 1) im Profil definiert, die das XML-Format der Klasse core:SearchTask verwendet.
Der Abfragekonfigurator stellt eine grafische Benutzeroberfläche bereit, mit der XML-Konfigurationsdateien zur Definition von Abfragen systematisch aufgebaut und interaktiv getestet werden können (s. a. Such API).
Die Konfigurationsdatei kann Metadatenvariablen aus dem Profilaufruf im Format @VARIABLENNAME@ und ohne das Präfix MSG_CALL_ einbeziehen.
Beim Erstellen einer Abfrage mit dem Abfragekonfigurator, werden automatisch die verwendeten Anmeldedaten für die Authentifizierung der Abfrage eingebunden. (s. Lobster_data Login).
Der betreffende Unterknoten base:LobsterDataLoginRequest kann bei Bedarf anschließend durch Editieren der XML-Datei angepasst werden.
Neben absoluten Angaben können für Anmeldeparameter (Benutzer, Rolle, Firma, usw.) dabei auch Metadatenvariablen aus dem Profilaufruf als Parameter einbezogen werden.
Wenn der Aufruf des Profils per Lobster Data Platform / Orchestration erfolgt, stehen die Anmeldedaten der Sitzung z. B. über die per Standard befüllten Variablen (wie SCM_User_username , SCM_Company_id etc.) zur Verfügung.
Konfiguration
Die nachfolgenden Konfigurationsschritte beschränken sich auf die ersten Phasen 1-3 des Profils, in denen die Beschaffung der Eingangsdaten (Suchergebnisse) über die SearchCronTask-API geregelt wird.
Die weitere Verarbeitung ausgehend von der mit den Suchergebnissen befüllten Quellstruktur im Phase 3 betrifft die SearchCronTask-API nicht. Sie ist abhängig von der konkreten Aufgabenstellung mit allgemeinen Funktionen von Lobster_data zu regeln.
Basis-Daten
Im Tabreiter Basis-Daten des Profils sind zwei Einstellungen relevant:
Als Dokumentenart muss XML angegeben werden, da die Suchergebnisse von Lobster Data Platform / Orchestration im XML-Format eintreffen.
Als Zeichenkodierung muss "UTF-8" ausgewählt sein, da Lobster Data Platform / Orchestration diese Codierung für die Suchergebnisse verwendet.
Phase 1: Eingangsagent
Im Tabreiter Phase 1 muss zunächst die Art des Eingangsagenten ausgewählt werden. Nach der Auswahl von Zeitgesteuert erscheint unterhalb u. a. die Option Eigene Klasse (API), der die SearchCronTask-API angehört.
Nach der Auswahl der Kategorie Eigene Klasse kann der Eingangsagent parametriert werden:
Als Klasse muss hier SCM: SearchCronTask ausgewählt werden.
Die Konfigurationsdatei muss aus bereits vorhandenen Dateien ausgewählt oder komplett neu erstellt werden.
Beispiel für das Erstellen einer Konfigurationsdatei:
Ein Profil soll als Eingangdaten eine einfache Liste aller "Benutzernamen" erhalten, deren Konto inaktiv gesetzt ist und im laufenden Kalenderjahr nicht verändert wurde.
Eine entsprechende Abfrage kann mit einer Anmeldung, die mindestens über Leserechte für die betreffenden Benutzerkonten verfügt, per Abfragekonfigurator erstellt und getestet werden:
In einer Tupel-Suche für die Entität "Benutzer" wir zunächst unter den Projektionen das Feld "Benutzername" (username) angegeben.
Als Bedingung wird hier eine Einfache Feld Einschränkung (active ungleich true) mit einer Feld Einschränkung (lastModified kleiner als "Anfang des Jahres") per UND-verknüpft.
Aus dem XML-Tab im Abfragekonfigurator kann die XML-Definition der Abfrage über die Zwischenablage direkt in eine (ggf. neu angelegte) Konfigurationsdatei übernommen werden:
<?
xml
version
=
"1.0"
encoding
=
"UTF-8"
?>
<
core
:SearchTask
xmlns:xsd
=
"http://www.w3.org/2001/XMLSchema"
xmlns:xsi
=
"http://www.w3.org/2001/XMLSchema-instance"
xmlns:base
=
"SCM.BASE"
xmlns:core
=
"CORESYSTEM"
entity
=
"base:User"
skipCsvEnvelope
=
"false"
tryUseExistingConnection
=
"true"
>
<
base
:LobsterDataLoginRequest
clientType
=
"HTML5_DESKTOP"
locale
=
"de"
forceLogin
=
"false"
safeMode
=
"false"
isMobile
=
"false"
userName
=
"UserAdmin"
selectedRole
=
"51"
selectedCompany
=
"501"
skipCheckCombination
=
"false"
/>
<
core
:TupleSearch>
<
core
:SearchJunction
junction
=
"CONJUNCTION"
>
<
core
:SimplePropertySearch
projection
=
"active"
compareType
=
"!="
booleanValue
=
"true"
/>
<
core
:PropertySearch>
<
core
:PropertyProjection
property
=
"lastModified"
/>
<
compareType
><</
compareType
>
<
value
type
=
"START_THIS_YEAR"
xsi:type
=
"core:DateTimeValue"
/>
</
core
:PropertySearch>
</
core
:SearchJunction>
...
<
core
:PropertyProjection
property
=
"username"
/>
<
groupBy
/>
</
core
:TupleSearch>
</
core
:SearchTask>
Phase 2: Parser
Im Tabreiter Phase 2 sind drei wichtige Einstellungen für den "Parser" vorzunehmen:
Die Option Namespaces ignorieren muss deaktiviert sein.
Als XML-Tag für Datenblatt muss der zum Typ der Suche passende Knotenname (für eine Suche "core:SearchResult", für ein Tupel-Suche "core:TupleSearchResult") eingetragen sein.
Als Lobster XML Parser muss die Version "V4" (sofern lizenziert, sonst "V2") ausgewählt sein.
Phase 3: Mapping (Quellstruktur)
Die Quellstruktur für das Mapping (Phase 3) im Profil kann passend zur Definition der Abfrage automatisch erzeugt werden. Abhängig vom verwendeten Typ der Suche erscheint dabei eine Struktur der Klasse core:SearchResult oder core:TupleSearchResult, deren Unterknoten result jeweils die eigentlichen Suchergebnisse auflistet (Datenobjekte bei einer Suche oder Tupel von Projektionsergebnissen bei einer Tupel-Suche).
Das Erzeugen einer Quellstruktur passend zur SearchTask-Definition in der Konfigurationsdatei ermöglicht der Dialog zum Laden von Lobster_pro Vorlagen (Menüleiste der Quellstruktur > "Vorlage laden" > "Lobster SCM").
Da als Eingangsagent (s. Phase 1) die Eigene Klasse core:SearchCronTask ausgewählt ist, erscheint im Dialog die Checkbox Vom Search-Task (per Standard gesetzt).
Das Feld Entität ist ebenfalls bereits vorbelegt. Hier erscheint der Name der Klasse auf den sich die Abfragedefinition in der Konfigurationsdatei bezieht.
Per Klick auf den Button Anwenden (nicht im Bild) wird die Quellstruktur ausgehend von der Klasse core:SearchResult bzw. core:TupleSearchResult (s. Screenshot) erstellt:
►ACHTUNG◄ Falls die Abfragedefinition in der Konfigurationsdatei Parameter verwendet (s. a. Abschnitt unten), sind diese beim Erstellen der Quellstruktur nicht mit Werten besetzt. Das führt zu Schwierigkeiten, wenn ein Parameter ein Feld der Abfragedefinition füllen soll, für das ein leerer Wert nicht akzeptabel ist. In diesem Fall sollte anstelle des Parameters zunächst ein konkreter Wert eingetragen werden. Nachdem die Quellstruktur generiert wurde, kann dann der Parameter wieder in die Konfigurationsdatei eingetragen werden.
Verwenden von Parametern innerhalb der Konfigurationsdatei
Die Abfragedefinition in der Konfigurationsdatei kann Parameter verwenden, an deren Stelle zur Laufzeit die Werte von Metadatenvariablen des Profils eingesetzt werden.
Der Bezug zur Variablen wird über die Syntax @<VARIABLENNAME>@ hergestellt, wobei anstelle von <VARIABLENNAME> der Name einer Metadatenvariablen ohne das Präfix MSG_CALL_ anzugeben ist.
Beispiele:
Innerhalb der Abfragedefinition für einen SearchCronTask, wird im Abfragekonfigurator zunächst eine konkrete Bedingung für den Abruf bestimmter Benutzerkonten festgelegt:
Abfragekonfigurator (Ausschnitt) |
XML (Ausschnitt) |
|
Sämtliche Attribute für die Einfache Feld Einschränkung explizit mit Werten belegt. < core :SimplePropertySearch projection = "username" compareType = "ilike" stringValue = "ad%" /> Mit dieser Bedingung werden nur Benutzerkonten zurückgegeben, deren Benutzername (username) mit der Zeichenfolge AD (ohne Beachtung der Groß-/Kleinschreibung) beginnt. |
Im nächsten Schritt soll ein Parameter die Vergleichszeichenfolge für diese Bedingung zur Laufzeit des Profils aus der Metadatenvariablen mit dem Namen var__USERNAME_ILIKE beziehen:
Abfragekonfigurator (Ausschnitt) |
XML (Ausschnitt) |
|
Der Parameter wird im Abfragekonfigurator als Zeichenfolge für die Einfache Feld Einschränkung eingetragen. < core :SimplePropertySearch projection = "username" compareType = "ilike" stringValue = "@var__USERNAME_ILIKE@" /> Mit dieser Bedingung werden nur Benutzerkonten zurückgegeben, deren Benutzername (username) ohne Beachtung der Groß-/Kleinschreibung der Vergleichszeichenfolge entspricht, die beim Aufruf des Profils als Wert der Variablen var__USERNAME_ILIKE anliegt.
|
Um das Profil noch flexibler einsetzen zu können sollen nun auch noch die Attribute projection und compareType für die Einfache Feld Einschränkung durch Parameter gesetzt werden.
Abfragekonfigurator (Ausschnitt) |
XML (Ausschnitt) |
Die grafische Oberfläche lässt keine Zuordnung der Parameter-Zeichenfolgen für die per Auswahlfeld zu treffenden Einstellungen zu. Daher muss zu diesem Zweck die Konfigurationsdatei direkt im XML-Format bearbeitet werden (Ergebnis s. rechts). |
Hier verweisen Parameter auf die Metadatenvariablen PROJECTION , COMPARE_TYPE und COMPARE_STRING: < core :SimplePropertySearch projection = "@PROJECTION@" compareType = "@COMPARE_TYPE@" stringValue = "@COMPARE_STRING@" /> Zur Laufzeit sind auf dieser Grundlage flexible Bedingungen über Variablen "formulierbar" solange immer ein Zeichenfolgenvergleich passend ist. Beispiele: (mit unterschiedlichen Kombinationen von Variable:Wert) PROJECTION:locale, COMPARE_TYPE:!=, COMPARE_STRING:de
PROJECTION:address.countryCode, COMPARE_TYPE:==, COMPARE_STRING:AT
|