I believe you can just add a wildcard character, the asterisk ("*"). I just did a query on an exact literal and got nothing, but then added a wildcard asterisk to the end of the search string and it got all the records starting with that text in that index field.
I believe the rules are the same as those for URL Integration queries. From the comments of some of my Foxpro code, here are examples:
REMEMBER! Field names in queries are case sensitive! Field names (in the database) are usually ALL CAPS.
The actual database field name of a field can be viewed in the DocuWare Administration desktop application.
Queries place field name in square brackets and the value on double-quotes. Though, for numeric fields,
the quotes appear to be optional. operators can have whitespace around them. Here are example query expressions:
[DWDOCID]=123 && This will query by the internal DocuWare document ID.
[CUST_NO] = "WA60" && This will query the field "CUST_NO", trying to exactly match "WA60".
[LASTNAME] LIKE "K*" && Wildcard search (note use of "*" instead of "%" for wildcard character).
[SHIPTO_STATE] = EMPTY() && Queries SHIPTO_STATE for empty values ("EMPTY()" must be uppercase).
[BILLTO_STATE] = NOTEMPTY() && Queries BILLTO_STATE for non-empty values ("NONEMPTY()" must be uppercase).
[DocuWareFulltext] = "find this string" && Full-text search.
[DWSTOREDATETIME] > 2017-06-14 19:45:31 && Date/time expression *** CONVERT TO UTC ***
[START_DATE] >= 2016-06-01 AND [START_DATE] <= 2016-08-01 && Boolean conditional, checking date field over a date range, inclusively.
Expressions can be joined by AND or OR and can be qualified with NOT. Delmiters around string values MUST be double-quotes.
Also, the conditional statements and compound keywords (e.g. LIKE, AND, OR, etc.) need to be capitalized as well.
If multiple documents are found, a result list is displayed in the browser. If only one document matches
the search, it is directly displayed.
*** SPECIAL NOTE WHEN USING DATE/TIME FIELDS *** Date/time fields are stored in DocuWare as UTC timestamps.
While queries in the web client or Platform SDK allow the use of local date/time formats, URL Integration queries
appear to use the date/times passed in as-is and compare against the stored UTC timestamps. So, if you are using
date/time fields in your query, the date/time values need to be convertwed to UTC to get accurate results.
When doing queries with the Platform SDK you don't need the square bracket syntax, of course. I verified that EMPTY() and NOTEMPTY() work as well, just remember to include the parentheses in the search value.
Also, I believe you can only choose AND or OR as the operator for all terms in your search -- they cannot be a mix of ANDs and ORs, and there are no parenthetical ways of forming more complex search terms. Though, the Platform SDK supports ranges more elegantly, so the limitation of not mixing ANDs and ORs is generally not an issue (or at least hasn't been for us in this regard).