!!TODO!!

dms.GetResultList

Beschreibung:

Dieser Job sucht nach DMS-Objekten, die der Anfrage entsprechen. Die Festlegung der DMS-Zielobjekte und Felder geschieht über ein XML-Anfragedokument. In dem XML-Anfragedokument können OS-Namen, interne Namen, GUIDs und Datenbanknamen verwendet werden.

Über Attribute lassen sich allgemeine Eigenschaften der Anfrage setzen. Diese Attribute lassen sich sowohl als Jobparameter setzen, als auch als XML Attribute im Rootelement der XML Anfrage definieren, wobei die XML Attribute vorrangig behandelt werden.

Parameter:

Rückgabe: 0 = Job erfolgreich, ansonsten Fehlercode

Rückgabewerte:

Ausführliche Beschreibung

Eine Anfrage besteht im Wesentlichen aus der Festlegung des angefragten DMS-Objekts, der Auswahl der zurückzugebenden Felder und dem Setzen von Suchbedingungen. Darüber hinaus besteht z. B. die Möglichkeit, Standortinformationen anzufragen, Volltext- oder Basisparameterrecherchen durchzuführen, Verknüpfungen zu Objekten aus anderen Schränken zu erstellen oder die Anfragen zu parametrisieren.

DMS-Anfragetypen

Bei Suchanfragen wird prinzipiell zwischen linearen und hierarchischen Anfragen unterschieden. Einen Sonderfall stellen die Detailanfragen dar.

Lineare Anfragen / Lineare Objektlisten (LOL)

Über lineare Anfragen können die einfachen Indexdaten von Objekten eines bestimmten Typs angefordert werden. Tabellensteuerelemente und Mehrfachparameterfelder sind davon ausgeschlossen. Werden Dokumente oder Register angefragt, können auch Felder des direkten Elternregisters und des Ordners angefragt werden.

Hierarchische Anfragen / Hierarchische Objektlisten (HOL)

Hierarchische Anfragen können nicht nur den Inhalt von Tabellensteuerelementen und Mehrfachparameterfeldern zurückgeben, sondern auch Kindelemente, also z. B. die Register und Dokumente innerhalb des angefragten Ordners. Zusätzlich können Objekteigenschaften wie z. B. Dokumentenvarianten, Zugriffsrechte und Notizen angefordert werden.

Hierarchische Anfragen über verschachtelte Registerstrukturen sind nicht möglich.

Neben den funktionellen Unterschieden zwischen linearen und hierarchischen Anfragen gibt es einen bedeutenden technischen Unterschied. Die Trefferlisten für lineare Anfragen können mit einem Satz von Datenbankanfragen erhalten werden. Bei hierarchischen Anfragen muss zusätzlich zu jedem Treffer, d.h. für jede Objektinstanz, mindestens eine weitere Datenbankanfrage durchgeführt werden. Jede angefragte Objekteigenschaft erhöht diese Zahl der Datenbankanfragen pro Objektinstanz.

Kann auf Tabellensteuerelemente, Mehrfachparameter, Kindelemente und Zusatzeigenschaften (Dokumentenvarianten, Zugriffsrechte, Notizen) verzichtet werden, empfiehlt sich aus Performancegründen, immer eine lineare Anfrage zu stellen.

Gemischte Anfragen (MIX)

Aufgrund der oben beschriebenen erheblichen Performanceunterschiede gibt es noch einen dritten Anfragetyp, der als gemischte Anfrage bezeichnet wird. Dabei handelt sich um eine Mischung zwischen linearer und hierarchischer Anfrage, in der komplexe Informationen zu Ordnern oder Registern und einfache Informationen zu deren direkten Kindobjekten angefordert werden können. Zu den Kindobjekten wird pro Objekttyp eine Datenbankanfrage gestellt. Das Einsatzszenario entspricht z. B. dem Öffnen eines Ordners, um dessen vollständigen Indexdaten und Objekteigenschaften zu erhalten sowie die Übersicht aller Register und Dokumente, die sich in diesem Ordner befinden.

DMS – Ergebnisformate

picture-rId19Das XML Format für die Anfrageergebnisse beginnt immer mit dem <DMSContent> Element. Dieses enthält ein Attribut 'format', welches die Werte LOL für lineare Objektliste, HOL für hierarchische Objektliste und 'MIXED' für gemischte Trefferliste annehmen kann.

Lineare Objektliste (LOL)

Lineare Objektlisten werden durch das <Rowset> Element eingeleitet. Sie besitzen einen tabellarischen Aufbau, d.h. es wird zuerst der Tabellenkopf beschrieben (<Columns>) und darunter alle Trefferzeilen (<Rows>) aufgelistet.

picture-rId20

Beispiel:

<?xml version="1.0" encoding="UTF-16" standalone="yes" ?>
<DMSContent format="
24T15:18:19" user="ROOT" station="OSEPA">
<Archive name="Patient" id="5" osguid="04C7E64C981C456A9D1F5B12D188A752">
<ObjectType name="Patient" id="5" osguid="04C7E64C981C456A9D1F5B12D188A752"
type="FOLDER" table="stamm6">
<Rowset>
<Columns>
<Column object="Patient" type="FOLDER" name="Name" datatype="TEXT"
dbname="feld2" ostype="X" size="50">Name</Column>
<Column object="Patient" type="FOLDER" name="Vorname" datatype="TEXT"
dbname="feld3" ostype="X" size="50">Vorname</Column>
<Column object="Patient" type="FOLDER" name="Ort" datatype="TEXT"
dbname="feld10" ostype="X" size="50">Ort</Column>
</Columns>
<Rows>
D:\Testdaten\VirtPC\Queries\HOL\tmp0002.xml - #
<Value>Abold</Value>
<Value>Beate</Value>
<Value>Berlin</Value>
</Row>
<Row id="38003">
<Value>Abold</Value>
<Value>Christina</Value>
<Value>Berlin</Value>
</Row>
</Rows>
</Rowset>
<Statisticsstartpos="0" pagesize="2" total_hits="530" />
</ObjectType>
</Archive>
<Messages/>
</DMSContent>

