Kaufman Joe Bell Laboratories Inc No longer there

Craig, good info! I thought it only showed # of documents if full-text was turned on for the cabinet, but it shows for any cabinet (and I confirmed this still works in 6.11).

The SQL query will only work on-premise, correct? Or is there another spot to do free-text SQL querying on the data (that exists in the cloud version)?

Thanks,
Joe Kaufman

Florian,

Thank you for the definitive response!

Thanks,
Joe Kaufman

Ronald,

By "archive" I assume you mean file cabinet? 

I am not seeing a way to get the number back from any tool or even the Platform SDK. Everything is paged and asynchronous, topping out at whatever limit is set for searches.

However, if you are on-premise then you can access the database directly to get the number of documents in a cabinet. Are you on-premise? And what version of DW?

Finally, if you have access to the server data storage area, you can simply check the properties of the folder containing the documents for the cabinet. Of course, that would require an on-premise situation as well.

It would be great to have a way to know the total number when a system is in the cloud...

Thanks,
Joe Kaufman

Florian,

Thanks for the input! While we have you here, can you address the original issue? I appreciate the documentation link, but the documentation is actually part of the problem in this case. Here, the "q" parameter is not mentioned or used:

https://developer.docuware.com/dotNet_CodeExamples/f9a6a984-57a9-42e9-8d26-1dd35611cf47.html?q=GetFromDocumentsForDocumentsQueryResultAsync

But this still lists "q" as a valid parameter (though it is part of an extension method):

https://developer.docuware.com/dotNet_API_Reference/PlatformServerClient/DocuWare.Platform.ServerClient.SchemaExtensions.html#DocuWare_Platform_ServerClient_SchemaExtensions_GetFromDocumentsForDocumentsQueryResultAsync_DocuWare_Platform_ServerClient_ServiceConnection_System_String_System_String_System_String___System_String___System_Nullable_System_Int32__System_Nullable_System_Int32__System_Nullable_System_Int32__System_String_System_Nullable_System_Boolean__

So, is "q" supposed to work, or not? Can you shed any light on the internal server error, "The given key was not present in the dictionary" that we both see when we try to query directly from the file cabinet? If it is broken, any plan on fixing it? It is frustrating when documentation says something should be doable but then it doesn't work.

The "Get Documents" portion of the Postman collection is not helpful either, as it only utilizes count, fields, and going after a document by specific ID in the examples. Querying for a document (directly from the file cabinet) via the "q" parameter is not illustrated. Only searching via a dialog is exemplified further down in the collection. (EDIT: Trying to use the "q" parameter in the Postman samples for directly accessing documents from the cabinet fails with the same error no matter what query expression is passed in...)

Can we get a definitive answer on the "q" parameter as used in GetFromDocumentsForDocumentsQueryResultAsync()?

Thanks,
Joe Kaufman

We amateurs can get a lot done if we stick together.  *smile*

On a thread long ago (trying to get the DW Platform SDK working from Visual Foxpro) I got to the point of saying I would just fill out a support ticket. Problem is, DocuWare will not give in-depth support on the Platform SDK unless you specifically license that level of support. I think it was a reasonable figure if you are doing a lot of implementing (like $1000-$1500/year), but that didn't make sense for us since we are just one installation (I am not a consultant or reseller, just a guy working for a company that had to switch migrate from Fortis to DocuWare).

When I was told I wouldn't get any help without ponying up what would have been about a 20-25% license increase for us, that's when I started using Fiddler and Postman to figure out what was going on (mainly with authentication). I also use a lot of integration with a C# wrapper program I wrote where a bunch of common functions are exposed via command line.

DocuWare may have changed their licensing scheme since them, so you could always try to ask these questions via an "official" support ticket to see what they would say (then post here, please!). In my experience, there are quite a few commercial tools out there with a powerful API obfuscated by marginal documentation and developer support that costs extra... But you can still give it a try!

Thanks,
Joe Kaufman

Aurelien,

