Oracle® Beehive Deployment Guide Release 1 (1.4) Part Number E13795-02 |
|
|
View PDF |
This module provides overviews of the various Oracle and third-party components supported by Oracle Beehive and the related considerations for deploying them with the system.
This module contains the following topics:
Deploying Oracle Beehive with Oracle Real Application Clusters (Oracle RAC)
Deploying Oracle Beehive with Oracle Universal Records Management (Oracle URM)
Deploying Oracle Beehive with an External Oracle BPEL Process Manager Instance
Deploying Oracle Beehive with Oracle Secure Enterprise Search 10g
Deploying Oracle Beehive with Microsoft Exchange Server 2003
Oracle Beehive stores all of its data—collaborative, configuration, and audit data, as well as its log archives—in Oracle Database. Every Oracle Beehive deployment must have at least one Oracle Database instance installed and available prior to installing Oracle Beehive. Oracle Beehive supports Oracle Database 10g Release 2 (10.2.0.3) Patch Set 2 and Oracle Database 11g Release 1 (11.1.0.6).
Prior to installing Oracle Beehive and deploying it with Oracle Database, there are several required steps that you must take and a few recommended configuration steps you should consider. These steps will prepare your database environment for certain Oracle Beehive installation prerequisites and other requirements, and include:
Installing any patches required for your version of Oracle Database.
Setting the minimum values for certain Oracle Database initialization parameters, including java_pool_size
, job_queue_processes
, and processes
.
Enabling the system's archiving capabilities.
If you plan to use a database that uses raw storage, customizing Oracle Beehive's custom tablespaces script (beehive_custom_ts.sql
).
For more information on these and other database-related steps, including details on how to perform these steps, please refer to the Oracle Beehive Installation Guide for your operating system.
Notes:
For high availability deployments with a shared file system (or that leverage the filesystem_reference
object within workspaces), all computers on which Oracle Beehive Application Tier instances and Oracle Database instances reside must have access to the file system reference paths at the same logical location. This shared access may be accomplished using a Network File System (NFS) server, symbolic links (symlinks), or another supported method. Typically, organizations will experience optimal performance if their file systems reside on computers other than those on which Oracle Beehive and Oracle Database reside. For information on managing file system directories deployed with Oracle Beehive, please refer to "Managing File System Directories" in the Oracle Beehive Administrator's Guide.
Oracle Beehive supports the option to deploy a secondary database instance dedicated to the system's search functions. This option should be considered in large deployments as it may provide significant performance improvements for search-related features. For more information on this option, please contact your Oracle Support representative.
Oracle Beehive supports Oracle Real Application Clusters (Oracle RAC). With Oracle RAC, you can deploy Oracle Database across multiple computers so that they each share a single physical database. This is useful for deployments that need to achieve high availability and scalability, especially on low cost hardware. With Oracle RAC, the number of computers across which Oracle Database is distributed is invisible to Oracle Beehive and its users.
Oracle Beehive supports affinity toward Oracle RAC database instances, providing more efficient user sessions and balanced database workloads. Currently, database instance affinity is supported by the E-mail Service and the Event Framework only. With the E-mail Service, affinity is based on the instance associated with a user's Internet Message Access Protocol (IMAP) session. Support for other Oracle Beehive services and affinity types will be provided in later releases.
If you plan to deploy Oracle Beehive with Oracle RAC, you should consider the pre- and post-installation steps necessary to prepare your deployment for this option. These topics are covered in the following sections:
Prior to installing Oracle Beehive and deploying it with Oracle RAC, there are several required configuration steps that you must take and a few recommended steps that you should consider. These steps, which will prepare your high availability environment for certain Oracle Beehive installation prerequisites and other requirements, include:
Creating multiple logical database services.
Starting all of the logical database services that you created.
Enabling X/Open Distributed Transaction Processing (DTP) for all database services.
For deployments that require communications over Secure Sockets Layer (SSL), enabling Secure Oracle Notification Services (ONS) notification.
For databases that use raw storage, creating the ORABPEL
tablespace manually.
For more information on these and other pre-installation steps related to Oracle RAC, including details on how to perform these steps, please refer to the Oracle Beehive Installation Guide for your operating system.
After installing Oracle Beehive, you must complete several post-installation steps, including:
Retrieving your site and database object system identifiers (you'll need these for the post-installation steps that follow).
Changing the value of the connect_string
property by substituting the database service name with the global service name.
Updating the database system object and the local bootstrap file with the updated connect string value.
Modifying the database system object's configuration by specifying the database services you created and the ONS remote ports that are listening on your Oracle RAC nodes.
Creating an affinity service instance for each Oracle RAC node and adding the names of the affinity service instances to your Oracle Beehive configuration.
Committing (activating) the changes listed above to all Oracle Beehive instances.
Configuring your Oracle RAC nodes to receive secure ONS notifications (if they haven't been configured already).
For more information on these and other post-installation steps related to Oracle RAC, including details on how to perform these steps, please refer to the Oracle Beehive Installation Guide for your operating system.
Oracle Beehive provides flexible user account management and provisioning by supporting both native and system-external user directory options. With Oracle Beehive, administrators can manage user account data either natively in Oracle Beehive or externally through integration with a supported LDAP-based user directory server. Oracle Beehive provides this flexibility for user account management through the User Directory Service (UDS).
Currently, Oracle Beehive supports the following user directory servers:
Organizations can also leverage external user directories to manage user authentication attributes such as usernames and passwords. This option requires Oracle Beehive administrators to configure the Authentication Service after installation using the beectl
command-line utility. For more information regarding this option, please refer to the Oracle Beehive Administrator's Guide.
If you choose to integrate Oracle Beehive with a supported external user directory, you should consider the limitations of this option as well as the steps to prepare your deployment for this option. These topics are covered in the following sections:
Preparing to Deploy Oracle Beehive with an External User Directory
Limitations of Deploying Oracle Beehive with an External User Directory
After installing Oracle Beehive but before deploying the system with an external user directory, you must import user account data from your external user directory server instance to UDS. This process involves creating the following XML files:
LDAP mapping profile: An XML file that contains external user directory server settings and specifies how to convert those entries to Oracle Beehive users and groups. This involves specifying attribute mappings between those defined in an external directory server and those used by Oracle Beehive.
User file: An XML file that represents, in a format specified by Oracle Beehive, all the user accounts that need to be synchronized. To create this, administrators use the LDAP mapping profile and the beectl
download_external_user_data command.
For more information, including the steps to create these files, please refer to the Oracle Beehive Installation Guide for your operating system.
Despite the multiple options and benefits provided by Oracle Beehive's support of external user directories, certain limitations exist and include:
Oracle Beehive does not support integration with multiple, unique user directories. Oracle Beehive can only integrate with a single user directory instance on a specific server.
The user directory option in which you initially deploy Oracle Beehive is fixed. You cannot migrate to another supported option after the system is deployed. For example, if you choose to initially deploy Oracle Beehive leveraging its native user directory, you cannot change to an external user directory later. Therefore, Oracle strongly recommends that you consider and choose your user directory option before deploying Oracle Beehive.
User accounts can only be mastered in one place, either natively in Oracle Beehive or in an external user directory. Despite this requirement, administrators may choose to master most user account attributes in one directory even if the user accounts themselves are mastered in another directory. However, certain user account attributes that are specific to Oracle Beehive, such as voicemail passwords and instant messaging user names, can only be mastered in Oracle Beehive.
To manage user account attributes that are mastered in external LDAP directories, administrators can only use the tools provided with or for those directories. Administrators cannot use the tools provided with Oracle Beehive, such as beectl
, to manage user account attributes that are mastered in external LDAP directories.
The synchronization process between external user directory servers and Oracle Beehive is unidirectional, that is, changes in an external user directory are imported into Oracle Beehive only. Oracle Beehive cannot promote the user account attributes that it manages to external user directories.
Oracle Universal Records Management (Oracle URM) enables organizations to manage their records and retention policies, disposition processes, and litigation holds or freezes in a central repository known as a Universal Records Management (URM) server. Organizations can then apply those policies, dispositions, and holds to content stored in other systems, such as Oracle Beehive. Oracle Beehive provides integration with Oracle URM through the Records Management Service.
Deploying Oracle Beehive with Oracle URM requires that you have an Oracle URM instance installed and configured prior to installing Oracle Beehive. After you install Oracle Beehive, you must complete several tasks, some of which you perform in Oracle Beehive and others in Oracle URM. These tasks are grouped as follows:
Oracle Beehive-based Tasks for Deploying Oracle Beehive with Oracle URM
Oracle URM-based Tasks for Deploying Oracle Beehive with Oracle URM
Deploying Oracle Beehive with Oracle URM requires completion of the following tasks in Oracle Beehive:
Specifying (registering) the Oracle URM instance that you want Oracle Beehive to leverage. For this, you can use Oracle Beekeeper or the beectl
utility. With beectl, you issue the add_urm
and activate_configuration
commands.
Starting the Records Management Service through opmnctl
.
For more information on these tasks, please refer to the Oracle Beehive Administrator's Guide.
Deploying Oracle Beehive with Oracle URM requires logging in to Oracle URM as a user with administrator privileges and completing the following tasks:
Verifying that the sysadmin
user has been granted all possible roles in Oracle URM. This includes the rma
, rmaadmin
, admin
, ermadmin
, ermrequestor
, rmaprivileged
, and sysmanager
roles.
Creating retention categories and folders that are required by your organization for content managed by Oracle Beehive. You can create retention categories within record series or file plans. You can create retention folders within retention categories and other retention folders. Once created, you can view retention categories and folders in Oracle Beehive by issuing the list_file_plan
command through beectl
.
Creating disposition rules required by your organization for content managed by Oracle Beehive.
Note:
Currently Oracle Beehive only supports thedestroy
disposition action. Oracle Beehive will not process any other disposition actions that are defined and assigned to retention categories.Enabling the dispositions for the content managed by your Oracle Beehive instance.
For more information on these tasks, please refer to the documentation provided with your Oracle URM instance.
Oracle Wallet is a component of Oracle Application Server 10g that provides important authentication capabilities. A wallet is a password-protected container that stores authentication and signing credentials, including private keys, certificates, and trusted certificates, all of which are used by Secure Sockets Layer (SSL) for strong authentication. Oracle Wallet provides an encrypted Transport Layer Security (TLS) communication channel that some Oracle Beehive services require, such as the XMPP Service and the Workflow Service. Oracle Wallet is also required when configuring Oracle Beehive Web Services for Security Assertions Markup Language (SAML) authentication.
After installing Oracle Beehive, you should configure Oracle Beehive to use Oracle Wallet so that clients may access the system with a TLS connection. These steps include:
Enabling auto-login for Oracle Wallet.
Enabling Oracle Remote Method Invocation over SSL (ORMIS) for Oracle Wallet.
Configuring your Oracle Beehive server instance to use Oracle Wallet. If your deployment contains multiple instances, you will need to configure each instance separately.
For more information on the specific steps required to deploy Oracle Beehive with Oracle Wallet, refer to the Oracle Beehive Installation Guide for your operating system.
Out of the box, Oracle Beehive comes pre-bundled with one Oracle BPEL Process Manager instance that is configured with a few default workflows through the Workflow Service. You may leverage this internal instance or, if your organization has an existing Oracle Beehive BPEL Process Manager instance, you may integrate Oracle Beehive with that one instead. This section discusses the considerations related to the integrating Oracle Beehive with an existing Oracle Beehive BPEL Process Manager instance.
Caution:
If you plan to deploy Oracle Beehive with an external BPEL Process Manager instance, Oracle strongly recommends that you configure this integration immediately after you install Oracle Beehive, or very soon thereafter. You may encounter issues if you initially deploy Oracle Beehive with its internal BPEL Process Manager instance and later switch to an external BPEL Process Manager instance.To deploy Oracle Beehive with an external Oracle BPEL Process Manager instance, you must complete the following tasks after you install Oracle Beehive:
Specify the external Oracle BPEL Process Manager instance and BPEL cluster that you want Oracle Beehive to use. You use the beectl
utility to complete these tasks.
In the ORABPEL repository for your external instance, create a synonym to the Oracle Beehive Workflow PL/SQL package. Additionally, you may create a database link to this package if the schemas for the external ORABPEL repository and Oracle Beehive are not stored in the same database.
Deploy the Oracle Beehive Identity Service Provider package (isprovider.jar) and configuration file (is_config.xml) to your external Oracle BPEL Process Manager instance. You complete this task either through auto-deploy mode of Oracle BPEL Process Manager or by using the Oracle BPEL Console.
Note:
After you deploy the Oracle Beehive Identity Service Provider package, any existing Identity Service configurations for your external Oracle BPEL Process Manager instance will no longer work. However, you may optionally merge the Oracle Beehive is_config.xml file with the one in your external Oracle BPEL Process Manager instance. This will allow the Oracle Beehive Identity Service provider and other custom providers to coexist. Furthermore, if you integrate Oracle Beehive with an external user directory (LDAP) that is already configured for your external Oracle BPEL Process Manager instance, then you do not have to complete this step. For more information on this option, please refer to the Oracle BPEL Process Manager Administrator's Guide.Deploy the default Oracle Beehive BPEL workflows, as well as any custom workflows, to your external Oracle BPEL Process Manager instance. To deploy the default workflows, you use the beectl
utility. To deploy custom workflows, you also use the beectl
utility (to register the workflows) and either auto-deploy mode of Oracle BPEL Process Manager or the Oracle BPEL Console (to manually deploy the custom workflow suitcase into your external instance).
Notes:
For more information on the specific steps required to deploy Oracle Beehive with an external Oracle BPEL Process Manager instance, please refer to the Oracle Beehive Installation Guide for your operating system.
For more information on the tasks that are related to the pre-bundled internal Oracle BPEL Process Manager and its workflows, please refer to "Managing Oracle Beehive Events, Policies, and Workflows" in the Oracle Beehive Administrator's Guide.
For more information on considerations and tasks that are specific to Oracle BPEL Process Manager, and especially external instances of it, please refer to the Oracle BPEL Process Manager Administrator's Guide.
Oracle Beehive maintains its own optimized search index enabling users to perform comprehensive searches across all Oracle Beehive artifacts. At the enterprise level, however, other information repositories might exist and contain information that users need. For example, depending on their roles, knowledge workers might need to find expense reports or purchase requisitions stored outside of Oracle Beehive. This level of search across all enterprise information repositories is provided by Oracle Secure Enterprise Search.
Oracle Secure Enterprise Search has been designed as a stand-alone enterprise search solution. It incorporates best-in-class indexing, crawling, and security capabilities to create a reliable and comprehensive search solution for any organization.
To leverage this powerful option requires the completion of tasks (post-installation) that are specific to Oracle Beehive and others that are specific to Oracle Secure Enterprise Search 10g. For example, your Oracle Beehive instance must be configured in Oracle Secure Enterprise Search 10g as a federated data source.
You use to the beectl
utility to complete the tasks that are specific to Oracle Beehive, which inlude:
Creating a special user account that has administrator rights to the content managed by Oracle Beehive.
Configuring the Secure Enterprise Search service by entering the host and port number of your Oracle Beehive Application Tier instance, and by enabling the service.
Activating these changes using the activate_configuration
command.
You use the Oracle Secure Enterprise Search Administration Tool to complete the tasks that are specific to Oracle Secure Enterprise Search 10g, which include:
Activating the identity plug-in on the Global Settings - Identity Management Setup page.
Specifying your Oracle Beehive database instance as a federated source.
Specifying the Uniform Resource Identifier (URI) of the Oracle Beehive Search Service.
Entering the credentials of the special user account that you created in Oracle Beehive.
For more information on the tasks that are specific to Oracle Beehive, please refer to the Oracle Beehive Installation Guide for your operating system. For more information on the tasks that are specific to Oracle Secure Enterprise Search 10g, please refer to "Setting up Federated Sources" in the Oracle Secure Enterprise Search 10g Administrator's Guide.
Oracle Beehive supports integration with Microsoft Exchange Server 2003 through the Oracle Collaboration Coexistence Gateway. The Oracle Collaboration Coexistence Gateway is an Oracle proprietary solution that allows Oracle Beehive users to collaborate with Microsoft Exchange users beyond the limited capabilities of e-mail. Additionally, this solution allows Microsoft Exchange users to leverage Oracle Beehive features without being migrated from Microsoft Exchange.
To learn more about how to deploy Oracle Beehive with Microsoft Exchange Server 2003, refer to the following topics:
Installing and Configuring the Oracle Collaboration Coexistence Gateway
Load Balancer Requirements for Deploying Oracle Beehive with Microsoft Exchange Server 2003
To integrate Oracle Beehive with Microsoft Exchange Server 2003, you install and configure the following Oracle Collaboration Coexistence Gateway components on one or more computers in your Microsoft Exchange domain:
Oracle Coexistence Connector for Microsoft Exchange Server
Oracle Change Notification Service for Microsoft Exchange Server
You install both of these component separately on one or more computers in your Microsoft Exchange domain using the Oracle Beehive Install Wizard. Although you may install both components on the same computer, it is not recommended that you do so. Instead, it is recommended that you install these components on separate computers that each host their own Microsoft Exchange Server 2003 instances. Furthermore, you should install the Oracle Change Notification Service only on computers that host Microsoft Exchange user mailboxes and the Oracle Coexistence Connector for Microsoft Exchange Server only on computers that do not host user mailboxes. You may also install these components on computers in one or more Microsoft Exchange routing groups.
After installing Oracle Collaboration Coexistence Gateway components, you must perform several post-installation tasks, which include configuring the Coexistence Service and configuring your deployment's load balancers (if required). You perform these tasks manually outside of the Oracle Beehive Install Wizard.
Notes:
For more information on specific prerequisites and steps related to installing the Oracle Collaboration Coexistence Gateway and its components, please refer to "Oracle Collaboration Coexistence Gateway Install Help" in the Oracle Beehive Installation Guide for Microsoft Windows.
For information on configuring the Coexistence Service, please refer to the Oracle Beehive Administrator's Guide.
For information on any load balancer requirements that might apply, please refer to "Load Balancer Requirements for Deploying Oracle Beehive with Microsoft Exchange Server 2003".
Depending on the message type, the Oracle Collaboration Coexistence Gateway sends messages between Oracle Beehive and Microsoft Exchange Server 2003 over HTTP/HTTPS or SMTP. Therefore, you will need one or more load balancers if your integration plans include more than one Oracle Beehive Application Tier instance or more than one Oracle Coexistence Connector instance. In these cases, load balancers are required to manage the HTTP/HTTPS traffic and, potentially, the SMTP traffic between Oracle Beehive and Microsoft Exchange Server. This requirement is due to the fact that the Coexistence Service (which resides on all Oracle Beehive server instances) and the Oracle Coexistence Connector (which must reside on at least one Microsoft Exchange Server instance) accept only a single URL representing their connection endpoints. Although it is not required to configure load balancers for SMTP-based coexistence traffic, it is recommended that you do so.
Oracle Beehive supports integration with Symantec Scan Engine. This provides another option for organizations that want to leverage existing Symantec Scan Engine instances or that want anti-virus features beyond what the Oracle Beehive Virus Scanner provides. Through this integration, organizations can leverage the scan types and modes that Symantec Scan Engine provides, as well as its artifact and message filtering capabilities. Oracle Beehive supports Symantec Scan Engine version 5.1.2 or later.
Administrators manage the Oracle Beehive Virus Scanner through beectl
. To manage Symantec Scan Engine, administrators should leverage the tools provided with that product.
For details on integrating Symantec Scan Engine with Oracle Beehive, refer to "Adding a Virus Engine to Oracle Beehive" in the Oracle Beehive Administrator's Guide. To configure Symantec Scan Engine to scan e-mail messages, refer to "Managing Attachment Blocking and Virus Scanning" in the Oracle Beehive Administrator's Guide.