I used to be able to go to:
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?
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!
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.
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:
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:
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.
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.
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.
I hope you come back with good news -- downloading multiple documents via URL could be really, really handy for folks who do not want to get into Platform coding. I mentioned the use of Folders on that other thread, but needing to set up a folder just to overcome the 100-document view limit is sort of a kludge.
In any case, I appreciate your attention, and hope you have a great weekend!
I have posted a more direct question on this topic, complete with my URL Integration creator screenshots, so hopefully someone will tell us what's what. Maybe it has been un-featured for a while now.
Over on this thread we have been discussing the nifty idea of using URL integration to download a lot of documents at once:
The idea is that in the same way you can download multiple documents from the web client as a ZIP file, a free query in URL Integrator would allow one to download more than 100 at a time. One user stated that he gets a zip file containing multiple documents to download in this fashion.
I have attached the screens from the URL Integrator wizard as I attempt the same thing. I am gathering all documents from our Fixed Assets cabinet that start with a "P" in the Asset ID. The query is correct. I know there are several documents that meet this criteria. In fact, if I change the Integration Type to Result List and Viewer, I see multiple documents returned without error.
But when I use "Download" as the integration type (as depicted in the attached pictures), only one document downloads, the first result found. By changing the query I can make that first document change, and a different document does download each time. But under no scenario can I make multiple documents download as a ZIP file.
I am on 6.11, and another user says they have the same issue in 7.0 -- multiple documents will not download as a ZIP file.
Can someone explain what the correct behavior is and why it works for some but not for others? Can one reliably count on URL integration to download multiple documetns in a ZIP file, and what versions of DocuWare should this be working in?
Glad you got that working! Python makes the coding look easy. *smile*