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:
- 0x00000010 = XML Ergebnis wird als Datei zurückgegeben, sonst als Buffer
ACHTUNG UNICODE: Es sollte nur noch 'LOL' oder 'HOL'Format geliefert werden. Sollte das Output Format 'TXT' sein und das Ergebnis als Datei geliefert werden, so ist dies nur noch in Kombination mit den Parametern 'OutputUnicode=1' und 'Encoding=UTF-8/UTF-16' möglich. Diese Kombination funktioniert dann ebenfalls in ANSI Systemen, kann also clientseitig sowohl zur Ansteuerung von Unicode- als auch ANSI-Systemen verwendet werden.
Für typübergreifende Verweisdokumente wird bei LOL-Anfragetypen weder 'mimetyp' noch 'size' zurückgegeben.
Rückgabe: 0 = Job erfolgreich, ansonsten Fehlercode
Rückgabewerte:
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.
Bei Suchanfragen wird prinzipiell zwischen linearen und hierarchischen Anfragen unterschieden. Einen Sonderfall stellen die Detailanfragen dar.
Ü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 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.
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.
Das 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 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.
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.
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>
<!—Dokumenttyp ‘Arztbrief' -->
<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>
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>
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" />
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>
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 |
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.
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:
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>
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>
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.
Ü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>
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
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=">">
<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:
Operator | XML konformes Format |
---|---|
< | < |
<= | <= |
= | = |
!= | != |
> | > |
>= | >= |
BETWEEN | BETWEEN |
NOT BETWEEN | NOT BETWEEN |
IN | IN |
NOT IN | NOT IN |
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.
Zur Prüfung eines Werte auf NULL steht das <NULL/> Element zur Verfügung, dass anstelle des <Value> Elementes verwendet werden muss.
Ü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 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.
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:
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.
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>
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.
Über das <Fulltext> Element kann eine Volltextanfrage durchgeführt werden. Volltextklauseln können als Text des Elementes <Fulltext> geschrieben werden.
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.
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'.
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.
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.
Ü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.
Die Auswahl der Kindobjekte lässt sich über zusätzliche Bedingungen weiter einschränken.
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.
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) |
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.
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.
Ü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>
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.
Werden 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>
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>
Durch Setzen des Attributs 'status' auf '1' im <DMSQuery> Element werden zu jedem Objekt folgende Statusinformationen ermittelt:
Und speziell für Dokumente:
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" />
Ü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>
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>
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>
Ü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.
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.
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.
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.
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.