Aurelien,
If the "q" is like the "q" parameter for URL integration, here is what I have in my comments about how to form the query parameter:
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. Delimiters 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.
*** 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 converted to UTC
to get accurate results.
Additionally, the query parameter needs to be URL encoded, doing whatever something like
System.Web.HttpServerUtility.UrlTokenEncode() does in .NET. Not sure how I figured that out, but that's what the code (that works) says.
When it comes to the call itself, I don't use the resource you list. In fact, I think I tried it in version 6.11 and it didn't work. All I could do with that resource was to return ALL documents from the file cabinet. If I tried to add a query parameter, the call threw a strange error (in .NET).
So, I use the following resource, and it works from Visual FoxPro:
/DocuWare/Platform/FileCabinets/{cab GUID}/Query/DialogExpression?dialogId={dialog GUID}&count=2100000000
This works through a dialog, so it is a bit more of a pain to use since you have to know the GUID of the file cabinet
and the search dialog.
Where is the query, you might ask? When using the above resource, you do it as a POST, not a GET, and the query is in the POST data. Here is an example of POSTed XML:
<?xml version="1.0" encoding="utf-8"?>
<DialogExpression xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Operation="And" xmlns="http://dev.docuware.com/schema/public/services/platform">
<Condition DBName="COMPANY">
<Value>bell</Value>
</Condition>
</DialogExpression>
You basically just construct XML with field names and values, and the values can be wildcards or system keywords like EMPTY() and NOTEMPTY(). POST this content to the resource and you get back an XML result with all the found document records. You'll have to parse that out however you see fit into whatever result you need.
Lots of trial and error on this stuff. One way to learn about what is going on under the hood is to do operations in C#/.NET using the libraries that make such operations easier to construct (syntactically). Then, if you watch network traffic with something like Fiddler you can see what the raw HTTP calls look like (I can, anyway, as our server is HTTP, not HTTPS -- not sure what happens with HTTPS). IIRC, posted data in those calls is usually JSON instead of XML, which you can totally use if you are more comfortable with JSON. I've had better luck posting XML for some reason.
Again, this is all on 6.11, an on-premise installation.
Hope this helps!
Thanks,
Joe Kaufman
