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 points to the same OpenText Content Server installation as the configured main/REST API base URL. Ensuring and verifying that 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 points to the same OpenText Content Server installation as the other configured API base URLs. Ensuring and verifying that 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).

For technical reasons, the connector user’s language in OpenText Content Server must be set to “English ( United States )”. This is done as follows:

  1. Log into the OpenText Content Server UI as the connector user.

  2. Go to My account → Settings → General.
    The URL in your browser’s address bar should now end in ?func=personal.settings.

  3. Set the option Language: to English ( United States ).

  4. Click Update.

(If another language had been set before or by default, the naming of the mentioned UI elements differs accordingly.)

Regardless of where the user was created, setting the required permissions and privileges is also 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

Preparations for Change Processing

The Automated Change Processing of the connector supports two different approaches for retrieving recent changes in OpenText Content Server:

  • the LiveReport approach, and

  • the Search approach.

The LiveReport approach employs a LiveReport that queries the audit table in the OpenText Content Server database. This method is able to retrieve any type of change event which is captured by auditing. It requires the setup of a dedicated LiveReport.

The Search approach makes use of the internal OpenText Content Server search. This method does not detect all changes. Especially, it cannot retrieve deletions or permission changes that prevent the connector from accessing a node.

If you want to apply change processing, you have to prepare OpenText Content Server so that one of these approaches can be used.

LiveReport Approach

If you want to use a LiveReport for change processing, you have to create a dedicated LiveReport for this task. If an administrator is available to do this, one option is to import the LiveReport. To do so, execute the following steps:

  1. Download the appropriate LiveReport export:

    • If your OpenText Content Server installation uses a Microsoft SQL Server database, use this export.

    • If your OpenText Content Server installation uses an Oracle database, use this export.

  2. Navigate to Admin → Content Server Administration → LiveReports Administration → Import LiveReports.

  3. Under Create In, select the location where the new LiveReport shall be imported to.

  4. Under File, select the downloaded LiveReport export.

  5. Click Add.

  6. Navigate to the location where the new LiveReport was imported to.

  7. Copy the node ID/objId of the new LiveReport; this will be needed for the connector configuration.

  8. Follow the instructions about permissions etc. below.

If importing the LiveReport is not a viable option, you can create the LiveReport manually, To do so, execute the following steps:

  1. Navigate to the location where the new LiveReport shall be created.

  2. Click the Add Item menu and select LiveReport.

  3. Enter a name and click Add. Now a new page for configuring the LiveReport opens.

  4. Set Title to Raytion Connector Change Processing LiveReport or something similarly descriptive.

  5. For Database Connection, select one that gives the LiveReport access to the audit table. By default, Use the global LiveReports database connection works.

  6. For Inputs, add the following inputs (using the + icon):

    • #: 1, Type: Date, Prompt: Earliest Change, URL Parameter: earliest

    • #: 2, Type: SQLList, Prompt: Node (Sub)Types, URL Parameter: subtypes

    • #: 3, Type: SQLList, Prompt: Start Nodes, URL Parameter: startnodes

  7. For SQL, insert an appropriate query (via copy+paste):

    • If your OpenText Content Server installation uses a Microsoft SQL Server database, use this query.

    • If your OpenText Content Server installation uses an Oracle database, use this query.

    The change events that shall be retrieved are specified in the query, in the list preceded by AuditStr IN. If this list contains change events which are not relevant for your search scenario, you can remove these events from the query.

    Other modifications to the query may or may not be supported.

  8. Deselect Use Cursor Fetch Mode.

  9. Select Use Transaction Mode.

  10. Select Show Verbose Database Error Messages.

  11. For Parameters, add the following parameters (using the + icon):

    • #: %1, Type: User Input, Options: Input # 1

    • #: %2, Type: User Input, Options: Input # 2

    • #: %3, Type: Filter Permissions

    • #: %4, Type: UserID

    • #: %5, Type: User Input, Options: Input # 3

  12. Set Report Format to Auto LiveReport.

  13. Leave the other options unchanged.

  14. Click Save and Exit.

otcs livereport config

Grant the technical connector user (see Section Technical User above) "See" + "See Contents" permissions to this LiveReport. This is necessary so that the connector can invoke a LiveReport run and get its results.

Be aware that every other user with "See Contents" permission can use the LiveReport to read the audit table, so make sure the permissions are set appropriately.

The node ID of the LiveReport has to be provided in the connector configuration.

Make sure that all events which you want to be handled by change processing are covered by the OpenText Content Server audit. You can check and adapt the audited events via Admin → Content Server Administration → Core System - Feature Configuration → Event Auditing → Set Auditing Interests.

Search Approach

The search approach detects recent changes by using the OpenText Content Server search. More concretely, it searches 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 Admin → 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 Admin → 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.