Hierarchische Objektliste (HOL)

Hierarchische Trefferlisten werden durch das <ObjectList> Element eingeleitet. Für jedes Trefferobjekt werden Felddefinition und Feldwert geschrieben. Hierarchische Trefferlisten können über das <ChildObjects> Element beliebige Hierarchietiefen abbilden.

picture-rId22

Beispiel:

Hierarchische Objektliste

<DMSContent format="
24T15:29:03" user="ROOT" station="OSEPA">
<Archive name="Patient" id="5"   osguid="04C7E64C981C456A1F5B12D188A752">
<!—Ordner -->  
<ObjectType name="Patient" id="5"
osguid="04C7E64C981C456A9D1F5B12D188A752" type="FOLDER" table="stamm6">
<!—Ordnerliste -->  
<ObjectList>
<Object id="37751">
<Fields>
<Field name="PatientenID" datatype="TEXT" dbname="feld1" ostype="X"
size="20">777777</Field>
<Field name="Name" datatype="TEXT" dbname="feld2" ostype="X"
size="50">Sandmann</Field>
<Field name="Vorname" datatype="TEXT" dbname="feld3" ostype="X"
size="50">Sandor</Field>
</Fields>
<!—Kindobjekte des Ordners -->
<ChildObjects>
<!—Register -->
<ObjectType name="Aufenthalt" id="6488064"
osguid="A90F043941488DB43B69CBDA" type="REGISTER" table="register1">
<ObjectList>
<Object id="3226">
<Fields>
<Field name="Fallnummer" datatype="TEXT" dbname="feld62" ostype="X"
size="20">987654</Field>
<Field name="Beginn" datatype="DATE" dbname="datum1" ostype="D"
size="10">01.10.2003</Field>
<Fieldname="Ende" datatype="DATE" dbname="datum2" ostype="D"
size="10" />
</Fields>
<-- Kindobjekte des Registers -->
<ChildObjects>
<!—DokumenttypArztbrief' -->
<ObjectType name="Arztbrief" id="262273" osguid="14799BCD39A920AF3"
type="DOCUMENT" modul="WINDOWS"  table="object162">
<ObjectList>
<Object id="37744">
<Fields>
<Field name="Datum" datatype="DATE" dbname="datum1" ostype="D"
size="10">12.11.2003</Field>
<Field name="erstell. Arzt" datatype="TEXT" dbname="feld1"
ostype="X" size="50">DEMO</Field>
<Field name="Typ" datatype="TEXT" dbname="feld3" ostype="X"
size="20">Arztbrief operativ</Field>
<Fieldname="Status" datatype="INTEGER" dbname="zahl2"
ostype="9" size="1" />
</Fields>
</Object>
</ObjectList>
<Statisticsstartpos="0" pagesize="5" total_hits="1" />
</ObjectType>
</ChildObjects>
</Object>
</ObjectList>
<Statisticsstartpos="0" pagesize="5" total_hits="1" />
</ObjectType>
</ChildObjects>
</Object>
</ObjectList>
<Statisticsstartpos="0" pagesize="5" total_hits="1" />
</ObjectType>
</Archive>
<Messages/>
</DMSContent>

Darstellung der Feldwerte

Im Allgemeinen werden Feldwerte als XML Elementtext ausgegeben. Für einige Feldtypen gibt es aber Unterschiede zwischen dem Wert in der Datenbank und dem angezeigten Wert, dazu zählen:

Für diese Feldtypen wird der Datenbankwert als Wert eines ‘value' Attributes zurückgegeben, während der Anzeigetext im XML Elementtext enthalten ist.

Beispiel für LOL:

<Value value="M">männlich</Value>

Beispiel für HOL:

<Field value="M" name="Geschlecht" datatype="TEXT" dbname="feld7"
ostype="X" size="1">männlich</Field>

Das <Statistics> Element

Am Ende jeder Trefferliste findet sich das <Statistics> Element, welches Angaben über den Ergebnisumfang enthält. Diese Informationen sind insbesondere zum Blättern durch Trefferlisten wichtig.

<Statisticsstartpos="20" pagesize="20" total_hits="50" />

Das <Messages> Element

Informationen über fehlerhafte Anfragen finden sich in den <Message> Elementen.

Beispiel:

<Messages>
<Message faultcode="-2116351928" sourcecode="475">Die Volltextanfrage konnte nicht durchgeführt werden, da kein Suchtext angegeben wurde.
</Message>
</Messages>

Kombination von Anfragetypen und Ausgabeformaten

Das Ausgabeformat für lineare Anfragen ist standardmäßig das oben beschriebene LOL-XML-Format. Es ist aber auch möglich, lineare Trefferlisten in einem einfachen Textformat oder im HOL-XML-Format anzufordern. Dies geschieht über den Parameter 'OutputFormat'.

Im Textformat werden die Werte durch ein über den Parameter 'ItemDelimiter' definierbares Trennzeichen voneinander getrennt.

Ausgabeformat
TXT
Anfragetyp LOL
MIX
HOL

Allgemeines Anfrageverhalten

In einer Suchanfrage können Suchbedingungen für ein oder mehrere Objekttypen formuliert werden. Es können z. B. bei einer Dokumentenanfrage sowohl Bedingungen für ein Register und Ordner festgelegt werden.

Für den enaio® client wurde ein besonderes Anfrageverhalten definiert. Enthalten Anfragen Registerbedingungen – egal ob Anwender oder aus dem Rechtesystem – ist das Anfrageverhalten laut 'Anforderungen für Anfragen in enaio® client' wie folgt definiert:

Für Dokumente gilt die Regel:

