Joe Kaufman Bell Laboratories Inc No longer there

Hameed,

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!

Thanks,

Joe Kaufman

Fabrice,

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.

Thanks,

Joe Kaufman

Don't you use LogCollector to collect errors on the Desktop, found at:

C:\Program Files (x86)\DocuWare\Desktop\LogCollector

?

Thanks,

Joe Kaufman

Hey all,

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?

Thanks,
Joe Kaufman

Phil,

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.

Thanks,
Joe Kaufman

Phil,

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.

Thanks,

Joe Kaufman

Jason,

Nifty solution. I will be eager to see what support says about that sort of behind-the-scenes manipulation, and obviously such code may break between versions.

I imagine DocuWare let the issue fall off the back burner when they changed to named licenses. Perhaps the main focus was on concurrency, not on basic workstation security. That's a shame, because I don't see the downside to offering an auto-logout capability. It doesn't seem like DocuWare would have to compromise on anything to keep that functionality available, even if it were off by default (or even hidden in a config file).

Thanks,

Joe Kaufman

Phil,

Thanks! Yes, we are definitely set to 10 minutes in that config file.

Thanks,

Joe Kaufman

Oh, and 10 minutes is exactly my experience. The extra two minutes is a built-in grace period for connection instances. Even if you issue an explicit "LogOff" while using the SDK, for example, the license expiration does not occur for an additional 120 seconds. Though, that may be the IIS 120 second time-out in play -- not sure.

Thanks,

Joe Kaufman

Phil,

Thanks for this truly definitive answer! What is the config file, by chance? I am not thinking I would ever need to change that setting, but it would be nice to know.

I also assume IIS needs to be bounced after changing the setting? I might play around with it just to confirm things act the way I think they should.

Sorry to hear 6.12 is out of luck -- I fear we may need to stay "left behind" even longer after hearing the timeouts don't work in 6.12 the way they do in 6.11. I share the lament of womdering why this was changed. Control over timeouts seems like a reasonable control to have, at least for on-premise work.

Thanks,

Joe Kaufman