• RE: Increasing Bar Code Recognition in v7 and above

    Kim,

    Hi, Kim, long time no see!

    Just a bit over two years ago after initial roll-out (a Fortis migration that you assisted with), we were seeing a 5-10% failure rate of barcodes as well, on everything from splitter/ID barcodes to index fields (we use a lot of barcoded scan sheets). One of our scan sheets has something like 20 barcodes on it.

    I spent two days testing batch after batch, just trying to increase accuracy. I ran across the same article you found, but it didn't go deep enough. DocuWare support was, in a word, unsupportive. They did tell me more about some of the other VintaSoft settings, but basically said don't mess with them (or gave a standard, "Well, if you do touch them you are on your own, and they won't make any difference anyway.") They were wrong.

    It took me a long time to start tweaking the ExpectedNoBarcodes setting because I thought it meant that the import should expect "no" barcodes. Turns out it is just a really stupidly named parameter that means "expected NUMBER of barcodes", and it was set to 0 by default (because, remember, it wasn't supposed to have any effect on anything anyway). I also researched that the higher the number, the more it could affect performance.

    The bottom line is that everyone was wrong. I upped ExpectedNoBarcodes to 99, and BAM! The next three test runs I did had 100% barcode accuracy, and the scan job did not run appreciably slower. And we have seen pretty much 100% accuracy for 2 years now. Some printers still print unreadable separator/ID barcodes (which is weird), but by and large we are chugging through thousands of barcodes a day with perfect scanning.

    Below are the notes I took about the additional fields in the VintaSoft settings (with my ExpectedNoBarcodes comments asterisked):

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

    10/06/2017 - Additional information from DocuWare tech support:

    TradeOff is the option which tries to bring together speed and quality. The possible values are BestSpeed, Balanced, BestQuality. In case barcodes are not recognized (especially smaller barcodes) then switch to BestQuality. This will decrease performance and increase the average number of recognized garbage barcodes. Changing the trade off can make things better, but also worse. So be careful. When changing the trade off the quality threshold should be adapted (the higher the trade off the lower the quality threshold).

    All other mentioned setting should not be touched, that's why they are not included in the faq.

    ExpectedNoBarcodes
    Possible values are: any integer number equal or larger than zero
    Default value: 0
    *** Set this value to 99 to make sure the VintaSoft engine reads all barcodes on a page and doesn't stop prematurely! ***

    QualityThreshold
    Possible values are: 0.00 - 1.00
    Default value: 0.20

    ConfidenceThreshold
    Possible values are: 0.00 - 1.00
    Default value: 0.95
    ==================

    Here is the full VintaSoft.settings file we use, where we have everything commented out except Code128 barcodes:

    ==============================
    <?xml version="1.0"?>
    <BarcodeSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" TradeOff="BestSpeed" MinimalBarcodeLength="1" ExpectedNoBarcodes="99" RenderResolution="300" Iso15415Threshold="-1.0" Iso15416Threshold="-1.0" QualityThreshold="0.2" ConfidenceThreshold="0.95" Erode="false" AutomaticMode="true" xmlns="http://dev.docuware.com/settings/barcode/configuration">
      <BarcodeTypes>
        <!--<BarcodeType DwBarcodeType="C25Interleaved" />-->
        <!--<BarcodeType DwBarcodeType="Code39" />-->
        <BarcodeType DwBarcodeType="Code128" />
        <!--<BarcodeType DwBarcodeType="Ean128" />-->
        <!--<BarcodeType DwBarcodeType="EanExt5" />-->
        <!--<BarcodeType DwBarcodeType="EanExt2" />-->
        <!--<BarcodeType DwBarcodeType="Code93" />-->
        <!--<BarcodeType DwBarcodeType="Codabar" />-->
        <!--<BarcodeType DwBarcodeType="Ean13" />-->
        <!--<BarcodeType DwBarcodeType="Ean8" />-->
        <!--<BarcodeType DwBarcodeType="C25Industrial" />-->
        <!--<BarcodeType DwBarcodeType="UpcA" />-->
        <!--<BarcodeType DwBarcodeType="UpcE" />-->
        <!--<BarcodeType DwBarcodeType="Code11" />-->
        <!--<BarcodeType DwBarcodeType="MSI" />-->
        <!--<BarcodeType DwBarcodeType="RSS" />-->
        <!--<BarcodeType DwBarcodeType="Postal" />-->
        <!--<BarcodeType DwBarcodeType="PatchCode" />-->
        <!--<BarcodeType DwBarcodeType="Telepen" />-->
        <!--<BarcodeType DwBarcodeType="Aztec" />-->
        <!--<BarcodeType DwBarcodeType="DataMatrix" />-->
        <!--<BarcodeType DwBarcodeType="QR" />-->
        <!--<BarcodeType DwBarcodeType="PDF417" />-->
        <!--<BarcodeType DwBarcodeType="MaxiCode" />-->     
        <!--<BarcodeType DwBarcodeType="Pharmacode" />-->    
      </BarcodeTypes>
      <Iso15415BarcodeTypes>
      </Iso15415BarcodeTypes>
      <Iso15416BarcodeTypes>
        <!--<BarcodeType DwBarcodeType="Code128" />-->
        <!--<BarcodeType DwBarcodeType="C25Interleaved" />-->
        <!--<BarcodeType DwBarcodeType="UpcE" />-->
      </Iso15416BarcodeTypes>
    </BarcodeSettings>
    ==========================================

    I do not know how DW 7.1 does things on the Desktop, but hopefully you can still swap out the settings file, restart desktop services, and try to scan again. Hopefully it increases your accuracy.

    Thanks,
    Joe Kaufman
  • RE: Upload a documant with index data via java script

    Martin,

    The .NET code is just a wrapper around the Platform SDK resources which can be called from any language. If you do a Google search on the following:

    docuware platform "non-.net"

    you will find several posts about that. More recently, DocuWare has even released a Postman collection of examples that illustrate how to perform calls to the Platform SDK from any web-capable language or scripting tool (e.g. curl):

    https://developer.docuware.com/rest/examples/postman-collection-download.html

    There is also a link to some node.js examples there which may translate more easily into JavaScript...

    Good luck!

    Joe Kaufman
  • RE: Total count of documents in archive

    Craig, good info! I thought it only showed # of documents if full-text was turned on for the cabinet, but it shows for any cabinet (and I confirmed this still works in 6.11).

    The SQL query will only work on-premise, correct? Or is there another spot to do free-text SQL querying on the data (that exists in the cloud version)?

    Thanks,
    Joe Kaufman
  • RE: REST API : Document searches by fields

    Florian,

    Thank you for the definitive response!

    Thanks,
    Joe Kaufman
  • RE: Total count of documents in archive

    Ronald,

    By "archive" I assume you mean file cabinet? 

    I am not seeing a way to get the number back from any tool or even the Platform SDK. Everything is paged and asynchronous, topping out at whatever limit is set for searches.

    However, if you are on-premise then you can access the database directly to get the number of documents in a cabinet. Are you on-premise? And what version of DW?

    Finally, if you have access to the server data storage area, you can simply check the properties of the folder containing the documents for the cabinet. Of course, that would require an on-premise situation as well.

    It would be great to have a way to know the total number when a system is in the cloud...

    Thanks,
    Joe Kaufman
  • RE: REST API : Document searches by fields

    Florian,

    Thanks for the input! While we have you here, can you address the original issue? I appreciate the documentation link, but the documentation is actually part of the problem in this case. Here, the "q" parameter is not mentioned or used:

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

    But this still lists "q" as a valid parameter (though it is part of an extension method):

    https://developer.docuware.com/dotNet_API_Reference/PlatformServerClient/DocuWare.Platform.ServerClient.SchemaExtensions.html#DocuWare_Platform_ServerClient_SchemaExtensions_GetFromDocumentsForDocumentsQueryResultAsync_DocuWare_Platform_ServerClient_ServiceConnection_System_String_System_String_System_String___System_String___System_Nullable_System_Int32__System_Nullable_System_Int32__System_Nullable_System_Int32__System_String_System_Nullable_System_Boolean__

    So, is "q" supposed to work, or not? Can you shed any light on the internal server error, "The given key was not present in the dictionary" that we both see when we try to query directly from the file cabinet? If it is broken, any plan on fixing it? It is frustrating when documentation says something should be doable but then it doesn't work.

    The "Get Documents" portion of the Postman collection is not helpful either, as it only utilizes count, fields, and going after a document by specific ID in the examples. Querying for a document (directly from the file cabinet) via the "q" parameter is not illustrated. Only searching via a dialog is exemplified further down in the collection. (EDIT: Trying to use the "q" parameter in the Postman samples for directly accessing documents from the cabinet fails with the same error no matter what query expression is passed in...)

    Can we get a definitive answer on the "q" parameter as used in GetFromDocumentsForDocumentsQueryResultAsync()?

    Thanks,
    Joe Kaufman

  • RE: REST API : Document searches by fields

    We amateurs can get a lot done if we stick together.  *smile*

    On a thread long ago (trying to get the DW Platform SDK working from Visual Foxpro) I got to the point of saying I would just fill out a support ticket. Problem is, DocuWare will not give in-depth support on the Platform SDK unless you specifically license that level of support. I think it was a reasonable figure if you are doing a lot of implementing (like $1000-$1500/year), but that didn't make sense for us since we are just one installation (I am not a consultant or reseller, just a guy working for a company that had to switch migrate from Fortis to DocuWare).

    When I was told I wouldn't get any help without ponying up what would have been about a 20-25% license increase for us, that's when I started using Fiddler and Postman to figure out what was going on (mainly with authentication). I also use a lot of integration with a C# wrapper program I wrote where a bunch of common functions are exposed via command line.

    DocuWare may have changed their licensing scheme since them, so you could always try to ask these questions via an "official" support ticket to see what they would say (then post here, please!). In my experience, there are quite a few commercial tools out there with a powerful API obfuscated by marginal documentation and developer support that costs extra... But you can still give it a try!

    Thanks,
    Joe Kaufman
  • RE: REST API : Document searches by fields

    Aurelien,

    I think if the query did work directly against the cabinet, it would just use an encoded "q" expression, not POST data. The problem is, it just doesn't work. I tried searching for a past thread about the error I got with GetFromDocumentsForDocumentsQueryResultAsync() when trying to use the "query" parameter, but I cannot find it anywhere (it was on the old forums). It looks like they still have not gotten it to work.

    I went ahead and tried a query again to recall what the error was (on 6.11 on-premise) It is:
     
    500 Internal Server Error (The given key was not present in the dictionary.)

    It doesn't matter what I try for the query parameter -- if it is a non-empty string I get the above error, valid expression or not.

    The count parameter does work, though, to limit the number of records returned. So, if you just want all or some the files in a file cabinet, it is the method to use so that you don't need to mess with a dialog GUID.

    Thanks,
    Joe Kaufman


     
  • RE: REST API : Document searches by fields

    Aurelien,

    If the "q" is like the "q" parameter for URL integration, here is what I have in my comments about how to form the query parameter:
     
    Field names in queries are case sensitive! Field names (in the database) are usually ALL CAPS.
    The actual database field name of a field can be viewed in the DocuWare Administration desktop
    application. Queries place field name in square brackets and the value on double-quotes.
    Though, for numeric fields, the quotes appear to be optional. Operators can have whitespace
    around them. Here are example query expressions:
    
    [DWDOCID]=123    (This will query by the internal DocuWare document ID.)
    [CUST_NO] = "WA60"    (This will query the field "CUST_NO", trying to exactly match "WA60".)
    [LASTNAME] LIKE "K*"    (Wildcard search -- note use of "*" instead of "%" for wildcard character.)
    [SHIPTO_STATE] = EMPTY()    (Queries SHIPTO_STATE for empty values ("EMPTY()" must be uppercase).)
    [BILLTO_STATE] = NOTEMPTY()    (Queries BILLTO_STATE for non-empty values ("NONEMPTY()" must be uppercase).)
    [DocuWareFulltext] = "find this string"        (Full-text search.)
    [DWSTOREDATETIME] > 2017-06-14 19:45:31        (Date/time expression *** CONVERT TO UTC ***)
    [START_DATE] >= 2016-06-01 AND [START_DATE] <= 2016-08-01    (Boolean conditional, checking date field over a date range, inclusively.)
    
    Expressions can be joined by AND or OR and can be qualified with NOT. Delimiters around string
    values MUST be double-quotes. Also, the conditional statements and compound keywords (e.g. LIKE, AND, OR, etc.)
    need to be capitalized as well.
    
    *** SPECIAL NOTE WHEN USING DATE/TIME FIELDS ***  Date/time fields are stored in DocuWare as UTC timestamps.
    While queries in the web client or Platform SDK allow the use of local date/time formats, URL Integration
    queries appear to use the date/times passed in as-is and compare against the stored UTC timestamps.
    So, if you are using date/time fields in your query, the date/time values need to be converted to UTC
    to get accurate results.

    Additionally, the query parameter needs to be URL encoded, doing whatever something like System.Web.HttpServerUtility.UrlTokenEncode() does in .NET. Not sure how I figured that out, but that's what the code (that works) says.

    When it comes to the call itself, I don't use the resource you list. In fact, I think I tried it in version 6.11 and it didn't work. All I could do with that resource was to return ALL documents from the file cabinet. If I tried to add a query parameter, the call threw a strange error (in .NET).

    So, I use the following resource, and it works from Visual FoxPro:
     
    /DocuWare/Platform/FileCabinets/{cab GUID}/Query/DialogExpression?dialogId={dialog GUID}&count=2100000000

    This works through a dialog, so it is a bit more of a pain to use since you have to know the GUID of the file cabinet and the search dialog.

    Where is the query, you might ask? When using the above resource, you do it as a POST, not a GET, and the query is in the POST data. Here is an example of POSTed XML:
     
    <?xml version="1.0" encoding="utf-8"?>
    <DialogExpression xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"  Operation="And"  xmlns="http://dev.docuware.com/schema/public/services/platform">
        <Condition DBName="COMPANY">
            <Value>bell</Value>
        </Condition>
    </DialogExpression>

    You basically just construct XML with field names and values, and the values can be wildcards or system keywords like EMPTY() and NOTEMPTY(). POST this content to the resource and you get back an XML result with all the found document records. You'll have to parse that out however you see fit into whatever result you need.

    Lots of trial and error on this stuff. One way to learn about what is going on under the hood is to do operations in C#/.NET using the libraries that make such operations easier to construct (syntactically). Then, if you watch network traffic with something like Fiddler you can see what the raw HTTP calls look like (I can, anyway, as our server is HTTP, not HTTPS -- not sure what happens with HTTPS). IIRC, posted data in those calls is usually JSON instead of XML, which you can totally use if you are more comfortable with JSON. I've had better luck posting XML for some reason.

    Again, this is all on 6.11, an on-premise installation.

    Hope this helps!

    Thanks,
    Joe Kaufman

     
  • RE: Clip like in the web client, but from Platform SDK API?

    Seth and Josef,

    Thank you! Seth, yes, I have that Merge code working, though not in FoxPro. I may have to write some of these routines in C# instead. I guess I can go ahead and just upload all documents to their final destination, settling on the first one as the "main" document. Then Merge them together once they are all up there. At this point I don't really see why I was so dead set against it, especially if the starting document retains its ID (the documentation says a new document is created, but that must not really be the case, except that of course the document is different once it has stuff clipped to it...

    Thanks,
    Joe Kaufman