Es sind alle Dokumente zu liefern, die sich in einem Register befinden, das den Suchkriterien entspricht und zusätzlich alle Dokumente, die sich in keinem Register befinden.

Für Ordner gilt die Regel:

Es sind alle Ordner zu liefern, in denen sich ein Register befindet, das den Suchkriterien entspricht und alle zusätzlich alle Ordner, die kein Register enthalten.

Im Job GetResultList lässt sich dieses Verhalten über den Jobparameter 'RegisterContext' bzw. das XML Attribut 'registercontext' steuern. Ist der Parameter nicht angegebenen oder er hat den Wert 1ist dieses Suchverhalten aktiv, hat der Parameter den Wert 0 ist diese Funktion abgeschaltet.

Erstellen von Anfragen

Zur Erstellung einer Anfrage müssen zunächst die anzufragenden DMS Objekte und Felder definiert werden. Die DMS Objekte und Felder können identifiziert werden über:

Beispiel für eine einfache Anfrage

Mit folgender Anfrage werden alle Ordner des Schranks 'Patient' angefordert. Da Objektnamen innerhalb eines Schrankes nicht eindeutig sein müssen – z. B. kann ein Dokumenttyp so heißen wie der Ordnertyp – kann man den Objekttyp über das Attribut 'type' festlegen. Gültige Werte sind 'FOLDER', 'REGISTER' und 'DOCUMENT'.

Über die Zuweisung des Wertes 'ALL' zum <Fields> Attribut 'field_schema' wird der DMS Executor angewiesen, alle DMS Felder des angefragten Objektes – also hier des Patientenordners – zurückzugeben.

<?xml version="1.0" encoding="UTF-8" ?>
<DMSQuery>
<Archive name="Patient">
<ObjectType name="Patient" type="FOLDER" >
<Fields field_schema="ALL"/>
</ObjectType>
</Archive>
</DMSQuery>

Felder definieren

Werden nicht alle Indexdaten benötigt, lassen sich die gewünschten Felder auch explizit festlegen. Dazu setzt man für das Feldschema Attribut 'field_schema' den Wert 'DEF'.

<?xml version="1.0" encoding="UTF-8" ?>
<DMSQuery>
<Archive name="Patient">
<ObjectType name="Patient" type="FOLDER" >
<Fields field_schema="DEF">
<Fieldname="Name"/>
<Fieldname="Vorname"/>
<Fieldname="PLZ / Wohnort"/>
<Fieldname="Ort"/>
</Fields>
</ObjectType>
</Archive>
</DMSQuery>

Optionsschaltflächen

Eine Sonderrolle nehmen Optionsschaltflächen ein, da es sich hierbei um eine Gruppe von Feldern handelt. Besitzt eine solche Gruppe ein statisches Gruppenfeld, lässt sich dieses als Recherchefeld verwenden. Ansonsten kann jedes einzelne Auswahlfeld als Stellvertreter der Gruppe ausgewählt werden.

Systemfelder

Über das <Field> Element lassen sich auch Systemfelder anfragen. Dazu ist das Attribut 'system' auf '1' zu setzen. Systemfelder lassen sich über einen internen Namen, eine GUID oder über ihren Datenbankfeldnamen angeben. Eine Übersicht über die zulässigen Systemfelder findet sich in der DMS Referenz. Im folgenden Beispiel wird zusätzlich zu allen Indexdaten des Objektes 'Bilder' die Anzahl der Dokumentdateien angefragt.

<?xml version="1.0" encoding="UTF-8" ?>
<DMSQuery>
<Archive name="Patient">
<ObjectType name="Bilder" type="DOCUMENT" >
<Fields field_schema="ALL">
<Fieldinternal_name="OBJECT_COUNT" system="1"/>
</Fields>
</ObjectType>
</Archive>
</DMSQuery>

Sortierung

Um die Trefferlisten einer LOL Anfrage nach bestimmten Feldern zu sortieren, muss dass Attribut 'sortpos' mit einem Wert größer 0 angegeben werden. Zusätzlich kann über das Attribut 'sortorder' mit dem Wert ASC eine aufsteigende bzw. mit dem Wert DESC eine absteigende Sortierung gewählt werden. Wird das Attribut 'sortorder' nicht angegeben, wird aufsteigend sortiert, es sei denn, ein Feld mit höherer Sortierpriorität hat das Attribut sortorder explizit gesetzt. In diesem Fall wird der Wert für die folgenden Felder ohne das Attribut übernommen.

Besitzen mehrere Felder das Attribut 'sortpos', so haben Felder mit niedrigerem 'sortpos'-Wert eine höhere Priorität.

Mit der folgenden Anfrage werden alle Register vom Typ 'Aufnahme' aus dem Schrank 'Patient' angefordert. Dabei werden alle Indexdaten sowie die Dokumentendateianzahl angefordert. Sortiert werden die Treffer aufsteigend nach dem Feld 'Autor' und anschließend absteigend nach 'Datum'.

<?xml version="1.0" encoding="UTF-8" ?>
<DMSQuery>
<Archive name="Patient">
<ObjectType name="Aufnahme" type="REGISTER" >
<Fields field_schema="ALL">
<Fieldname="Autor" sortpos="1" sortorder="ASC"/>
<Fieldname="Datum" sortpos="2" sortorder="DESC"/>
</Fields>
</ObjectType>
</Archive>
</DMSQuery>

Für hierarchische Anfragen ist eine Soriterung der Ausgabe nicht möglich

Suchbedingungen

Bedingungen können nicht nur für das angefragte Objekt formuliert werden, sondern auch auf Eltern- und Kindobjekte. Daher muss zunächst das Klauselobjekt (Attribut ConditionObject), für das die Suchbedingen gelten sollen, festgelegt werden. Es können in einer Anfrage Suchbedingen für mehrere Objekte gleichzeitig definiert werden.

