| Oracle® Fusion Middleware Autonomy Search Integration Sample Guide for Oracle WebLogic Portal 10g Release 3 (10.3.5) Part Number E15073-04 |
|
|
View PDF |
| Oracle® Fusion Middleware Autonomy Search Integration Sample Guide for Oracle WebLogic Portal 10g Release 3 (10.3.5) Part Number E15073-04 |
|
|
View PDF |
When you move to a production environment, you must configure Autonomy to match the portal environment you use.
This involves editing the configuration files for the search components you are using, deploying the Autonomy Service Dashboard, and configuring Autonomy fetches to search for information according to parameters you set.
The tasks covered in this chapter assume a typical Autonomy configuration running in an Oracle WebLogic Portal cluster. Consult the Autonomy documentation if you want to create a more complex configuration, such as running HTTPFetch on a separate server. Contact Autonomy Corporation to receive the Autonomy documentation.
Figure 7-1 provides an example of a typical production environment.
Figure 7-1 Example of Oracle WebLogic Portal Cluster Using Autonomy
This chapter discusses the following topics:
This section discusses how to install Autonomy on your target server.
Oracle WebLogic Portal makes available versions of Autonomy that are compatible with operating systems that Oracle WebLogic Portal also supports. However, you may run Autonomy on separate server that uses an operating system that Oracle WebLogic Portal does not support. For more information about the supported configurations for Autonomy, see the Autonomy documentation.
Note:
To obtain Autonomy files for a non-Oracle WebLogic Portal supported operating system, contact your Autonomy representative. For more information about configuring Autonomy on a non-WebLogic supported operating system, see Section 7.3.4, "Configuring the WLP Content Management Fetch When Using a Non-WebLogic Portal Supported Operating System."
This section discusses how to install Autonomy.
Note:
This procedure is only valid if you upgraded to Oracle WebLogic Portal 10.3.4. If you performed a clean installation of Oracle WebLogic Portal and obtained Autonomy from Autonomy Corporation, ignore this procedure and perform the installation instructions provided by Autonomy Corporation.
To install Autonomy:
Create a directory on your target server for the Autonomy components.
From your Oracle WebLogic Portal installation, navigate to the Autonomy distribution for your target operating system. For example, <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/<operatingsystem>
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
Copy the entire directory from your installation directory to the target directory on your target server.
You need to modify your Autonomy configuration to match your production environment and the parameters of your cluster. This includes modifying the respective configurations of the search tools you are using to account for security concerns and their network location.
You also need to configure the types of information you want to include in your searches.
Note:
For out-of-the-box implementation, you can set CONTENT_SEARCH_OPTION=full in the startWebLogic script and add the necessary properties to the repository.
Table 7-1 lists the location of the configuration files you need to modify.
Table 7-1 Autonomy Components and Their Respective Configuration Files
| Autonomy Component | Configuration File You Need to Modify |
|---|---|
|
DiSH Server |
//IDOLserver/DiSH/AutonomyDiSH.cfg |
|
IDOL Server |
//IDOLserver/IDOL/AutonomyIDOLServer.cfg |
|
Agent Stores for the IDOL Server |
//IDOLserver/IDOL/agentstore/agentstore.cfg |
|
HTTP Fetch |
//HTTPFetch/HTTPFetch.cfg |
|
File System Fetch |
//FileSystemFetch/FileSystemFetch.cfg |
This section includes the following topics:
The Intelligent Data Operating Layer (IDOL) server is responsible for indexing content as well as processing queries. For more information about the IDOL server, see the Autonomy IDOL Server documentation.
To configure the IDOL server for your production environment modify the AutonomyIDOLServer.cfg file. The file is located //autonomy/IDOLserver/IDOL/AutonomyIDOLServer.cfg.
To configure the Autonomy IDOL server:
Open the AutonomyIDOLServer.cfg file in a text editor.
In the [License] section, edit the LicenseServerACIPort to match the port on which DiSH is running, if you changed this port.
In the [Service] section, enter the port number by which service commands can be sent to DiSH. By default this is 20003. Note that this port must not be used by any other service.
In the [Server] section,
Edit the client list settings (IndexClients, AdminClients) for security as required.
Edit the IndexPort and Port (ACI) settings as needed.
In the [Paths] section, edit the Modules and TemplateDirectory to point to the location of these directories on the target system. These must be absolute paths.
Locate and edit all other directory or file path settings and adjust to point to the new location (for example, the [NT_V4] Library). These must be absolute paths.
In the [Database] section, create and remove Autonomy databases as required for your needs. Consult the Autonomy documentation for managing databases.
When finished, save your changes.
The Distributed Services Handler (DiSH) is used to manage Autonomy components. You can access DiSH functions through the Autonomy Service Dashboard or use Autonomy's ACI interface. For more information about the Autonomy DiSH, see the Autonomy DiSH documentation.
To configure DiSH, you can use a text editor to modify the autonomyDiSH.cfg file. The autonomyDiSH.cfg file is located in the //autonomy/IDOLserver/IDOL/AutonomyIDOLDiSH.cfg directory.
To configure Autonomy DiSH:
Open the autonomyDiSH.cfg file in a text editor.
In the [Service] section, edit the ServicePort setting if needed to avoid port conflicts.
In the [Server] section, edit the following:
Modify the AdminClients as required for establishing security as needed.
Modify the Port setting if needed to avoid port conflicts.
In the [Email] section, make modifications as defined by your company's SMTP setup.
In the [ChildServices] section, remove the setting for the BEACMRepoFetch service.
Remove the [BEACMRepoFetch] section.
In the [IDOLServer], [HTTPFetch] and [FileSystemFetch] sections, modify each path to ensure the executable files use the location on the target server. These paths must be absolute.
If you changed the Service Port or ACI port (or plan on doing so in the agentstore.cfg file), you need to adjust these settings to match.
When finished, save your changes.
Agents provide the facilities to find and monitor information from a configurable list of internet and intranet sites, news feeds, chat streams and internal repositories that you want to enable your portal users to search.
For more information about using agents, see the Autonomy IDOL Server Guide, published by Autonomy Corporation. Contact WebLogic Portal Customer Support to obtain a copy of this guide.
To configure the Agentstore for your cluster, edit the agentstore.cfg file. The file is located //IDOLserver/IDOL/agentstore/agentstore.cfg.
To configure agentstore:
Open the agentstore.cfg file in a text editor.
Modify [License], [Service] and [Server] settings as required for port conflicts and security.
Locate and replace all file and directory settings and adjust to point to the new location. The paths must be absolute.
In the [Paths] section, change the TemplateDirectory to point to the new location.
In the [Logging] section, change the LogDirectory and the LogArchiveDirectory to point to the new location.
In the [LanguageTypes] section, change the LanguageDirectory to point to the new location.
When finished, save your changes.
HTTP Fetch is responsible for crawling specified web sites and passes the content to the IDOLServer for indexing.You need configure this fetch and create HTTP fetch jobs that you need.
You do this by editing the HTTPFetch.cfg file. It is located //autonomy/HTTPFetch/HTTPFetch.cfg
To configure the HTTP Fetch:
Open the HTTPFetch.cfg in a text editor.
The [Service] section determines which machines are permitted to use and control the HTTPFetch service via the service port. Modify the port and client security control as required.
Note:
If you modify the port settings in this file, you need to update the HTTPFetch port settings in the AutonomyDiSH.cfg file.
The [Default] section contains the default settings that apply to all the jobs that you define in [Spider]section. If you changed the IndexPort in the AutonomyIDOLserver.cfg file, you need to modify the IndexPort setting to match.
When finished, save your changes.
Create HTTP Fetch jobs as required (to spider and index the web sites you want to search). For information about creating fetch jobs, see the Autonomy HTTPFetch documentation.
File System Fetch polls specified areas of a file system and, when content changes are found, imports the content and passes the content to the IDOLServer for indexing.
To control how files are imported from an internal location (for example, from a computer on your network), you need to configure File System Fetch and then create the fetch jobs you need.
The File System Fetch configuration file is located: //autonomy/FileSystemFetch/FileSystemFetch.cfg
Use a text editor to edit the FileSystemFetch.cfg file to match your production environment.
To configure File System Fetch:
Modify the [Server] and [Service] sections to change ports, if needed, and to control security. If you modify the port information in this file, you need to also update the settings related to File System Fetch in the AutonomyDiSH.cfg file.
In the [Default] section, modify the IndexPort to match the IndexPort set in AutonomyIDOLserver.cfg, if necessary.
When finished, save your changes.
Create File System Fetch jobs as required (to spider and index certain file system locations) for your needs. For information about creating fetch jobs, see the Autonomy File System Fetch documentation.
If deploying Oracle WebLogic Portal in a cluster environment, you need to ensure that each machine in your cluster can access the content indexed by File System Fetch, see Section 7.4, "Staging File System Fetch within a WebLogic Cluster."
To set up full-text search for your WLP repositories, you must configure the WLP Content Management fetch and then enable your WLP repositories for full-text search.
This section includes the following topics:
Section 7.3.2, "Configuring WLP Repositories for Full-Text Search"
Section 7.3.3, "Troubleshooting Full-Text Search for WLP Content Management Repository"
The content management fetch enables full-text search for WLP repositories. For each managed server in your Oracle WebLogic Portal cluster, you need to configure the content management fetch.
To configure the content management fetch:
Set an environment variable called CONTENT_SEARCH_OPTION and assign it a value of minimal.
Edit the BEACMRepoFetch.cfg file. This file configures the settings for the full-text search of repositories.
If you have upgraded to Oracle WebLogic Portal 10.3.4, the BEACMRepoFetch.cfg file is located in //operating_system_directory/internal/BEACMRepoFetch/BEACMRepoFetch.cfg.
If you have performed a clean installation of Oracle WebLogic Portal 10.3.4, you must create your own BEACMRepoFetch.cfg file—using the code in Example 7-1, "Example BEACMRepoFetch.cfg File"—then add the file to the //operating_system_directory/internal/BEACMepoFetch directory.
Perform the following edits to the BEACMRepoFetch.cfg file:
Modify [Server] and [Default] settings to change port numbers and client security as required.
Modify [Default] DreHost settings to point to the hostname or IP address of the server which is running the IDOLServer.
Modify [Default] IndexPort to match the IndexPort setting in the AutonomyIDOLServer.cfg file on the remote server.
When finished, save your changes.
Note:
Do not modify any other settings within this file.
Example 7-1 Example BEACMRepoFetch.cfg File
If you have performed a clean installation of Oracle WebLogic Portal, you should create a BEACMRepoFetch.cfg file—using the code in this example—then add the file to the //operating_system_directory/internal/BEACMepoFetch directory.
[Server] Port=9110 QueryClients=* AdminClients=* Threads=5 [Service] ServicePort=10084 ServiceControlClients=* ServiceStatusClients=* [Default] AciPort=9014 PollingAction=2 PollingMaxNumber=1000 DreHost=127.0.0.1 IndexPort=9001 PollingMethod=2 PollingPostAction=1 PollingPeriod=5 seconds AllowOriginalFileDeletion=true RemoveLogFileOnStart=on ImportIDXFilesAction=0 ImportTempDir=./importTemp ImportDefaultSlaveDirectory=../../filters ImportCharsetConvTablesDirectory=../../IDOLserver/IDOL/langfiles ImportReadChecking=true StableCheckMinWaitTime=2 IndexMode=cmUniqueName [Configuration] Number=2 0=BEACMRepoImport 1=BEACMRepoIDXImport [BEACMRepoImport] DirectoryPathCSVs=../../../internal/BEACMRepoTemp/binary DirectoryRecurse=on ImportStoreContent=on ImportSummary=on ImportBreaking=ON ImportBreakingMinParagraphWords=300 ImportBreakingMaxParagraphWords=500 ImportBreakingMinDocWords=500 ImportIntelligentTitleSummary=0 ImportExtractDateFrom=8 ImportExtractDateToField=DREDATE ImportExtractDateToFormat=EPOCHSECONDS [BEACMRepoIDXImport] DirectoryPathCSVs=../../../internal/BEACMRepoTemp/nonbinary DirectoryFileMatch=*.txt,*.idx DirectoryRecurse=on ImportMinLength=0 ImportMinLengthWords=0 ImportStoreContent=off ImportBifIncludeQuotes=true
After you have configured the Content Management Fetch, you need to enable your WLP repositories to take advantage of full-text search. This ensures your WLP repositories can locate the Autonomy IDOL server.
This section includes the following topics:
You need to define Autonomy sample integration properties for your WLP repositories within the Virtual Content Repository using the Portal Administration Console. These properties ensure that your WLP repositories can locate the Autonomy services.
Table 7-2 lists the Autonomy sample integration properties you need to configure.
Table 7-2 Autonomy Sample Integration Properties for WLP Repositories
| Property | Definition |
|---|---|
public.search.staging.area |
You need to set this property ONLY if you are using using a shared drive to index content. For more information, see Section 7.3.4, "Configuring the WLP Content Management Fetch When Using a Non-WebLogic Portal Supported Operating System." When setting this property, you must use the system default file delimiter or the data will not be properly indexed, as shown in the following examples:
Note: The paths with Note: This path is appended to the The default directory is:
|
|
public.search.engine.host |
This is the hostname for the machine on which the IDOL server resides. |
|
public.search.index.port |
This is the Autonomy index port. This value needs to match the |
|
public.search.query.port |
This is the port setting that is used by the IDOL server. This value needs to match the |
|
public.search.urlconnection.timeout |
When Autonomy database commands are issued using HTTP to the search indexing port and the search engine port, this time-out setting is specifies the HTTP connection time-out, in milliseconds. The default time-out is 180000 (180 seconds). |
Note:
After you make any changes to repository properties, Portal Administration Console users must log out and log back in to view the changes.
To add a property to a repository:
From the main menu of the Portal Administration Console, select Content > Content Management.
In the resource tree, click Repositories to view the Manage | Repositories tree.
In the Manage | Repositories resource tree, select the WLP Repository to which you want to add a property.
In the Properties section on the Summary tab, click Add Property.
In the Add Property dialog, enter the name and value for your property. Enter each property included in Table 7-2.
Click Save.
A summary of the new repository information is displayed in the Summary tab.
You need to ensure that all full-text functions are enabled for each WLP repository you want to enable to use full-text search.
Table 7-3 lists the advanced full-text search repository properties and how they are used.
Table 7-3 Required Settings for Full-Text Search
| Advanced Property | What it does: |
|---|---|
|
Search Enabled |
Enables users to search the repository. |
|
Search Indexing Enabled |
For a repository that supports full-text search, allows content to be indexed for portal search. This enables portal developers to include full-text content search or metadata search in any portlets that they develop. |
|
Full-Text Search Enabled |
For a repository that supports full-text search, enables users to search the repository using the full-text of the content within the repository. |
To edit full-text search repository properties:
Select Content > Content Management from the navigation menu at the top of the console.
Select Manage | Repositories.
In the resource tree, click the repository you want to modify to view its Summary tab.
In the Advanced section, click Advanced to view the Edit Advanced Properties for Repository dialog.
In the Edit Advanced Properties for Repository dialog, ensure that each property in Table 7-3 is enabled.
When finished making changes, click Save.
Your modifications display in the Advanced section of the Summary page.
Note:
After you disconnect a repository or make any changes to repository properties, Portal Administration Console users must log out and log back in to view the changes.
Use the following to check full-text search in your Autonomy configuration:
Verify that the Autonomy processes are running: AutonomyDiSH.exe, content.exe, and so on.
Verify that the data is indexed in Autonomy. To view all data in Autonomy, use http://localhost:9014/action=list.
Verify that the repository configuration settings are enabled:
cm_fireRepositoryEvents=true
search-is-enabled=true
search-indexing-is-enabled=true
fulltext-search-is-enabled=true
Verify that the ObjectClass is marked searchable.
Verify that ObjectClass property definitions are marked searchable.
Note:
For more information about ObjectClass, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
Verify that Autonomy is configured to start automatically. This option is in the domain/bin/startWebLogic script.
Scan the Autonomy log files (files ending in .log) for warnings and errors. These files are under <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/... directory.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
Verify that indexed data is being written to the FileSystemFetch directory specified via the public.search.staging.area repository configuration property. The default tree is under <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/internal/BEACMRepoTemp.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
If you run Autonomy on an operating system that is not also supported by Oracle WebLogic Portal, you must configure the content management search differently. You must create a shared file system that can be written to by Oracle WebLogic Portal and also accessed by Autonomy's server.
Figure 7-2 provides an example of a remote Autonomy installation using a shared file system.
Figure 7-2 Example Remote Autonomy Installation on a non-Oracle WebLogic Portal supported operating system
To configure WLP Content Management search:
Stop all Autonomy services.
Create a shared directory where shared_drive is the name of your shared drive.
On the Autonomy host, mount shared_drive.
For each managed server in your cluster, mount shared_drive.
Note:
Mount shared_drive with the same exact mapping on each managed server.
On each managed server, set the CONTENT_SEARCH_OPTION environment variable to none. This prevents Autonomy from starting the content management search.
Using the Oracle WebLogic Portal Administration Console, define a repository property called public.search.staging.area with a value of shared_drive. For more information on setting other Autonomy properties, see Section 7.4, "Staging File System Fetch within a WebLogic Cluster."
Use a text editor to modify the <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/<operating_system_directory>/internal/BEACMRepoFetch/BEACMRepoFetch.cfg file to point to the shared_drive you have created. This will ensure that the repository content gets indexed.
In the [BEACMImport] section, set the DirectoryPathCSVs variable to match the directory of your shared_drive/binary
In the [BEACMRepoIDXImport] section, set the DirectoryPathCSVs variable to match the location of your shared_drive/nonbinary.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
Restart Autonomy services. See the autonomy.sh or autonomy.cmd file in <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10 for a sample start script.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
When you deploy Oracle WebLogic Portal in a cluster environment, each machine in the cluster must be able to access information and content that is indexed by Autonomy fetches. For example, both WLP repositories and Autonomy's File System Fetch use file systems to store indexed content. You should configure each machine in your cluster to be able to access these file systems.
Note:
The Content Management Fetch does not require these steps, see Section 7.3, "Setting Up Content Management Search."
File System Fetch is used to index content that resides in a file system. When indexing, unless otherwise configured, the DREREFERENCE property is set to the complete path of the file. Therefore, with default queries, the link to return the actual content (file) will be the path to the file. Within a server cluster, each node in the cluster must have access to the file system on which the document resides.
Create a shared file system that is accessible by both the host machine upon which File System Fetch resides and also accessible by each node in your Oracle WebLogic Portal cluster. The mapping to the path where the files reside must be the same for each node in the cluster and the FileSystemFetch host.
Place the files to be imported/indexed into the shared drive as required.
Configure the FileSystemFetch job to import/index the contents of the shared drive using the mapping from the above step. For more information about configuring File System Fetch, see the Autonomy File System Fetch documentation.
Note:
When returning query results to the browser and displaying a link to access/download the file, pass the DREREFERENCE property (which will contain the fully qualified path/file name) through a servlet which will stream the file to the browser. For more information about indexing and queries, see the Autonomy IDOL Server Guide and the Autonomy JavaDoc, published by Autonomy Corporation. Contact WebLogic Portal Customer Support to obtain a copy of this guide.
You must configure the start script that is used to start Autonomy services on your server. You can either copy these to your target server and modify as required, based on your target directory or you can create similar scripts to meet your needs.
The Autonomy start script depends on two environment variables that should be set on your portal domain server: WL_ and CONTENT_SEARCH_OPTION.
WL_ must be set to the weblogic directory in your WebLogic installation
CONTENT_SEARCH_OPTION is used to indicate that level to which Autonomy will run.
full indicates to run the Autonomy DiSH engine and have it start all configured children
minimal indicates to only run the BEACMRepoFetch engine for use within the WLP repositories (this is the minimal production configuration when using WLP repositories)
none disables all Autonomy services.
You call this script with either start or stop as a parameter.
Review the autonomy.cmd/sh files that reside in the <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10 directory. Example 7-2 shows an example script.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
Modify as necessary. Be sure to map the Autonomy shared library directories and ensure that the AutonomyDiSH.exe is started.
Example 7-2 Example Autonomy Start Script
setlocal
if "%WL_%" == "" goto :NO_WL_
if "%1" == "" goto :USAGE
cd %WL_%\cm\thirdparty\autonomy-wlp10\win32
if "%1" == "start" (
echo Cleaning up license and uid files
rmdir /s /q HTTPFetch\license >nul 2>&1
rmdir /s /q IDOLserver\DiSH\license >nul 2>&1
rmdir /s /q IDOLserver\IDOL\content\license >nul 2>&1
rmdir /s /q IDOLserver\IDOL\agentstore\license >nul 2>&1
rmdir /s /q IDOLserver\IDOL\category\license >nul 2>&1
rmdir /s /q IDOLserver\IDOL\community\license >nul 2>&1
rmdir /s /q HTTPFetch\uid >nul 2>&1
rmdir /s /q internal\BEACMRepoFetch\uid >nul 2>&1
rmdir /s /q IDOLserver\DiSH\uid >nul 2>&1
rmdir /s /q IDOLserver\IDOL\uid >nul 2>&1
rmdir /s /q IDOLserver\IDOL\content\uid >nul 2>&1
rmdir /s /q IDOLserver\IDOL\agentstore\uid >nul 2>&1
rmdir /s /q IDOLserver\IDOL\category\uid >nul 2>&1
rmdir /s /q IDOLserver\IDOL\community\uid >nul 2>&1
rmdir /s /q FileSystemFetch\uid >nul 2>&1
echo Starting Autonomy with CONTENT_SEARCH_OPTION = %CONTENT_SEARCH_OPTION%
if "%CONTENT_SEARCH_OPTION%" == "full" (
if not exist IDOLserver\DiSH\AutonomyDiSH.exe (
@echo Unable to locate the Autonomy DiSH executable. Cannot start
the search engine.
goto :_the_end
)
cd IDOLserver\DiSH
%WL_%\server\bin\beaexecg.exe -hidewindow -command:"AutonomyDiSH.exe"
@echo Autonomy Distributed Search Handler engine started.
)
if "%CONTENT_SEARCH_OPTION%" == "minimal" (
if not exist internal\BEACMRepoFetch\BEACMRepoFetch.exe (
@echo Unable to locate the BEACMRepoFetch executable. Cannot start
the search engine.
goto :_the_end
)
cd internal\BEACMRepoFetch
%WL_%\server\bin\beaexecg.exe -hidewindow -command:"BEACMRepoFetch.exe"
@echo Autonomy BEACMRepoFetch engine started.
)
goto :_the_end
)
if "%1" == "stop" (
@REM taskkill depends on the path to WBem. Adding it here
@REM just to ensure that it exists on the system path.
set PATH=%SystemRoot%\System32\Wbem;%PATH%
if "%CONTENT_SEARCH_OPTION%" == "minimal" (
taskkill /F /T /IM BEACMRepoFetch* >nul
@echo Autonomy BEACMRepoFetch engine stopped.
)
if "%CONTENT_SEARCH_OPTION%" == "full" (
taskkill /F /T /IM AutonomyDiSH* >nul
@echo Autonomy processes stopped.
)
goto :_the_end
)
goto :USAGE
:NO_WL_
@echo The environment variable WL_ is not set. Cannot start Autonomy DiSH.
goto _the_end
:USAGE
@echo Usage: "autonomy.cmd [start|stop]"
pause
goto _the_end
:_the_end
endlocal
Note:
The path in the example above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
Run your script.
Verify that the services are running. On Windows, use the TaskManager application and view the Processes tab. If using Unix, use the ps command to view a list of services that are currently running. The following services should be running:
content.exe
category.exe
community.exe
agentstore.exe
AutonomyIDOLserver.exe,
AutonomyDiSH.exe
HTTPFetch.exe
FileSystemFetch.exe.
Inspect the log files for each of the services to verify that there were no errors such as port conflicts, license restrictions, and so on.
On a Windows 2000 host, content management full-text search requires the PsKill utility to be installed and available in the PATH. PsKill is required to properly shut down the full-text search processes when the domain is shut down. The PsKill utility can be found at: http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/PsKill.mspx.
After installing it, run the PsKill command once to accept the license. Make sure it exists on your system PATH, and then restart the server. The scripts can now properly shut down the full-text search processes.
The Autonomy Service Dashboard is a stand-alone front-end web application that allows administrators to manage all Autonomy modules and child services running locally or remotely.
The Dashboard communicates with one or more Autonomy Distributed Service Handler (DiSH) modules that provide the back-end process for monitoring and controlling all the Autonomy child services, such as fetches.
You deploy the Autonomy Service Dashboard as a portal application within your enterprise application using the Oracle WebLogic Server Console. Before deploying the dashboard, you must modify the configuration to match your production environment.
For complete documentation on how to use the Autonomy Service Dashboard, see the Autonomy DiSH documentation.
This section includes the following topics:
Before you deploy the Autonomy Service Dashboard, you need to edit the location configuration to match the new deployment location. The default location that is used is: <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/common/lib/.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
To prepare the Autonomy Service Dashboard for installation:
Copy the autonomyservicedashboard.cfg to its new location.
Edit the configuration information to match the new location by editing the web.xml file for the Autonomy Service Dashboard.
Create a temporary directory to use when completing your edits. For example, c:/temp/working
Copy the autonomyservicedashboard.war to your working directory.
Using a compression utility such as WinZip or JavaJar, unzip the autonomyservicedashboard.war.
Configure the WEB-INF/web.xml file by editing the <context-param> value to match the new location of the autonomyservicedashboard.war file. The default location is <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/common/lib.
Save the C:/working/META-INF/web.xml file.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
In the C:/temp/working directory, re-zip or re-compress the autonomyservicedashboard.war file. Overwrite the existing autonomyservicedashboard.war file with the new file of the same name that contains your modified web.xml file. Be sure to keep the files in their original directory structure, including the META-INF directory.
Copy the autonomyservicedashboard.war file you just created back to the location where you want to locate the Autonomy Service Dashboard. For example, <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10/common/lib/.
Note:
The path above is based on an upgraded Oracle WebLogic Portal domain. If you performed a clean installation of Oracle WebLogic Portal and installed Autonomy separately from Oracle WebLogic Portal, the path in your environment might differ from the path above. For this reason, you should change the path in your environment accordingly.
You should deploy the Autonomy Service Dashboard in the same domain as is used by your portal cluster. However it needs to be deployed as a stand-alone application rather than part of your portal application.
Note:
You can also deploy the Autonomy Service Dashboard into another web application container, such as Tomcat.
After you deploy the Autonomy Service Dashboard, you can use the default user name of admin and the default password of admin to log in.
To deploy the Autonomy Service Dashboard:
From the Oracle WebLogic Portal domain where you wish to deploy the Autonomy Service Dashboard, run the Oracle WebLogic Server Console.
In the Domain Structure section, select Deployments. This displays a list of the deployed components.
In the Change Center section, click Lock & Edit.
In the Summary of Deployments section, click Install.
Navigate to the location of the autonomyservicedashboard.war file and select it.
Click Next.
Select Install this deployment as an application and click Next.
Make changes as required
Click Finish.
In the Summary of Deployments section, review any messages or errors displayed.
In the Change Center section, click Activate Changes.
Verify that the autonomyservicedashboard deployment is prepared.
Mark the check box next to the autonomyservicedashboard deployment and click Start > Servicing all requests.
In the Start Application Assistant, click Yes.
Navigate to the Autonomy Service Dashboard to verify that is it deployed. The default URL is: http://localhost:7001/autonomyservicedashboard.
Using the default login (admin) and password (admin), log in to the Autonomy Service Dashboard.
Configure the Autonomy Service Dashboard to point to your DiSH implementation (use the same server and port settings that you used when you edited the autonomyDiSH.cfg file in Section 7.2.2, "Configuring the Autonomy DiSH."
For complete documentation on how to use the Autonomy Service Dashboard, see the Autonomy DiSH documentation.
Ensure that the IP address of the computer(s) running the Autonomy Service Dashboard are configured in the AdminClient settings of the services. For information on how to configure these settings, see the Autonomy IDOL Server documentation.
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|