OpenText Content Server Setup

Before the connector can traverse nodes from OpenText Content Server, a few things need to be done in OpenText Content Server.

Content Web Services

To fetch all the metadata needed, especially for secure search, the connector needs to access the Content Web Services of OpenText Content Server to traverse. These SOAP APIs are delivered with a standard installation of OpenText Content Server, but not necessarily installed.

To check whether the Content Web Services are installed for the OpenText Content Server to traverse, there are two possibilities besides asking the administrators responsible for OpenText Content Server:

  • Check the IIS or Tomcat configuration for the corresponding directory/WAR, usually called cws or cws.war respectively.

  • Try to access a part of the Content Web Services.

    • For IIS installations, take the base URL of OpenText Content Server, replace the last two parts with /cws/Authentication.svc?wsdl (so that, e.g., https://otcs.server.com/OTCS/cs.exe becomes https://otcs.server.com/cws/Authentication.svc?wsdl), and see if that returns an XML document (more specifically, a valid WSDL file).

    • For Tomcat installations, take the base URL of OpenText Content Server, replace the last two parts with /cws/services/Authentication?wsdl (so that, e.g., https://otcs.server.com/OTCS/cs becomes https://otcs.server.com/cws/services/Authentication?wsdl), and see if that returns an XML document (more specifically, a valid WSDL file).

To install the Content Web Services, follow the installation instructions provided by OpenText for the web/application server used. The connector fully supports the Content Web Services running on a different server or host than the main OpenText Content Server base URL, e.g., if the main web frontend is using the Apache httpd web server (which does not really support hosting the Content Web Services directly).

The connector does not have any checks to ensure that the configured Content Web Services base URL configured points to the same OpenText Content Server installation as the configured main/REST API base URL. Ensuring and verifying this is the case is the responsibility of the administrators for the connector and for the OpenText Content Server installation.

Records Management Security Management SOAP API

If Security Clearance (part of Records Management) is used in the OpenText Content Server to traverse, the connector needs to access an additional SOAP API that is independent of the Content Web Services. This additional SOAP API is also delivered with a standard installation of OpenText Content Server, but not necessarily installed.

To check that the Records Management Security Management SOAP API is installed, the same procedures as for Content Web Services can be used, with cs-services-rmsecmanagement and /cs-services-rmsecmanagement/services/ RMSecManagement.svc?wsdl or cs-services-rmsecmanagement.war and /cs-services-rmsecmanagement/services/RMSecManagement?wsdl being the relevant name/URL part.

To install the Records Management Security Management SOAP API, the same instructions as for the Content Web Services should be followed, just with the names and URL parts adjusted as for the presence check.[1]

As with the Content Web Services, the connector does not have any checks to ensure that the configured Records Management Security Management SOAP API URL configured point to the same OpenText Content Server installation as the other configured API base URLs. Ensuring and verifying this is the case is the responsibility of the administrators for the connector and for the OpenText Content Server installation.

Technical User

To access the data in OpenText Content Server, the connector needs to authenticate itself with OpenText Content Server. To do so, a user is needed, and while it is possible to use any user with the right permissions, it is highly recommended to create a technical user specifically for the connector.

Depending on how the OpenText Directory Services are set up, creating the user is done in

  • OpenText Directory Services itself, through OTDS Admin → Partitions → the appropriate internal partition → View Members → Add → New User, or

  • the LDAP server/Active Directory connected to OpenText Directory Services (see the documentation of the third-party software on how to create users there).

Regardless of where the user was created, setting the required permissions and privileges is done in OpenText Content Server.

Needed Permissions and Privileges

At a minimum, the technical user needs the privileges “Log-in enabled” and “Public Access enabled” in OpenText Content Server, which in turn means the technical user must not be disabled/deactivated in the underlying user store. Additionally, the user needs access to the properties, the content, and the permissions of all the nodes the connector should traverse.

The shortest way, at least in terms of effort spent in the OpenText Content Server, to give the user permissions to all documents is to give the user the privilege “System administration rights” in OpenText Content Server. This method is particularly well-suited for proofs of concept and similar tests (assuming exception from relevant security policies can be obtained). If needed for auditing or firewalling purposes, a complete list of accessed API endpoints, SOAP API methods, etc. is available on request.

When giving the technical user administrator rights is not feasible, the technical user needs the appropriate permissions to see the contents and all permissions on all documents to be traversed. The minimum permission required depends on the Access Control settings in OpenText Content Server and the node type(s) to be traversed.

If the Access Control settings allow access to the permissions with the “See Contents” permission, this permission is sufficient for the most common node types. Otherwise, the “Edit Permissions” is required. Some node types always require “Edit Permissions”, including:

  • Active Editing Sessions

  • Appearance Workspace Folder

  • Asset Folder

  • Batch Labels

  • Blog

  • Blog Entry

  • Circulation

  • Classifications

  • Classification Tree

  • Classification

  • Column

  • FAQ

  • FAQ Entry

  • Facet

  • Facet Tree

  • Failed Editing Sessions

  • Fixed System Column

  • Forum

  • Forum Topics & Replies

  • Locators

  • Milestone

  • News

  • O365 Office Online Volume

  • Perspective Asset Folder

  • Physical Item Type

  • Physical Item Types

  • Physical Objects Administration

  • Physical Objects Workspace

  • Project

  • Prospector Snapshot

  • Provenance

  • Query File

  • RM Classification

  • Reply

  • Reports

  • Search Query

  • Shortcut

  • Storage Management

  • Task Group

  • Task

  • Topic

  • Transfers

  • Transport Item

  • Transport Package Folder

  • Transport Package

  • URL

OpenText Content Server Search and Modified Date Triggers

The automated change processing of the connector detects live updates by searching for nodes with changed Modified Dates. For this to work, the internal search of the traversed OpenText Content Server needs to be running and have a data source (like the default Enterprise Data Source) that contains all nodes to be traversed. To check the status of the internal search, go to Content Server Administration → Search Administration → Open the System Object Volume and Content Server Administration → Search Administration → View System Object Status.

Additionally, the OpenText Content Server allows administrators to configure whether certain changes to nodes will also change the Modified Date. It is recommended to activate all Modified Date Triggers, but especially the one for Permissions changes, to ensure those changes are timely mirrored in the ACLs of the items in the search engine. To check or modify these settings, go to Content Server Administration → Core System - Feature Configuration → Modified Date Triggers.

1. There are dedicated instructions to install this SOAP API provided by OpenText, but those are outdated and only applicable for LiveLink Content Server up to version 9.x.