Im folgenden Beispiel werden alle Patienten angefragt, die am 1.1.2004 auf Station 1 aufgenommen wurden und größer als 180 cm sind:

<?xml version="1.0" encoding="UTF-16" ?>
<DMSQuery>
<Archive name="Patient">
<ObjectType name="Patient" type="FOLDER">
<Fields field_schema="DEF">
<Fieldname="Name"/>
<Fieldname="Vorname"/>
<Fieldname="PLZ / Wohnort"/>
<Fieldname="Ort"/>
</Fields>
<Conditions>
<ConditionObject name="Aufenthalt" type="REGISTER">
<FieldCondition name="Station" operator="=">
<Value>1</Value>
</FieldCondition>
<FieldCondition name="Beginn">
<Value>1.1.2004</Value>
</FieldCondition>
</ConditionObject>
<ConditionObject name="Körpermaße" type="DOCUMENT">
<FieldCondition name="Körperhöhe [cm]" operator="&gt;">
<Value>180</Value>
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>

Wie in diesem Beispiel zu sehen ist, muss der '>' Operator (Attribut operator='>') kodiert werden, damit das Dokument dem XML Format entspricht. Wird in einer Bedingung kein Operator angegeben, wird der Operator '=' verwendet. Folgende Vergleichsoperatoren sind zulässig:

Vergleichsoperatoren
Operator XML konformes Format
< <
<= <=
= =
!= !=
> >
>= >=
BETWEEN BETWEEN
NOT BETWEEN NOT BETWEEN
IN IN
NOT IN NOT IN
Platzhalter

Bei Anfragen auf Textfelder können die gleichen Platzhalter wie in enaio® client verwendet werden:

Platzhalter Bedeutung
* beliebige Zeichenfolge
? Einzelnes Zeichen
~ Phonetische Suche (nur MSSQL und Oracle)

Als Escapezeichen dient der Backslash, d.h. mit ? würde nach einem Fragezeichen gesucht werden.

Null wert

Zur Prüfung eines Werte auf NULL steht das <NULL/> Element zur Verfügung, dass anstelle des <Value> Elementes verwendet werden muss.

Spezialwerte

Über das Element <SpecialValue> lassen sich Spezialwerte abbilden. Folgende Werte stehen dafür zur Verfügung:

#COMPUTER-GUID#" GUID des Computers des angemeldeten Benutzers
#COMPUTER-NAME#" Name des Computers des angemeldeten Benutzers
#COMPUTER-IP#" IP Adressen des Computers des angemeldeten Benutzers
#ANLEGER#" Verknüpfung mit Basisparameterfeld „Anleger“
#ANLEGEDATUM#" Verknüpfung mit Basisparameterfeld „Anlegedatum“
#ARCHIVAR#" Verknüpfung mit Basisparameterfeld „Archivar“
#ARCHIVIERUNGSDATUM#" Verknüpfung mit Basisparameterfeld „Archivierungsdatum“
#BENUTZER#" Name des angemeldeten Benutzers
#BESITZER#" Verknüpfung mit Basisparameterfeld „Besitzer“, welches die GUID des Besitzers enthält
"#DATUM# aktuelles Datum
Basisparameter-Eigenschaften von Dokumenten

Basisparameter-Eigenschaften von Dokumenten können als Suchbedingung über 'OBJEKT_SEARCHFLAGS' angegeben werden.

OBJEKT_SEARCHFLAGS können über Bitwerte einzeln oder kombiniert angegeben werden.

Für Kombinationen gelten folgende Regeln:

Eigenschaften, Werte und Gruppen:

archiviert 1 Gruppe 1
zur Archivierung freigegeben 2 Gruppe 1
nicht zur Archivierung freigegeben 4 Gruppe 1
ohne Seiten 8 Gruppe 1
von mir ausgecheckt 16 Gruppe 2
von anderen ausgecheckt 32 Gruppe 2
im Register 64 Gruppe 3
in keinem Register 128 Gruppe 3
ausgelagert 256 Gruppe 2
Verweisdokument 512 Gruppe 1
mehrere Standorte 1024 -
mit Varianten 2048 -
signiert in aktueller Version 4096 Gruppe 1
signiert in vorheriger Version 8192 Gruppe 1

Beispiel:

<Conditions>
<ConditionObject name="Document1" type="DOCUMENT">
<FieldCondition name="OBJECT_SEARCHFLAGS" system="1">
<Value>68</Value>
</FieldCondition>
</ConditionObject>
</Conditions>

Mit dem Wert '68' werden Dokumente mit der Eigenschaft 'im Register' (64) UND der Eigenschaft 'nicht zur Archivierung freigegeben' (4) gesucht.

Besonderheiten der DMS-Feldtypen

Suchbedingungen für Tabellenfelder

Dialogelemente vom Typ 'Tabelle' bestehen selbst aus einer oder mehreren Spalten, die einzeln recherchierbar sind. Im XML Anfrageformat ist dies folgendermaßen abgebildet:

picture-rId23

Anstelle eines <FieldCondition> Elementes wird ein <TableCondition> Element angegeben, mit dem die Tabelle selbst referenziert wird. Über das <TableColumn> Element wird die Tabellenspalte definiert, für die das Suchkriterium formuliert werden soll.

Beispiel:

<DMSQuery>
<Archive name="Testschrank">
<ObjectType name="WinDoc">
<Fieldsfield_schema="ALL" />
<Conditions>
<ConditionObject name="WinDoc">
<TableCondition name="MeineTabelle">
<TableColumn name="1.Spalte" operator="=">
<Value>11</Value>
</TableColumn>
</TableCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>

Liste mit Mehrfachauswahl

Bei Listen mit Mehrfachauswahl wird grundsätzlich der Platzhalter '*'an Anfang und Ende des Suchwortes gehängt.

Datum