I think if the query did work directly against the cabinet, it would just use an encoded "q" expression, not POST data. The problem is, it just doesn't work. I tried searching for a past thread about the error I got with GetFromDocumentsForDocumentsQueryResultAsync() when trying to use the "query" parameter, but I cannot find it anywhere (it was on the old forums). It looks like they still have not gotten it to work.

I went ahead and tried a query again to recall what the error was (on 6.11 on-premise) It is:
 

500 Internal Server Error (The given key was not present in the dictionary.)

It doesn't matter what I try for the query parameter -- if it is a non-empty string I get the above error, valid expression or not.

The count parameter does work, though, to limit the number of records returned. So, if you just want all or some the files in a file cabinet, it is the method to use so that you don't need to mess with a dialog GUID.

Thanks,
Joe Kaufman


 

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

 

Seth and Josef,

Thank you! Seth, yes, I have that Merge code working, though not in FoxPro. I may have to write some of these routines in C# instead. I guess I can go ahead and just upload all documents to their final destination, settling on the first one as the "main" document. Then Merge them together once they are all up there. At this point I don't really see why I was so dead set against it, especially if the starting document retains its ID (the documentation says a new document is created, but that must not really be the case, except that of course the document is different once it has stuff clipped to it...

Thanks,
Joe Kaufman

Seth,

Yes. I want to upload a "start" document to a file cabinet, then clip additional documents to the back of that one (they are volumes of a study).

How are you clipping documents to the back of another via the API? The "Merge" operation? Are you clipping documents from one file cabinet to a document in a different file cabinet? Or do you upload the CSV to the same cabinet then merge them?

That is interesting, what you say about the document ID changing if you clip to the front. In my tests, I can clip to the front of back (when using the web client) and the starting document retains its ID no matter what I do. Now, if I split out the separate clipped parts then all documents get a new ID, obviously.

If you have sample code of what you are doing, that would be great. I wanted to avoid having to fully upload the additional files to the cabinet (with indexes) just to clip them and have the indexes not mean anything. That is why I wanted to clip documents in a document tray (no indexing required) to a document stored in a file cabinet. Since the web client can do it, I assumed there must be a cleaner way to do it via the Platform SDK API. If I do end up just needing to upload everything fully into a file cabinet (with indexes) and then merge them there it wouldn't be the end of the world, I don;t suppose.

Thanks,
JoeK

Hey all,

Since I got no response on the other forum, I figured I'd ask a single question more explicitly here.

All of this is on DocuWare 6.11, on-premise.

When using the web client, you can clip documents to an existing document by right-clicking on the document and selecting the "Clip" option (as depicted in the first attached image).

After selecting that option, the Clipping operation is made available via a two-pane screen with the starting document on the top and places to pull in other documents (to clip) on the bottom (e.g. a Document Tray). The second attached image depicts this interface.

So far, so good. You can drag documents to clip in front or behind the starting document, then click the yellow "Clip" button to clip everything together in the order you have assembled. It's really quite nice. The starting document retains all of its indexes, and the clipped document is tacked on back (or front). In my testing, it doesn't even change the Document ID of the starting document. Plus, you can ask to preserve clipped documents in their source tray instead of deleting them.

My question is this: How do I perform this operation via the Platform SDK (API?) Is it possible, or is this functionality only provided via the web client for some reason? Various "Merge" and "Transfer" functions exist in the Platform SDK, but merging involves a single file cabinet GUID. There is no way a function call involving one GUID can take documents from one place and clip them to a document in another place. Transfer functions allow that sort of thing but there is no clip functionality built into that. Additionally, the merge functions are clear to state a new document is created (new ID) and that the documents involved in the merge are deleted from the system. What the web client does is apparently a mix of transferring and merging all in one, and it doesn't change the starting document's ID. It even offers the ability to preserve the documents being clipped.

Can I do this in the Platform SDK API, and if so, what are the functions I should be looking for?

If I can't do it via the Platform SDK, is my only route to place all documents into a document tray, clip them together in the tray, then store the merged document to a file cabinet? I think I can do that now that I have figured out how to upload to a tray via the API, it just seems far less elegant than what the web client offers natively.

Thanks,
Joe Kaufman