Documentation Index

In order to upload a new document you can take two approaches as described as below.

Uploading a new file

Way 1: Upload one or more files within a single step.

You can pass some documents and index data within a single request. In such a case, the message body must be encoded using “multipart/form-data”.

Each part of the form data contains a file. In case the first part has a media type of “application/xml”, “application/json”, “text/xml”, “text/json” or “application/*+xml”, then this part is expected to contain the document’s meta data (fields) Document. There is also another a new lightweight contract which can be used to store InputDocument. The supported media types form InputDocument are application/vnd.docuware.platform.inputdocument+xml and application/vnd.docuware.platform.inputdocument+json.

Both contracts have different xml layout and restrictions

  • Examples of Document structure - no restrictions:
  • Examples of InputDocument structure - contains restrictions:
    • XML Example 1 - storing InputDocument without data files as database record. Dwocuware data records do not contain sections.
    • XML Example 2 - Using this contract for storing documents in Docuware there is one very important thing to remember: the number of section attributes under /InputDocument/Sections tag should match the number of the uploaded files . If they do not match the store operation will fail. The reason for that is that the each section can store its own metadata called ApplicationProperties.
      Each section tag in the xml /InputDocument/Sections/Section can be empty or filled with application properties.
      In this example one data files is required.
    • XML Example 3 - storing InputDocument with metadata for all sections. In this example two data files are required. If the data files are more or less than three the store will fail.

The content type of each part must match the content type of the uploaded file. Post the data to the link named “documents” of the target file cabinet. Note that the server expects you also must create a content disposition header for each part, which could look like

Content-Disposition: file; filename="filename.pdf"

Way 2: Upload a single file.

This works only if the file cabinet can handle new documents without index data. (This means, the content server has to invent meta data in order to pass the new document to the content server.) The content type header is used to get the content type of the file.

Post the data to the link named “documents” of the target file cabinet.

Example: If you use curl, you can upload a file like this:

curl --user admin:admin \
    -H "Content-Type: application/pdf" \
    --data-binary @document.pdf \
    http://your-machine/filecabinets/1/Documents

Way 3: Create a document step by step.

This step is the most flexible way of creating a document, but requires more server calls. First, you have to create a document containing only index data. To do this, post a Document structure to the link named “documents” of the target file cabinet. A document structure can look like in the following examples: XML Example 1, XML Example 2 or JSON Example.

In the returned Document structure use the link named “sections” and post a single file (specifiying the correct content type) or multiple files using the “multipart/form-data”. encoding.

Uploaded document without text shot processing

By default a text shot extraction process is started when a document is uploaded. If the client application provides the text shot after the document is stored, the processTextshot to false. The text shot can then be uploaded in a second step by posting a DocumentContent to the textShot link of the created Section.

A file cabinet should provide a link called unprocessedDocumentUpload which provided a link with the processTextshot set to false.