| Oracle® Collaboration Suite Deployment Guide 10g Release 1 (10.1.2) Part Number B25492-04 |
|
|
View PDF |
| Oracle® Collaboration Suite Deployment Guide 10g Release 1 (10.1.2) Part Number B25492-04 |
|
|
View PDF |
This chapter contains the following topics:
Planning for Oracle Calendar Server and Oracle Calendar Application System Deployment
Oracle Calendar Server and Oracle Calendar Application System Deployment Configurations
Deploying the Oracle Calendar Web Client and Oracle Calendar Web services
Oracle Calendar is composed of the Oracle Calendar server, the Oracle Calendar application system and a variety of clients. This chapter provides conceptual and planning information for deploying the Oracle Calendar server, the Oracle Calendar application system and the various Oracle Calendar clients.
This chapter provides conceptual and planning information for deploying the Oracle Calendar server and the Oracle Calendar application system.
Oracle Calendar architecture contains two principle components, the Oracle Calendar application system and the Oracle Calendar server. Oracle Calendar is also deployed with Oracle Application Server components such as Web Cache, Oracle HTTP Server and Oracle Internet Directory. The Oracle Calendar server can be deployed with the Oracle Mail Server to support sending and receiving of calendar notifications by e-mail. However, the Oracle Calendar server can also be configured to use third-party SMTP processes to facilitate the sending of calendar information and notifications, regardless of which e-mail server is used in production.
Figure 5-1 illustrates Oracle Calendar architecture. One important difference that distinguishes Oracle Calendar from other Oracle Collaboration Suite applications is that the Oracle Calendar server database is integrated into the application and therefore deployed on the Applications tier and typically not on the Infrastructure tier.
Web Cache
Oracle HTTP Server
IMAP4 server
SMTP server
Oracle Calendar application system
Oracle Calendar server
The Infrastructure tier contains Oracle Internet Directory.
Web-based clients such as browsers, PDAs, and cell phones connect to the Oracle Calendar server through the Web Cache and Oracle HTTP Server using the HTTP protocol. Oracle HTTP Server provides single sign-on authentication with Oracle Internet Directory and then directs the connection to the Oracle Calendar application system, which in turn connects to the Oracle Calendar server using the Oracle Calendar Access Protocol (OCAP).
Desktop clients such as Oracle Connector for Outlook, the Oracle Calendar desktop client, and the Oracle Calendar Sync client (connected to a desktop computer using a cradle) connect directly with the Oracle Calendar server using OCAP. The Oracle Calendar server authenticates desktop clients with Oracle Internet Directory using LDAP.
|
Note: The Oracle Calendar server and the Oracle Calendar application system have specific connection requirements that significantly impact deployment considerations. These requirements are discussed in the "Oracle Calendar Server Functionality" section. |
The Oracle Calendar server is the back end to an integrated suite of calendaring and scheduling products. Networked users can use a variety of desktop clients to manage their calendars. Mobile users can synchronize their agendas with a variety of PDAs or, with the addition of wireless technology of Oracle, can send and receive calendar entries using a mobile phone.
Figure 5-2 illustrates the Oracle Calendar server. In this figure, the Oracle Calendar server contains the following components:
Calendar Sessions
Calendar sessions are comprised of the listeners, processes and threads that perform specific Oracle Calendar operations. The components contained in a calendar session are described in the "Calendar server Architecture" section of Chapter 2 in the Calendar Administrator's Guide
Calendar Nodes
A calendar node is a calendar information database in which the server stores data such as user records, meetings, and events for a set of users. A server can host one or several nodes. Nodes may be connected into a node network, allowing users on different nodes (and servers) to schedule meetings and events transparently with one another. Each node has a specific, unique identification number called the Node-ID, which must be unique across a network of nodes.
When the Oracle Calendar server is installed, a node is automatically created and additional nodes can be added to the server. In order to group your users into nodes, logical divisions among your user base must be clearly delineated. Before making these decisions, however, the following factors must be considered:
The maximum capacity of an Oracle Calendar server node in terms of the number of users each node and the number of nodes each computer varies depending on a number of factors such as usage patterns, scheduling patterns, and regional deployment tissues. For more information see the "Planning for Oracle Calendar Server and Oracle Calendar Application System Deployment" section.
Network issues
Although server-to-server calendar communication requires low network bandwidth, in order to obtain acceptable performance for users accessing a remote server, a network bandwidth of 64 kbps or higher is suggested. If this is not possible, then you may want to consider installing a local server.
Scheduling between nodes
More server resources are required when scheduling meetings between users on different nodes in an Oracle Calendar node network. For this reason, it is a good practice to group users who work together on one node and thereby minimize the number of meetings involving users from other nodes.
Although it is possible to move individual users from node to node, the process can be lengthy and may alter or remove some information. Minimize the need to move individual users as a result of either reaching maximum node capacity, or the need to split a node according to logical divisions. For a more detailed discussion of the unimvuser utility, see Appendix E, "Utilities" of the Oracle Calendar Reference Manual.
Administrative considerations
While the bulk of the Oracle Calendar server administration can be performed remotely, there are tasks related to system maintenance that might require an on-site administrator. If you do not have personnel to manage back-up media and system problems at a branch office, then it is probably not a good idea to locate a server there.
The time required to administer your calendar node network is also affected by the necessary repetition of some tasks. Certain features, such as holidays, are specific to each node. The tasks associated with these features, such as adding holidays, must be done separately on each node.
Each node in a calendar node network that is linked to a directory server must point to the same directory server. When the Oracle Calendar server is deployed as part of Oracle Collaboration Suite, Oracle Internet Directory serves as the directory system. In a standalone deployment of the Oracle Calendar server, a directory system is optional and when present, all nodes in a network must use the same logical directory server.
Master Node
Each Oracle Calendar server deployment can contain only one master node. All clients connect to the master node on their first login. The master node then queries the directory server for identification and authentication. When the master node receives this information, it redirects the client to the appropriate server and node.
Clients use the master node to automatically route connections to the server and node that hosts the account of the user who is logging into the system. Upon connection to this centralized access point, the master node queries clients for identification. When the master node receives this information, it redirects the client to the appropriate server and a final, persistent network connection is made and maintained until the user terminates the session. You can optionally change the node that is designated as the master node and in case of large deployments, you can create an Oracle Calendar node or server dedicated exclusively to providing master node service.
The Oracle Calendar application system is a framework for managing Oracle Calendar components or plug-ins through Web-based means. The features of Oracle Calendar are provided through Web-based applications by loading each of the components on startup.
Figure 5-4 Oracle Calendar Application System
Figure 5-4 illustrates the Oracle Calendar application system. In this figure, the Oracle Calendar application system contains the following components:
Oracle Calendar Web client
Oracle Mobile Data Sync
Oracle Calendar Web services
Oracle Calendar Web Client
The Oracle Calendar Web client enables users to share agendas, schedule meetings, and book resources and equipment.
Oracle Mobile Data Sync
Oracle Mobile Data Sync offers two-way direct synchronization with the Oracle Calendar server over any standard Hypertext Transfer Protocol (HTTP) connection, by opening up the calendar infrastructure to OMA-DS-compliant devices (formerly referred to as SyncML-compliant devices) or applications with Internet access. The Oracle Mobile Data Sync architecture can also be extended to support third-party standards-based or proprietary infrastructures.
Oracle Mobile Data Sync provides a flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere.
Oracle Calendar Web Services
Oracle Calendar Web services enable applications to retrieve, through common XML queries, calendaring data for display in any portal, client application, or backend server. iCal data is coded in XML, wherein iCal becomes xCal. SOAP is used to encapsulate the messages for delivery. The calendaring data Web services SOAP is stored directly on the Calendar server store. This is in effect the CWSL, or Calendar Web Services Language.
This section describes Oracle Calendar server functionality with Oracle Calendar Web client and Oracle Calendar desktop client connections. The Oracle Calendar server has very specific configuration requirements to maintain successful connections with these types of connections.
Figure 5-5 illustrates how the Oracle Calendar Web client accesses the Oracle Calendar server.
Figure 5-5 Oracle Calendar Web Client Connections
In Figure 5-5, two instances of the Oracle Calendar application system and three instances of the Oracle Calendar server including a master node are deployed on the Applications tier in a DMZ and Oracle Internet Directory is deployed on the Infrastructure tier. Web browsers connects through a load balancer to the Web Cache and Oracle HTTP Server. Oracle HTTP Server first performs a single sign-on authentication against Oracle Internet Directory, and then sends an HTTP request to one of the Oracle Calendar application system instances. The Oracle Calendar application system instance sends the request to one of the Oracle Calendar server instances using OCAP.
Persistence is not required between the load balancer and the Oracle Calendar application system when a user is logging on. However, once the user has logged on, the load balancer must persistently send all user data to the appropriate Oracle Calendar application system instance. Persistence is required for single sign-on authentication, and, like all Oracle Collaboration Suite Web applications, the Oracle Calendar application system depends on single sign-on authentication. If the load balancer randomly sends information to another Applications tier, then authentication errors may occur. This is not the case for standalone Oracle Calendar installations, where single sign-on authentication is not used.
Connections Between the Oracle Calendar Application System and the Oracle Calendar Server
Each Oracle Calendar application system instance must maintain a fixed number of persistent, shared OCAP connections to each Oracle Calendar server instance. You cannot load balance the connections between the Oracle Calendar application system and the Oracle Calendar server.
Connections Between clients and the Oracle Calendar Application System
Connections between the clients and the Oracle Calendar application system are neither a fixed number, shared, nor persistent and consequently can be load balanced.
Figure 5-6 illustrates how desktop clients access the Oracle Calendar server.
Figure 5-6 Oracle Calendar Server Desktop Client Connections
In Figure 5-6, multiple desktop clients connect to multiple instances of the Oracle Calendar server using fixed, persistent OCAP connections. The Oracle Calendar server updates user information by accessing Oracle Internet Directory using an LDAP connection. Data is not replicated between Oracle Calendar server instances and only information needed for a local node of a user is replicated. Because users exist on only one node and data is not replicated or shared between Oracle Calendar server instances, the connections to the Oracle Calendar server cannot be load-balanced.
This section discusses issues and requirements for planning an Oracle Calendar server deployment.
Planning for an Oracle Calendar deployment requires an understanding of the number of Oracle Calendar users. This information varies according to different categories.
The recommended capacity each node and each server is heavily dependent on hardware, the expected usage pattern of the service, and the type of clients to be used. A small, economical, or older host may only be able to functionally handle 500 or 1,000 accounts, whereas a large, enterprise class computer could easily accommodate three or four nodes each serving over 5,000 users.
For an organization that heavily uses scheduling, deployment should not exceed 10,000 users each host, whereas for an organization with a modest usage pattern over 20,000 users may be deployed on the same host. An environment deploying Oracle Calendar desktop clients (Windows, Mac, Linux, Solaris) and Oracle Connector for Outlook could provide calendar service for up to 10,000 users on a single computer, whereas an environment consisting only of the Oracle Calendar Web client would be able to host well over 20,000 users on the same resource.
Configured users are individuals with user accounts on an Oracle Calendar server node.
Logged-on users are user who are connected to a node but who are not actively making database requests. This figure is generally estimated to be from 33–50% of configured users. Try to forecast how your users will use the calendar application. For example, if everyone starts work at the same time, you might anticipate a period of peak usage in the morning where up to 60% of all users will be logged on at once. Also, a number of users may choose to stay logged on all day, keeping the calendaring application open in the background to permit quick and frequent access.
You can optimize Oracle Calendar server performance by deploying groups of users that share complimentary usage patterns on the same calendar node. For example, an organization's Chicago office is expected to steadily decrease as its sales force is relocated to the New York office. Deploying the users from both offices on the same node reduces the administrative time required for managing two nodes. Having users in two different time zones on the same node requires a minor configuration change for the Chicago users to enable them to set their time zone from the client.
Depending on the size and distribution of your organization, you may want to deploy the Oracle Calendar server according to usage patterns based on geography and time zones. You may want to have users of one geographic region share the same nodes as users of another geographic region if time differences ensure that neither group of users will be active at the same time.
Because Oracle Calendar has a large number of clients, the type of clients accessing the Oracle Calendar server can significantly impact your deployment. If most of the connections are through the Oracle Calendar Web client, then most of the stress will take place on the tier that contains Web Cache, Oracle HTTP Server, and the Oracle Calendar application system. Consequently this is the portion of your deployment that you may need to scale first. If the majority of your connections are through Oracle Calendar desktop clients, then most of the stress will be on Oracle Calendar servers because these clients establish and maintain connections to (and persistent sessions on) the Oracle Calendar servers. So as your user base grows, you may need to scale the Oracle Calendar server portion of your deployment to accommodate an increased number of direct client connections to the Oracle Calendar server.
You can optimize your Oracle Calendar server deployment users based on geographic location or by functional groups. By grouping users that often schedule each other onto the same node, you will both reduce the network traffic between servers and also the data replicated between nodes.
For example, while an organization's Sales and Financing departments have completely different functional areas, they may collaborate on numerous projects for which they share the same scheduling. For example, the Sales department may work with the Financing department to produce attractive new financing packages that they can offer to customers when selling their products. If the calendaring information for each department is stored on the same node, then there will be no need for frequent data replication between them.
The Oracle Calendar server stores user provisioning policies in the master configuration file on the master node. In the default Oracle Calendar server installation, all user provisioning is handled by the master node. The first and most important step in a large deployment is to change your provisioning policies as required by making any necessary changes in the master configuration file.
Ensure that you complete all of the instructions in the Oracle Collaboration Suite Installation Guide.
|
See Also: For information on installing Oracle Calendar, see the following guides: |
Multiple instances of Oracle Calendar can be installed on the same Unix or Linux host (not on Windows). By default, each instance of Oracle Calendar is installed with all its components on the same host. This includes the following components:
Oracle Calendar server
Oracle Calendar Administrator
Oracle Mobile Data Sync
Oracle Calendar Web client
Oracle Calendar Web services
Oracle Calendar SDK
If you wish to run different components on different hosts (for example, to run the Oracle Calendar application system on a different host than the Oracle Calendar server), then you must keep the following in mind.
When the Oracle Calendar server is installed in a standalone mode, Oracle Calendar Web clients identify themselves to the Oracle Calendar server using a shared key stored in both the Oracle Calendar application system and server configuration files. This shared key must match exactly across all Oracle Calendar application system and server instances. As this key is generated automatically by the installation procedure, and is different for each install, you will have to perform this configuration manually.
If you wish to spread the user base of a deployment across multiple calendar server nodes on the same host or distributed across multiple hosts, then you must connect the nodes into a network.
This section describes available Oracle Calendar server deployment configurations and explains the advantages and disadvantages of each one.
Unlike other Oracle Collaboration Suite applications, the Oracle Calendar server database is deployed on the Applications tier by default. Figure 5-8 illustrates a typical Oracle Calendar server deployment with multiple Oracle Calendar application system and Oracle Calendar server hosts.
Figure 5-8 Deploying Oracle Calendar Server in the Applications Tier
Applications Tier
In Figure 5-8, the Applications tier is located in a DMZ with a load balancer for Web clients. The following components are deployed on the Applications tier:
Web Cache
Oracle HTTP Server
Two Oracle Calendar application system hosts
Three Oracle Calendar application system hosts
IMAP4 Server
SMTP Server
Infrastructure Tier
In Figure 5-8, the Infrastructure tier contains the Oracle Mail repository and Oracle Internet Directory.
HTTP Connections
In Figure 5-8, clients such as browsers, PDAs (using OMA-DS), and mobile devices connect to the Oracle Calendar server through Web Cache and Oracle HTTP Server using the HTTP protocol. Oracle HTTP Server provides single sign-on authentication with Oracle Internet Directory and then directs the connection to the Oracle Calendar application system, which in turn connects to the Oracle Calendar server using OCAP.
Each Oracle Calendar application system instance must maintain a fixed number of persistent, shared OCAP connections to each Oracle Calendar server instance. Connections between clients and the Oracle Calendar application system are neither a fixed number, shared, nor persistent, and consequently can be load balanced.
Desktop Client Connections
Desktop clients such as Oracle Connector for Outlook, the Oracle Calendar desktop client, and the Oracle Calendar sync client (connected to a desktop computer through cradle) connect directly with the Oracle Calendar server using OCAP. The Oracle Calendar server authenticates desktop clients with Oracle Internet Directory using LDAP.
You can optionally deploy the Oracle Calendar server on the Infrastructure tier. Regardless of where the Oracle Calendar server is installed, attention should be given to RAID options to achieve reliable storage and performance. Figure 5-9 illustrates this deployment configuration.
Figure 5-9 Deploying Oracle Calendar Server in the Infrastructure Tier
Applications Tier
In Figure 5-9, the Applications tier is located in a DMZ with a load balancer for the Oracle Calendar Web client but not for Oracle Calendar desktop clients. The following components are deployed on the Applications tier:
Web Cache
Oracle HTTP Server
Two Oracle Calendar application system hosts
IMAP4 Server
SMTP Server
Infrastructure Tier
In Figure 5-9, the following components are deployed on the Infrastructure tier:
Three Oracle Calendar server hosts
Oracle Mail repository
Oracle Internet Directory
In this configuration, firewall ports must be open to enable OCAP connections from the Applications tier to the Infrastructure tier. If a load balancer is being used on the Infrastructure tier firewall, make sure that it does not load balance calendar connections (i.e. connections to the Oracle Calendar server DNS host name or port numbers) because it will disrupt the persistent shared OCAP connections, causing calendar operations to fail. Note that the only advantage of having the calendar database on the infrastructure is to take advantage of storage configurations and failover configurations.
HTTP Connections
In Figure 5-9, HTTP or HTTPS-based clients such as browsers, PDAs (using OMA-DS, formerly known as SyncML), and mobile devices connect to the Oracle Calendar server through Web Cache and Oracle HTTP Server using the HTTP protocol. Oracle HTTP Server provides single sign-on authentication with the Oracle Internet Directory and then directs the connection to the Oracle Calendar application system, which in turn connects to the Oracle Calendar server using OCAP.
Each Oracle Calendar application system instance must maintain a fixed number of persistent, shared OCAP connections to each Oracle Calendar server instance. Connections between clients and the Oracle Calendar application system are neither a fixed number, shared, nor persistent and consequently can be load balanced.
Desktop Client Connections
Desktop clients such as Oracle Connector for Outlook, the Oracle Calendar desktop client, and the Oracle Calendar Sync client (connected to a desktop computer through a cradle) connect directly with the Oracle Calendar server using OCAP. The Oracle Calendar server authenticates desktop clients with Oracle Internet Directory using LDAP.
This section contains the following topics:
Oracle Calendar Web Client and Oracle Calendar Web Services Architecture
Oracle Calendar Web Client and Oracle Calendar Web Services Standalone Installation Notes
Oracle Calendar Web Client and Oracle Calendar Web Services Sizing and Memory Use
Oracle Calendar Web Client and Oracle Calendar Web Services Deployment and Maintenance
The Oracle Calendar Web client and Oracle Calendar Web services are both part of the Oracle Calendar application system, as illustrated by the following diagram.
Figure 5-10 Oracle Calendar Web client and Oracle Calendar Web services
|
Notes: This section describes Oracle Calendar Web client and Oracle Calendar Web services deployment, rather than Oracle Calendar application system deployment as a whole. The deployment of the other component of the Oracle Calendar application system (Oracle Mobile Data Sync) is described separately in "Deploying Oracle Mobile Data Sync". For more information on Oracle Calendar application system architecture, see the following sections: |
Oracle Calendar application system components are FastCGI-based. The Oracle Calendar application system connects to the back-end datastore, the Oracle Calendar server.
When you deploy an instance of the Oracle Calendar application system on an Applications tier, all three of its components are included. You may want to disable certain components, depending on how the Applications tier is positioned in your architecture, and whether or not you want certain components to be accessible externally. (For details on disabling components of the Oracle Calendar application system, see Customizing OCAS Components in Chapter 3 of Oracle Calendar Administrator's Guide.)
For example, the Oracle Calendar Web client and Oracle Calendar Web services could be enabled only on Applications tiers behind the DMZ for internal use by your organization. In such a setup, external access would require users to tunnel through to these tiers using a VPN client.
Alternatively, you could enable the Oracle Calendar Web client on Applications tiers within the DMZ while making sure it is adequately protected with SSL and a firewall. In such a setup, you may choose to disable access to Oracle Calendar Web services on these tiers if there is no need for external access.
|
Note: In order for the Oracle Collaboration Suite Portal Calendar portlet to function properly, the Portal must have access to Oracle Calendar Web services. |
If you have a large number of users, you will likely be deploying two to four Applications tiers with a load balancer. When load balancing, ensure that alternate domains such as webclient1.oracle.com and webclient2.oracle.com are not used, as the Oracle Calendar application system does not support this. The domain name must remain consistent.
Standalone installations of Oracle Calendar support the following versions of Apache with mod_fastcgi.
Apache 1.3.26 and later with mod_fastcgi 2.2.12
Apache 2.0.53 and later with mod_fastcgi 2.4.2
While the preceding versions of mod_fastcgi have been tested and are known to work with their associated Apache version, newer versions of mod_fastcgi versions will also likely work as they are developed.
Download the appropriate software from http://www.apache.org/ and http://www.fastcgi.com/.
An Oracle Calendar application system instance that does not include Oracle Mobile Data Sync has no permanent memory requirements, as data is stored on the backend Calendar server. For Oracle Calendar application system instances that do include Oracle Mobile Data Sync, see Oracle Mobile Data Sync Sizing and Memory Use.
The main requirements to consider when planning a deployment of the Oracle Calendar Web client and Oracle Calendar Web services are the number of FastCGI processes to run, the amount of RAM needed to run them, and the number of Applications tiers available to run them on. These factors are interrelated and are described in the following sections.
The amount of RAM required by the Oracle Calendar Web client or Oracle Calendar Web services is directly connected to the number of FastCGI processes running on an Applications tier. Each FastCGI process requires approximately 20 to 30 MB of RAM. The number of FastCGI processes you need depends on how many users you have, and, more specifically, how many of those concurrently use the Oracle Calendar Web client or Oracle Calendar Web services.
Each FastCGI process can handle three to four requests each second (numbers will vary depending on hardware and load). In other words, you need one FastCGI process for every three to four concurrent connections. The total number of FastCGI processes can be spread across multiple Applications tiers running the Oracle Calendar Web client or Oracle Calendar Web services. These processes must be considered in addition to the number allocated for Oracle Mobile Data Sync, as described in Oracle Mobile Data Sync Sizing and Memory Use.
Imagine that Vision Corporation has 50,000 users, and that number is broken down as follows:
Total Users (including desktop client, Oracle Connector for Outlook and Web client users): 50,000
Expected Oracle Calendar Web client users: 10,000
Vision Corporation's users must adhere to a defined 9:00 a.m. to 5:00 p.m. schedule, so almost all of these 10,000 Oracle Calendar Web client users will sign in and access their calendar within the first thirty minutes of the work day. On a busy day, this could occur during the first ten minutes.
Peak concurrency (users each second): (10,000 requests) / (10 minutes) = 1000 requests each minute, or 16.67 requests each second.
Number of FastCGI processes needed: (16.67 requests each second) / (3.5 requests each second each FastCGI process) = 4.76
If Vision Corporation is running Oracle Collaboration Suite on two Applications tiers for load balancing and redundancy, then the default of five FastCGIs on each tier should be more than enough to handle any extreme peak periods.
Because a FastCGI process requires 20 to 30 MB of RAM, each tier would require about 125 MB of RAM for the Web client.
In the preceding section, the example and its calculations are provided as a guideline for you to determine the needs of your own organization. You may have many more Oracle Calendar users, but less chance of concurrent use, especially if members of your organization are working in different time zones.
The number of FastCGIs required for your organization depends on Oracle Calendar Web client use patterns. Also, you should only run as many FastCGI processes as are necessary, so as not to impact other applications running on the tiers.
A general starting point is to assume that at peak, 0.5% to 5.0% of Calendar users will concurrently use the Oracle Calendar Web client at any given time. In environments where only the Oracle Calendar Web client is available and users are active within the same time period, concurrency will be near the top of the range. In a geographically dispersed environment where all the desktop clients are available, concurrency will be near the bottom of the range.
Experiment with your architecture to determine the optimum settings for your needs. Check the Oracle HTTP Server error.log for messages indicating FastCGI overload, such as:
Resource temporarily unavailable: FastCGI: failed to connect to server
FastCGI: comm with server "server_path" aborted
You should only run as many FastCGI processes as are necessary, in case there are other applications sharing tiers with the Oracle Calendar Web client and Oracle Calendar Web services. For information on setting the number of FastCGI processes, see Oracle Calendar Administrator's Guide.
This section only provides a high-level overview of some post-installation tasks for the Oracle Calendar Web client and Oracle Calendar Web services. Consult Oracle Calendar Administrator's Guide for detailed instructions on managing, configuring and maintaining all components of Oracle Calendar.
By default, Oracle Calendar Web client and Oracle Calendar Web services are enabled on an installation of the Oracle Calendar application system. To disable them, comment out the appropriate sections of ocas.conf, as described in Customizing Oracle Calendar application system Components in Chapter 3 of Oracle Calendar Administrator's Guide.
Use Oracle Enterprise Manager to stop and start the Oracle Calendar Web client and Oracle Calendar Web services.
You can also manage the Oracle Calendar Web client and Oracle Calendar Web services using the following commands in $ORACLE_HOME/ocas/bin/.
To start the Oracle Calendar Web client and Oracle Calendar Web services (if they are enabled on an Applications tier) enter the following command:
ocasctl -start -n FastCGI_processes
Where FastCGI_processes is the number of FastCGI processes you want to run on that tier.
To stop the Oracle Calendar Web client and Oracle Calendar Web services enter the following command:
ocasctl -stopall
This section contains the following topics:
One of the keys to planning a successful Oracle Mobile Data Sync deployment is to make sure that members of your organization use supported mobile devices. Oracle Mobile Data Sync is built around the OMA-DS (Open Mobile Alliance Data Synchronization, formerly known as SyncML) standard, and while any device built to this standard should work with Oracle Mobile Data Sync, it is best to use devices tested and certified by Oracle. A list of such devices, along with configuration instructions, is published on the Oracle Technology Network site here:
Ensure that users in your organization have access to this site, as it contains important information and is updated regularly.
Another important site for Oracle Mobile Data Sync users is the Troubleshooting and FAQ page, located at the following URL:
This site provides answers to commonly asked questions about synchronization technology and how it is implemented in Oracle Mobile Data Sync.
If secure synchronization of data is a high priority for your organization, then use devices that support SSL synchronization. The list of devices on the Oracle Technology Network site specifies which support SSL synchronization. Oracle Mobile Data Sync supports SSL connections that are properly configured on the appropriate port during Oracle Collaboration Suite installation and configuration.
Another issue to consider when choosing devices is that they have varying degrees of support for traveling through different time zones. This is important for members of your organization who might be traveling a great deal. Information on this is also available on the Oracle Technology Network site.
By default, Oracle Mobile Data Sync will allow any OMA-DS-compliant device to connect to it and synchronize. However, you can configure the server to only accept connections from supported devices of your choice. For more information, see Oracle Mobile Data Sync Administrative Tasks in Chapter 3 of Oracle Calendar Administrator's Guide.
This section contains the following topics:
Oracle Mobile Data Sync and the Oracle Calendar Application System
Oracle Mobile Data Sync Tiers and Storage of Synchronization Information
Oracle Mobile Data Sync is deployed as part of the Oracle Calendar application system, as illustrated in the following diagram.
Figure 5-11 The Oracle Calendar Application System and Oracle Mobile Data Sync
|
Notes: This section describes Oracle Mobile Data Sync deployment, rather than Oracle Calendar application system deployment as a whole. The deployment of the other components of the Oracle Calendar application system (the Oracle Calendar Web client and Oracle Calendar Web services) is described separately in "Deploying the Oracle Calendar Web Client and Oracle Calendar Web services". For more information on Oracle Calendar application system architecture, see the following sections: |
Like the other two Oracle Calendar application system components, Oracle Mobile Data Sync is FastCGI-based and connects to the backend datastore, the Oracle Calendar server.
When you deploy an Oracle Calendar application system instance, all three of its components are included. If you do not plan on making the Oracle Calendar Web client and Oracle Calendar Web services available externally, then you should consider dedicating an Oracle Calendar application system tier to Oracle Mobile Data Sync, with the other components disabled, and placing this tier inside the DMZ so that it is accessible by external devices. The Oracle Calendar Web client and Oracle Calendar Web services components can be deployed on other Oracle Calendar application system instances behind, or inside the DMZ.
Oracle Mobile Data Sync must be directly accessible by devices and not through Oracle Application Server Single Sign-On. The Oracle Collaboration Suite installation program provides a Oracle Mobile Data Sync access point that is not protected by Oracle Application Server Single Sign-On, so no extra configuration is required for this. The default URL for Oracle Mobile Data Sync is http://your-domain.com/ocst-bin/ocas.fcgi. Check ocal.conf to confirm the actual address for your organization.
As it is best to make Oracle Mobile Data Sync externally accessible, and as Applications tiers are usually installed inside a corporate network behind a firewall, the Applications tier containing the Oracle Calendar server port (OCAL port) must be open to the Oracle Mobile Data Sync server. The default is port 5730, but the port number can be obtained from the ports list Web page in Oracle Collaboration Suite Control For more information, see "Checking Oracle Collaboration Suite Port Numbers" in Chapter 1 of Oracle Collaboration Suite Administrator's Guide.
Figure 5-12 Oracle Mobile Data Sync ports and connections
In the preceding diagram, the Oracle Mobile Data Sync server resides in the DMZ and accepts SSL and non-SSL connections over ports 443 and 80, respectively. The Oracle Mobile Data Sync server connects to the Oracle Calendar server, which is behind the DMZ. The Oracle Calendar server listens for Oracle Mobile Data Sync requests on port 5730.
A more complex, but real-world deployment of Oracle Mobile Data Sync would look similar to the following illustration.
Figure 5-13 Oracle Mobile Data Sync common deployment
In the preceding illustration, all sync clients connect to a load balancer in the DMZ. The load balancer accepts SSL and non-SSL connections, then redirects these connections to ports 4443 and 7777, respectively, as non-SSL data (protected in the DMZ) on the Oracle Mobile Data Sync servers. These share a common NFS mount for storage of synchronization information (as described in the next section), and connect to Oracle Calendar servers behind the DMZ. The Oracle Calendar servers listen for Oracle Mobile Data Sync requests on port 5730.
Internal users of PDAs connect to the load balancer through the intranet, while external users of mobile devices can tunnel in to the network using VPN. External users of PDAs and mobile devices can also connect through GPRS or EDGE protocols to the URL of the load balancer.
By default, each Oracle Mobile Data Sync Applications tier stores the following information in its own respective internal location:
Session database: This contains the information used during a synchronization session. In other words, it is a location to store messages that are passed between the device and server during a device synchronization.
Links database: This contains the information maintained for all synchronizations, such as device time zones, last recorded synchronizations, device-ID to server-ID mappings, and so on.
If you have multiple Oracle Mobile Data Sync tiers, then you must point them all to a central, unified location to store this information, such as an NFS mount or a datastore (network appliance). Failure to do this can result in many unnecessary slow (full) synchronizations. See Oracle Mobile Data Sync Administrative Tasks in Chapter 3 of Oracle Calendar Administrator's Guide to find out how to modify ocas.conf to do this.
The following sections describe Oracle Mobile Data Sync sizing and memory use:
Like the Oracle Calendar Web client and Oracle Calendar Web services, Oracle Mobile Data Sync RAM requirements are directly connected to the number of FastCGI processes running on an Applications tier. Each FastCGI process requires approximately 20 to 30 MB of RAM. The number of FastCGI processes you need for Oracle Mobile Data Sync depends on how many daily synchronizations occur in your organization. These processes must be considered in addition to the number allocated for the Oracle Calendar Web client and Oracle Calendar Web services, as described in Oracle Calendar Web Client and Oracle Calendar Web Services Sizing and Memory Use.
One FastCGI process is required for every synchronization that occurs. The length of each synchronization varies greatly, from two to three seconds for most synchronizations, to over a minute for full, but less common synchronizations. A safe assumption is that the average synchronization time is 20 seconds. In other words, assume that one FastCGI process can handle three synchronizations each minute.
You must run enough FastCGI processes to handle the number of synchronizations you expect to occur in your organization during peak hours. The total number of FastCGI processes can be spread across multiple Applications tiers running Oracle Mobile Data Sync. Make sure you run enough FastCGI processes to handle spikes in Oracle Mobile Data Sync use (such as after a new deployment).
The following example illustrates how to prepare for peak Oracle Mobile Data Sync use. Under normal circumstances, your organization probably would not experience the kind of intense use described here.
Imagine that Vision Corporation has 50,000 users, and the number is broken down as follows:
Total Users: 50,000
Expected Oracle Mobile Data Sync users: 1,000
Vision Corporation's users must adhere to a defined 9:00 a.m. to 5:00 p.m. schedule, so almost all of these 1,000 Oracle Mobile Data Sync users will probably synchronize during the first hour of the work day. Because it is difficult to judge when exactly these synchronizations will occur — there could be a peak point during the hour — let us do the calculations as if there are 2,000 Oracle Mobile Data Sync users.
Exaggerated total Oracle Mobile Data Sync users: 2,000
Peak concurrency (synchronizations each minute): (2,000 synchronizations) / (60 minutes) = 33.33 synchronizations each minute.
Number of FastCGI processes needed: (33.33 synchronizations each minute) / (3 synchronizations each minute each FastCGI process) = 11.11
For the sake of simplicity, and as this example uses exaggerated numbers to account for peak, if not extraordinary circumstances, let us round off that number down to ten FastCGI processes.
If Vision Corporation is running Oracle Collaboration Suite on two Applications tiers for load balancing and redundancy, then the default of five FastCGIs on each tier should be more than enough to handle extreme peak synchronization periods (Web client use aside).
Because a FastCGI process requires 20 to 30 MB of RAM, each tier would require about 125 MB of RAM for Oracle Mobile Data Sync.
Based on this example, and allowing for variance in synchronization times and lengths, the following table lists ranges of Oracle Mobile Data Sync users, suggested FastCGI numbers, and the amount of memory needed.
Plan on allocating about 100 KB of permanent hard disk space per Oracle Mobile Data Sync user to store mapping tables and device information (links database). Two MB of temporary hard disk space each concurrent user should be allocated to maintain information used across synchronization messages during a synchronization session (session database).
A standalone Oracle Mobile Data Sync instance, composed of a standalone Oracle HTTP Server and standalone Oracle Calendar application system, with only the Oracle Mobile Data Sync request handler enabled (not Oracle Calendar Web client and Oracle Calendar Web services) requires about 500 MB.
After consulting the table in the preceding section, experiment with your FastCGI numbers and architecture to determine the optimum settings for your needs. Do surveys of your employees to determine how many people are synchronizing, and when. Try and establish patterns for use — perhaps more people synchronize on Monday mornings, or perhaps you have workers in different time zones who synchronize at various times of day.
Check the Oracle HTTP Server error.log for messages indicating FastCGI overload, shown as follows:
Resource temporarily unavailable: FastCGI: failed to connect to server
FastCGI: comm with server "server_path" aborted
You should only run as many FastCGI processes as are necessary, in case there are other applications sharing tiers with Oracle Mobile Data Sync. For information on setting the number of FastCGI processes, see Oracle Calendar Administrator's Guide.
This section only provides a high-level overview of some post-installation tasks for Oracle Mobile Data Sync. Consult Oracle Calendar Administrator's Guide for detailed instructions on managing, configuring and maintaining all components of Oracle Calendar.
By default, Oracle Mobile Data Sync is enabled on an installation of the Oracle Calendar application system. To disable it, comment out the appropriate section of ocas.conf, as described in Customizing OCAS Components in Chapter 3 of Oracle Calendar Administrator's Guide.
This section contains the following topics:
The first thing to do when planning an Oracle Connector for Outlook deployment is to make sure you have access to supported version of Microsoft Outlook. These are listed in Appendix F, "Installing Oracle Collaboration Suite Clients" of the Oracle Collaboration Suite Installation Guide. Ensure that you also install the latest patches and service packs, as applicable. Microsoft Outlook 2000 must be used in Corporate Workgroup mode.
|
Note: Third-party Outlook add-ons can cause unexpected behavior in Oracle Connector for Outlook. If your organization uses and depends on third-party add-ons, then check with Oracle support to see if there are any known issues with them. |
Oracle Connector for Outlook supports Windows Roaming Profiles and Windows Server 2003 Terminal Services. Think about whether or not you want to use these technologies before you start deploying and installing Oracle Connector for Outlook.
This section contains the following topics:
As of 10g Release 1 (10.1.1), Oracle Connector for Outlook is certified to work with Microsoft Windows Roaming Profiles. Windows Roaming Profiles is the mechanism whereby a user's profile — including startup applications, shortcuts, desktop settings, and registry settings — are stored on and retrieved from a central network server. With Windows Roaming Profiles, a user can have access to their data from any network-enabled computer. Oracle Connector for Outlook must be installed on the local computers, but can be configured on login from startup scripts. Data is stored in specific folders that are mapped to the server, while registry information for users is retrieved from the server and set up locally on first login.
When using Windows Roaming Profiles, make sure that:
All workstations use the same versions and patches of Windows, Outlook and Oracle Connector for Outlook.
Oracle Connector for Outlook is deployed on all workstations using the same installation and configuration options.
Oracle Connector for Outlook offline folders are mapped to a location on the home drive. For example, Z:\profile_name\.
The default path for archiving should be mapped to a location on the home drive so that PST archives are available on every workstation. For example, Z:\profile_name\archive\.
Avoid accessing the same roaming profile from different workstations simultaneously, because this can lead to unexpected behavior.
As of 10g Release 1 (10.1.1), Oracle Connector for Outlook is certified to work with Windows Server 2003 Terminal Services. Terminal Services were conceived to provide organizations with a secure and cost-effective means of hosting Windows desktop sessions on a remote server. Remote users connect to a server through a desktop or Web interface and benefit from the full Windows experience without the overhead of running applications locally. Windows Server 2003 Terminal Services requires greater than normal bandwidth, and you must ensure that all drives are mapped correctly.
Consider using Terminal Services in combination with Roaming Profiles, such as when you have several Terminal Services servers running behind a load balancer. Without roaming profiles, each time a client is directed to a different server, a profile will have to be re-created for that client. With a roaming profile stored on the backend, this will not be necessary — the client will have access to its profile no matter what server it is directed to.
Not all fields of Oracle Connector for Outlook support the Unicode character set. This means that if clients of several different language sets are connecting to the same terminal server, unexpected behavior may result. Ideally, you should configure separate servers with different character sets as follows:
Western (English, French, Italian, Spanish, German)
Cyrillic (Russian, Hungarian)
Asian (Chinese, Japanese)
Greek
Arabic
Clients can be configured to connect to the server of the appropriate language.
There are three common methods for deploying Oracle Connector for Outlook across an organization. For details on installation steps, see Appendix F, "Installing Oracle Collaboration Suite Clients" of the Oracle Collaboration Suite Installation Guide.
This section contains the following topics:
Using Software Delivery Tools and Performing Silent Installations
Sharing the Oracle Connector for Outlook Installation Executable
This is the simplest method for end-users and the recommended choice for deploying Oracle Connector for Outlook. It requires using the Microsoft MSI installer with Microsoft Active Directory to deploy Oracle Connector for Outlook to workstations without requiring the user to log on with administrative rights. Each instance is deployed with the logon information of the user and server information extracted through Active Directory. MSI, which is extracted from the Oracle Connector for Outlook installation executable, can be used to copy over the binary files, install, reboot, and execute a PRF file to configure a user's profile. This can be done as a "silent install," where the user does not need to be involved in, or even aware of, the installation process.
Third-party software delivery tool technology enables administrators to then automatically upgrade users when needed, and even uninstall unauthorized (such as Beta) versions. Licenses must be acquired for whatever software delivery tool is used.
|
See Also: Oracle Connector for Outlook Maintenance for information on Oracle Connector for Outlook's automatic update feature. |
For details on performing silent installations, enabling elevated privileges for users without administrative rights, and using Microsoft MSI, see Appendix F of the Oracle Collaboration Suite Installation Guide.
|
Note: This feature only became available in release 10.1.3 of Oracle Connector for Outlook. |
This strategy is appropriate for organizations that have no established mechanism (such as Active Directory) for delivering new software to users. Administrators can extract a small, distributable executable from the Oracle Connector for Outlook package, and users can run the distributed executable, known as the Remote Installer, to download and install Oracle Connector for Outlook.
The Remote Installer is configured by the administrator to point to the full Oracle Connector for Outlook installation package, which can be stored on a Web site, FTP site, or shared network location. The Remote Installer itself can be distributed to users by e-mail or by placing it in a shared network location of its own.
The Remote Installer can additionally be configured to install Oracle Connector for Outlook with or without prompting the user, and use a command switch that calls a remote initialization (INI) file.
Users must have administrative rights to their computers to use the Remote Installer. No user-side configuration is necessary after installation of upgrades, or after full installations using an appropriately configured remote initialization (INI) file.
For information on extracting and configuring the Remote Installer, see Appendix F of the Oracle Collaboration Suite Installation Guide.
This method involves creating a base image that includes Oracle Connector for Outlook and installing it on all computers in your organization. The drawbacks to this method include:
It is not practical to reimage all computers in an organization.
User-side configuration is required, including entering passwords and specifying server names.
This method involves sharing the Oracle Connector for Outlook installation executable on a network. Users run the executable to install Oracle Connector for Outlook. This can cause a drain on bandwidth and, like with the Base Image method, requires user-side configuration after installation. Users must have administrative rights to their computers to use this method.
Consider using PRF files to configure profiles for your users. In addition to allowing you to pre-configure parameters such as server names and ports, PRF files provide a convenient way of implementing organizational policy for all users. For example, you may want to ensure the following things about the user profiles:
They preclude users from changing their passwords
They are populated with organizational information not modifiable by users
Sample PRF content is included in see Appendix F of the Oracle Collaboration Suite Installation Guide. Ensure that you customize the top part of this content appropriately.
|
Note: Users ofModprof.exe can still use this tool to create and modify Outlook 2000 profiles. However, Oracle strongly recommends using the Configuration Wizard that comes with Oracle Connector for Outlook. |
Other characteristics to plan on configuring in a deployment, whether through PRFs, Modprof.exe, or manually, include the following:
IMAP4 settings
POP3 settings
PST mail archive files
Enabling or disabling of e-mail virus scans
Backup software
Synchronization protocols (older synchronization tools require you to specify which protocol to use)
Third-party service provider settings
Ensure DNS is set up correctly and that the proper ports are used for mail, calendar and contacts, namely:
IMAP: 143
SMTP: 25
Calendar: 5730
POP3: 110
Oracle Connector for Outlook also supports SSL or TLS secure protocols on the appropriate ports.
To deploy using PRFs, you may want to write a script that does the following:
Prompts the user for a user name and password, then uses that information to run a PRF file to set up a profile for that user.
Runs a PRF file that not only sets up a profile but is also configured to acquire credentials from the system, though this is more difficult.
Have the user run the PRF to create the profile, after which the user will have to enter a login user name and password.
Automating deployment can be highly desirable, and you may want to combine some of the strategies mentioned here into one executable that, for example, silently installs Oracle Connector for Outlook then runs a script that configures profiles of users using PRF files.
Oracle Connector for Outlook includes a Configuration Wizard for configuring and creating PRF files and profiles. For information on the Configuration Wizard, working with PRF files, and configuring Oracle Connector for Outlook, see Appendix F, "Installing Oracle Collaboration Suite Clients" of the Oracle Collaboration Suite Installation Guide.
After installation, Oracle Connector for Outlook can further be configured using settings defined in the [OUTLOOK_CONNECTOR] section of the unison.ini file on the Oracle Calendar server. For example, use unison.ini to control how often the Global Address Book is downloaded to users' workstations. For further information, see "Controlling Client Behavior" in Chapter 3 of Oracle Calendar Reference Manual.
Oracle Connector for Outlook includes built-in logging functionality. Log information is stored on workstations of users. Users can set preferences for this by selecting Help on the Outlook main menu, then clicking About Oracle Connector for Outlook and Troubleshooting. Oracle recommends that at minimum, the default log settings be used.
Oracle Connector for Outlook 10.1.3 can be updated using its Automatic Update feature. (Versions prior to 10.1.3 do not support this.) With this feature, users can check for, download, and install updates from a centralized location whenever they are available. This can be done manually or automatically. Administrators must set up a Web site, FTP site, or shared network location in which to store updates, and make sure that Oracle Connector for Outlook installations point to this location. The Automatic Update feature can also be used to change Oracle Connector for Outlook configuration settings on users' computers. For more information, see Appendix F of the Oracle Collaboration Suite Installation Guide.
The Oracle Calendar desktop client can be deployed in similar ways to Oracle Connector for Outlook, such as by using software delivery tools, base images or shared executables. For example, you may want to deploy the Oracle Calendar desktop client for Macintosh using a base image shared by Macintosh users in your organization.
Oracle Calendar Sync is a simple application that can easily be installed by end-users.
The following topics describe deployment strategies for Oracle Calendar clients:
Deploying the Oracle Calendar Desktop Client with Windows Server 2003 Terminal Services
Deploying the Oracle Calendar Desktop Client to Local Computers
Deploying the Oracle Calendar Desktop Client on Shared Workstations
|
Note: Before undertaking any Oracle Calendar client deployment, check for supported platforms in Appendix F of the Oracle Collaboration Suite Installation Guide. |
The Oracle Calendar desktop client supports Windows Server 2003 Terminal Services with Citrix Metaframe XP Version 1.00. The advantage of deploying the Oracle Calendar desktop client in this way is that installation only has to be done once, and it is easy to control which versions have been deployed to users.
If you have remote users connecting to the server, then you may find that they experience slow performance, depending on the network capacity.
The Oracle Calendar desktop client supports silent installation. The advantage of this is that no interaction is required from users. For Windows platforms, you can perform customized silent installations by extracting the files from the Oracle Calendar desktop client installation executable and modifying unison.ini. For details on silent installations, see "Installing Calendar Clients" in Appendix F of the Oracle Collaboration Suite Installation Guide.
|
Note: Silent installation is only supported for the Windows and Linux/Solaris versions of the Oracle Calendar desktop client. |
Alternatively, you may choose to create a base image that includes the Oracle Calendar desktop client and is installed on all computers in your organization. This is easier than asking users to find a copy of the installation executable on the network. However some drawbacks to this method are as follows:
It is not practical to reimage all computers in an organization.
User-side configuration is required, including entering passwords and specifying server names.
Linux and Solaris installations of the Oracle Calendar desktop client place all required files within a single directory hierarchy without dependencies on the name or IP address of the host. This makes these two clients ideal candidates for a base image deployment.
Finally, you may choose to simply share an installation executable on a network. Users run the executable to install the Oracle Calendar desktop client. While this is a simple way to make the installation program available to users, it can cause a drain on bandwidth and, such as that with the base image method, requires user-side configuration after installation. Windows and Macintosh users must have administrative rights to their computers to use this method. The installation steps are simple and can be performed using a full graphical interface or a text mode interface.
One final issue to consider when deploying the Oracle Calendar desktop client is the use of shared workstations, such as in a library or on a public computer.
The Oracle Calendar desktop client stores user preferences and, optionally, local copies of agendas and address books on the computer on which it is installed. If various users log on to a computer using the same credentials and open their respective Calendar accounts using the Oracle Calendar desktop client, they must share the same Preferences. Also, each Calendar user will be prompted to locate their own database files (offline agendas and address books). The number of sets of database files is unlimited, so a periodic cleanup of the computer may be necessary.
Most users in these circumstances will not need offline access to their information and would probably be better off simply using the Oracle Calendar Web client. If this is not possible or practical, Oracle recommends that you disable Oracle Calendar desktop client offline address book functionality as follows:
For all users: Set offlineab to FALSE in the [LIMITS] section of the Calendar server's unison.ini file.
For all users on a specific computer: Set offlineab to FALSE in the local UNISON.INI file (not unison.ini). Do this in the following section of the file, according to your platform:
On Windows and Macintosh: [GENPREFS]
On Linux and Solaris: [LIMITS]
For further information, see "Controlling Client Behavior" in Chapter 3 of Oracle Calendar Reference Manual.
Installing Oracle Calendar Sync is a simple procedure and is described in "Installing Calendar Clients" in Appendix F of the Oracle Collaboration Suite Installation Guide. You can choose to share the installation executable on the network, or make it a part of your organization's base image so that users can install it as needed. Ensure that users already have their device and its accompanying software installed before installing Oracle Calendar Sync.
Oracle recommends that devices only be synchronized with one computer. Synchronizing a device with multiple computers can lead to unexpected behavior.
