No, should I need that? I am using Windows integration, and I get logged in fine.
If I run the integration in Result List mode, I get all documents according to the query. "Display first one" is not turned on.
If I run the integration as the Viewer, the first matching document (only) is displayed in the viewer.
If I run the integration in Download mode, the first found document for the search is downloaded.
There is no scenario I can generate where multiple documents download as a ZIP file, and I am receiving no authentication or query errors. I am on 6.11. What version of DocuWare is working correctly for you?
EDIT: I thought versioning might have something to do with it, but I have now tried this on versioned and non-versioned cabinets -- still cannot get multiple files to download as a ZIP file in DocuWare 6.11 (on-premise).
The result list is not set to display first, though I did make the error go away by making the "Source" a result list instead of a File Cabinet.
But it is still only downloading the first document it finds that meets the criteria.
I assume a "Download Type" of "Download" is appropriate ("Plugin" is also an option)? I cannot get the Download integration type working for multiple files no matter what I try.
But, as I said, going with the reult list gets rid of the File Cabinet direct query error, so thanks for that!
I am afraid it is not working for me. :\ I get query errors and the result is a single. downloaded file that is the first to meet the criteria.
Can you provide a screenshot of your query, one that will download multiple documents at once? I am on 6.11, so maybe that is the problem...
Is that effective for hundreds of documents? Or can you do multiple documents that way? In other words, can you do a very wide query and have it download hundreds of docs at once? Smart enough to put them in a zip file? That is a cool trick, and a great use of URL integration!
EDIT: I keep getting errors on my query, even something that should return everything like:
Though, it does still download the first document in the search results. How are you able to download multiple documents at once using this methodology? How can you force multiple documents into a ZIP file the way the web client would download them?
Are you saying you want to overcome the 100-document-view limit so you can select more documetns at once and download as a ZIP file?
If so, you can use Folders to help with this. If you set up a folder into a file cabinet (make the criteria something that grabs the documents you want), a folder will display everything it matches to (up to 10,000 documents). Then you can highlight all the documents you want and pull them all down at once. Not sure how great performance is going to be downloading more than 100 documents at a time, but a Folder view allows you to see more documents at once.
The other option would be to use the Platform SDK and download documents via a separate integration.
Hope this helps!
If you search the support form for "xmlhttp" and "serverxmlhttp" you will see some examples of accessing the API via Visual Foxpro, and others have asked about toolkits like node.js. The full list of entry points (URL resources) to consume via the API can be found here:
http://<your DW server>/DocuWare/Platform/Home/UriTemplatesDocumentation
(online DW documentation appears to not be loading this morning. Grrrr.)
At some point I wish DocuWare would post more generic examples (such as curl), or a Postman package with examples. As far as I know, though, no such pieces of documentation exist at this time. You just need to become familiar with how pythom does GETs and PUTs and POSTs and you should be off to the races.
Don't you use LogCollector to collect errors on the Desktop, found at:
C:\Program Files (x86)\DocuWare\Desktop\LogCollector
I wanted to clarify licensing and session timeouts with regard to various versions of DocuWare in order to understand how stuck I am with our current version (6.11).
Background: We have 20 concurrent license, and so far that has been plenty -- we rarely are using more than 10 at any given time). This is because in 6.11, sessions timeout after roughly 12 minutes of idle time, whether those sessions are in a web clint or Platform SDK service connections. The timeouts are also useful because forcing a logoff (Platform SDK scenario) does not actually kill the connection immediately. The connection remains for an additional two minutes, and everything I have heard from DocuWare support indicates this cannot be changed.
Correct me where I am wrong about the additional points I am about to make:
If we move to 6.12, it looks like connections will no longer automatically timeout. Any scan station or occasional user who checks DocuWare in the morning and leaves their browser up all day will be burning a license all day. We'll be out of licenses by noon, most days. From what I have read, there is also no way of forcing a logoff in 6.12 via an administrative tool, so ven if we can see who is logged on, there is no way to kill that license use without contacting the user and telling them to log off.
Any Platform SDK connection will also burn a license, I assume, unless a logoff is issued. This is problematic. I do not currently log-off a Platform SDK connection after each operation because then I cannot make modular code. That is, if I connect, perform an operation (say, indexing a document), and logoff, I will burn though all 20 license in a matter of seconds if I do any sort of batch process that performs the operation many times. This is because of that two-minute "grace period" on disconnections. If I do more than 20 operations in 120 seconds (which is obviously very possible), all licenses are used up.
That's why I create a global service connection instance and then let it timeout when it goes idle, and that scheme has been working fine for over a year now. NOTE: On .NET this is not as much of an issue because a .NET application appears to know how to use an existing ServiceConnection instance and not burn through a license every time, even with disconnects in between. At least, that is how I recall it working before. But we are not using .NET for the bulk of our Platform SDK connections -- we just use an XMLHTTP object, automated via Visual Foxpro. In 6.12, these connections would burn a license every time they are initiated, and they would not logoff until 120 seconds after an explicit LogOff resource is accessed.
I am thinking I am between a rock and a hard place. If I move to 6.12 we will be forced to get more licenses, and those will be named. Either that or I will need to figure out a way to disconnect Platform SDK connections and still allow for modular, batch programming, something I cannot see how to do right now. Or, we just stay on 6.11 where everything works the way we want, but we eventually fall off of DocuWare support for being too old.
Am I missing something here, or is my assessment basically correct? Anyone else out there dealing with these sorts of dilemmas?
I apologize for the way my tone came off -- I didn't mean to sound bullying; and by "you" I mean DocuWare, not you personally.
In my opinion, when a customer demands something, that resides on the spectrum of "desperate times". It is not DocuWare's call -- it is the customers'. I'll put it this way: where I work, if a customer asks for something, we do it unless we have a very good reason not to that we can help the customer understand. Otherwise, the customer goes somewhere else. It would probably be worse if we said we listened to the customer's voice, hundreds of customers told us what they needed, and we ignored it. You ask which is more important, data or a timeout -- I feel you are missing the point. Over 200 customers are wondering why data integrity and session timeouts need to be mutually exclusive.
I am not sure who the Product Owner is on this thread. Tobias? There is nothing to indicate his status if that is the case, so I honestly didn't know we were hearing from a "Product Owner" (I always thought Tobias was a support person like yourself). Not sure it matters, though, since his responses stopped coming even after people continued to explain their business-case need.
I agree that a comprehensive workstation lockdown SOP would be better for end-users overall, and named licenses cover concurrency issues, but that doesn't change the fact that the customer is always right. That is, unless DocuWare can more clearly explain the downside of keeping the timeout solution in play -- something no one (not even a Product Owner) has done yet.
It would seem desperate times call for desperate measures, though. What else is one supposed to do if a customer requirement states that all connections to various resources (such as DocuWare) need to have timeouts built in for security? I don't think it is DocuWare's place to dictate what clients want to do in that regard. And at over 200 votes, the "user voice" is definitely saying this needs to be addressed, even with named licensing now being the case.
Judging by Jason's posts here, I have no doubt he wouldn't be so "cavalier" unless there was no other option. Unless you prefer the final option to be to dump DocuWare for a tool that supports this client need -- that's always an alternative, I suppose.