Das Datum kann prinzipiell in allen gängigen Formaten angegeben werden. Für zweistellige Jahreszahlen gilt: wird eine Jahreszahl xy kleiner als 50 angegeben, wird daraus die Jahreszahl 20xy erstellt. Ist die Jahreszahl xy kleiner oder gleich 50 wird daraus die Jahreszahl 19xy erstellt.

Beipiel:

04 führt zu 2004
76 führt zu 1976

Bei Verwendung des Gleichheitsoperators für ein unvollständiges Datum, wird über den entsprechenden Zeitbereich gesucht.

Beispiel:

=1999 führt zu BETWEEN 1.1.1999 AND 31.12.1999
!= 1999 führt zu NOT BETWEEN 1.1.1999 AND 31.12.1999

Werden zwei Werte (über zwei <Value> Elemente) innerhalb einer Datumsbedingung angegeben, so werden diese automatisch als Bereich behandelt und ein 'BETWEEN' bzw. ein 'NOT BETWEEN' im SQL Statement verwendet.

Text

Es wird automatisch der LIKE Operator verwendet, wenn Platzhalter verwendet werden.

Optionsschaltflächen

Soll ein Suchkriterium auf eine Radiobuttongruppe gesetzt werden, so kann sowohl ein evtl. vorhandenes Gruppenfeld als auch ein beliebiges Radiobuttonfeld der Gruppe verwendet werden, um das Suchkriterium festzulegen.

Boolsche (UND/ODER) Verknüpfungen von Bedingungen

Suchbedingungen werden standardmäßig mit einem logischen UND verknüpft. Es besteht aber auch die Möglichkeit, Suchbedingungen mit ODER bzw. beliebige Kombinationen von UND und ODER zu verknüpfen. Dazu müssen die einzelnen Feldbedingungen über das <FieldGroup> Element gruppiert werden. Feldgruppen können dabei wiederum Feldgruppen enthalten.

<ConditionObject name="Pressearchiv">
<FieldGroup operator="OR">
<FieldCondition name="Fachgebiet">
<Value>Technik</Value>
</FieldCondition>
<FieldCondition name="Erstellt von:">
<Value>Schmitz</Value>
</FieldCondition>
</FieldGroup>
<Created>
<From>1.1.2002</From>
<To>31.12.2003</To>
</Created>
</ConditionObject>
Verknüpfung der Bedingungen bei mehreren <ConditionObject> Elementen

Wie bereits erwähnt, lassen sich innerhalb einer Anfrage Bedingungen auf mehrere Objekttypen definieren. Beziehen sich mehrere <ConditionObject> Elemente auf den gleichen Objekttyp so werden die darin jeweils enthaltenen Bedingungsgruppen mit ODER verknüpft.

Volltextbedingungen

Über das <Fulltext> Element kann eine Volltextanfrage durchgeführt werden. Volltextklauseln können als Text des Elementes <Fulltext> geschrieben werden.

Standortinformationen

Bei Recherchen nach Dokumenten oder Registern ist es oft wünschenswert, Informationen über den Standort, d.h. Ordner oder das Elternregister zu erhalten. Dazu legt man im <ParentObjects> Element fest, in welchem Umfang Informationen über die Elternobjekte angefragt werden sollen.

Für lineare Anfragen lassen sich maximal ein Register und der Ordner angeben. Ordner-, Register- und Objektfelder erscheinen in einer Trefferzeile.

Für hierarchische Anfragen wird bei Vorhandensein des <ParentsObjects> Element der gesamte Objektpfad bestimmt. Über die <SubObjectType> Elemente lassen sich zu den einzelnen Registern und zum Ordner die Felder festlegen.

Export von hierarchischen Strukturen

Hierarchische Anfragen unterscheiden sich von linearen Anfragen vor allem dadurch, dass ganze Objektstrukturen exportiert werden können. Dazu wird zunächst die Suche wie beschrieben nach dem übergeordneten Objekt formuliert. Als Unterelement erhält die Anfrage nun das Element <ChildObjects>. Dieses besitzt die Attribute 'export_depth' und 'child_schema'.

picture-rId24

Angabe der Exporttiefe

Mit dem Attribute 'export_depth' wird die Exporttiefe festgelegt, d.h. die Anzahl der zu exportierenden Objektebenen. 0 würde keine Kindobjekte exportieren, 1 nur die direkten Kindobjekte, etc.

Angabe des Objektschemas

Für das Attribut 'child_schema' stehen folgende Werte zur Verfügung:

Wert Bedeutung
DEF Benutzerdefinert
REG Alle Register werden automatisch hinzugefügt
DOC Alle Dokumente werden automatisch hinzugefügt
ALL Alle Register und Dokumente werden automatisch hinzugefügt

Über 'statistics_only=1' kann die Auswertung des Rechtesystems ausgeschaltet werden.

Angabe der Kindobjekttypen

Über das <ChildObjectType> Element lassen sich einzelne Kindobjekttypen festlegen. Innerhalb der <ChildObjectType> Elemente können Felder nach den gleichen Regeln wie für das Hauptanfrageobjekt festgelegt werden.

Hinweis:

Ein Kindobjekttyp darf nur einmal in der Kindobjekttypliste auftauchen.

picture-rId25

Einschränkungen für Kindobjekte

Die Auswahl der Kindobjekte lässt sich über zusätzliche Bedingungen weiter einschränken.

picture-rId26

Basisparameterrecherchen

Es ist möglich, Ordner, Register und Dokumente über die Basisparameter zu suchen. Nach der Festlegung des Schrankes über das <Archive> Element, kann man die Details für eine Ordner-, Register-, oder Dokumentenrecherche über Basisparameter festlegen.

picture-rId27

Innerhalb des entsprechenden Elementes (<FolderBaseParams>, <RegisterBaseParams> oder <DocumentBaseParams>) lassen sich nun folgende Suchbedingungen für die Basisparameter definieren:

