NetDocuments target connector

The NetDocuments target connector uses the NetDocuments REST API. NetDocuments is a cloud-based DMS and does not have a specific version number. It supports both v1 and v2 REST API endpoints, but only the v1 endpoint is used by the connector.

Features

• Creation of folders with their metadata
• Creation of documents with their versions and metadata
• Setting permissions (ACLs)

note

Only metadata of the current version of an object will be migrated.

note

In order to improve the performance of the connector, the second subflow that creates the RECORD objects uses a scheduling mechanism instead of the typical recursion used in Xillio connectors. Instead of waiting till a maximum of 1000 objects have been created before recursing, it sends not yet scheduled objects every 5 seconds into the flow while keeping the 1000 limit into account. The added benefit here is that an iteration of a recursion does not block on a large file.

Requirements

For the connector to work, a REST API application will have to be registered within NetDocuments. This has to be done by an administrator in the NetDocuments portal.

Furthermore, an application service account that is linked to the previously registered application will have to be created. This can be done in the repository's admin console by navigating to the service accounts inside users and groups.

Lastly, the application service account needs to be added as an administrator to the cabinet(s) in the cabinet administration page in the admin console.

Settings

mongoConnection

The Mongo connection string including the database name to connect to.

clientID

The client ID of the NetDocuments application.

clientSecret

The client secret of the NetDocuments application.

repositoryID

The ID of the repository where the content is to be created. This identifier can be found by navigating to the NetDocuments admin console and retrieving the value from the URL after <baseUrl>/neWeb2/administration.

Example: CA-AB1234CD

baseUrl

The base URL to the NetDocuments REST API.

Example: https://api.eu.netdocuments.com

The URL is determined by the region the NetDocuments repository is in.

Region	Front-end URL	REST API URL
United States	https://vault.netvoyage.com	https://api.vault.netvoyage.com
United Kingdom	https://eu.netdocuments.com	https://api.eu.netdocuments.com
Australia	https://au.netdocuments.com	https://api.au.netdocuments.com
Germany	https://de.netdocuments.com	https://api.de.netdocuments.com
Australia	https://can.netdocuments.com	https://api.can.netdocuments.com

Model

The NetDocuments metadata is populated from the Content Store. Since NetDocuments does not have custom content types, RECORD objects will be created as documents and CONTAINER objects will be created as folders. Below we describe the schemas with an explanation of how the fields are translated to the NetDocuments attributes.

RECORD and CONTAINER

{
  "migration" : {
    // REQUIRED | BOOLEAN | DESCRIPTION: Only objects where this value is set to 'true' will be created in NetDocuments
    "migrate" : true
  },
  "target" : {
    // All the Content Store required fields + optional ones if required. Fields will be mapped to their NetDocuments counter part automatically.
    // Please note that it is not possible to set the creation and modification fields with the exception of the last modified field for documents.
    "properties" : {
      // Any additional properties, using their technical identifiers defined in NetDocuments
    }
  }
}

In order to find out about the technical names for the metadata fields, the NetDocuments source connector can be used. The fields are stored with content type: Field and the technical name can be found in source.name.systemName. For lookup fields, the allowed lookup values are also stored by the source connector with content type: FieldValue. The field value to be used is stored in source.name.systemName.

ACL

{
  "migration" : {
    // REQUIRED | BOOLEAN | DESCRIPTION: Only objects where this value is set to 'true' will be created in NetDocuments
    "migrate" : true
  },
  "target" : {
    "permissions" : [
      // REQUIRED | ARRAY | DESCRIPTION: the available permissions are: administer,cabDefault,edit,noAccess,share,view
    ],
    "principals" : [
      // REQUIRED | ARRAY | DESCRIPTION: an array of principal objects. The systemName should reference an NetDocuments identifier (User or Group GUID). These are stored by the NetDocuments source connector as `PRINCIPAL` objects.
    ]
  }
}

note

If an object has multiple ACL entries for the same principal(s), only the permissions from the first one processed will take effect. Furthermore, when setting permissions always assign an ACL with a group containing the application service account with VESA (view,edit,share and administer) permissions. If this is omitted the connector will not be able to make changes to the object anymore.