Joe Kaufman Bell Laboratories Inc No longer there

Hameed,

What is the target for the C2O configuration? That is, are you trying to store an email to a document tray or directly to a file cabinet?

Can you get any Store configuration to work?

I just tried again with 64-bit Outlook (I had deactivated the COM add-in) and was able to store an email to a document tray with no errors...

Thanks,

Joe Kaufman

Casey,

I am using Outlook 2016, 64-bit, and C2O has worked for me. WHen I check the COM add-in, it even lists what appears to be a 64-bit loader DLL called "adxloader64".

I do not know what might be causing the original poster's issues, though, sorry...

Thanks,

Joe Kaufman

Juan,

OK, not sure if I am doing this right, but here is code using the SDK in .NET (C#) to clip a document to another document within a file cabinet:

        private void DoClip()
        {
            string cabID = "0B54ED91-B7B2-4F48-89BE-CD9C927A2C02";
            Document doc = DWConn.GetFromDocumentForDocumentAsync(580, cabID).Result;
            IntegerList intList = new IntegerList();
            intList.Int = new List<int>();
            intList.Int.Add(581);
            doc.PutToClippedDocumentsRelationForDocument(intList);
        }

The first line is simple -- you need the file cabinet ID (GUID) before you can do anything to a file cabinet.

Then we instantiate a Document object with the document ID (in this case 580) using the SDK method GetFromDocumentForDocumentAsync() (the invocation of "Result" keeps things synchronous).

Then we create and populate an IntegerList instance. Not sure why it is so convoluted to build a simple list of integers, but I don't know enough about it to question that the above code works (you cannot create your own List<int> and cast it to IntegerList -- wouldn't compile).

Finally, we use the PutToClippedDocumentsRelationForDocument() method to clip the documents. In this case, the integer list has a single document ID in it, 581, and that document will be clipped to 580. I tried it and it works. The document that was 581 is clipped to 580, and document 581 no longer exists on its own. I do not know how to control the order. I assume it just tacks documents onto the end in the order as established by your IntegerList.

Incidentally, you can also UNclip a stored document using a standard HTTP GET:

http://<server>//DocuWare/Platform/FileCabinets/0B54ED91-B7B2-4F48-89BE-CD9C927A2C02/Operations/Unclip?docId=580

The line above (assuming you are already authenticated) would take document 580 and unclip everything into separate documents. Document 580 would no longer exist after the above operation. I did not try an unclip operation in .NET.

The unclip is quite interesting, as people have asked for it in the interface:

https://docuware.uservoice.com/forums/230570-client-english/suggestions/6017714-implement-the-ability-to-unclip-documents-that-hav

but it doesn't look like it has been implemented yet in the web client (as of 6.11). Yet it can be done in the SDK.

When using an IntegerList of document IDs to clip to the original document, if you use a document ID that does not exist in the same file cabinet as the source document, a fairly cryptic 403 error is returned from the server: 

"403 Forbidden - Some of selected documents are locked either by content server or by other clients."

I think this error is a catch all for anything that goes wrong when DocuWare tries to find the document(s) to clip to the original and something goes awry.

Hope this helps...

Thanks,
Joe Kaufman

PS. I also got clipping working with basic HTTP calls, like this POST:

http://<server>/DocuWare/Platform/FileCabinets/0B54ED91-B7B2-4F48-89BE-CD9C927A2C02/Operations/ClippedDocuments?docId=582&operation=Clip

where the JSON-based POST data (Content-Type: application/json) looks like the following:

{"Int":[583]}