XML Element Bedeutung
<Creator> Ersteller
<Created> Erstellungsdatum
<Modifier> Benutzer, der das Objekt zuletzt bearbeitet hat
<Modified> Datum der letzten Änderung. Werden zwei Werte angegeben, so wird über den Zeitraum zwischen diesen Daten gesucht
<Owner> Benutzername des Besitzers
<ArchiveState><ArchiveStateValue> Für Dokumente: Archivierungsstatus. Zulässige Werte: ARCHIVED (archiviert), ARCHIVABLE, (archivierbar), NOT_ARCHIVABLE (nicht archivierbar), NO_PAGES (keine Seiten), PAGE_ERROR (Fehlerhafte Seite), REFERENCE (Verweis)
<Locked><LockStateValue> Für Dokumente: Auscheckstatus. Zulässige Werte: UNLOCKED (nicht ausgecheckt), SELF (vom anfragenden Benutzer selbst ausgecheckt), OTHERS (von einem anderen Benutzer augecheckt), EXTERNAL (ausgelagert)

picture-rId28

Für Dokumente und Registeranfragen lässt sich außerdem über das <ChildObjects> Element die Auswahl der Objekttypen einschränken, oder für Ordner die Feldauswahl und die Sortierreihenfolge in der Trefferliste festlegen.

Volltextrecherchen

Ist die Volltextindexierung in enaio® eingerichtet, lässt sich über alle in enaio® editor entsprechend konfigurierten Objekttypen eine Volltextsuche durchführen. Dazu wird nach Festlegung des Schranks über das <Archive> Elementes, innerhalb des <FulltextQuery> Elementes die Volltextklausel über das <Fulltext> angegeben.

picture-rId29

Über das optionale <ChildObjects> Element lässt sich die Auswahl der Objekttypen einschränken oder die Feldauswahl und die Sortierreihenfolge der Objekte in der Trefferliste festlegen.

Beispiel:

Volltextsuche nach dem Wort 'Meningitis' in allen Arztbriefen und Diagnosen.

<?xml version="1.0" encoding="UTF-8" ?>
<DMSQuery>
<Archive name="Patient">
<FulltextQuery>
<ChildObjects child_schema="DEF">
<ChildObjectType name="Arztbrief">
<Fields>
<Fieldname="Datum" />
<Fieldname="Oberarzt" />
<Fieldname="Typ" />
</Fields>
</ChildObjectType>
<ChildObjectType name="Diagnose">
<Fieldsfield_schema="ALL" />
</ChildObjectType>
</ChildObjects>
<Fulltext>Meningitis</Fulltext>
</FulltextQuery>
</Archive>
</DMSQuery>

Parametrisierung von Anfragen

Zur Erleichterung der Wiederverwendung von Anfragen besteht die Möglichkeit, Suchbedingungen zu parametrisieren. Dazu werden unterhalb des <DMSQuery> Elementes alle Parameter definiert und initialisiert. In den Bedingungen der Anfrage können diese Parameterwerte über ihren Parameternamen mit Hilfe des 'ref' Attributes im <ParamValue> Element referenziert werden.

Beispiel:

<DMSQuery>
<Params>
<Param name="PatID">3987</Param>
</Params>
<Archive name="Patient">
<ObjectType name="Patient">
<Fieldsfield_schema="ALL" />
<Conditions>
<ConditionObject name="Patient">
<FieldCondition name="PatientenID">
<ParamValueref="PatID" />
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>

Eine Clientanwendung kann auf diese Weise ohne genauere Kenntnis der Anfragestruktur den Wert für die Bedingung über den Parameter ändern.

Schrankübergreifende Anfragen

picture-rId30Werden in einer Trefferliste zu einem Objekt Informationen benötigt, die in einem Objekt aus einem anderen Schrank enthalten sind, lässt sich dieses in einer HOL Anfrage über das <ExternalObjects> Element formulieren

Das <ExternalObjects> Element wird unterhalb des <ObjectType> Elementes definiert. Die Verknüpfung eines externen Objekts mit dem Ausgangsobjekt geschieht über eine Feldreferenz. Dazu wird bei dem Ausgangsobjektfeld, das den Wert für die Verknüpfung liefern soll, über das Attribut 'link_name' ein beliebiger Aliasname definiert. In der Feldbedingung des externen Objektes wird dieser Aliasname über das Attribut 'ref' im Element <LinkedValue> referenziert.

Beispiel:

Zu jedem S/W Dokument soll die Adresse des Autors mitgeliefert werden:

<DMSQuery>
<Archive name="Pressearchiv">
<ObjectType name="S/W-Scans">
<Fields>
<Fieldname="Dokumentart" />
<Fieldname="Autor" link_name="Autor" />
<Fieldname="Datum" />
</Fields>
<ExternalObjects>
<ExternalArchive name="Adressen">
<ExternalObjectType name="Adressen">
<Fieldsfield_schema="ALL" />
<SubConditions>
<FieldCondition name="Name:">
<LinkedValueref="Autor" />
</FieldCondition>
</SubConditions>
</ExternalObjectType>
</ExternalArchive>
</ExternalObjects>
</ObjectType>
</Archive>
</DMSQuery>

Erweiterte Informationen

Basisparameter

Durch Setzen des Basisparameterflags 'baseparams' auf '1' wird erreicht, dass zusätzlich zu den Verschlagwortungsfeldern auch alle Basisparameter angefragt werden. Speziell in der HOL wird dafür eine eigene Elementengruppe erzeugt:

Für alle Objekttypen werden die Werte für folgende Parameter ermittel:

Als Wert für den Besitzer wird dessen Name als text ausgegeben, die Benutzer GUID als Attribut 'osguid'.

Für Dokumente werden zusätzlich noch der ein- bzw. Auscheckstatus und er Archivierungsstatus bestimmt, sowie Retentionzeiten.

