DMSQuery XML Format
The DMSQuery format is the XML request format for search queries to the enaio® server. It describes which archives and object types to search, which fields should appear in the result and under what conditions objects should be returned.
The corresponding schema file is DMSQuery.xsd. The result of a DMSQuery request is returned in
DMSContent XML format.
1. Usage
The DMSQuery format is used as input by the following jobs:
| Job | Description |
|---|---|
Primary research job — executes the query and returns hits in DMSContent format |
|
Search in the trash — query in DMSQuery format |
|
Create stored search — stores a DMSQuery on the server |
|
Update stored search — replaces an existing DMSQuery |
|
Retrieve stored search — returns the stored DMSQuery |
|
Converts a DMSQuery to another query format (or vice versa) |
|
Execute a stored search — internally uses the stored DMSQuery |
2. Request Types (requesttype)
The requesttype attribute on the <DMSQuery> element determines the structure of the returned
DMSContent:
| Value | Name | Result |
|---|---|---|
|
Linear Object List |
Tabular hit list ( |
|
Hierarchical Object List |
Hierarchical object list ( |
|
Mixed |
HOL data for the requested object combined with LOL data for parents and children. |
|
Detail (deprecated) |
No longer use — use |
3. Quick Start — Common Query Patterns
3.1. Simple Field Search (LOL)
Search all documents of a type where a field has a specific value:
<DMSQuery requesttype="LOL" pagesize="20" offset="0">
<Archive internal_name="patient">
<ObjectType type="DOCUMENT" internal_name="medical_letter">
<Fields>
<Field internal_name="date"/>
<Field internal_name="subject"/>
<Field internal_name="physician"/>
</Fields>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="medical_letter">
<FieldCondition internal_name="physician" operator="=">
<Value>Dr. Müller</Value>
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>
3.2. Complete HOL Query with Base Parameters
<DMSQuery requesttype="HOL" baseparams="1" pagesize="10" offset="0">
<Archive internal_name="patient">
<ObjectType type="DOCUMENT" internal_name="medical_letter">
<Fields field_schema="ALL"/>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="medical_letter">
<FieldCondition internal_name="date" operator="BETWEEN">
<Value>2024-01-01</Value>
<Value>2024-12-31</Value>
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>
4. XML Structure (Overview)
<DMSQuery requesttype="LOL|HOL|MIX"
pagesize="20" offset="0" maxhits="-1"
baseparams="0" variants="0" rights="0"
combined="0" sql="0" icons="0"
disablesearchgroups="1" narrowsearch="0"
status="0" fileinfo="0" object_inserts="0"
registercontext="0" outputformat="0">
<!-- Optional parameter definitions for parametrized queries -->
<Params>
<Param name="myParam"><Value>Search term</Value></Param>
</Params>
<!-- One or more archives -->
<Archive internal_name="archive1">
<!-- Object type query -->
<ObjectType type="DOCUMENT" internal_name="invoice" alias="Invoice">
<Fields field_schema="DEF">
<Field internal_name="date" sortpos="1" sortorder="DESC"/>
<Field internal_name="amount"/>
</Fields>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="invoice">
<FieldCondition internal_name="status" operator="=">
<Value>approved</Value>
</FieldCondition>
<FieldCondition internal_name="amount" operator=">=">
<Value>1000</Value>
</FieldCondition>
</ConditionObject>
</Conditions>
<!-- HOL: Request child objects -->
<ChildObjects child_schema="DEF" export_depth="1">
<ChildObjectType type="REGISTER" internal_name="invoice_items">
<Fields field_schema="ALL"/>
</ChildObjectType>
</ChildObjects>
<!-- HOL: Request path to parent objects -->
<ParentObjects parent_schema="DEF">
<SubObjectType type="FOLDER" internal_name="company"/>
</ParentObjects>
<!-- Linked objects from another archive -->
<ExternalObjects>
<ExternalArchive internal_name="contacts">
<ExternalObjectType internal_name="contact_person">
<Fields field_schema="MIN"/>
</ExternalObjectType>
</ExternalArchive>
</ExternalObjects>
</ObjectType>
<!-- Search by base parameters (folders) -->
<FolderBaseParams>
<Creator><Value>admin</Value></Creator>
<Created><From>2024-01-01</From><To>2024-12-31</To></Created>
</FolderBaseParams>
<!-- Full-text search -->
<FulltextQuery>
<Fulltext MODE="PATTERN">
<Value>Discharge letter</Value>
</Fulltext>
</FulltextQuery>
</Archive>
</DMSQuery>
5. Elements and Attributes
5.1. <DMSQuery> (root element)
5.1.1. Result Control
| Attribute | Type | Default | Description |
|---|---|---|---|
|
|
Request type: |
|
|
xs:long |
|
Maximum number of hits per response ( |
|
xs:long |
|
0-based start index for pagination |
|
xs:long |
|
Absolute hit limit ( |
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
5.1.2. Search Behavior
| Attribute | Type | Default | Description |
|---|---|---|---|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
|
|
xs:short |
|
Status filter for objects (reserved) |
|
xs:short |
— |
Numeric output format code (supplementary to |
5.2. <Params> / <Param>
Optional parameter definitions for parametrized queries. Parameters allow storing a DMSQuery template and filling it with values at runtime (e.g. for stored searches via dms.ExecuteStoredQuery).
The name attribute on <Param> is not formally defined in the XSD, but required in practice, as <FieldCondition> refers to it via <ParamValue ref="name">.
|
The <Params> block must be placed before the first <Archive> element. If it follows
<Archive>, the server silently discards it — without an error message and without an error code.
All <ParamValue ref="…"/> conditions are dropped as a result, and the query widens to the entire
object type.
|
Each <Param> contains exactly one of the following value types:
| Child element | Meaning |
|---|---|
|
Fixed standard value |
|
Parameter is empty (NULL) |
|
Value is taken from the field with the specified |
<DMSQuery requesttype="LOL">
<Params>
<Param name="doctor"><Value>Dr. Müller</Value></Param>
<Param name="dateFrom"><Value>2024-01-01</Value></Param>
<Param name="dateTo"><Value>2024-12-31</Value></Param>
</Params>
<Archive internal_name="patient">
<ObjectType type="DOCUMENT" internal_name="medical_letter">
<Fields><Field internal_name="subject"/></Fields>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="medical_letter">
<FieldCondition internal_name="physician" operator="=">
<ParamValue ref="doctor"/>
</FieldCondition>
<FieldCondition internal_name="date" operator="BETWEEN">
<ParamValue ref="dateFrom"/>
<ParamValue ref="dateTo"/>
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>
5.3. <Archive>
Defines the archive to be searched. At least one of the attributes id, name, internal_name
or osguid must be specified. Multiple <Archive> elements are allowed (cross-archive search).
internal_name is only required for cross-archive queries (multiple <Archive> elements)
— assuming the contained <ObjectType> elements also use internal_name. For single-archive queries,
the attribute can be omitted.
|
| Attribute | Type | Default | Description |
|---|---|---|---|
|
xs:long |
|
Numeric archive ID |
|
xs:string |
— |
Display name |
|
xs:string |
— |
Internal name (recommended) |
|
xs:string |
— |
GUID |
Child elements (any combination, multiple allowed):
-
<ObjectType>— typed object search -
<FolderBaseParams>— folder search by base parameters -
<RegisterBaseParams>— register search by base parameters -
<DocumentBaseParams>— document search by base parameters -
<FulltextQuery>— full-text search
5.3.1. Several searches in one call
Several <Archive> blocks, and several <ObjectType> blocks per archive, bundle searches that
are independent of each other into a single call. The response mirrors the structure of the
request: one result list per block, each with its own <Statistics>. No combination and no
intersection takes place between the blocks.
This is something different from several
<ConditionObject> blocks inside one <ObjectType> —
those act as conditions on the same result list.
Measured against enaio® server 12.0.769.25242, one hit per block:
<!-- Two archives: the response contains two <Archive> blocks -->
<DMSQuery requesttype="HOL">
<Archive internal_name="Unittest_DMS">
<ObjectType internal_name="Unittest_DMS"> … </ObjectType>
</Archive>
<Archive internal_name="Unittest">
<ObjectType internal_name="Unittest"> … </ObjectType>
</Archive>
</DMSQuery>
<!-- Two object types in one archive: the response contains both <ObjectType> blocks -->
<DMSQuery requesttype="HOL">
<Archive internal_name="Unittest_DMS">
<ObjectType internal_name="Unittest_DMS"> … </ObjectType>
<ObjectType internal_name="Unittest_DMS_Document"> … </ObjectType>
</Archive>
</DMSQuery>
5.4. <ObjectType>
Defines the searched object type and the desired output fields and search conditions.
| Attribute | Type | Default | Description |
|---|---|---|---|
|
— |
|
|
|
xs:long |
|
Numeric ID of the object type |
|
xs:string |
— |
Display name |
|
xs:string |
— |
Internal name (recommended) |
|
xs:string |
— |
GUID |
|
xs:string |
— |
Database table name |
|
xs:string |
— |
Alias name that appears in hit list (faster access for multiple object types) |
Child elements:
| Element | Purpose |
|---|---|
|
Which fields should appear in the result |
|
Filter conditions — which objects should be returned |
|
Child objects that should be returned hierarchically |
|
Parent path (folders/register) that should be returned |
|
Linked objects from other archives |
5.5. <Fields> / <Field>
<Fields> lists the fields that should appear in the result.
Attribute on <Fields> |
Type | Default | Description |
|---|---|---|---|
|
|
Predefined selection of fields to return (overridable by individual |
The field_schema attribute on <Fields> controls which fields are defaultly included — individual <Field> elements supplement or override this selection.
Attribute on <Field> |
Type | Default | Description |
|---|---|---|---|
|
xs:string |
— |
Display name of the field |
|
xs:string |
— |
Internal name (recommended) |
|
xs:string |
— |
Database column name |
|
xs:string |
— |
GUID |
|
xs:short |
|
|
|
xs:long |
|
Sorting position in the result ( |
|
xs:string |
— |
Sorting direction: |
|
xs:string |
— |
Alias name for the field value — enables use as condition value in |
System fields for position information (only in relation tables): folder_id, register_id, register_type.
|
5.6. <Conditions> / <ConditionObject>
<Conditions> contains either a list of <ConditionObject> elements or a list
of <ObjectID> elements (direct retrieval by ID).
5.6.1. Variant 1 — Field-based Conditions (<ConditionObject>)
Each <ConditionObject> carries the same identification attributes as <ObjectType> and
contains any number of condition elements:
-
<FieldCondition>— condition on a simple field -
<FieldGroup>— logical group of conditions (AND/OR) -
<TableCondition>— condition on a table field -
<Fulltext>— full-text condition
Each <ConditionObject> applies to exactly one object type. Blocks for different object types
are connected with AND, multiple blocks for the same object type with OR.
Since <FieldGroup> always resides within a single block, an OR connection cannot span
two object types. An expression such as (document status = open) OR (folder name = archive)
cannot be expressed in a single DMSQuery and has to be split into two queries.
|
5.7. <FieldCondition>
The central condition for an index field.
| Attribute | Type | Default | Description |
|---|---|---|---|
|
xs:string |
— |
Internal field name (recommended) |
|
xs:string |
— |
Database column name |
|
xs:string |
— |
Display name |
|
xs:short |
|
|
|
|
Comparison operator |
|
|
|
Not evaluated by the server — see the warning below the table |
The bool_op attribute is not evaluated by enaio® 12.0. All conditions within a
<ConditionObject> or <SubConditions> block are connected with AND regardless of the attribute
value. An OR connection is only possible via <FieldGroup operator="OR">. The
attribute remains permitted by the schema so that existing queries continue to validate.
|
As a child element (condition value), exactly one of the following types must be specified — for
BETWEEN, IN and NOT IN, two or more <Value> elements are required:
| Child element | Meaning |
|---|---|
|
Literal comparison value |
|
Placeholder value (see Placeholders) |
|
Reference to a declared |
|
Reference to the field value of a field in the main object (for |
|
Check for NULL (no value) |
|
Internal special value |
<!-- Equality -->
<FieldCondition internal_name="status" operator="="><Value>approved</Value></FieldCondition>
<!-- Date range -->
<FieldCondition internal_name="date" operator="BETWEEN">
<Value>2024-01-01</Value>
<Value>2024-12-31</Value>
</FieldCondition>
<!-- List of values -->
<FieldCondition internal_name="category" operator="IN">
<Value>A</Value>
<Value>B</Value>
<Value>C</Value>
</FieldCondition>
<!-- NULL check -->
<FieldCondition internal_name="archived_by" operator="="><NULL/></FieldCondition>
<!-- Current logged-in user -->
<FieldCondition internal_name="owner" operator="=">
<Value special="1">#USER#</Value>
</FieldCondition>
5.7.1. Wildcards in text conditions
A comparison on a text field is a pattern match, with the = operator as well. The wildcards of
DMSQuery are:
| Character | Meaning |
|---|---|
|
Any number of characters, including none |
|
Exactly one character |
% and _ are not wildcards. The server escapes them in the value, so they are matched
literally. Anyone coming from SQL who uses % as a wildcard gets an empty result without any
message.
|
The LIKE operator behaves identically to =; the difference is made by the value, not by the
operator. Measured against enaio® server 12.0.769.25242 through the sql="1" attribute, which
returns the generated statement:
| Condition in the DMSQuery | Generated SQL |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If the value contains neither a wildcard nor a character that needs escaping, the server generates
a plain =. Apostrophes in the value are doubled correctly; escaping by the caller is neither
necessary nor correct.
5.8. <FieldGroup>
Groups multiple conditions into a logical unit. Enables nested AND/OR expressions.
| Attribute | Type | Required | Description |
|---|---|---|---|
|
Yes |
|
Child elements: <FieldCondition>, <TableCondition>, date conditions, <FieldGroup> (recursive).
<!-- (status = "open" OR status = "pending") AND amount >= 500 -->
<ConditionObject type="DOCUMENT" internal_name="invoice">
<FieldGroup operator="OR">
<FieldCondition internal_name="status" operator="="><Value>open</Value></FieldCondition>
<FieldCondition internal_name="status" operator="="><Value>pending</Value></FieldCondition>
</FieldGroup>
<FieldCondition internal_name="amount" operator=">=">
<Value>500</Value>
</FieldCondition>
</ConditionObject>
5.9. <TableCondition>
Condition for a table field (Grid control). Each <TableColumn> corresponds to a column
of the table field and carries the same attributes and child elements as <FieldCondition>.
| Attribute | Type | Default | Description |
|---|---|---|---|
|
xs:string |
— |
Identification of the table field |
|
xs:long |
|
Row number ( |
<!-- Search for invoices that contain a position with amount > 1000 -->
<TableCondition internal_name="positions">
<TableColumn internal_name="pos_amount" operator=">">
<Value>1000</Value>
</TableColumn>
</TableCondition>
5.10. <ChildObjects>
Only for HOL queries. Defines which child objects should be returned hierarchically.
| Attribute | Type | Default | Description |
|---|---|---|---|
|
|
|
|
|
xs:short |
|
Depth of hierarchy ( |
|
— |
Standard field selection for all children |
Child elements: <ChildObjectType> (one element per requested child type) or <SubObjectType>.
<ChildObjectType> carries the same identification attributes as <ObjectType> plus:
- alias — alias name for the hit list
- <Fields> — desired fields
- <SubConditions> — additional filter conditions for child objects (HOL only, see <SubConditions>)
- <ExternalObjects> — linked foreign archive objects of children
The schema as shipped by the manufacturer declares <Fields> in <ChildObjectType> and
<SubObjectType> as well as <ExternalObjects> in <ChildObjectType> and <ParentObjectType> as
mandatory elements. The server answers queries even when they are missing: without <Fields>, the
field_schema of the enclosing element applies. In the corrected schema both elements are optional
(see Deviations Between Schema and Server Behaviour).
|
5.11. <ParentObjects>
Only for HOL queries. Returns the path to parent objects (folders, registers).
| Attribute | Type | Default | Description |
|---|---|---|---|
|
|
Which parent types should be returned |
|
|
— |
Standard field selection for parent objects |
Child elements:
- <ParentObjectType>+ — explicit parent types
- <SubObjectType> — the target object in the path
5.11.1. Structure of the response
The response contains no <ParentObjects> element. The server inverts the hierarchy
and returns an ordinary top-down tree: the topmost parent object is the <Object> at the root,
every further level hangs in its
<ChildObjects>. The requested object sits at the
bottom. A consumer must therefore not look for <ParentObjects> but walk the <ChildObjects>
tree down to the leaf.
|
Measured against enaio® server 12.0.769.25242 with a query on a document across folder, register and subregister:
<ObjectType internal_name="Folder" type="FOLDER">
<ObjectList><Object id="145151"> <!-- folder: topmost parent object -->
<ChildObjects>
<ObjectType internal_name="Register" type="REGISTER">
<ObjectList><Object id="145153">
<ChildObjects>
<ObjectType internal_name="Subregister" type="REGISTER">
<ObjectList><Object id="145155">
<ChildObjects>
<ObjectType internal_name="Document" type="DOCUMENT">
<ObjectList><Object id="145156"/></ObjectList> <!-- the requested object -->
</ObjectType>
</ChildObjects>
</Object></ObjectList>
</ObjectType>
</ChildObjects>
</Object></ObjectList>
</ObjectType>
</ChildObjects>
</Object></ObjectList>
</ObjectType>
5.12. <ExternalObjects>
Linked objects from other archives — enables cross-archive joins.
Each <ExternalArchive> identifies a foreign archive (via archive_ident attributes)
and optionally contains an <ExternalObjectType> element that defines the foreign object type
and its fields/conditions.
Field values of the main object can be used as condition values:
-
In the main object, set the
<Field>element withlink_name="myAlias". -
In the
<ExternalObjectType>, formulate the condition with<LinkedValue ref="myAlias"/>.
<ObjectType type="DOCUMENT" internal_name="invoice">
<Fields>
<Field internal_name="customer_id" link_name="cust_ref"/>
</Fields>
<ExternalObjects>
<ExternalArchive internal_name="contacts">
<ExternalObjectType internal_name="company">
<Fields>
<Field internal_name="company_name"/>
</Fields>
<SubConditions>
<FieldCondition internal_name="id" operator="=">
<LinkedValue ref="cust_ref"/>
</FieldCondition>
</SubConditions>
</ExternalObjectType>
</ExternalArchive>
</ExternalObjects>
</ObjectType>
ref points at the alias assigned with link_name, not at the internal name, the
display name or the database name of the field. If step 1 is missing, or the alias does not
match, the reference cannot be resolved — and the server does not report this but returns an
empty external archive block with total_hits="0" and an empty <Messages>. Both steps therefore
have to be set together.
|
Measured against enaio® server 12.0.769.25242: with link_name and a matching ref the query
returns the expected external object, and with an alias that was never assigned it silently
returns nothing. link_name works on index fields of any type as well as on system fields
(measured on OBJECT_ID). The value is resolved per hit of the main object — the external
archive condition is therefore evaluated separately for every object of the main result list.
The structure of the response is described at
<ExternalObjects> in the DMSContent
format.
5.13. <SubConditions>
Additional filter conditions for child, parent and foreign archive objects. Usable in
<ChildObjectType>, <SubObjectType> and <ExternalObjectType>; for child objects in HOL queries
only.
Permitted child elements:
-
<FieldCondition>— condition on a simple field -
<FieldGroup>— logical group of conditions (AND/OR), nesting allowed -
<TableCondition>— condition on a table field -
<Expression>— expression
<FieldGroup> is not listed in the content model of <SubConditions> in the schema as
shipped by the manufacturer; the corrected version adds it. The server accepts and evaluates the
element there, including nesting. Since bool_op is not evaluated, <FieldGroup> is the only way to connect conditions for
child objects with OR. Unknown elements are rejected at this position with -1029 — so
<FieldGroup> really is evaluated and not merely tolerated.
|
<!-- returns the registers named "A" or "B" -->
<ChildObjectType type="REGISTER" internal_name="invoice_register">
<Fields field_schema="DEF">
<Field internal_name="name"/>
</Fields>
<SubConditions>
<FieldGroup operator="OR">
<FieldCondition internal_name="name" operator="="><Value>A</Value></FieldCondition>
<FieldCondition internal_name="name" operator="="><Value>B</Value></FieldCondition>
</FieldGroup>
</SubConditions>
</ChildObjectType>
5.14. Base Parameter Search
Search by base parameters (metadata) allows filtering without knowing the index fields.
5.14.1. <FolderBaseParams> / <RegisterBaseParams>
Search for folders or registers by metadata. Contains the child elements:
| Element | Description |
|---|---|
|
Created by (up to 2 values; implicitly OR-connected) |
|
Creation date range |
|
Last modified by |
|
Modification date range |
|
Owner (always OR-connected) |
|
Request child objects of found parent objects (HOL) |
5.14.2. <DocumentBaseParams>
Like <FolderBaseParams>, additionally:
| Element | Description |
|---|---|
|
Filter by archiving status (one or more values; implicitly OR) |
|
Filter by checkout status |
5.15. <FulltextQuery>
Full-text search over all documents of the archive.
<FulltextQuery>
<Fulltext MODE="PATTERN">
<Value>discharge* AND Müller</Value>
</Fulltext>
</FulltextQuery>
Optional control attributes (for the RetrievalWare full-text engine):
| Attribute | Type | Default | Description |
|---|---|---|---|
|
|
Search mode |
|
|
xs:short |
|
Expansion level for synonyms |
|
xs:boolean |
|
Fuzzy search for half words |
|
xs:short |
|
Threshold for fuzzy spell correction |
|
xs:short |
|
Maximum fuzzy alternatives |
|
xs:short |
|
Maximum regex expansions |
|
xs:short |
|
Limit for word expansions |
6. Enumeration Types
6.1. requesttypes
| Value | Result Format | Description |
|---|---|---|
|
DMSContent |
Linear Object List — tabular format |
|
DMSContent |
Hierarchical Object List — complete object data |
|
DMSContent |
Mixed — HOL data + optional LOL data for parents/children |
|
— |
Deprecated — use |
6.2. field_schema
| Value | Description |
|---|---|
|
Standard fields according to object type configuration |
|
All fields of the object type |
|
All fields including relational (linked) fields |
|
Minimal field set (only ID and required fields) |
|
The server does not validate the enumeration. An unknown or empty value leads neither to an
error nor to the documented default
A typo in the attribute therefore goes unnoticed: the query becomes more expensive and returns more fields than intended, without any indication. Callers should validate the value themselves before sending. |
6.3. object_schema
| Value | Description |
|---|---|
|
Only explicitly listed types |
|
All object types of the archive |
|
Only register types |
|
Only document types |
6.5. ComparisonOperators
| Operator | Meaning |
|---|---|
|
Equal |
|
Not equal |
|
Less than |
|
Less than or equal |
|
Greater than |
|
Greater than or equal |
|
Value is in a list — specify multiple |
|
Value is not in a list |
|
Value lies between two limits — specify exactly two |
|
Value does not lie between two limits |
|
Equal — equivalent to |
|
Not equal — equivalent to |
|
Not less than — equivalent to |
|
Not greater than — equivalent to |
|
Pattern comparison with wildcards — behaves identically to |
The operators ==, !==, !<, !> and LIKE are missing from the schema as shipped by
the manufacturer but are supported by the server — it names them in the error message for error code
-1033; their meaning follows the SQL convention. The server compares operator names
case-insensitively (between behaves like BETWEEN).
|
6.7. FullTextSearchModeType
| Value | Meaning |
|---|---|
|
Pattern recognition with wildcards ( |
|
Boolean expressions ( |
|
Conceptual search (semantic similarity) |
6.8. Placeholders (special="1")
Special values are used in <Value special="1"> and resolved by the server at runtime:
| Placeholder | Resolved Value |
|---|---|
|
Login name of the current user |
|
Owner of the current user |
|
Current date |
|
Creator (login name) |
|
Creation date |
|
Archivist (login name) |
|
Archiving date |
|
Client computer name |
|
Client IP address |
|
Client GUID |
7. Complete Examples
7.1. Multi-level Search with FieldGroup (OR/AND Combination)
Search for documents that are (open OR pending) AND amount ≥ 500:
<DMSQuery requesttype="LOL" pagesize="50" offset="0" baseparams="0">
<Archive internal_name="accounting">
<ObjectType type="DOCUMENT" internal_name="invoice">
<Fields>
<Field internal_name="invoice_number" sortpos="1" sortorder="DESC"/>
<Field internal_name="date"/>
<Field internal_name="status"/>
<Field internal_name="amount"/>
</Fields>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="invoice">
<FieldGroup operator="OR">
<FieldCondition internal_name="status" operator="=">
<Value>open</Value>
</FieldCondition>
<FieldCondition internal_name="status" operator="=">
<Value>pending</Value>
</FieldCondition>
</FieldGroup>
<FieldCondition internal_name="amount" operator=">=">
<Value>500</Value>
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>
7.2. HOL Query with BaseParams and Rights
All documents of the current user from 2024, with base parameters and rights:
<DMSQuery requesttype="HOL" baseparams="1" rights="1" pagesize="20" offset="0">
<Archive internal_name="patient">
<ObjectType type="DOCUMENT" internal_name="medical_letter">
<Fields field_schema="ALL"/>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="medical_letter">
<FieldCondition internal_name="date" operator="BETWEEN">
<Value>2024-01-01</Value>
<Value>2024-12-31</Value>
</FieldCondition>
</ConditionObject>
</Conditions>
</ObjectType>
<DocumentBaseParams>
<Owner operator="=">
<Value special="1">#USER#</Value>
</Owner>
<ArchiveState>
<ArchiveStateValue>ARCHIVED</ArchiveStateValue>
<ArchiveStateValue>ARCHIVABLE</ArchiveStateValue>
</ArchiveState>
</DocumentBaseParams>
</Archive>
</DMSQuery>
7.3. Search by Table Field
Invoices with a position over 1000 €, sorted by invoice number:
<DMSQuery requesttype="LOL" pagesize="20" offset="0">
<Archive internal_name="accounting">
<ObjectType type="DOCUMENT" internal_name="invoice">
<Fields>
<Field internal_name="invoice_number" sortpos="1" sortorder="ASC"/>
<Field internal_name="date"/>
</Fields>
<Conditions>
<ConditionObject type="DOCUMENT" internal_name="invoice">
<TableCondition internal_name="positions">
<TableColumn internal_name="pos_amount" operator=">">
<Value>1000</Value>
</TableColumn>
</TableCondition>
</ConditionObject>
</Conditions>
</ObjectType>
</Archive>
</DMSQuery>
7.4. Full-text Search with Child Objects (HOL)
Full-text search in the archive and hierarchical return with sub-registers:
<DMSQuery requesttype="HOL" baseparams="0" pagesize="10" offset="0">
<Archive internal_name="patient">
<FulltextQuery>
<ChildObjects child_schema="DEF">
<ChildObjectType type="DOCUMENT" internal_name="medical_letter">
<Fields field_schema="DEF"/>
</ChildObjectType>
</ChildObjects>
<Fulltext MODE="PATTERN">
<Value>discharge letter*</Value>
</Fulltext>
</FulltextQuery>
</Archive>
</DMSQuery>
8. Deviations Between Schema and Server Behaviour
At the following points, the DMSQuery.xsd as shipped by the manufacturer describes something
other than what the server actually requires or evaluates. Measured against enaio® server
12.0.769.25242. The schema version maintained with this documentation is corrected at every point
listed (see Corrected Schema Files).
| Location | Shipped schema | Server behaviour (measured) |
|---|---|---|
|
Connection with the previous condition ( |
Not evaluated; within a block, AND always applies. OR only via |
|
Not part of the content model |
Accepted and evaluated, including nesting — the only way to connect child object conditions with OR |
Position of |
Before the first |
A wrong position produces no error but silently drops all parameter conditions |
|
Not declared |
Required — |
|
Mandatory element |
Optional; without it, the |
|
Mandatory element |
Optional |
Eleven operators |
Additionally |
|
|
Not declared |
Accepted and evaluated; the server then returns a |
Response to |
— |
Contains no |
Unresolvable |
— |
No error, but an empty external archive block with |
|
Applies to LOL only |
Applies to HOL as well — the |
|
Equality comparison |
Pattern match with |