Library functionality

The Integration Service is fitted with library functionality which is shared by several services. The document management services, in particular, ensure consistency by the following mechanisms:

  • check attribute types

    This library functionality can be involved in any operation which manipulates a revision. Attribute type checks are performed by the Integration Service whenever attribute values are assigned to attribute keys in a revision definition.

  • check document types

    This library functionality is carried out by all operations that reference a document type. The association between a document and a document type is either established implicitly using the default document type (“documentSetDefaultType”) or explicitly by setting the corresponding input parameter of the service.

  • check content properties

    This library functionality is a common functionality carried out by all operations that create or update the content properties of a content object. It is carried out sequentially for each content property.

  • prepare binary files

    This library functionality of the Integration Service can be involved in any operation which manipulates a revision. Binary file preparation will be performed whenever binary SOAP attachments are supplied as part of the content. For details see the section beneath.

Prepare binary files

For each content object attached in a revision, during document creation the following checks and operations are performed:

  • Check that each key in the content property set is of type NMTOKEN has at least 1 and at most 255 characters and check that each value in the content property set has at most 2000 characters.

  • Check that no optional XML attributes creationTime or modificationTime are present (on the binaryObject element). These attributes are to be assigned later, when the Integration Service assigns the current time to the fields creationTime and modificationTime (of the binary objects) before making the revision persistent, so both fields are the same at the time of document creation.

  • Compute the mime type for each binary object.

  • If an optional attribute with a mime type is provided, conserve the value.

  • Otherwise, if the filename with an extension is provided, derive the value from the file extension via an internally defined mapping table.

  • Otherwise, set to default “application/octet-stream”.

  • The Integration Service generates the IDs for the document and revision.

  • The Integration Service creates a new and empty document. The revision given as an argument becomes the first revision of the document.

  • The Integration Service streams the revision’s metadata and binary objects to the repository archive for permanent storage. This way, the Integration Service may turn the revision into a form suitable for persistent storage.

  • If Single Instance archiving is enabled, which is an option that is in particular useful for storing e-mail attachments, see [SM Mail], the Integration Service checks whether the content object is already stored in the archive by a hash value comparison. If the content object already exists, it is not stored redundantly but rather an internal reference to the existing object is created.

    Database partitioning is an optional feature that is supported by extensions. Single instancing only works within one database partition. One object cannot be shared across multiple partitions.

  • If an incoming document creation request provides the following parameters, these are used for integrity checks:

    • file size

    • hashDigest and hashAlgorithm (must both be provided, otherwise this raises an error)

These given values are not stored in the archive. However, independent from this mechanism, in an ImageMaster archive configuration a hash algorithm is specified and this one is used to determine a hash value, which is stored in the archive together with the calculated file size.

The table below lists the supported hash algorithms. Items marked as not allowed cannot be used with the current ImageMaster release but are maintained for backward compatibility.

Algorithm

Encouraged

Allowed

Notes

MD2

no

no

Disallowed since ImageMaster 9.5.1 release. Insecure and slow on modern hardware.

MD5

no

no

Disallowed since ImageMaster 9.5.1 release. Insecure.

SHA-1

no

yes

Known weaknesses. Most browsers intend to end support by 2017. Will be disallowed in some future releases.

SHA-224

yes

yes

 

SHA-256

yes

yes

 

SHA-384

yes

yes

 

SHA-512

yes

yes

 

SHA-512/224

yes

yes

 

SHA-512/256

yes

yes

 

SHA3-224

yes

yes

 

SHA3-256

yes

yes

 

SHA3-384

yes

yes

 

SHA3-512

yes

yes

 

Table 351: Supported hash algorithms