<BaseParams>
<Creator>liebe</Creator>
<Created>12.12.2003</Created>
<Modifier>root</Modifier>
<Modified>14.12.2003</Modified>
<Owner guid=”BC1123CDFAAAS”>liebe</Owner>
<ArchiveState>ARCHIVABLE</ArchiveState>
<Locked>SELF</Locked>
</BaseParams>
Objektstatus

Durch Setzen des Attributs 'status' auf '1' im <DMSQuery> Element werden zu jedem Objekt folgende Statusinformationen ermittelt:

Und speziell für Dokumente:

Rechte

Durch Setzen des Attributs 'rights' auf '1' im <DMSQuery> Element, werden für den anfragenden Benutzer zu jedem Objekt die Zugriffsrechte ermittelt. Folgende Rechte werden ermittelt:

Attribut Beschreibung
modify_index Benutzer darf die Indexdaten des Objekts ändern
delete_object Benutzer darf das Objekt löschen
export_object Benutzer darf das Objekt öffnen bzw. Exportieren
modify_object Benutzer darf Änderungen an den Dokumentendateien vornehmen.

Beispiel:

<Rightsmodify_index="1" delete_object="1" export_object="1"
modify_object="1" />
Objekttyprelationen

Über Objekttyprelationen lässt sich die Anzahl von Objektinstanzen eines gegebenen Typs einschränken. Über den Jobparameter 'ObjectInserts' bzw. über das Anfrageattribut 'object_inserts' lässt sich die Anzahl der noch einfügbaren Objektinstanzen unter Berücksichtigung der Objekttyprelationen und des Rechtesystems anfragen. Für jeden möglichen Kindobjekttyp, der nach dem Rechtesystem eingefügt werden darf, gibt es dann unterhalb des <Rights> Elementes ein Element <ObjektInserts>, welches als Attribute den Objekttyp (Attribut 'type') und die Anzahl der einfügbaren Instanzen (Attribut 'count') enthält. Ist der Wert für 'count' = -1,, gibt es keine Einschränkungen.

Weiterhin befindet sich im <Rights> Element das Attribut 'object_inserts', welches anzeigt, ob Objekttyprelationen angefragt wurden.

Wurde das 'rights' Attribut nicht auf '1' gesetzt, werden die Attribute für die Zugriffsrechte im <Rights> Element auf -1 gesetzt.

<Rights object_inserts="1" modify_index="1" delete_object="1" export_object="1" modify_object="1">
<ObjectInserts type="65536" count="-1" /> 
<ObjectInserts type="131108" count="-1" /> 
<ObjectInserts type="131119" count="0" /> 
<ObjectInserts type="196608" count="-1" /> 
<ObjectInserts type="196619" count="0" /> 
<ObjectInserts type="196622" count="-1" /> 
<ObjectInserts type="262144" count="-1" /> 
<ObjectInserts type="6488064" count="198" /> 
</Rights>
Dateiinformationen

Durch Setzen des Attributs 'fileinfo' auf '1' im <DMSQuery> Element, werden zu jedem Dokument die folgenden Dateinformationen extrahiert und als Attribute in ein <FileProperties> Element geschrieben.

Wenn der Job-Parameter [FollowDocLink] auf '1' gesetzt ist (oder im <DMSQuery> Element), werden bei typübergreifenden Verweisdokumenten die Dateiinformationen des verlinkten Dokuments zurückgeliefert. In diesem Fall werden zusätzlich die Attribute 'linkid' und 'linktypeid' geschrieben.

Für typübergreifende Verweisdokumente wird bei LOL-Anfragetypen weder 'mimetyp' noch 'size' zurückgegeben.

Folgende Dateieigenschaften können ermittelt werden:

Attribut Beschreibung
count Anzahl der Dateien
size Größe des Dokumentes in Bytes
extension Dateityp Standarderweiterung
mimetype Mimetyp
linkid ID des verlinkten Objektes
linktypeid Type ID des verlinkten Objektes
documentpagecount Anzahl der Dokument Seiten (wenn bekannt)

Beispiel:

<Object id="415">
<FilePropertiescount="1" size="179489" extension="jpg"  
mimetype="image/jpeg"/>
</Object>
Notizen

Wenn das DMSQuery Attribut 'remarks' auf '1' gesetzt wird, werden Notizen und Notizverknüpfungen mit zurückgeliefert für jedes angefragte Dokument, wenn welche vorhanden sind. Es werden Textnotizen und Objektnotizen (Verknüfungen) ausgegeben. Diese Funktion steht nur bei HOL-Anfragen zur Verfügung.

Attribut/Tag Beschreibung
id ID der Notiz
type Typ der Notiz (1=Weiß,2=Gelb,3=Grün,4=Blau)
relation Bei Objektrelation 1
medium Medium ID wenn Notizen im Work Verzeichnis abgelegt werden, 0 wenn der Notztext in der Datenbank gespeichert ist.
Creator Anlegername mit interner ID des Anlegers als Attribut.
Created Anlegedatum mit Timestamp als Attribut.
Modifier Letzter Bearbeiter mit der interner ID des Bearbeiter Attribut.
Modified Datum der letzten Bearbeitung mit Timestamp als Attribut.
Text Notztext mit interner ID, wenn die Notizen in der Datenbank abgelegt sind. Leer wenn es sich um eine Objektnotiz handelt.

Beispiel:

<Object id="81">
<Remarks>
<Remarkid="1413"type="1" relation="0"medium="4">
<Creatorid="16">MAIER</Creator>
<Createdvalue="1143560855">28.03.2006 17:47:35</Created>
<Modifierid="18">SCHMIDT</Modifier>
<Modifiedvalue="1946463756">30.04.2006 14:50:12</Modified>
<Textid="">Notiztext</Text>
</Remark>
</Remarks>
</Object>
Spracheinstellungen

