Joe Kaufman Bell Laboratories Inc No longer there

Yeah, another user request there...  To me, the most elegant way of doing this would be to have all of the "System entries" exposed as "Pre-defined entries" that you could assign to a File Cabinet field. No reason one shouldn't be able to expose all of that. Sort of a built in auto-index job. That way people canb even expost things like DWDOCID, which might be useful for more technical services.

I'm off to genericize adding a known index name to store page count and then have my autojob fill it in for any file cabinet having that field name.

Thanks,

JoeK

And does cache on the client browser matter as well? Have you tried viewing the site from a machine that has never lo9gged on to it before?

Thanks,

Joe Kaufman

Hey all,

I am pretty sure I know the answer to this (that it cannot be done natively), but is there a way to display the number of pages in a dcument in a result list? I am still gathering the use-case for this need from my end user, but I can see how it would be helpful when verifying scanned documents or looking for a specific document that you know might be larger or smaller or of a standard page count.

I already have code that gathers page-count information from a file cabinet's related _SECT table, but I have no way of forcing that to display in a result list dialog, obviously, unless I write my own client (no thanks).

The non-native workaround would be to add a page-count index field and then back-fill it via an auto-job. I can do that, I am just not sure the business need is worth that hassle.

Any information or ideas on how best to approach this would be appreciated! If DocuWare cannot do this natively, it would be nice if it were considered for a future release.

Thanks,

Joe Kaufman

Kim,

See this forum post for some information on licenses and timeouts:

https://www.docuware.com/forum/english-forums/docuware-help-technical-problems/license-problem-when-using-platform-sdk

Basically, what I have found out just by watching the Connections Overview from the DW Admin Tool (we are running 6.11 on-premise) is the following:

• When someone is authenticated and starts using a license, it is allocated for 30 minutes.
• After 10 minutes of inactivity, the expiration time will change to 2 minutes from the current time.
• Any activity at any point will push the time back to 30 minutes.
• Doing an explicit "logoff" via the Platform SDK resource will still leave the license in use for 2 more minutes. You cannot get around the 2 minute "feature", as it is there so DocuWare can optimize connectivity.

As that linked thread states, when connecting via a Platform SDK connection in .NET, you can use the same ServiceConnection object and do everything you want under just one license being used.

In non-.NET environments, be sure to use some sort of "global" HTTP request object when you want to use the Platform SDK so that you aren't using another license every time you perform an operation. Because even if you do an explicit logoff for that connection, it will still remain active for 2 minutes. In other words, if you do more than X operations within 120 seconds (where X is your max number of licenses), you will exceed your allocated licenses.

As far as the web client goes, if users do sporadic operations then, yes, they should time out after about 12 minutes -- 10 minutes of inactivity and then 2 more minutes of grace period.

Just sitting and watching the Connections Overviwe in the DW Admin tool (click on the main node for your organization and then press CTRL+P) can be very illustrative. It tells you what is considered just a connection and what burns a license, and by refreshing it you can see when connections go idle and then disappear completely two minutes later (assuming the user remains inactive).

Hope this helps...

Thanks,

Joe Kaufman

Stephane,

The resource you are referring to can only return all the documents in the file cabinet. The "q" parameter seems like it should work to act as a filter, but IIRC, it does not work, failing in both the .NET query and the straight URL resource type of query.

To get queries working via the Platform SDK you need to go through a search dialog, using a resource such as:

/DocuWare/Platform/FileCabinets/{cabID}/Query/DialogExpression?dialogId={dialogID}

POST the query to that URL using post data that has the proper XML syntax to define a "DialogExpression" node.

What I really wish the .NET library offered was a way to see what the POST data and the resource URL looked like at the time you execute a method via the DocuWare wrapper libraries. That would be the ultimate in educational. As it stands, the .NET wrappers hide the underpinnings too well, so when you need to access the same Platform functionality from outside of .NET you need to do a lot of trial and error until something works.

