Zwei neue Komponenten erleichtern das Erstellen von Datenexporten, Schnittenstellenprojekten und Auswertungen mit enaio® blueline.

  • enaioBlueSearch, welches langfristig die GetResultList-Komponente beerben soll. enaioBlueSearch punktet mit einer flexiblen Anfragesyntax und der Möglichkeit, Systemfelder komfortabel per DropDown-Liste auszuwählen.
  • enaioBlueGetIndexData, welches ergänzende Metadaten und Informationen zu bekannten Objekt-IDs abfragbar macht. Dabei erlaubt es eine DropDown-Liste, die Implementation gegenüber der enaio®-API zu wählen, abhängig vom gewünschten Feature-Umfang.

Folgende Beispielstrecke soll die Verwendung der zwei neuen Komponenten verdeutlichen:

Beispielstrecke: Anfragen mit den neuen Komponenten enaioBlueSearch und enaioBlueGetIndexData.

Als Datenbasis soll uns eine einfache Ablage der enaio®-Dokumentation mit einem variantierten Dokument dienen:

Beispieldokumente inkl. Variante für OS_Installationshandbuch.

Die enaioBlueSearch-Komponente (DocsWithVariants) fragt dabei über einer einfachen Syntax alle Dokumente mit dem Namen *Installationshandbuch* ab:

Anfragesyntax mit Syntaxvervollständigung innerhalb des Code-Fensters (Query).

Ergebnisfelder lassen sich entweder durch deren interne Namen oder - im Fall von Systemfeldern - durch eine praktische DropDown-Liste verknüpfen:

DropDown-Liste für Systemfelder inklusive Hinweis auf Anwendbarkeit für Stamm-/Register-/Dokumentfelder.

Zusätzlich zu den eigentlichen Systemparametern kann auch ein “virtueller” Parameter Variants angefragt werden. Dieser gibt die hierarchische Struktur der Dokumentvarianten als String (Versions-ID,ID der Vaterversion,Versionsnummer,Aktivstatus;Nächste Versions-ID...) zurück.

Das Anfragen von Dokumentvarianten geht mittels Variants-Feld schnell von statten.

Zunächst soll hier aber die Komponente enaioBlueGetIndexData mit der Implementation der enaio®-API dms.GetResultList gezeigt werden. Diese eignet sich für alle Metadatenanfragen die sich lediglich auf die aktive Variante eines Dokuments beziehen und ist in diesen Fällen zu bevorzugen. Sie bietet das Maximum an verfügbaren Systemfeldern. Hier am Beispiel der SDREG_ID (Register-ID/Standort des Mittels Object-ID übergebenen Dokuments):

Die Auswahlliste passt sich dynamisch der gewählten Implementation und damit verfügbaren Systemfelder an.

Hier sehen wir im Beispiel die Ausgabe des Register-ID also des Standorts des angefragten Dokuments:

Testweise Ausgabe des Anfrageergebnisses via tLogRow.

Im zweiten Schritt soll die hier gezeigte Erweiterung der Strecke die Funktion der Implementation der enaio®-API dms.GetObjectDetails zeigen. Die Strecke wird mit einem tReplicate erweitert und das zuvor angefragte Feld Variants normalisiert (tNormalize). Dies macht aus einer Eingangs-Row so viele Ausgangs-Rows, wie Varianten vorliegen:

Normalisieren des Variants-Strings durch Splitting am Semikolon.

Beispielhaft lassen wir uns für jede Variante das Anlagedatum (Basisparameterauswahl CreationDate) zurückgeben:

Implementation dms.GetObjectDetails, die anders als dms.GetResultList auch inaktive Varianten auslesen kann.

Das Ergebnis im Testlauf ist entsprechend um die Ausgaben des zweiten Zweiges ergänzt (siehe Markierung im Text). Jede Variante erhält eine eigene Zeile, obwohl nur ein Treffer durch die Suchanfrage zurückgegeben wurde. Zu sehen sind die Anlagedaten und Varianteninformationen:

Beispielstrecke mit Ausgaben beider Zweige.