Joe Kaufman Bell Laboratories Inc No longer there

Hello,

Shot in the dark here, but has anyone else noticed slowdowns in scanning after a scanning workstation is updated to use Windows Feature Update 2004? We have one person here who, after running the update, has scanning operations take a second or two per page where the scanning used to be a continuous stream. When the 2004 feature update is uninstalled, scanning resumes full speed.

Canon has not been helpful thus far, so it would seem they have not had many (or any) people report a slowdown, but I thought I would try posting here. We are running DocuWare 6.11 on-premise and use Canon scanners such as the DR-6010C.

Thanks,
Joe Kaufman

P.S. As a bonus question, what brand of scanner do other folks use? Anything else in the Canon price point that works as well with DocuWare? Any gotchas (or brands) to avoid in anyone else's experience?

Stephen,

I believe the name is determined by whichever database field (index) is given the "Document Name" attribute when designing the file cabinet. There can be only one "Document Name" field designated, and when that index is filled in, it becomes the document name.

What are you placing in the field designated as Document Name? If you set that index (via the API or the web client), does the name then display as you would hope?

Thanks,
Joe Kaufman

Adriano.

I am not sure what you have all tried, but it is very possible to login to DocuWare with basic authentication. Check out this post:

https://support.docuware.com/de-DE/forums/questions-about-usage-and-configuration/cd2c7857-8f41-e911-a967-000d3ab3fe8a

There are details on how I use Foxpro to access DocuWare (on-premise, version 6.11). 

Long story short, via Postman, if you do a POST with the URL:

http://<server>/DocuWare/Platform/Account/Logon?Organization=<org name>&Username=<username>&Password=<password>

you should see XML representing various DocuWare links -- it means you are authenticated. If you do this POST with some sort of persistent connection/request object (such as MSXML2.ServerXMLHTTP or MSXML2.XMLHTTP on Windows), you can then do additional GETs to access the various API functions.

Hope this helps!

Thanks,
Joe Kaufman

 

Steve,

That's a really good question.

I could not find that date anywhere in the DocuWare database. I checked the base dwdata table, the related _SECT table, and the related _PAGE table. Didn't find anything that matched.

So, I found the root document as stored in the file system on the DocuWare server. DocuWare stores the actual document in a defined hierarchy, and the file will always have an XML file beside it. In the XML file is a modification time that matches, and it matches the last modification time on the file itself. Since the viewer obviously pulls the document in from it's file-based location, it must get the information from the document as it does so, and displays the last time the document itself was modified/created when it was just a regular old file on disk.

I am not sure if that date resides anywhere else, and I am not sure if it comes back in the document information class when using the Platform SDK. That means I am not at all sure as to how you could easily pull that date on your own. Hopefully someone more in the know responds with a more thorough answer...

Thanks,
Joe Kaufman

Jon,

First off, do you have access to the underlying database? It is always easier to query the index data directly if that is the case.

If you don;t have access to the database, then you need to get back document information one of two ways: 1) Pull down all documents in a file cabinet, or 2) Execute a query via the SDK to get a list of documents back. When you get a "Document" object back it isn't the actual document, but the record representing the indexes for the document (which is what you need).

This describes how you get all documents from a document tray or file cabinet:

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

and this explains how to execute a query:

https://developer.docuware.com/dotNet_CodeExamples/b8b6ddf4-fee5-4b5c-84cc-046895c8aa5a.html

Note that the data you get back from this is not as easy to parse as, say, a relational database table. But you can parse the returned documents using loops and things like LINQ to pluck out the information you need.

Like I said, accessing the data directly is much more straightforward, so if that is an option, forego the SDK and hit the table directly. Just don;t do any modifications via that methodology.

Thanks,
Joe Kaufman

Vural,

Glad to hear it! It was just a lucky guess on my part, as all the versions of .NET make my head hurt...

Thanks,
Joe Kaufman

Vural,

The code for establishing a connection looks correct, but the error is not really related to that, I don't think. Something is going wrong when a certain assembly tries to get loaded.

It is sort of a new version of "DLL Hell", and it sometimes relates to packages not being installed correctly (or versions being off). Assembly configuration is still a chore sometimes in the .NET world, but I do not know why you would be having versioning issues if you installed the latest DocuWare packages from NuGet.

I think you may have a conflict with .NET Core vs. .NET Framework. What sort of application are you trying to code? That is, what is the project type? I assume you are using Visual Studio Code and not the full-blown (paid) version of Visual Studio? Here are a few links I found that talks about issues with the ConfigurationManager:

https://github.com/pusher/pusher-websocket-dotnet/issues/34

https://stackoverflow.com/questions/46360716/cant-use-system-configuration-configuration-manager-in-a-net-standard2-0-libra/50937932

https://stackoverflow.com/questions/47098698/how-to-use-net-framework-from-net-core

As you can see, StackOverflow is your friend.  *smile*  I am betting this is just a configuration/reference issue related to the type of application you are building. If you can develop a .NET Framework application using Windows Forms I know the stuff works, as that is what we use. I have not tried any DocuWare code as part of an ASP.NET or .NET Core project.

Good luck!
​​​​​​​
Joe Kaufman

Vural,

Not sure if it is allowable for your project, but have you tried using the very nice DocuWare packages that wrap the API in easy-to-use C# code? I have found that for certain operations, using the API with straight POSTs and GETs is problematic (I am doing a lot of that from Visual Foxpro). You can learn more about the .NET packages at:

https://developer.docuware.com/dotNet/66b2ed1e-2aef-452a-97cd-5014bbf0242b.html

But if you have to use the more raw GETs and POSTs (as I imagine a college project might require you to do), I am not sure why your code does not work. In reviewing my Foxpro code, your entry point appears to be correct, but I do not try to upload and index the document all at once. I upload it, then index it using a separate POST. On what line are you getting the actual error? Have you tried just uploading the file, and does that succeed? The more you can break the transaction down the better you can debug the problem. The issue might lie with the XML not being in a format DocuWare expects, for example.

Sorry I cannot be of more help, as on the C# side I use the DocuWare Nuget packages to make life a whole lot easier.

Good luck!
Joe Kaufman

Can anyone help me with this? I am still unable to access the Partner Portal -- two web sites just take me back and forth when I try to access "My Account" inside the portal login page (see my previous post on the topic).

I am no closer to being able to download a LIC file, so is this possible or not? I'd rather not open a support ticket for such a silly endeavor...

Thanks,
Joe Kaufman

Simon,

I just wasted ten minutes trying to login to the partner portal, and then taking screenshots to show how it is an exercise in futility.

Whether I am signed into the forums or not, when I click the link you state I go to a page that looks like my "access the portal" picture attached. I click the circled link, and it takes me to the "portal" (picture also attached).

No matter what I click on in the so-called portal (such as "My Account"), it takes me back to the "access the portal" page. Lather, rinse, repeat.

Extremely frustrating. DocuWare has always (pardon my French) sucked as far as web site navigation goes, but the so-called streamlined site isn't any better. Now hard is it to have a straightforward login process that isn't buried in multiple links or caught in back-and-forth page navigation?

I am no closer to being able to access LIC files on my own should the need arise.

Thanks,
Joe Kaufman