|
Oracle® Application Server 10g Best Practices
10g (9.0.4) Part No. B12223-01 |
|
|
|
|
Oracle® Application Server 10g Best Practices
10g (9.0.4) Part No. B12223-01 |
|
|
|
|
This chapter describes best practices for Oracle Application Server Portal (OracleAS Portal). It includes the following topics:
This section describes installation, configuration, administration, and troubleshooting best practices. It includes the following topics:
To separate the database containing OracleAS Portal metadata from the database that the Identity Management infrastructure resides in, use the following steps:
Use Oracle Universal Installer to install and configure the Identity Management infrastructure.
Use the Oracle Application Server Repository Creation Assistant (OracleAS RepCA) to install the OracleAS Metadata Repository into an existing (customer) database.
Use Oracle Universal Installer or the Oracle Enterprise Manager Application Server Control to configure your OracleAS Portal middle-tier to use the Identity Management infrastructure and the OracleAS Metadata Repository installed in step one and two.
Oracle recommends against using ptlasst to create OracleAS Portal schemas in Oracle Application Server.
|
See Also:
|
If possible, use the OracleAS Portal Dependency Settings file, iasconfig.xml, and tool, ptlconfig, to perform middle-tier configuration. If you use ptlasst, the OracleAS Portal Dependency Settings file does not get updated. Using the iasconfig.xml file for subsequent configurations may cause your site to be mis-configured.
For more information refer to the Oracle Application Server Portal Configuration Guide.
The OracleAS Metadata Repository contains an OracleAS Portal database schema in which all the OracleAS Portal metadata, content, and PL/SQL code are stored. The PL/SQL code that executes in the OracleAS Portal schema generates diagnostic output that can be correlated with diagnostic output generated from other components of Oracle Application Server. Be sure to configure the database containing the OracleAS Metadata Repository to allow the output of the diagnostic log file. In addition, you must also register this log file with the Application Server Control to achieve the most holistic view of OracleAS Portal Diagnostics.
For more information about the OracleAS Metadata Repository and using the Application Server Control Console Log Viewer refer to the Oracle Application Server Portal Configuration Guide.
This section describes OracleAS Portal performance. It features the following topics:
Section 8.2.8, "Reduce Page Complexity to Improve Cachability"
Section 8.2.9, "Measure Tuning Effectiveness to Improve Performance"
OracleAS Portal provides two different caching mechanisms to improve performance:
Out-of-the-box integration with OracleAS Web Cache using in-memory cache solution
Persistent file-based cache
By default, OracleAS Portal issues dynamic caching instructions to OracleAS Web Cache so that default content (such as pages) can be cached. The page designer can use the different cache options (whole page, page definition, or none) to ensure that the correct balance is maintained between speedy delivery of cached content and avoiding the delivery of stale content. It is important that the page or portlet designer understand that the degree of dynamism of a Web page is inversely proportional to its cachability. Page designers should fully understand validation, expiration, and invalidation-based caching so that they can select the most appropriate cache method for their pages.
The OracleAS Portal file-based cache is always maintained alongside OracleAS Web Cache, providing redundant cover should the in-memory solution fail. The file-based cache is also useful for things like persistent sessions. When you need to maintain a record of either an authenticated session or perhaps a session context as part of a larger atomic transaction. You can improve file-cache performance by locating the cache on a RAM disk, especially the session cache for cached session cookies. The session cache benefits the most from this approach, as this area of the cache suffers a high input-output load in a heavily subscribed secure portal.
OracleAS Portal has enhanced its page caching options in Oracle Application Server, introducing the ability to cache page and portlets at the system level, thus storing a single copy of each object for all users. Here are the page caching options available in OracleAS Portal:
With this option, you can create a cached copy of the page definition in both OracleAS Web Cache and the OracleAS Portal cache for each user. The page definition includes:
Metadata describing the page structure
Identification of the portlets that the page contains
Style information for the page
Choose this option for the following types of pages:
Pages with highly dynamic content
Pages that contain portlets with short expiry periods
Pages that contain portlets using validation-based caching or invalidation-based caching
Cache Page Definition And Content For [ ] Minutes
With this option, you can create a cached copy of the page definition and page content, including the rendered content of all portlets, for a specified period. The fully assembled page is cached by the Web browser and in the OracleAS Portal cache. Choose this option for pages with more static content and long expiry periods. If you select this option, you may want to include a Refresh link on the page to regenerate the page content from the database.
Cache Page Definition Only at System Level
By using this option, you can create a single cached copy of the page definition in the system cache for all users. Because the page definition is the same for all users, page customization options are disabled. This caching option greatly reduces storage requirements and improves performance. Select this option for pages with highly dynamic content as long as they do not require customization.
Cache Page Definition And Content at System Level for [ ] Minutes
With this option, you can create a single cached copy of the page definition and page content, including the rendered content of all portlets. The cached information remains the same for all users in the system cache for a specified period. Page customizations are not possible because the page definition and content is the same for all users. Select this option for pages that are more static and unlikely to change within the specified period. Note that with this option, portlets display public content only. If you select this option, you may want to include a Refresh link on the page to regenerate the page content from the database.
Do not Cache
Use this option to disable page caching. If you select this option, it may adversely affect your OracleAS Portal performance, as dynamic page generation places a heavy load on both the database and the middle tier.
By default, OracleAS Web Cache is installed, configured, and co-located with the OracleAS Portal middle-tier. For optimal performance, deploy OracleAS Web Cache on a dedicated computer.
A performance-related enhancement in OracleAS Portal is the ability to cache portlets at the system level, which places a single copy of the portlet in the system cache for all users.
Before caching portlets at the system level, consider the following:
Caching a portlet at the system level disables all customization options for the portlet.
Caching a portlet at the system level does not enforce access privileges for the portlet.
Caching a portlet at the system level means that only public data is displayed. Therefore, portlets such as the Recent Objects portlet or the External Applications portlet, which do not contain public data, are not displayed.
If a page is cached at system level, and that page happens to contain a portlet, then that portlet is also cached at the system level.
If the Web provider specifies system-level caching for a portlet, then the portlet is cached at the system level. However, you have the option to change the cache setting for the portlet manually.
If a portlet is not cached at the system level, but the page on which it appears caches both the page definition and the content, then this portlet is cached at the user level. With user-level caching, the portlet can be customized and access privileges can be enforced.
In summary, do not cache a portlet at the system level if that portlet includes sensitive data or other information that you do not want to display to all users. Examples of content that may be suitable for system-level caching include page banners and news portlets.
There are two different types of providers: Web providers and database providers. Using the right type of provider for your portlets can help improve your portal performance.
Database providers are implemented in Java or PL/SQL and are executed as stored procedures within the Oracle database. The OracleAS Portal middle-tier communicates with these providers in two ways:
through mod_plsql, if the provider resides in the local OracleAS Portal database
by SOAP over HTTP, if the provider resides in a remote database
Note that a portlet that executes in the database is not restricted in terms of functionality, as database facilities allow for external communication in many ways, including HTTP connections to external content. Database providers are particularly appropriate for portlets that require significant interaction with the database, and in situations where the development team has extensive Oracle PL/SQL development experience.
Web providers are implemented in any Web deployment environment (for example: Java, ASP, or Perl) and are executed as applications external to OracleAS Portal. OracleAS Portal communicates with these providers using SOAP over HTTP. Web providers are most appropriate for external information sources (for example: Internet news, business information) and in environments where developers have experience using Java and other Web development languages.
OracleAS Portal provides a parallel page engine (PPE) stateless servlet that fetches page metadata, assembles the page, and manages the cache. Because it is stateless, PPE is a key worker component that can be deployed across multiple OC4J instances.
By default, Oracle Application Server is installed with a single oc4j_portal instance in which the PPE servlet is deployed. From a scalability perspective, it is highly recommended that you have at least one other (if not more) OC4J instance that also has the PPE servlet deployed. Alternatively, you can increase the number of OC4J processes dedicated to the single instance. Oracle HTTP Server load balance routing distributes requests across the multiple instances or processes, providing better scalability for the entire system.
OracleAS Infrastructure 10g, including the database, provides important functionality to OracleAS Portal, as all metadata, database providers, and infrastructure entities reside there. Because of this heavy dependency on the database, conventional database tuning, such as putting OracleAS Portal indexes on a separate disk, becomes extremely important to optimize OracleAS Portal performance. However, it is not recommended that you analyze the schema for additional tuning opportunities, as this analysis has already been performed for you by the CBO (Cost Based Optimizer) and has been used where appropriate. Moreover, there are also standard ongoing jobs that re-tune the schema based on collected statistics on a regular basis.
Another aspect of tuning is the SQL*NET tuning between the mod_plsql (for example, Oracle HTTP Server) computer and the database itself. You should also consider RAC as an option for the availability and scalability of the OracleAS Portal database.
mod_plsql maintains its own connection pool, thus removing the need for the use of MTS in most cases. There are, however, some tuning parameters that you can adjust to optimize mod_plsql performance and ensure that processes are not shut down heavily:
Set MaxClients=MaxSpareServers=average system load
Set MaxRequestPerchild=10000
Set MinSpareServer=1
Set KeepAlive to off for heavily loaded sites
Tuning these parameters affects the performance of Oracle HTTP Server with respect to non mod_plsqlrequests.
Therefore, if you wish to service other types of requests with the same installation, you can employ a dual listener strategy: Start two Apache listeners, one tuned for standard content requests, and the other tuned for mod_plsql content requests. You can find more information about this approach and other factors in the mod_plsql section of the Oracle Application Server 10g Performance Guide.
When you register a Web provider, you can use a checkbox to cache session-specific information, such as session id and user login time, for each request. Although this is a mandatory requirement for Web providers that rely on session information to ensure the validity of atomic transactions, providers that do not rely on this information should deactivate this option, as doing so improves the portlet cache hit rate.
End user perception of the performance of a page is related to several factors. One of the most obvious factors is the performance of individual portlets. A single slow portlet can slow down the end-user perception of the performance of a whole page. This is because portlets are executed in parallel and the page will not be returned to the user until the slowest portlet either returns content or times out.
Page execution speed, therefore, is equal to the speed of the slowest portlet, plus page assembly overhead.
If you are noting performance issues with a page try using the _DEBUG utility. Refer to the Oracle Application Server Portal Configuration Guide for more information.
Page complexity, which is a function of page security and the number of tabs, items, and portlets on a page, affects throughput by increasing the amount of metadata that needs to be generated as well as the number of security and validity checks. Page complexity does not affect page assembly time in the middle-tier, but may affect the time it takes to validate and refresh portlet content.
One way to evaluate whether your attempts to improve performance are effective is to measure the performance, then use those measurements to further fine tune the system.
To get granular results from system internals, append &_DEBUG=1 to the end of the portal page URL for which you wish to measure performance. The output is a report from the parallel page engine that provides details of performance of each component on the page, whether a cache miss or hit occurred, and how long page loading took.
Repeating this practice periodically will help keep your system fine-tuned for better performance. You can read more about the information provided by _DEBUG in the Oracle Application Server Portal Configuration Guide.
This section describes performance features for OracleAS Portal. It includes the following topics:
The PPE uses the concept of fetcher threads. These are threads within the PPE servlet which are used to service requests for portlet content. By default there are 25 fetcher threads within the PPE waiting to service requests. If a page has 26 portlets and that page is requested then 25 of the portlets will be requested in parallel and the 26th request will wait for the next available fetcher thread.
This serialization effect will ultimately slow down the portal performance as more requests are received. This degradation will affect the whole portal site, to combat this at a more granular page level OracleAS Portal introduces a feature called Managed Portlet Execution (MPE).
This feature provides a throttle effect similar to fetcher threads but on a per-page basis. If a page has 25 portlets 20 will run the other 5 will wait for free slots then they will run, in effect they'll be throttled.
MPE is set to 20 by default, but this is a configurable parameter allowing administrators to ensure that the performance of the whole site is not degraded by over-zealous page designers putting excessive quantities of portlets on one page.
The file cache under $ORACLE_HOME/Apache/modplsql/cache in the Oracle Application Server middle-tier installation has been enhanced so that it now has a sub-directory for explicit storage of the page metadata (PMD). The separate storage of the PMD allows the cleanup processes to be more explicit in their selection of content to be pruned.
Cleanup is now controlled by new explicit parameters:
PlsqlCacheMaxAge 30
PlsqlCacheCleanupTime Saturday 23:00
PMD content will be given preferential retention treatment ensuring the greatest cache hit ratios occur for PMD objects. These objects are the most expensive to generate and the least likely to change in a running production site.
When a document is cached in OracleAS Web Cache it is cached using an invalidation basis. This means the content is stored in OracleAS Web Cache until it is explicitly invalidated by a SOAP message issued by the portal repository. Prior to OracleAS Portal, the portal repository needed to issue a single invalidation message for each piece of content that had changed for each possible cached element.
If a page based on a template is secured and cached on a per user basis for 10 users and the template is changed then the portal must issue 10 invalidation messages.
OracleAS Portal introduces a concept of search key invalidation where the content is cached with a common identifier (search key) that allows the portal repository to issue one invalidation message for the content with the common identifier thus invalidating all the content that matches that key with a single message.
The section describes content management and publishing best practices. It includes the following topics:
Section 8.4.1, "Use a Single Page Group for Delegating Administration"
Section 8.4.2, "Research Your Taxonomy Before Building Up a Page Hierarchy"
Section 8.4.4, "Use Navigation Pages to Manage Template Content"
Section 8.4.5, "Categories, Perspectives, and Custom Attributes"
Section 8.4.6, "Understand how Multilingual Content is Managed"
Section 8.4.8, "Use Content Management APIs to Migrate Existing Content"
Section 8.4.9, "Use WebDAV Capabilities to Support Desktop Application Centric Users"
OracleAS Portal allows you to organize portal pages within page groups. The easiest way to get started is with a single page group. Within a page group, you can easily copy or move content elements across pages.
However, in a larger environment, you may want different people to administer different areas of the site. Delegating administration is much easier if you separate your site into multiple page groups.
Currently, it is not possible to copy or move content elements between page groups, or to use templates, styles, and metadata elements (categories, perspectives, attributes, and item types) owned by one page group in another page group. However, if you want to use templates, styles, and metadata across page groups, you can place them in the supplied Shared Object Page Group. In addition, any page can be published as a portlet, which allows the content on that page to be viewed on any other page in any page group.
For more information about configuration and administration refer to the Oracle Application Server Portal User's Guide.
There are several different ways to organize the content that your portal needs to provide to its end users. This organization is referred to as a taxonomy. You can create a physical taxonomy consisting of pages and sub-pages. You can also create virtual taxonomies consisting of categories and perspectives. Users can browse a taxonomy, which appears as a hierarchy of pages. Each category and perspective page is built dynamically by searching for content belonging to the selected category or perspective when the page is rendered.
Reorganizing the physical taxonomy is easy and can be done by moving pages around within a page group and by moving items between pages (keep in mind that pages and items cannot be moved between page groups). However, reorganizing category and perspective values is not currently supported. Although you can reassign content to a different category or perspective, this must be done manually for each piece of content or programmatically by using the content management APIs. Therefore, carefully plan your category and perspective hierarchies before you start to add content to your pages.
For more information refer to the Oracle Application Server Portal User's Guide.
Creating pages with OracleAS Portal is easy, and it may be tempting to start adding pages quickly at the onset of your portal development project without first defining one or more page templates. To ensure a consistent look and feel to your site and to minimize maintenance effort, it is recommended that you always base your pages on page templates. You can keep this association for the lifecycle of the page in order to enforce a specific look and feel, control the page creation process and minimize maintenance efforts. Alternatively, you can use a page template as a convenient starting point for creating a custom page layout. In this use case, you would create the page using a template (thus inheriting the page layout and region property settings), disassociate the page from the template and make page unique changes to region properties and layout. Keep in mind that you can always re-apply the template to the page or apply a new template if required.
It is also a good practice to manage your templates that could be used in multiple page groups in the Shared Objects page group, as templates cannot be promoted from another page group to Shared Objects.
For more information about OracleAS Portal page templates refer to the Oracle Application Server Portal User's Guide.
A page template defines the layout (the placement of item and portlet regions) for pages. A template can also contain content, in the form of portlets and items that you want to appear on all its pages. However, changes made to a template are seen immediately in its dependent pages. Making changes to the content on a template can take minutes or even hours, depending on the extent of the changes. During this time, the pages themselves will be in a state of flux as the template is modified. This can have an undesirable impact on your portal users and may require that the affected pages be unavailable while performing template maintenance.
You can avoid this by managing template content on navigation pages. For example, use a navigation page to contain the banner for your template, which may include such elements as the Page Name Smart Text, company logo, and various Smart Links such as the Customize icon and the Home Page link. When you want to modify the banner, copy the navigation page and make changes to the copy. When you are satisfied with the changes, replace the original banner navigation page portlet on the template with the modified copy. This can be done very quickly and will have minimal impact on portal users. The same recommendation applies to navigation bars, page footers, and other content that you want to include on the template.
For more information navigation pages refer to the Oracle Application Server Portal User's Guide.
One of the big advantages of OracleAS Portal is the ability to define and associate metadata with any content. OracleAS Portal provides three types of metadata:
Categories: Used for mutually exclusive properties like "What is it?"
Perspectives: Used for content that may require multiple properties values like "Who is the audience?"
Custom Attributes: Used for other mutually exclusive properties
It is important to understand the characteristics of these metadata elements in terms of their impact on content organization, maintenance, presentation, and search. For example, while they all aid in searching for content, each has a different style for search submission and for presentation in search results. There are also important differences in terms of how content contributors assign metadata values to content and in how these elements are presented on pages.
Table 8-1 summarizes the characteristics of the metadata elements.
Table 8-1 Metadata Element Characteristics
| Characteristic | Custom Attributes | Categories | Perspectives |
|---|---|---|---|
| Can be mandatory on Add/Edit item | Yes | Yes | Yes |
| Can be selected for Group By in Region display | No | Yes | No |
| Can be arranged in a navigable hierarchy | No | Yes | Yes |
| Allows multiple values for a single item | No | No | Yes |
| Select values from Static List of Values | Yes | Yes | Yes |
| Select values from Dynamic List of Values (based on SQL Query) | Yes | No | No |
| Can be associated with an icon | No | Yes | Yes |
| Searchable | Yes | Yes | Yes |
| Can be shown in Item display | Yes | Yes | Yes |
| Can be shown in Search Results | Yes | Yes | Yes |
| Can be used to order a custom query (using SQL against the WWSBR_ALL_ITEMS repository view) | No | Yes | No |
| Translatable | Yes | Yes | Yes |
| Data types | Boolean, Date, File, Number, PL/SQL, Text (Single or Multi- Line), URL | Text Only | Text Only |
OracleAS Portal allows you to store, manage, and publish translations of your portal content. Many of the objects that are managed in your portal can be associated with one or more languages in addition to the default language defined for a page group. Translated content is automatically published to viewers of your portal in their selected language.
Although the translation feature is very useful and powerful, it is important to understand how translations are created, managed, published, and queried. In particular, the impact of creating or editing an object in a non-default language should be made clear to your content contributors and portal users. Listed below are several characteristics of the translation feature that are important to understand.
When edits are unintentionally made to an object in a language other than the default language, the edits may appear to be lost when the object is viewed in the original, language. Content contributors may not realize that multiple language records can exist for a single object.
When a non-translatable attribute is edited, the value of the attribute is automatically copied to all language records. The content contributor may wonder why the attribute value has suddenly changed after switching to a different language.
Editing a translatable attribute does not copy the change to all language records. In this case, the content contributor may be concerned that all changes were lost when viewing the object in a different language.
Translations may exist for one version of an item, but not for another version. If the current version changes, it may seem as if the translation has been lost.
The OracleAS Portal page editing capabilities allow you to create complex page structures and a compelling user interface for a wide range of collaborative and Intranet-based portal configurations.
However, if your portal page calls for a sophisticated graphic design, you can use Unstructured User Interface Templates (also called UI Templates) to help you achieve that design. A UI Templates is HTML code, created in any HTML authoring tool, for the purpose of surrounding an OracleAS Portal page. By placing special OracleAS Portal substitution tags in your HTML, you can place portal elements such as Sub-Page links, an Edit Page link, a Navigator link and other elements common to a portal page directly in your HTML code. The only requirement for an HTML page to be used as an Unstructured UI Template is the inclusion of the Oracle Application Server substitution tag, #BODY#. The location of the #BODY# tag in the HTML determines where the OracleAS Portal page itself will be rendered. At runtime, this UI Template is combined with the dynamically generated content of the portal page to produce the final result.
By using this technique, you can apply virtually any corporate look to your portal pages, even if this design would not be achievable using the regular portal page design capabilities.
Unstructured UI Templates are created and maintained under Portlet Providers > Locally Built Providers > Shared Components > User Interface Templates in the Navigator.
Before using an Unstructured UI Template on a page, the page Page Group properties must be configured to enable UI Templates. Once this is done, use an option on the Page Properties > Other tab to select a UI Template for the page. Note that the option to select a UI Template is available only for pages that do not have a Template specified on the Page Properties > Template tab. If you would like to use a UI template and a page based on a template together, then the UI Template must be applied to the page template which can then be applied to the page.
For more information about unstructured UI Templates refer to the Oracle Application Server Portal User's Guide.
When setting up your portal, you may find that you want to load and attribute directory/file structures that exist on a file system into the portal repository. While it is very time consuming to upload and set the attribution for every file using the Web browser interface, there is an alternative. You can use Content Management APIs.
Functions include:
add_item: uploads a file from the file system and adds a new item to an item region
modify_item: allows you to set the attribution for an existing item and helps you perform content management task programmatically without any Web browser-based interaction
All of the files you plan to upload using the APIs must be accessible from the same file system as the installed Portal Metadata Repository.
OracleAS Portal supports the use of WebDAV clients, such as Microsoft Web Folders, to access the Portal Metadata Repository. This allows users to directly edit a document (like an MS Word document) on a portal page and save it back to the repository without ever having to download or upload the file. It also allows users to publish files located on the local file system to a portal page directly from the Windows Explorer, as well as to delete, copy, or move those files. The same security settings found in the Web browser-based interface are also enforced in the WebDAV environment, using OracleAS Single Sign-On to authenticate to Portal.
For more information refer to the Oracle Application Server Portal User's Guide.
This section describes export and import best practices. It includes the following topics:
Section 8.5.1, "Review Supported Use Cases Before Performing an Export or Import"
Section 8.5.2, "Follow the Guidelines for Export and Import of Portal Objects"
OracleAS Portal provides a set of export and import utilities to enable you to copy portal content between portal installations. For example, you might use these utilities to copy or update portal page groups and application components between a development instance and a production instance of OracleAS Portal.
It is critical to understand that the provided OracleAS Portal export and import utilities support a specific set of use cases and usage scenarios. Oracle recommends reviewing Oracle Application Server Portal Configuration Guide before beginning the page and content design process for your portal if regular export and import of content between portal instances is a requirement. Oracle Application Server Portal Configuration Guide provides an overview of the export and import process and key concepts.It also describes the two most common export and import use cases:
Importing and exporting between development to production instances
Deploying identical content across multiple portal instances
For best practices and recommendations for export and import of the objects defined within OracleAS Portal, refer to the Oracle Application Server Portal Configuration Guide. It describes best practices for:
Migrating Your Users and Groups
Migrating Your Page Groups and Components
Migrating Your Web Providers
Migrating Your Portal DB Providers and Components
Migrating Your Search Components
Migrating Your External Applications
Migrating Your Portal Across Databases
For additional support updates and support information go to Oracle MetaLink (http://metalink.oracle.com).
