Troubleshooting / FAQ
Performance of the Source System Part of the Connector
There are many factors affecting the performance of content traversals on the source system side. Apart from the usual factors (especially the machine resources available to the connector, OpenText Content Server, the involved databases, etc. and the network connection to OpenText Content Server), several configuration options for the source system part of the connector directly affect the performance of the content traversals. They are listed below, structured according to the configuration groups in the connector UI.
An additional factor for the performance of content traversal is the order in which traversals are started. Both principal and content traversals need some information about principals/members, and for content traversals, this information is cached. The principal traversal does not use this cache, fetching the information directly from OpenText Content Server, but it does fill the cache. So if the configured cache expiration duration is longer than the duration of a principal traversal, starting content traversals directly after a principal traversal has finished improves the performance of the content traversal.
OpenText Content Server Connection Settings
As mentioned above, some data about principals/members are cached during content
traversals, and the time to live/cache expiration duration configured in this
section affects the performance as expected: a higher duration improves
performance at the cost of potentially putting stale data into the metadata of
items, especially the ACLs. So this value should primarily be set as required by
data freshness and only secondarily by performance needs. The data freshness is
not affected by how often the values are read from the cache, those reads do not
reset any timer. Due to the limited amount of data stored, the caches do not
have a size limit.
The configuration options HTTP timeout and maximum number of retries affect
performance in case of errors that cause the API call to be retried. Therefore,
these options should not be relevant for performance during normal operation and
should be set as required for the handling of transient errors.
The maximum REST API calls per second configuration option affects performance
of content traversals as expected (principal traversals do not use the REST
API), but only up to a certain point. This is because this option only
configures an upper limit on the rate of calls. All API calls are made
synchronously, and the connector only makes at most one API call per traversal
thread. If the rate of number of traversal threads divided by the average time
needed for an API call is lower than the configured API call rate limit, the
connector will not reach the limit and raising it will not improve performance.
OpenText Content Server Item Settings
Due to the OpenText Content Server APIs, each of the data activated/not set to zero in this section requires a separate call to OpenText Content Server per node. So the connector will make seven (7) extra calls per node when all options are activated, and with the exception of the call to fetch content, all calls will take about the same amount of time. So if some of the metadata are not needed, the corresponding option should be switched off to improve traversal performance.
The connector also honors the maximum content size limit as soon as possible.
That is, if the metadata of a node contain an accurate size of the content, and
that size is bigger than the configured limit, the connector will suppress
fetching the content, as it would be filtered out anyway. If the size is not
known in advance, the content is discarded directly after fetching about
configured limit + 1 bytes. The only exception to the preceding statement
happens when a limit of zero (0) bytes is configured. In this special case, the
connector does not rely on the content size from the metadata and always
suppresses fetching the content.
OpenText Content Server Debugging Settings
The JSON dumped with this configuration option is written to disk synchronously, directly affecting the performance of content traversals. So this option should be left unconfigured unless and until the output is actually needed, and the value should be returned to the default as soon as possible.
OpenText Content Server Content Traversal Settings
Apart from the expected effect (more content to traverse means more time needed to traverse the content), the root nodes configured in this section should also not overlap, as the connector may not be able to deduplicate the traversed nodes/items until they already have been fetched from OpenText Content Server and processed at least partially in the connector. This is especially true if multiple connector instances traverse the same OpenText Content Server and push the items to the same target system.
Delayed or Missing Updates with Automated Change Processing
While Automated Change Processing does get certain changes into the search engine faster than scheduled incremental traversals, it still is not instantaneous and cannot handle certain types of changes at all, due to limitations of OpenText Content Server. Possible causes for delayed or missing updates include:
- Delay in the internal search indexing
-
The changed Modified Date needs to be picked up and indexed by the search internal to OpenText Content Server before it is available to the Automated Change Processing. Depending on the configuration and resources available, this takes some time.
- Unchanged Modified Date
-
Certain changes, like modifying the Records Management metadata of nodes, do not change the Modified Date of that node. To update the items corresponding to the nodes thusly changed, an incremental traversal is necessary.
- Deletions
-
The OpenText Content Server API used by the Automated Change Processing only returns nodes that exist. To delete the items corresponding to deleted nodes, an incremental traversal is necessary.
External Group and Group Membership Limits in Microsoft Search
Raytion connectors reflect the custom security model of the source system in Microsoft Search. In order to do so, the connector creates external groups, which correspond to the groups from the source system.
The connector also links Microsoft Search users, i.e., users in Azure AD, to the correct external groups. This way, early-binding security trimming works.
External Groups Limit
However, there is a limit regarding the synchronization of external groups: All Microsoft Graph Connectors within a tenant can create up to 100,000 external groups. If this threshold is reached in your tenant, please contact the Microsoft support and check if they can extend the limit.