Über das Attribut 'lang_id' oder 'query_language' kann festgelegt werden, in welcher Sprache die Anfrage erfolgen soll. Die Feldnamen bzw. Objektnamen werden dann sprachabhängig gesucht. Ohne Angabe wird die Defaultsprache verwendet.

Icons

Durch setzen des Attributs 'icons' auf '1' in der DMSQuery wird das System angewiesen, die Icon-IDs aller benutzerdefinierten Icons zurückzuliefern. Dabei werden sowohl die die Icon-IDs aus dem Archivbereich, als auch die benutzerdefinierten Icon-IDs aus einer Trefferliste bestimmt. Die DMSContent Elemente '<Object>' (HOL-Anfrage) und '<Row>' (LOL-Anfrage) erhalten zusätzlich das Attribut 'iconid'.

Um auf Basis der Icon-ID eine Bilddatei zu erhalten, kann der Job 'cnv.GetIcons' verwendet werden.

Dokumentenvarianten

Für Dokumente vom Modultyp ‘W-Dokumente” lassen sich in enaio® Varianten erstellen und verwalten. Durch Setzen des Attributs 'variants' auf '1' im <DMSQuery> Element, werden zu jedem W-Dokument die Varianten ermittelt und entsprechend ihrer hierarchischen Struktur über <DocumentVariant> und < DocumentVariants> Elemente ausgegeben. Dabei werden jedoch keine Indexdaten ermittelt.

Attribut Bedeutung
is_active Wenn diese Variante die aktive Variante ist, dann 1, sonst 0.
doc_id Dokumenten ID dieser Variante
doc_ver Versionsbezeichnung
doc_parent ID der Ursprungsvariante, aus welcher diese Variante erzeugt worden ist. Zu beachten ist, dass hier auch IDs bereits gelöschter, nicht mehr im System vorhandener Dokument-IDs enthalten sein können.

Beispiel:

<DocumentVariant is_active="1" doc_id="64758" doc_ver="Original"
doc_parent="0">
<DocumentVariants level="0">
<DocumentVariant is_active="0" doc_id="73405" doc_ver="1.0.0"
doc_parent="64758">
<DocumentVariants level="1">
<DocumentVariant is_active="0" doc_id="73406" doc_ver="1.1.0"
doc_parent="73405"/>
<DocumentVariant is_active="0" doc_id="73407" doc_ver="2.0.0"
doc_parent="64758">
<DocumentVariantslevel="1" />
</DocumentVariant>
</DocumentVariants>
</DocumentVariant>

Hinweis:

Bei Recherchen nach W-Dokumenten wird immer die aktive Variante zurückgegeben.

Mehrere Anfragen in einem Anfragedokument definieren

In einem Anfragedokument lassen sich mehrere Anfragen definieren.

Beispiel:

<DMSQuery>
<Archive name="Adressen">
<ObjectType name="Adressen">
…
</ObjectType>
</Archive>
<Archive name="Patient">
<ObjectType name="
</ObjectType>
<ObjectType name="
…
</ObjectType>
<ObjectType name="Farbbilder" alias="F1">
…
</ObjectType>
</Archive>
</DMSQuery>

Um insbesondere auf Ergebnisse von Anfragen des gleichen Objekttyps gezielter zugreifen zu können, ist es möglich, das optionale Attribut 'alias' im <ObjectType> Element zu verwenden.Dieser Aliasname wird dann in den <ObjectType> Elementen des Ergebnisdokuments wiedergegeben.

Bei hierarchischen Anfragen mit Standortermittlung, wird das Attribut zusätzlich in das <ObjectType> Element des Ordners geschrieben.

Blättern durch Trefferlisten

Um Trefferlisten seitenweise abzurufen, muss man eine Anfrage mehrfach stellen und dabei dem Job über den Parameter 'PageSize' die Seitengröße und über den Parameter 'Offset' den Startpunkt für die Trefferliste mitteilen. Mit 'MaxHits' kann man die Gesamttreffermenge begrenzen.

Im Ergebnisdokument findet sich am Ende einer Trefferliste das <Statistics> Element mit den Attributen startpos, pagesize und total_hits:

<Statisticsstartpos="20" pagesize="20" total_hits="50" />

Daraus lässt sich ermitteln, wie viele Treffer die angeforderte Seite tatsächlich enthält und ob es noch weitere Treffer gibt. Der Wert des Attributs 'total_hits' kann maximal den Wert des Eingabeparameters 'MaxHits' annehmen.

Beispiel:

Aus einem Suchergebnis soll immer nur ein Ausschnitt von 20 Treffern angezeigt werden. Es sind maximal die ersten 100 Treffer von Interesse. Tatsächlich entsprechen aber 120 Objekte der Anfrage. Bei jedem Aufruf werden PageSize=20 und MaxHits=101 gesetzt. Würde man MaxHits nur auf 100 setzten, könnte man nicht erfahren, ob es über die 100 Treffer hinaus noch mehr Treffer gibt.

Seite Eingabe Ausgabe
1 Offset=0 <Statistics startpos='0' pagesize='20' total_hits='101' />
2 Offset=20 <Statistics startpos='20' pagesize='20' total_hits='101' />
3 Offset=40 <Statistics startpos='40' pagesize='20' total_hits='101' />
4 Offset=60 <Statistics startpos='60' pagesize='20' total_hits='101' />
5 Offset=80 <Statistics startpos='80' pagesize='20' total_hits='101' />

Nach dem Abruf der ersten Seite weiß der Aufrufende, dass es (101-1) / 20 = 5 Seiten gibt. Mit der 5. Seite ist startpos + pagesize = 100 und damit die gewünschte Trefferobergrenze erreicht. Da es aber 101 > 100 Treffer gibt, weiß der Aufrufende, dass es noch mehr Treffer gegeben hätte.


TOC abn adm ado cnv dms dtr krn lic med mng ocr std vtx wfm