This would clip document with ID 583 to the document with ID 582. You can change the "operation" parameter to "Staple", and that will bring in the POSTed documents and tack them on the end of the original. If the original had clipped sections, it all gets flattened out into one section after a staple operation, as far as I can tell (I haven't done much with clipping or stapling up until this point...)

Matthew,

I don't work with Document Trays enough -- wow, you are so right. It knows the value and even lists it in the columnar view but doesn't let you sort. That's really, really dumb. I am going to go vote for your idea immediately... I can totally think of several use-case scenarios right off the top of my head for wanting to be able to sort by that...

Thanks,

Joe Kaufman

Matthew,

I am guessing # of pages is not sortable because # of pages is not a system field stored at the Documkent header level. You have to look up pages elsewhere.

Any chance of putting the documents into a file cabinet and then populating number of pages behind the scene (hitting SQL Server)? We do that on select file cabinets, and I can share the code if you are interested.

Thanks,

Joe Kaufman

Phil,

I am guessing he means to have Windows be the default even the first time in. My system remembers the authentication method after I do it once, but the first time in I am sure it was DocuWare.

Not sure if that is what the OP is referring to...

Thanks,

Joe Kaufman

Here is a big SQL query I use to get all users and/or roles that have admin or use rights to existing document trays. It should be run against the "dwsystem" database on your DocuWare server (our database is MS SQL Server):

==============================
SELECT fcs.SetID AS ID, fcs.Name AS DocTray, fc.name AS FileCabinet,
    fcs.settings.value('(/WebBasketSettings/@DiskNumber)[1]', 'int') AS DiskNumber,
    r.name COLLATE SQL_Latin1_General_CP1_CI_AS AS UserOrRole, 'Role' AS Type,
    IIF(UPPER(fcp.settings.value('(/BasketProfile/GeneralRights)[1]', 'varchar(500)')) LIKE '%ADMIN_OPERATOR,%', 'Administrate', 'Use') AS Access
    FROM DWFCSettings fcs
    INNER JOIN DWFileCabinet fc ON fcs.settings.value('(/WebBasketSettings/@AssignedFileCabinetGuid)[1]', 'varchar(50)') = fc.Guid
    INNER JOIN DWFCSettingsToFCProfile fcsp ON fcs.setid = fcsp.setid
    INNER JOIN DWFCProfile fcp ON fcsp.fpid = fcp.fpid
    INNER JOIN DWFCProfileToRole fcpr ON fcsp.fpid = fcpr.fpid
    INNER JOIN DWRoles r ON fcpr.rid = r.rid
    WHERE UPPER(fcs.Type) LIKE '%WEBBASKETSETTINGS%'
UNION ALL
SELECT fcs.SetID AS ID, fcs.Name AS DocTray, fc.name AS FileCabinet,
    fcs.settings.value('(/WebBasketSettings/@DiskNumber)[1]', 'int') AS DiskNumber,
    u.name COLLATE SQL_Latin1_General_CP1_CI_AS AS UserOrRole, 'User' AS Type,
    IIF(UPPER(fcp.settings.value('(/BasketProfile/GeneralRights)[1]', 'varchar(500)')) LIKE '%ADMIN_OPERATOR,%', 'Administrate', 'Use') AS Access
    FROM DWFCSettings fcs
    INNER JOIN DWFileCabinet fc ON fcs.settings.value('(/WebBasketSettings/@AssignedFileCabinetGuid)[1]', 'varchar(50)') = fc.Guid
    INNER JOIN DWFCSettingsToFCProfile fcsp ON fcs.setid = fcsp.setid
    INNER JOIN DWFCProfile fcp ON fcsp.fpid = fcp.fpid
    INNER JOIN DWFCProfileToUser fcpu ON fcsp.fpid = fcpu.fpid
    INNER JOIN DWUser u ON fcpu.uid = u.uid
    WHERE UPPER(fcs.Type) LIKE '%WEBBASKETSETTINGS%'
ORDER BY DocTray, Type DESC, UserOrRole

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

It's ugly, but seems to work. This information can be subsequently used to get number of documents and total size in bytes, if you need those queries. But this should list all document trays and their backing file cabinets, along with User and Role rights.

Thanks,

Joe Kaufman

Grupo,

Are you on premise? Can you access the back-end database? You could follow through the data structure in that case to try to find trays linked to cabinets, and who has access to them...

Thanks,

Joe Kaufman

Yes, an office that has completely commoditized computing to use "dumb" scanners (as opposed to scanners hooked to a smart desktop client) is a good use case for why processing documents (fully) on the web would be nice. Would be quite an architecture change, though, to include that sort of processing on the server. I'd also worry about scanning consistency when using copier-based scanners. Hard to beat the consistency of a desktop scanner.

Such a company could devote a single workstation to an industrial scanner and people could just drop off packets of bar-coded materials, ready to go. But that is where another weakness of DocuWare's identification and splitting comes into play -- splitting does not work if you mix different document types onto one batch of scannables -- it won't do a split AND auto-ID at the same time. I figured that out as one of the first issues coming from Fortis (which does handle that situation), and we are just lucky that we don't do much of that any more...

Thanks,

Joe Kaufman

Gotcha. With the way things are split between desktop and web server now, I can see why documents in a tray (already on the web) cannot be run directly through a an Import Config...

Thanks,

Joe Kaufman