Joe Kaufman Bell Laboratories Inc No longer there

Martin,

We were doing that as well before we figured this out -- happy to help!

Thanks,

Joe Kaufman

Luiz,

I am not sure what you mean by "parameter". As my example further up indicates, you send the document up by making its binary stream the POST data in the "Send" call. That will create the document that you can proceed to index with subsequent Platform Service calls (as indicated in my example).

Thanks,

Joe Kaufman

Martin,

To create a data-only document, I have not used C#/.NET, but have it working from Visual Foxpro (or any language that can manipulate an HTTP request object).

The resource in play is this one:

/DocuWare/Platform/FileCabinets/{cabinbet guid}/Documents/

and then once I have an HTTP request object instance established (in this case, "_DWPlatformService"), the code to POST the request looks like this:

_DWPlatformService.Open("POST", "<URL involving the resource listed above>")
* Need to use a Content-Type of "application/xml" otherwise the POST will simply create a document with the index data XML inside it.
_DWPlatformService.SetRequestHeader("Content-Type", "application/xml")
_DWPlatformService.Send(<POST data>)

The POST data looks something like this, for a cabinet including indexes COMPANY and SENDER as an example:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="/DocuWare/Platform/Content/standard.xslt"?>
<Document xmlns:s="http://dev.docuware.com/schema/public/services" xmlns="http://dev.docuware.com/schema/public/services/platform">
    <Fields>
        <Field FieldName="COMPANY"><String>Data Only Company</String></Field>
        <Field FieldName="SENDER"><String>Data Only Sender</String></Field>
    </Fields>
</Document>

This will create a data-only document in the desired file cabinet.

Thanks,
Joe Kaufman

Phil,

I tihnk the "surprise" comes in because when we see a Result List we expect it to have the same functionality of any result list (for which we have permissions). The result list for a multi-cabinet search looks a lot like a normal list and appears to have a direct line to the documents we see. This is why it is odd when we cannot edit indexes.

I understand the complexity involved with editing multiple indexes -- permissions for one. What if someone wants to change multiple indexes across file cabinets but they actually only have permissions to change them for one of the cabinets accessed? That could get tricky.

But why not the ability to edit indexes on a single document? The result list knows the cabinet whence the document came, and knows the document ID. It doesn't seem like it would be that hard to allow the modification of indexes.

As far as no one asking for this, I can only assume that is because people don't use multi-cab searches very much. And this sort of thing could very well be the reason why. If such search results do not offer the same functionality as single-cab searches, of course folks aren't going to use it much. It feels odd that someone would even have to ask. When I come across an operation missing expected functionality (and there is no clear reason why it wouldn't be offered), I don't think "feature request" -- I usually think "bug", or at least "oversight".

Thanks,

Joe Kaufman

Stephane,

I am not sure I understand uploading a document and leading with the metadata. The URL mentioned is not something I have tried. The resource I use to upload documents directly to a file cabinet is:

/DocuWare/Platform/FileCabinets/{cab guid}/Documents

I POST to that resource including a request header "Content-Type" with the MIME type of the document. The POST data then is simply a binary stream of the document's file contents, as that handles text or binary data.

After the POST, the returned XML contains the new document ID. I then use that document ID to post the index data via a routine we have for that which uses resource:

/DocuWare/Platform/FileCabinets/{cab guid}/Documents/{doc guid}/Fields

and POSTs XML that looks like something like this:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="/DocuWare/Platform/Content/standard.xslt"?>
<DocumentIndexFields xmlns:s="http://dev.docuware.com/schema/public/services" xmlns="http://dev.docuware.com/schema/public/services/platform">
    <Field FieldName="TextField"><String>teststring</String></Field>
    <Field FieldName="DateField"><Date>2018-07-03</Date></Field>
    <Field FieldName="DateTimeField"><DateTime>2018-07-03T19:57:26Z</DateTime></Field>
</DocumentIndexFields>

This has been working fine for us (on-premise 6.11) since September 2017.

(Sorry, I could never get JSON to work, so stuck with XML in all of my REST API calls...)

Thanks,
Joe Kaufman
 

Josef! Thanks so much! That is great to know!

Nice job, DW engineers! Phil, you might want to change that "No" in your slides to at least "Untested, but probably works." (unless I am not understanding what "DocuWare Configuration:" means in the graphic...). Looks like Macs can do everything except pure desktop tools...

Thanks,

Joe Kaufman

Phil,

Yes, auditing is mentioned right in line with logging being turned off, I just wasn't sure if it was meant to act as the replacement and if it provided the same level of functionality (and perhaps more?).

If you could find out about a Mac being able to configure DocuWare, I would be very eager to know the answer. If all configuration has now been made unusable on a Mac-based browser, then that is a step back -- I can configure file cabinets and dialogs via a Mac on 6.11. And I had thought the whole point of getting more and more config options in the browser (away from DW Admin) was so that any client could do more and more. If that was not the goal, I am not sure why there was such a push to HTML5 (other than Silverlight being sub-optimal in a lot of ways...).

Thanks!

Joe Kaufman

Hey all,

From another thread I saw Phil's slide presentation about breaking changes in DW 7.0. It all looks fairly straightforward, but I did have two specific questions:

1. What does it mean that all logging agents have been removed? If I have logging set up to record all manual index changes, are you saying that will no longer work? Are these adequately replaced by audit reporting?

2. macOS: On the last pages, for "DocuWare web client" it says, "No Desktop Apps". But does the web client still work? You just can't do anything (like editing) that shells out to the OS? And under DocuWare configuration it says "No". If all configuration is done via a browser now, why wouldn't configuration work from a Mac? Are you saying you cannot even administer File Cabinets from a Mac?

Thanks,

Joe Kaufman

Craig,

No, I just went with Courier... The OCR fonts are a little to non-human for my taste, and the fields I listed were just as important for being human-readable as they were getting full-texted properly.

Thanks,

Joe Kaufman

Craig,

Another way to make sure the XML header files are all re-written would be to use the Platform API to "touch" each file, like simply updating an index field back with its original value. I believe this would rewrite the XML header files with the new structure. (Would also trigger any modification-based field changes, as it would change last mod. date.time.)

In that way, you could actually keep the old field, add a new field, do a very quick intra-table SQL Update statement to transfer data, delete the old field, and rename the new field back to the previous display name. Then run a quick Platform-based index change (or any workflow job that triggers a refresh of header information) to update XML header files.

The backing database field name will be different, but that probably won't matter to most people who only use the web interface to manipulate documents.

This method removes the requirement to do database backups and pull the data back from the restore. Though, if such things are second nature to you anyway, your way really is the best course of action while keeping the database field of the same name.

Thanks,

Joe Kaufman