Create a DocuWare Connector

A DocuWare connector enables you to ingest documents, their index-field metadata, and file contents from a DocuWare document management system into the Zeta Alpha platform. This guide shows you how to create and configure a DocuWare connector for your data ingestion workflows.

Info: This guide presents an example configuration for a DocuWare connector. The connector is tenant-agnostic — everything specific to your DocuWare instance (server, credentials, cabinets, and field names) lives in the content source configuration below.

Prerequisites

Before you begin, ensure you have:

1. Access to the Zeta Alpha Platform UI
2. A tenant created
3. An index created
4. A DocuWare Platform user whose credentials the connector can authenticate with (OAuth 2.0 password grant)
5. The file cabinet ID(s) you want to crawl (a GUID; see Step 4)

Note: DocuWare instances typically restrict access by IP. The Zeta Alpha crawler pods must egress from an address on your DocuWare allowlist, otherwise every request is rejected before authentication.

Step 1: Create the DocuWare Basic Configuration

To create a DocuWare connector, define a configuration file with the following basic fields:

• access_credentials.server_url: (string) Base URL of your DocuWare instance (e.g., "https://your-org.docuware.cloud"). The connector discovers the Identity Service and Platform endpoints from it.
• access_credentials.username: (string) DocuWare Platform user the connector authenticates as. Its permissions determine what the crawl can see.
• access_credentials.password: (string) Password for that user. Stored encrypted at rest.
• file_cabinet_ids: (array of strings) The file cabinet GUIDs to crawl. Use one content source per cabinet so access rights map cleanly to a single cabinet (see Step 3).
• download_content: (boolean, optional) Whether to download each document's file body for full-text indexing. Defaults to true. Set to false to ingest metadata only.
• title_inclusion_regex_patterns: (array of strings, optional) If set, only documents whose title matches at least one pattern are ingested.
• title_exclusion_regex_patterns: (array of strings, optional) Documents whose title matches any pattern are skipped. Applied after the inclusion filter.
• crawl_limit: (integer, optional) Stop after crawling this many documents. Useful for testing a configuration against a small sample before running a full crawl.

Example Configuration

{
    "name": "My DocuWare Connector",
    "description": "Accounting archive from DocuWare",
    "is_indexable": true,
    "connector": "docuware",
    "connector_configuration": {
        "docuware": {
            "access_credentials": {
                "server_url": "https://your-org.docuware.cloud",
                "username": "crawler@your-org.com",
                "password": "your-password"
            },
            "file_cabinet_ids": [
                "b1a2c3d4-0000-0000-0000-000000000000"
            ],
            "download_content": true,
            "title_exclusion_regex_patterns": [
                "^_"
            ]
        }
    }
}

Step 2: Add Field Mapping Configuration

When crawling DocuWare, the connector reads each document's index fields (the columns defined on the file cabinet) plus the generic system fields DocuWare exposes on every document. You map these onto your index fields with the field_mappings configuration.

The connector surfaces a small set of generic fields out of the box, regardless of mapping:

• title — DocuWare's configured document-name field for the cabinet
• last_updated_at — the document's last-modified timestamp (DWMODDATETIME)
• document_content_type — the file's content type
• document_content_size_bytes — the file size (DWDOCSIZE)
• uri / uri_hash — the stable document identity

Your cabinet's business fields (invoice number, document type, account, etc.) are not indexed unless you map them. Any crawled field that is neither one of the generic fields above nor listed in field_mappings is dropped. Because DocuWare cabinet fields are defined per instance, the field names are specific to your cabinet — inspect a sample document to see the exact content_source_field_name values to map.

Example Field Mappings

{
    ...
    "connector_configuration": {
        "docuware": {
            ...
            "field_mappings": [
                {
                    "content_source_field_name": "title",
                    "index_field_name": "DCMI.title"
                },
                {
                    "content_source_field_name": "last_updated_at",
                    "index_field_name": "DCMI.modified"
                },
                {
                    "content_source_field_name": "ART_DES_DOKUMENTS",
                    "index_field_name": "DCMI.type"
                },
                {
                    "content_source_field_name": "SKIT_DOKUMENTNUMMER",
                    "index_field_name": "DCMI.identifier"
                }
            ],
            ...
        }
    }
}

Step 3: Configure Access Rights

Access rights control who can view the ingested documents. You define them here, on the content source — the connector does not read them from DocuWare. It stamps the access rights you configure onto every document it ingests, which mirrors DocuWare's security at the cabinet level; DocuWare's document-level rules (Index Value Profiles) are not reflected. Use one content source per cabinet so each cabinet's audience stays unambiguous:

• allow_access_rights: (array of objects, optional) Users with any of these access rights can access the documents. If not passed, no user can retrieve them.
  • name: (string) The name of the access right (e.g., user UUID or "public")
  • type: (string, optional) The type of access right (e.g., "user_uuid")
  • content_source_id: (string, optional) If the right is scoped to a particular content source
• deny_access_rights: (array of objects, optional) Users with these access rights cannot access the documents.

Note: Access rights are stamped at crawl time, so changing allow_access_rights / deny_access_rights on an existing content source applies only to documents crawled afterwards. To update the access rights of documents already in the index, run a full sync to re-stamp them — a delta sync only revisits documents that changed in DocuWare.

Example Configuration with Access Rights

{
    ...
    "connector_configuration": {
        "docuware": {
            ...
            "allow_access_rights": [
                {
                    "name": "public"
                }
            ],
            ...
        }
    }
}

Step 4: Find Your File Cabinet IDs

The connector addresses cabinets by GUID, not by display name. To find a cabinet's ID:

1. In the DocuWare Platform REST API, list cabinets via GET /DocuWare/Platform/FileCabinets and read the Id of each FileCabinet.
2. Copy the GUID for each cabinet you want to crawl into file_cabinet_ids.

Use a separate content source per cabinet rather than listing several cabinets in one source, so access rights and field mappings stay scoped to a single cabinet's schema.

Step 5: Create the DocuWare Content Source

To create your DocuWare connector in the Zeta Alpha Platform UI:

1. Navigate to your tenant and click View next to your target index
2. Click View under Content Sources for the index
3. Click Create Content Source
4. Paste your JSON configuration
5. Click Submit

Crawling Behavior

The connector supports both full and incremental (delta) synchronization:

• Full sync enumerates every document in each cabinet and downloads the selected bodies. It also drives deletion reconciliation: documents no longer present are removed from the index.
• Delta sync picks up documents added or modified since the last run (using the DWMODDATETIME last-modified date), and reads deletions from DocuWare's organization-wide trash bin so removed documents are cleared from the index between full syncs.

Note: Delta deletion reconciliation relies on the trash bin, which DocuWare retains for a limited window (30 days by default). Schedule a recurring full sync alongside delta so that documents deleted longer ago than the trash retention window are still reconciled. Reading deletions also requires the crawl user to have permission to view the trash bin.