Basic Knowledge Discovery Text Setups
There are several ways to set up a simple Knowledge Discovery Text system, depending on the size of your installation, and the features that you want to use.
Component Setup
The most flexible and versatile approach is to install the individual components that you need, and configure each component separately. OpenText recommends that you use this component-based approach in production environments. The component setup allows you to:
- use only the components that you need.
- configure each component separately, which can be useful for optimization and tuning, as well as troubleshooting.
- set the components up on separate hardware or with dedicated resources to enhance the performance for different operations, and to allow you to scale resources for different components in a more flexible way.
- simplify component management and maintenance. In particular, it is easier to start, stop, and reinitialize individual components.
- design highly scalable, fault tolerant systems.
The following diagram shows a simple component-based Knowledge Discovery setup, with a Content index, View, Community, and Category, and a single Agentstore component supporting both Community and Category.
Each component has its own configuration file. For example, you configure the content.exe
in the content.cfg
file, you configure the category.exe
in the category.cfg
and so on.
NOTE: There are also other dependencies between components, which you must configure in the component configuration files. For example, the Community and Category configuration files must contain the host and port details for the Agentstore component.
Proxy
The Proxy component can be used to provide a single endpoint for actions that are then distributed to other servers (the Content, Category, Community, Agentstore, and View components). This option is suitable only for training and test environments.
This architecture does not include Query Manipulation Server (QMS), or Media Server. By default, it does not include distribution components, but you can add these if required.
The following diagram shows the architecture when using Proxy.
In this architecture, Proxy acts as a single point of contact for all your requests. It forwards all requests to the appropriate component. For example, it sends a Query
action or indexing request to the Content component, and it sends a UserRead
action to the Community component.
The Proxy configuration file must contain the host IP address and ACI port for each of the components that you want it to forward requests to. It dynamically configures other ports (such as the index port).
For most production environments, this architecture is too small and restrictive. For example:
-
it has limited scalability and no failover.
-
it is difficult to add additional Content components to increase the size of the index.
-
you cannot include QMS.
When you want to set up a full Knowledge Discovery system, you usually move to a component-based setup, where you configure and optimize components separately, and often on different hardware.