Joe Kaufman Bell Laboratories Inc No longer there

Ester,

Have you turned on versioning at the file cabinet level? That can be done in the web client by configuring a file cabinet.

Once you turn on versioning I do not believe it can be turned off without deleting the file cabinet entirely and re-building it.

Check in and check out will only appear for a file cabinet with that option checked.

Thanks,

Joe Kaufman

Josef,

I was also thinking this was like scan configs, where we were part of a lengthy thread on that in March of 2017 (wow, time flies!):

https://www.docuware.com/forum/english-forums/docuware-questions-about-usage-and-configuration/scanning-dynamic-import-config-barcode

(And yes, it still stinks that identifying isn't performed on every page, because I see no downside to it and Fortis had the capability.)

But then I thought this should be different from scanner-based configurations, because isn't each document sent as its own print job? That would mean documents are inherently separate and should identify individually. If a bunch of documents are printed as one "batch" job then identification would fail for all documents except the first one found to match a config, but a single document per print job should work.

David, are you sending documents to the DW printer one by one, or as some sort of batch job? You say you "print a batch of different types", but I am not sure how that works. Are you saying you consolidate a bunch of different documents into a single PDF and then send it to the DW printer? Perhaps I am just clueless as to how the DW Printer batches things up -- I assume it is a separate document per print job, queued up like any Windows printer would.

Thanks,
Joe Kaufman

Callum,

That works, but is this truly the new home of official DW documentation on the Platform? That is one weird link...

Thanks,

Joe Kaufman

Jose,

The .NET help has some examples of merging documents:

http://help.docuware.com/sdk/platform/html/7e48a8c5-4726-4f79-aeb6-885ec341c904.htm

But it looks like the ContentMergeOperation only supports stapling and clipping.

For pure attachments, I searched the URL resources page for the Platform service and cannot find the word "attach" anywhere on there. I have not done much with attachments, so I do not know the difference between attaching, clipping, and stapling.

I also have not done anything with versions in the Platform service. But hopefully someone will weigh in, at least with some additional .NET examples.

Thanks,

Joe Kaufman

Hey all,

I used to be able to go to:

https://docuware-online.com/DocuWare/Platform/Home/XSL

to get help on the Platform SDK (general help, not just .NET stuff).

This link appears to no longer work. I can change "docuware-online.com" to the name of our on-prem server and see the documentation from there, but that information is obviously version-capped to what we are currently running. If I want to look at something for 6.12 or 7.0 I am out of luck.

Can anyone tell me where this content has gone or when the link above will be back up?

Thanks,

Joe Kaufman

Bernie,

Yeah, we have been able to get things working the way we need, and DocuWare has a lot of advantages over Fortis when it comes to the basics, like searching.

Just FYI, we recently upgraded to SQL Server 2016 and it went without a hitch just using the basic installer wizard. No issues. We have about 800,000 documents covering 650 GB, and the dwdata database is around 20 GB in size. Hopefully your upgrade goes as smoothly!

Thanks,

Joe Kaufman

Kjetil,

Keep in mind that documents are not stored in the database -- the database just houses the meta-data for the documents, though in the case of full-text OCR, there will be a substantial amount of space used for the textshots.

The documents themselves will be stored on some server-accessible disk-space. Our dwdata database is about 20 GB and dwsystem is about half a GB. The folder storing all the actual documents is about 650 GB (we only have a little over 800,000 documents). What is the current size of the document store? How large is the average document?

This is a point where a reseller for DocuWare could help with estimates on size, though that sort of expertise certainly exists on this forum as well.

Thanks,

Joe Kaufman

Hey all,

Looks like this is a no-go, and I doubt asking for a feature request will go anywhere (but other folks are welcome to try that if they want!). Here is Phil's response from the other thread where I asked about using URL integration to download multiple documents:

==========================

After looking in to the behavior, I have this information.
By design, there are 4 URL integration types that will only return 1 document:

Viewer
Download
Document History
Info Dialog
 

The product team investigated the possibility of downloading multiple documents in versions 6.0, 6.5, 6.7, and 6.10 and it was not possible.
Further investigiation revealed that there does not appear to be much call for this functionality. So if it is required then it will need to be registered as a feature request.

==========================

So, I guess using the Platform Service or using Folders would be the only way to pull down more than 100 documents at once. Going deeper into that, the URL created by the web client for downloading multiple selected documents is sort of interesting. When you download multiple files, it does it via something like this:

http://docuware1/DocuWare/Platform/FileCabinets/c9a12a34-a24b-4c84-9643-744c90eca178/Documents/147388/FileDownload?
targetFileType=&keepAnnotations=false&downloadFile=true&autoPrint=false
&layers=&append=147387,147382,147380,147379,147378,147377,147376,147375,
147356,147355,147354,147353,147352,147351,147324,147308,147307,147306,147305
,147304,147303,147302,147300,147299,147298,147297,147296,147295,147294...

where the "append" parameter is just a comma-delimited list of document IDs. The problem is, if that list gets too long, the download fails with a 404 error. I was able to get up to 200 or 300 documents at once using the Folder idea, but that fails as well once the list gets too long. Perhaps that is part of the architectural limitation DocuWare ran into, making them ditch the whole idea.

Casey, do you recall the largest number of documents you ever downloaded with a URL Integration zip file? It might just be a URL length limitation -- looks like any URLs over 2,000 characters are frowned upon even though the HTTP standard does not provide a hard limit...

In summary, if you want to download more than a few hundred documents at once, the Folder idea won't work, either. That leaves the Platform Service.

Thanks,

Joe Kaufman

Phil,

Drat, that's disappointing. It is also a bit odd, since on that other thread someone (Casey, I believe) knows for a fact he used to be able to do it, and he thought it was as recently as version 6.5. So, I don't think the functionality has been gone that long.

I'm not going to bother with a feature request since even some really popular ones (lots of votes) don't seem to go anywhere. I don't anticipate DocuWare changing its stance on this even if the feature gets 100+ votes, and it won't get that anyway because there probably aren't enough people who understand how powerful the feature would be. This is one of those features that follow the "if you build it, they will come" motif, in my opinion. It's just a nice option to have for folks to have easier access to their documents. The more ways that can happen, the better, especially since URL integration is a lot easier to use than full Platform manipulation.

Thanks for looking into it.

Thanks,

Joe Kaufman

Bernie,

This is exactly the way we had things set up in Fortis as well (index-wise), and we made links so that when viewing an invoice you could then bring up the check that paid it, and vice versa. Sometimes one check might pay dozens of invoices.

We had a VERY elaborate query in Fortis to link AP Invoices and Checks on invoice numbers. The query was too complex for DocuWare to handle (it does not do nested parens, etc. very well). So we did what you are describing, back-filling the check number to the invoices when the checks are cut and stored into DocuWare later on.

Are you on-premise? SQL Server? What I did is write an automated program that runs periodically and does that exact thing, back-filling chek number to the invoice. I even have Foxpro code I could provide as a sample. If you are on-premise and feel comfortable with doing SQL Server queries and then using the Platform SDK to set the check number index on invoices, it could work.

Otherwise, this issue is exactly what an Autoindex Workflow is meant to help with. It might be a module worth considering.

I am curious -- are you saying you had this automated in Fortis? What did that look like? We did not do that, we just matched on invoice number. By the way, that is another option here -- depending on how many invoices your checks might pay, you could store all those invoice numbers on the Check record, yes? That would still make searches and linking difficult, but I am not sure how you were doing the back-fill in Fortis... I never ran across any sort of auto-indexing feature in Fortis.

Thanks,
Joe Kaufman