I guess the .NET stuff does show a lof of self-relation URLs, and those can help narrow down what things should look like.

Let me know if you need an example of XML that comprises a DialogExpression. Alternately you can use JSON if you are more comfortable with that (I have always had better luck getting XML to work as opposed to JSON...).

Good luck,

Joe Kaufman
 

We converted all of our Fortis documents (over 700,000 documents) to DocuWare using DWControl files. That methodology was used from the start because I thought we would use Import Jobs. That turned out to be really slow in testing, so I ended up writing a .NET application that uploaded all the documents and generated indexes based on DWControl files.

If I had a CSV file, that would actually be even easier using the Platform SDK libraries in .NET. I only used DWControl files because I already had them all generated for the files to upload.

Is Platform SDK programming an option? That would be the most flexible way to go on this.

Thanks,

Joe Kaufman

Kjetil,

I do not know how to do an "OR" sort of query like you are discussing, but am learning. Here's what I know about searching on non-Keyword fields (more on that later):

• You can search for a direct term, and by default, it will find any record that matches that index.
• You can turn on "Add wildcard to the search" for a field in a Search Dialog. This turns the search for that index into a "contains" logic instead of an exact match.
• You can use wildcard searching in the search value, such as "SearchTerm*", "*SearchTerm", and "*SearchTerm*". This gives you "starts with", "ends with" and "contains" functionality. A question mark can also be used in a wildcard search.

But I do not know how to do an "OR", but I very well could be missing something. You can do an "or" with URL Integration. In fact, you can do AND, OR, and NOT with URL Integration queries. You can also do AND and OR with Platform SDK searches, though I believe the search terms are then all AND or all OR -- they can't be a mix.

Now, one other way to make a field house multiple values (that can then be searched upon) is to make an index field be of the "Keyword" type. A Keyword field can house multiple values that you can search by. Though, this doesn't really help with your situation where you want to search for two things at once in the same field.

I do hope I am missing something here, and I am guessing I am. Because there are certain function keywords that can be used in queries, such as EMPTY() and NOTEMPTY(). 

That being said, I just checked the documentation, and found this:

http://help.docuware.com/en/#b57855t51009n75755

You CAN use an "or" operator between two search terms. For example, I went to our Accounts Payable cabinet and tried this expression in vendor name to make sure I got all FedEx invoices:

"Federal Express" OR "Federal Express Corp."

and that worked.

So, the TL;DR version of this is that, yes, it can be done, just check the help page listed at the URL above.

NOTE: You MUST use uppercase keywords. You must use OR and AND and not "or" and "and". I was having trouble, and the case-sensitivity is what was tripping me up.

Thanks,

Joe Kaufman

You and me both.  *smile*  We will figure it out, though. Just another reminder to test various configurations first before implementing a whole solution. Now that we caught this we should be fine moving forward with just a few business workflow tweaks.

Thanks for your help!

Thanks,

Joe Kaufman

I am told the font information is stripped out so the rendering is exactly as the printer needs without there being any font rendering issues.

My contact says they could simply start exporting a PDF WITH the font information first, for archival purposes, and then send the stripped PDF on to the final print destination. That would give us full-text back.

To put it another way (so that can understand it myself), the PDF us uber-flattened in a way such that it is basically just an image inside the PDF, and such PDFs do not OCR well unless you convert them to TIFF or PNG, etc.

Apparently Rawlings uses a different format for their final storage, which is why full-text works well for them.

Thanks,

Joe Kaufman

Phil,

I do not know what the PDF was before, as it is exported from Adobe Illustrator. Not sure what other processing is done to it or what format is native to AI.

I will send you one of these PDFs via email. I am not holding out much hope, as I just uploaded a bunch to Google Drive, and when converting the PDF to a Google Doc, only the stamp annotation text came through. So Google apparently cannot glean any text from the embedded image either.

Thanks,

Joe Kaufman