|
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2) B28654-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2) B28654-01 |
|
|
Previous |
Next |
This chapter describes best practices for OracleAS Portal. It includes the following topics:
This section contains the following topics:
For greatest flexibility with your upgrade, you should deploy, patch and test any custom portlet providers (whether they are Oracle PDK-Java providers, WSRP producers, or JSR-168 providers) to their own OC4J instance. Ideally, put this OC4J instance in a separate Oracle home from your OracleAS Portal middle tier. Generally, you upgrade and patch Java applications at a much greater frequency than an Enterprise Oracle Portal middle tier. Therefore, using a separate Oracle home or OC4J instance will make this process easier.
Implementation Details
To implement a portlet provider OC4J instance in a development environment:
Follow the instructions in Appendix A, "Installing OracleAS Developer Kits," in the Oracle Application Server Installation Guide.
Follow Section 6.3.1.2, "Configuring without the Portal and Wireless Option," in the Oracle Application Server Portal Developer's Guide
To implement a portlet provider OC4J instance in a test or production environment:
Follow the instructions to install a J2EE and Web Cache middle tier in Chapter 7, "Installing Middle Tiers," in the Oracle Application Server Installation Guide.
Follow Section 6.3, "Configuring Your Application Server to Run JPS-Compliant Portlets," in the Oracle Application Server Portal Developer's Guide
The default installation of Oracle Application Server 10g Release 2 (10.1.2.0.2) Portal and Wireless instance includes an OracleAS Portal 10g Release 2 (10.1.2.0.2) instance. Oracle Application Server 10g Release 2 (10.1.2.0.2) also ships with the Oracle Application Server Portal Upgrade CD-ROM, which enables you to upgrade the OracleAS Portal Repository from release 10.1.2.0.2 to release 10.1.4.
OracleAS Portal 10g Release 2 (10.1.4) represents a major step forward in the evolution of OracleAS Portal and as such, will provide significant value to customers. Key themes for this upgrade release include:
Comprehensive Fusion capabilities for better business agility
Unleash the power of portal content management and publishing, as well as enable sophisticated, flexible and highly performant architectures, and out-of-the-box portal solutions
Implementation Details
To upgrade from 10g Release 2 (10.1.2.0.2) to 10g Release 2 (10.1.4):
Install Oracle Application Server 10g Release 2 (10.1.2.0.2) Portal and Wireless.
Upgrade the repository to OracleAS Portal 10g Release 2 (10.1.4) using the Oracle Application Server Portal Upgrade CD-ROM.
This section contains the following topics:
Section 5.2.1, "Use Appropriate Caching Strategy to Improve Performance"
Section 5.2.2, "Use Providers Judiciously to Improve Portal Performance"
Section 5.2.3, "Use Parallel Page Engine to Improve Availability and Scalability"
Section 5.2.4, "Scale OracleAS Portal to Optimize Performance"
Section 5.2.5, "Use Repository Services to Remove the Need for mod_plsql Tuning"
Section 5.2.6, "Leverage Web Provider Session Caching to Improve the Portlet Cache-hit Rate"
Section 5.2.7, "Increase Perceived Execution Speed to Improve Performance of Portlets"
Section 5.2.8, "Reduce Page Complexity to Improve Cacheability"
Section 5.2.9, "Measure Tuning Effectiveness to Improve Performance"
Section 5.2.10, "Manage Portlet Execution For Each Page to Prevent Portal Slow-Down Issues"
OracleAS Portal provides two different caching mechanisms to improve performance:
Out-of-the-box integration with OracleAS Web Cache using an in-memory cache
Persistent file-based cache
By default, OracleAS Portal issues dynamic caching instructions to OracleAS Web Cache, permitting the default content, such as pages, to be cached. The page designer can use the different cache options, such as whole page, page definition, or none, to ensure that the correct balance is maintained between enabling the 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 cacheability. Page designers should fully understand validation, expiration, and invalidation-based caching so that they can select the most appropriate cache method for their pages.
OracleAS Portal enables the page designer to cache page and portlets at the system level, thus storing a single copy of each object for all users. The following are the page caching options available in OracleAS Portal:
Cache Page Definition Only
With this option, the page designer can create a cached copy of the page definition in bothOracleAS 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, the page designer can create a cached copy of the page definition and page content, including the rendered content of all portlets, for a specified period. The OracleAS Portal cache and the Web browser cache the fully assembled page.
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, the page designer 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, the page designer 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. As a page designer, 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. Selecting this option may adversely affect the performance of OracleAS Portal, 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.
Page Portlets Cached Independently (New Feature)
In previous releases, page portlets were treated differently from other portlets-every page portlet was flattened directly into the page metadata of the containing page. Page portlets are now handled like all other portlets. You can cache a page portlet independently; however, changing the portlet content invalidates the cache..
Portlet Caching
OracleAS Portal enables you 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, do not display.
Caching a page containing a portlet at the system level caches both the page and portlet at the system level.
A Web provider that specifies system-level caching for a portlet sets the portlet to cache at the system level. You have the option to change the cache setting for the portlet manually.
If you do not cache a portlet at the system level, but you place the portlet on a page that caches both the page definition and the content, then you cache the portlet at the user level. With user-level caching, you can customize portlet and enforce access privileges.
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.
Declarative Portlet Caching (New Feature)
Page designers can now define or override the caching policy of any portlet instance using a new feature. Simply navigating to the instance options for the portlet on a page will allow a page designer to override or specify caching options for a portlet instance.
Using the Force Portlet to be cached for N minutes option allows the page designer to ensure that the portal will cache a portlet for a period of time using expiry based caching. Even if the portlet implements no caching this feature will allow a page designer or administrator to implement some form of caching.
Partial Page Refresh (New Feature)
You can set a portlet to refresh without refreshing the entire contents of the page. Partial page refreshing prevents unnecessary client-side requests and also improves the page viewing experience as pages no longer flash as they disappear and reappear.
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.
You can implement database providers in Java or PL/SQL, which execute as stored procedures within the Oracle database. The OracleAS Portal middle tier communicates with database providers in two ways:
Through Repository Services, if the provider resides in the local OracleAS Portal database
By SOAP over HTTP, if the provider resides in a remote database
Note that OracleAS Portal does not restrict a portlet that executes in the database 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.
You can implement Web providers in any Web deployment environment (for example: Java, ASP, or PERL) and execute 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.
You can write Web providers using the PDK provided by Oracle or using WSRP and JSR 168 as open development standards for portlets.
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 you can deploy across multiple OC4J instances.
By default, Oracle Application Server installs with a single oc4j_portal instance in which the PPE servlet is deployed. From a scalability perspective, Oracle recommends that you have at least one OC4J instance where you have deployed the PPE servlet. 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, 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's performance. Oracle does not recommend that you analyze the schema for additional tuning opportunities, as the Cost-Based Optimizer (CBO) has already performed his analysis for you and used it 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 Oracle Net tuning between the Repository Services computer, such as Oracle HTTP Server, and the database itself. You should also consider Real Application Cluster (RAC) as an option for the availability and scalability of the OracleAS Portal database.
Prior to OracleAS Portal 10g Release 2 (10.1.4), Oracle recommends tuning the mod_plsql request process could be carried out to improve performance of repository bound activities. OracleAS Portal 10g Release 2 (10.1.4) no longer uses mod_plsql to make database calls. Instead, it uses something called Repository Services—a servlet component of the Portal Services servlet that maintains its own connection pool. There is no use of mod_plsql for OracleAS Portal requests to the database.
When you register a Web provider, you can 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. Doing so improves the portlet cache-hit rate and reduces the time taken to initiate the portlet request as there is no attempt to instantiate a remote session with the provider, which can be a costly step.
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. The slow refresh occurs because portlets execute in parallel and the page does not refresh for 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. OracleAS Portal 10g Release 2 (10.1.4) includes a new feature that provides a solution to this problem from the perspective of a page designer, called Page Assembly Timeout. This feature enables page designers to define a maximum page creation time. The option limits the amount of time the server delays page display while it assembles portlets. If OracleAS Portal does not assemble a portlet within the specified time, the portlet appears after the page displays, using partial page refreshing.
This option is useful for pages known to have potentially slow portlets, perhaps one that is running remotely on a slow server far away.
If you are noting performance issues with a page try using the _DEBUG utility.
Implementation Details
Page complexity, which is a combination 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 obtain specific 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.
Implementation Details
The PPE uses the concept of fetcher threads, which are threads within the PPE servlet that 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).
MPE provides a throttle effect similar to fetcher threads, but for each page. For example, if a page has 25 portlets, 20 will run and the other five will wait for free slots before running; in effect, these five are throttled.
MPE is set to 20 by default, but this is a configurable parameter enabling 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.
OracleAS Portal 10g (10.1.4) includes a new, more specific engine management feature for page portlets accessible through the parameter maxParallelPagePortlets, which restricts the maximum number of page portlets the system as a whole will process. This feature enables you to stop deeply nested pages from using all the available request threads and also to prevent the processing of recursively nested pages before all threads are used.
While Repository Services has replaced mod_plsql for backward compatibility, the persistent caching of content within the middle tier still uses the same file structures as when implemented within mod_plsql, therefore the following advice applies
The file cache under $ORACLE_HOME/Apache/modplsql/cache in the Oracle Application Server middle tier installation has a subdirectory 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:
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 you set a document to be cached in Oracle Web Cache, it is cached using an invalidation basis. This means the content is stored in Oracle Web Cache until it is explicitly invalidated by a SOAP message issued by the OracleAS Portal Repository. Prior to OracleAS Portal 10g Release 2 (10.1.4), the OracleAS Portal Repository needed to issue a single invalidation message for each piece of content that had changed for each possible cached element.
For example, suppose you base a page on a template, secure that page and cache it on for each user for 10 users, and then change that template. The portal must then 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 OracleAS 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.
This section contains the following topics:
Section 5.3.2, "Research Your Taxonomy Before Building Up a Page Hierarchy to Save Rework Time"
Section 5.3.3, "Use Portal Templates to Improve Consistency"
Section 5.3.4, "Use Navigation Pages to Manage Portal Template Content"
Section 5.3.5, "Use Categories, Perspectives and Custom Attributes to Enhance Content Metadata"
Section 5.3.6, "Use Translations to Create Multilingual Web Sites"
Section 5.3.8, "Use Content Management APIs to Migrate Existing Content"
Section 5.3.9, "Use Content Management APIs to Organize Content"
Section 5.3.11, "Use the Public Search API to Implement Custom Searches"
Section 5.3.12, "Use WebDAV Capabilities to Support Desktop Applications Centric Users"
Section 5.3.13, "Use HTML Templates to Create Pixel-Perfect Pages"
OracleAS Portal enables 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.
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.
Implementation Details
To enhance the sharing and reuse of objects between page groups, consider creating templates, styles, and item types in the supplied Shared Objects 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.
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. OracleAS Portal dynamically builds each category and perspective page by searching for content belonging to the selected category or perspective when rendering the page. Planning your taxonomy in advance saves rework at a later date.
Implementation Details
It is easy to reorganize the taxonomy by moving pages around within a page group and by moving items between pages. Keep in mind, however, that you can move items between pages in different page groups when the item type is shared between page groups, but you can move pages only within the same page group.
OracleAS Portal does not currently support reorganizing category and perspective values. Although you can reassign content to a different category or perspective, you must manually do so 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.
You can use portal templates to provide consistency for both pages and item content. Since both portal pages and portal items are both accessible by URL, as you navigate around your portal, using a similar template for both pages and items enables you to maintain a consistent look and feel.
It is also a good practice to manage your portal templates that could be used in multiple page groups in the Shared Objects page group, as the Shared Objects page group is the only page group. These contents can be shared with all customer-created page groups.
Implementation Details for Page Consistency
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 portal templates. To ensure a consistent look and feel to your site and to minimize maintenance effort, Oracle recommends that you always base your pages on portal 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.
To implement this best practice:
Create a portal template in the Shared Objects page group. Doing so allows the template to be used by all page groups within your portal installation.
Define your page structure and add common content. You can manage common content with navigation pages. (See Section 5.3.4, "Use Navigation Pages to Manage Portal Template Content" for more information.)
Assign templates to pages during page creation in step two of the Create Page wizard, or for pre-existing pages you can specify the usage in the Template tab within the Page Properties.
Implementation Details for Page Starting Point
Alternatively, you can use a portal template as a convenient starting point for creating a custom page layout. For example, you could 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.
To implement this best practice:
In the Page Properties for the page that should use a template as a starting point, set the page to use the template that will be used as a starting point..
Click the Detach From Template link.
Implementation Details for Item Consistency
You can also use portal templates to surround item content with consistent decoration just like portal pages can use templates for consistent decoration. This way, you can display item content that is called directly with a consistent look and feel.
To implement this best practice:
Create a Portal Template in the Shared Objects page group. Doing so allows the template to be used by all page groups within your portal installation.
Define your page structure and add common content.
Within the Portal Template region that you want items to show, add an item of type Item Placeholder. Choosing default content for the Item Placeholder is optional. This content displays if the template URL is called directly from a browser.
To specify for items to use this template, go to the page where the items reside. In the page properties, click on the Items tab. Within the the Portal Template Assignment section you can choose a template for all items on the the page to use. If desired, you can enable items to choose their own template by checking the Allow items on this page to use a different Portal Template checkbox.
Test the template by entering the Item's URL directly into the browser address bar.
|
See Also: Section 13.2, "Working with Portal Templates for Pages and Items," in the Oracle Application Server Portal User's Guide |
A portal 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. Making changes to a template immediately displays on 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 a negative impact on your portal users and may require that the affected pages be unavailable while performing template maintenance.
Implementation Details
You can avoid this impact 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.
To implement this best practice:
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. You can do this very quickly with 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.
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.
Implementation Details
Table 5-1 summarizes the characteristics of the metadata elements.
Table 5-1 Metadata Element Characteristics
| Characteristics | Custom Attributes | Categories | Perspective |
|---|---|---|---|
|
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 |
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 |
|
See Also: Section 6.3, "Setting Up Content Classification," in the Oracle Application Server Portal User's Guide |
OracleAS Portal enables you to store, manage, and publish translations of your portal content. You can associate many of the objects that are managed in your portal with one or more languages in addition to the default language defined for a page group. OracleAS Portal automatically publishes translated content to viewers of your portal in their selected language.
Implementation Details
Although the translation feature is very useful and powerful, it is important to understand how translations are created, managed, published, and queried. In particular, you should make clear to your content contributors and portal users the impact of creating or editing an object in a nondefault languages. The following are several characteristics of the translation feature that are important to understand:
Editing an object in a language other than the default language may cause the edits to 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.
Editing a non-translatable attribute automatically copies the value of the attribute 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.
|
See Also: Chapter 20, "Translating Portal Content," in the Oracle Application Server Portal User's Guide |
When different users perform the tasks of authoring, publishing and managing content, you may want to choose a view mode that optimizes the user interface to the features that are required for the role being performed. A content author may want to see what the content looks like on the page so a graphical viewing mode is most appropriate, and a content manager that needs to approve multiple documents can do so in a single operation when using a list view.
Implementation Details
When editing a page, you can switch between View modes by using the Graphical, Layout, and List links in the Edit toolbar.
You can set the default edit mode for all pages in a page group to any of the edit modes by configuring the page group properties.
When setting up your portal, you may find that you want to load and attribute directory and file structures that exist on a file system into the OracleAS Portal Repository. While it is very time consuming to upload and set the attribution for every file using the Web browser interface, as an alternative, you can use APIs.
Implementation Details
Functions of the content management APIs that help you migrate existing content include:
add_folder: Creates a new page within a given page group
add_item: Uploads a file from the file system and adds a new item to an item region
set_attribute, modify_item: Enables you to set the attribution for an existing item and helps you perform content management task programmatically without any Web browser-based interaction
modify_folder: Enables you to modify the page properties
All of the files you plan to upload using the APIs must be accessible from the same file system as the installed OracleAS Metadata Repository, and you need access to the files themselves.
|
See Also: Part III, "Content Management APIs," in the Oracle Application Server Portal Developer's Guide |
When managing your portal, there is often the requirement to have a staging page group and a production page group. That is, content contributors must author and manage content in a staging page group, which you then need to move to the production page group. While it is very time consuming to move every item using the Web browser interface, you can instead use the content management APIs.
Implementation Details
Functions of the content management APIs that help you organize content include:
move_item, copy_item: Enables you to transfer items from one page group to another page group
delete item: Enables you to delete an item that is no longer necessary
The metadata attribution of an item is automatically transferred when using the content management APIs.
|
See Also: Part III, "Content Management APIs," in the Oracle Application Server Portal Developer's Guide |
When users add content to OracleAS Portal's content management system you may want the system to perform certain actions, such as:
Sanity check and verify the content
Perform a virus scan on files
Send an email notification
Kick off an external Workflow
Invoke an external Program
The Content Management Event Framework (CMEF) enables you to react on any event that occurs in OracleAS Portal content management system and programmatically perform any action. In combination with the content management APIs and views, it enables full flexibility.
Item Verification Example
A user adds a text item and you want to ensure that the title is no longer than 30 characters. An OracleAS Portal workflow kicks off and programmatically verifies that the item title is not longer than allowed. If it is longer than 30 characters, the system automatically rejects the item with a message to the author that the title exceeded the maximum length. If the item passes the verification it gets automatically approved and published
External Workflow Example
A user adds a new item to a page. The CMEF hides the item and submits it to the BPEL Workflow Engine. Once the BPEL Workflow finishes, a step in the workflow either rejects or approves the item. If approved, the CMEF unhides the item and publishes it; if rejected, the CMEF deletes the item from the page.
Implementation Details
First, you enable the CMEF at the page group level. The CMEF writes to Oracle Advanced Queuing in the database and creates an entry for each of the 155 pre-defined events that can occur in OracleAS Portal's content management system. You must create a program called subscriber and register it with the CMEF. The subscriber program must implement the logic on how to react on which events in the queue. The subscriber program is responsible to de-queue events from Oracle Advanced Queuing. Ideally, you set up the subscriber program as a database job that executes periodically.
Frequently, you must create custom searches for your portal that perform beyond the functionality of the three out-of-the-box search portlets that OracleAS Portal provides. To create custom searches, you can use the public search API, which enables you to expose portal search submission and results in any third-party application. You can also use this API to publish the portal search results to a special document format, such as XML, which you can then use for further processing.
Implementation Details
The public search API includes the following search submission functions:
Item Search
Page Search
Category Search
Perspective Search
The public search API includes the following search-result functions:
Get item results as XML Document
Get page results as XML Document
OracleAS Portal supports the use of WebDAV clients, such as Microsoft Web Folders, to access the OracleAS Metadata Repository. WebDAV allows users to directly edit a document, such as a Microsoft Word document, on a portal page and save it back to the OracleAS Portal 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 OracleAS Portal.
From OracleAS Portal 10g (9.0.4.1) onwards, a new, powerful WebDAV Client with tight OracleAS Portal integration is available from Oracle: Oracle Drive. This WebDAV Client supports all operations available with the WebDAV protocol plus additional OracleAS Portal-specific functions, such as:
Portal Item Menu Options:
Set Properties
Change Access Control
Preview Content
View Versions
Approve/Reject
Submit for Approval
Portal Page Menu Options:
Set Properties
Change Access Control
View Page
In addition to the preceding functionality, Oracle Drive offers a number of useful Windows desktop integrations:
Mount OracleAS Portal Repositories as Microsoft Windows Drives
Edit and view content with any Windows application
Work with offline content and synchronize when online
Extra capabilities available in the right-click menus
Access the repositories with a command line (DOS) utility
Search from Windows Explorer
|
See Also: Chapter 19, "Using WebDAV Clients with OracleAS Portal" in the Oracle Application Server Portal User's Guide |
You can use OracleAS Portal's page editing capabilities to create complex page structures and a compelling user interface for a wide range of portal configurations. If your portal page calls for a sophisticated graphic design, you can use HTML Templates to control the HTML rendered as page decoration and item content layout. Using these templates allows for easy, standard based ways of using Web technologies, such as CSS and JavaScript. By placing special OracleAS Portal substitution tags in your HTML, you can place portal elements, such as Page Title, Sub-Page links, Edit Page link, Navigator link, Item attribute values, and other elements common to a portal page or item content directly in your HTML code.
There are two types of HTML templates: Page Skins and Content Layout. You apply Page Skins directly to a portal page or, if you apply them to a portal template, the HTML surrounds the portal page in its entirety. Content Layouts are snippets of HTML that you assign to a page region. The HTML repeats for every item contained within the region.
HTML templates also enable you to execute PL/SQL, allowing for programmatic control over the HTML.
By using this HTML Templates, you can apply virtually any corporate look to your portal pages, even if this design may not be achievable using the regular portal page design capabilities.
HTML Templates are created and maintained under Page Groups. If you want to use the same HTML Templates across multiple page groups, create them in the Shared Objects page group.
Implementation Details for HTML Page Skins
To apply a HTML Page Skin to a page, go to the Page Properties, Template tab. You will be able to select Page Skins created in the current page group and Page Skins created in the Shared Objects page group. A portal page may have only template applied to it. If you desire a page to use a Portal Template to define common content and structure, and also use a HTML Page Skin to surround the page with hand crafted HTML, you must apply the HTML Page Skin to the Portal Template and then apply the Portal Template to the page.
The most critical OracleAS Portal replacement tag for a HTML Page Skin is the #BODY# tag. Wherever this tag is placed within the HTML, the entire Portal Page will be rendered.
Implementation Details for HTML Content Layouts
You apply Content Layouts to region settings on the Attributes tab. To determine how you want the content to display within a region, use the attributes or choose an HTML Content Layout. The HTML snippet you write in a Content Layout repeats for every item contained within the region. There are portal replacement tags for all item attributes, including custom attributes.
Since the HTML is repeated for every item, it is not a good practice to declare JavaScript methods, or include CSS styles at this level. In cases where you need to use JavaScript or CSS, use HTML Page Skins and HTML Content Layouts in coordination with each other. Declare the JavaScript method or CSS in the HTML Page skin where it will not be repeated, then simply reference the style or JavaScript method from within the HTML Content Layout.
The ability to place <ORACLE> … </ORACLE> tags within HTML Templates allows Content Layouts to use IF statements to programmatically choose to output different HTML conditionally. While inside of the <ORACLE> tag, you will need to use a PL/SQL procedure such HTP.P('<B>Hello World</B>'); to output any HTML that you want to display on your page.
|
See Also: Section 13.3, "Working with HTML Templates" in the Oracle Application Server Portal User's Guide |
This section contains the following topics:
Section 5.4.1, "Review Supported Use Cases to Optimize Export and Import Operations"
Section 5.4.2, "Follow the Guidelines for Export and Import of Portal Objects to Prevent Errors"
OracleAS Portal provides a set of export and import utilities to enable you to copy content between OracleAS 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 the Oracle Application Server Portal Configuration Guide for your version of OracleAS Portal before beginning the page and content design process for your portal, if regular export and import of content between portal instances is a requirement. The 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, see 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
|
See Also:
|
This section contains the following topics:
Section 5.5.2, "Implement a Role-Based Security Model to Simplify Access Control Definition"
Section 5.5.4, "Group secured content to Optimize ACL Determination and "Network Access" Security."
While the installation process of OracleAS Portal allows for a fully functional portal out-of-the-box, the fact that it uses a number of standard administration settings and passwords prevents the default installation from being used in a environment where it may be compromised, for example, on an Internet site. Oracle recommends that you perform a number of simple post installation steps to change the configuration to site specific values, thereby preventing malicious attack by use of the default installation values.
Implementation Details
While much of the hardening of a portal site involves the changing of the default configuration values, a significant portion is dependent on the implementation of a secured network topology. Specifically, you want to minimize the direct access that a malicious user may have to the server itself, both from the external and internal network.
To harden your portal installation, consider doing the following:
Change the passwords for all default OracleAS Portal lightweight users
Change the default password used to bind the portal to the Oracle Internet Directory. This setting is found in the orclApplicationCommonName attribute under the Oracle Context.
Remove unnecessary pages, such as demonstration pages, to limit the ability to enter the portal site through back-doors.
Remove unnecessary seeded groups and privileges.
|
Note: In OracleAS Portal 10g Release 2 (10.1.2.0.2) the seeded administrator accounts no longer have high-level privileges in the directory. |
Revoke public access to the components within the portal, which may expose information from the OracleAS Metadata Repository or transactional database.
Control Access to the Builder Pages. This is particularly important because a link to the builder is exposed on the Customize user interface and allows users to see the structure of the site even if they cannot access any of the pages shown.
Remove Web access to standard DBMS functionally PL/SQL Packages, which may allow access to the portal schema in the OracleAS Metadata Repository or other repositories, such as UTL_HTTP and DBMS_JOB.
Consider placing the Oracle Application Server Portal middle tier behind a reverse proxy component to obfuscate the real name of the server. In particular, implement Network Address Translation (NAT) to hide the actual IP addresses of the portal's middle tier servers.
Secure the individual network hops SSL as required. At a minimum, ensure the connection between the user's Web browser and the OracleAS Single Sign-On server is SSL-enabled.
Implement a true Intranet/Extranet topology to separate both the physical executables and any generated content into two distinct user communities.
Implement Secured Network Access (discussed subsequently) to prevent sensitive pages from being accessible from outside of the corporate network.
|
See Also:
|
While the ability to define access privileges at the individual user level allows for the creation of very granular security policies, as the size of the user community increases such granular polices become successively more difficult to manage and maintain. Therefore, to simplify the implementation of security, Oracle recommends that you use a role-based metaphor, where a user's privileges are effectively defined by their functional position, rather than their direct identity.
Role-based access control (RBAC) is based on the concept that privileges are never assigned directly to a user. Rather, users are assigned to roles, permissions assigned to roles, and users ultimately acquire those permissions by being members of those roles. You can assign a user to multiple roles and a single role can contain multiple users. Similarly, you can assign the permissions themselves to multiple roles and multiple permissions to a given role.
By default, the OracleAS Portal enables you to assign privileges to both individual users and groups, the latter of which may be seen as either simple aggregations of users or as a role. With the group model, you assign a user to a group, while traditionally you might assign a role to a user. In the OracleAS Portal environment, the definition of a role is a group to which you assign privileges as opposed to a simple aggregation of users.
Therefore, to enforce a role-based access control style model within OracleAS Portal, ensure that you do not grant object ACLs or directory privileges directly to a user. Rather, only grant ACLs to groups/roles, while granting directory access by the assignment of the appropriate group/role .
Implementation Details
To implement a role-based security model:
Determine the appropriate User Functions and create an associated role.
Create a group using the Oracle Internet Directory Self-Service Console.
Assign Directory Privileges (on the Assign Privileges tab) as required by the role.
If the Role is to have an administrator function over users, then it will also require Manage privilege for All User Profiles (set from the Portal Group Profile portlet).
Convert the group into a role within the console.
Select the Enable Role assignment in the user management interface option on the Enable Roles page of the Identity Management Realm Configuration tab.
Prevent the direct assignment of directory privileges to users by removing the appropriate section within the Oracle Delegated Administration Services Interface when it is called from the OracleAS Portal interface (through the Create/Edit User Portlet).
To do so, either clear the setting on the Global Settings page or execute the wwsec_oid.set_preference_value package within SQL*Plus.
To prevent the direct assignment of a portal object ACL to a individual user, similarly remove the option in the Access Definition screen by running the secrlacl.sql script within SQL*Plus.
While the use of access control policies prevents users from directly viewing information to which they do not have clearance, it does not prevent that information from being compromised by those with the appropriate access, allowing it to be viewed in an inappropriate location, such as an Internet cafe. To decrease this risk, OracleAS Portal 10g (10.1.4) supports the concept of network access security, that is, the ability to define an appropriate network access path, by which it is valid to show the information, regardless of the ACL. This security is particularly useful in the intranet and extranet portal environment, where a user may view a secured page on the corporate network, but not externally, such as from home through the Internet.
To determine the network access requirements of a page, OracleAS Portal 10g Release 2 (10.1.4) does not include looks for specific attributes in that page (isViewRestricted and isEditRestricted). If these exist within the page, then OracleAS Portal secures the page accordingly when a user access it from an insecure location.
OracleAS Portal 10g Release 2 (10.1.4) does not include this metadata in the Standard Page Type, and may not secure the pages which were built previously using this type in this manner (though it is possible to globally turn off the ability to edit the page). Therefore, to allow OracleAS Portal to secure new pages, Oracle recommends you replace the default page type with one containing these attributes.
Implementation Details
To enable network access security:
Create two shared custom attributes specifically named isViewRestricted and isEditRestricted. Be careful with the case structure as the attribute names are case-sensitive.
Create a shared Custom Page Type to use as the default type when creating new portal pages. Base this page type on Standard Base Page type.
Add the custom attributes to the page type and define whether the page designer should have the ability to define whether to secure the page within the network.
If all pages will ultimately be limited to the Intranet then set the attribute values as follows
Default Value: ON
Required: Unchecked
To enable the page designer to define whether the page will be available through an unsecured network, select the required option to expose the attribute in the Page Builder user interface.
Configure the page group to expose the new page type within the Page Builder user interface.
Remove the Standard Page Type from the user interface and set the default page type to be the one created in the previous step.
Page designers should now choose the new network secured page type when building pages, as the default it is chosen automatically.
Once pages are built using the new page type, the pages will automatically be secured within the network when the server is configured for Extended Network Security.
|
See Also:
|
While the implementation of item-level security allows for a very granular permissions model, it does dramatically increase the processing required to determine the users access rights on the page. By default, items inherit the security permissions of the containing page or tab. Enabling item-level security overrides this default setting, and those without specific privileges on the item itself will not see it.
To address this issue, Oracle recommends that you, where possible, group items with the same access rights onto the same page. For example, rather than placing items of interest for the HR department on several pages and using item level security to hide them, group them on a single page and use the appropriate page level security to hide or show the entire page.
In OracleAS Portal Release 10g Release 2 (10.1.2.0.2) the implementation of Network Access security works at the page level, and as such, it is not currently possible to secure an individual item on a page. By grouping items that should not be visible externally onto a single page, the Network Access security can hide them all in a single action.
Implementation Details
Design pages to group items into logical or functional security groups.
|
See Also:
|
Frequently, you must allow portal pages to be seen by all users regardless of their specific access privileges. For example, all visitors to an Internet site should be able to see its Welcome page, while only authenticated visitors should be able to view the Welcome page of a company's internal site.
In both cases, the Welcome page may be considered public, because the users' specific permissions do not define their ability to view the page. Rather, the difference was whether the user was anonymous or a known identity.
In the anonymous case, access to the page is assumed for everyone, and therefore the standard ACL processing is bypassed. In the authenticated user case, all users must require at least View privilege, as the ACL determination is still performed. This is simplified by the fact that all users are dynamically made members of the AUTHENTICATED_USERS group when they log in. Therefore, any privilege you grant to this group also applies to any user that is authenticated to the portal.
Implementation Details
To enable non-authenticated users to view Public pages, set the Display Page To Public Users option on the Access tab.
To enable all authenticated users to view Public page, simply grant the View permission to the AUTHENTICATED_USERS group.
Implement Hash Message Authentication Code (HMAC) Encryption in Communication to Web Providers to allow for Secured Identity Propagation and J2EE based security.
Frequently, portlet developers base the security context of Web portlets on the identity of the user currently running within the portal (as opposed to a single generic account). While the portlet developer can use the PDK-Java APIs to allow the portlet to query the framework for the identity of the current user, there is an implicit trust of the information received by the portlet. That is, the portlet has to assume that the information passed within the packet headers is correct, and has not been altered during transmission (data substitution) or spoofed from a server other than the OracleAS Portal middle tier.
Traditionally the technique to ensure the integrity of the OracleAS Portal server, requesting the portlet, was to implement a Secure Socket Layer (SSL)-based connection, with an appropriate client certificate used to identify the portal server (the portlet provider itself would also need a certificate for the reverse trust relationship).
If the use of certificate based SSL is not viable, OracleAS Portal allows for message authentication through the use of a shared key, known only to the portlet provider and the OracleAS Portal middle tier. By the generation of a digital signature (passed with the SOAP message and based on the shared key, user information, timestamp and a Hash Message Authentication Code (HMAC) algorithm), the provider may authenticate the message by checking the signature against its own copy defined by the shared key. If the signatures match, the provider is assured that the message came from the correct source.
The provider may then enforce J2EE security by implementing the RunAS directive within the portlet.
Implementation Details
Register the shared key to the Web provider by defining a JNI variable within the web.xml file used by the Provider application. Alternatively, you can define the shared key within the deployment properties file:
<app_root>/WEB-INF/deployment/provider_name.properties
The disadvantage of performing the latter is that it prevents the use of the Application Server Control Console to interpret or set the value.
Add the provider property enhancedAuthentication=true to the deployment properties file.
Register the provider within the OracleAS Portal. On the General Properties tab, enter the shared secret key in the appropriate field.
Set the Login Frequency to Once per session.
While the use of well-defined security policies will prevent users from seeing content to which they are not entitled, one of the most common situations where security is compromised is when an authenticated user has left their portal session unattended. Given that the user has authenticated to a Single Sign-On environment, an opportunistic or malicious user who was able access the rightful user's browser (in their absence) would have access to all applications exposed by the portal. Furthermore, any transactions performed would be as the rightful user and could not be traced back to the miscreant.
A simple solution to such a situation is to invalidate the Single Sign-On session after a reasonable period of inactivity using the OracleAS Single Sign-On server's Global Inactivity Timeout functionality. Once activated, any request to a portal page (or any other partner application) after the specified period of inactivity, would result in a credential challenge. If the credential was the same as the currently defined portal session (as would be the case if the rightful user returned), then the user would be able to pick up where they left off within the portal. If not, then the current portal session is killed and a new session created to match the security policies of the new user.
Implementation Details
Configure the Global Inactivity Timeout within the OracleAS Single Sign-On Server. The implementation is due to its definition as a partner application.
Frequently, a number of disparate user communities share a given portal implementation, each of which is to be independently administrated by one or more members of that community. While Oracle Internet Directory supports the separation of user communities into distinct security realms (with associated delegated administration) the use of separate realms prevents the implementation of a single Shared Portal . That is, objects in a given security realm may not be seen by those in another. Therefore, to enable components of a portal to be utilized by multiple communities, you must place them in the same realm.
Once you have defined the user communities, you can restrict the various pages of the portal to a given user community by standard ACL definitions at the page group level. All communities may view shared objects, and therefore templates, styles and common pages may be used by all communities, while content pages are limited to the community owning the data.
Implementation Details
The major configuration requirement lies within the Directory Information Tree (DIT) itself.
Create a named community container (for example cn=CompanyA) under the cn=users container in the default realm. Define the users of this community under the new container. Do not grant any Global Privileges to these users (either directly or through an associated role).
Create a named sub-tree for the community under the portal's group container to store community-specific groups. Create a private group under this tree to define membership in the associated community. As a private group, only members of the community will be able to see it, or its membership.
Create a named sub-tree for the community under the group container under the Oracle Context node. This tree will be used to define community level administrators who will have delegated administration privileges for their community.
Define ACIs within the directory tree to revoke access from all communities to the default (master) user and group containers and all containers following these, that is, the communities.
Define ACIs at the Community level in the User and Groups sub-tree to grant browse, read, write, and update access to the containers for members in the community only. For shared portal pages, add the appropriate policy for subsequent community groups.
Create shared objects within the Builder to be used by all communities.
Create a page group to support the community portal. Define an ACL on this page group to allow access to the community group defined. Doing so will allow only members of the community to view these pages.
This section contains the following topics:
Section 5.6.1, "Install the Portal Extension for Oracle JDeveloper to Improve Portlet Development"
Section 5.6.4, "Ensure Links in Portlet Are Correct to Avoid Sending the User Away from the Portal"
Section 5.6.7, "When Is It Best to Use the Web Clipping Portlet?"
The OracleAS Portal Developer Kit (PDK) provides you with the necessary libraries to install an extension for Oracle JDeveloper that dramatically increases your flexibility and productivity when developing portlets. This extension includes two wizards, one for building PDK-Java portlets and one for building JPS (Java Portlet Specification - JSR 168)-compliant portlets. Both wizards guide you through the steps of creating the portlet skeleton and all you need do then is implement your own business logic.
Implementation Details
To obtain the extension:
On the right, under Software Downloads, click Portal Developer Kit.
Under Portal Extension for JDeveloper, click Portal Extension for Oracle JDeveloper to download the extension.
Click Portal Extension for Oracle JDeveloper Installation Guide for installation instructions.
The Web Services for Remote Portlets (WSRP) specification is a Web services standard that allows the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Being a standard, WSRP enables interoperability between a standards-enabled container based on a particular language (such as JSR 168, .NET, PERL) and any WSRP portal. Therefore, you can render a portlet (regardless of language) deployed to a WSRP-enabled container on any portal that supports this standard.
Java Portlet Specification (JPS) is based on JSR 168 and defines a set of APIs for building standards-based portlets using Java. You can deploy portlets built to this specification to a WSRP container for rendering portlets remotely.
|
See Also:
|
Show mode exhibits the runtime portlet functionality seen by users. JPS offers some modes not offered by OracleAS Portal and vice versa. If you are coding portlets to JPS, you can declare custom portlet modes that map to the extra modes offered by OracleAS Portal.
An OracleAS Portal portlet may have the following Show modes, each with its own visualization and behavior. JPS portlets can define custom portlet modes in portlet.xml. Defining custom modes is especially useful if the portlet must interoperate with portal implementations from other vendors.
The list of modes is the following:
Shared Screen Model (View Mode for JPS)
Edit Mode (JPS and OracleAS Portal)
Edit Defaults Mode (JPS and OracleAS Portal)
Preview Mode (JPS and OracleAS Portal)
Full Screen Mode (OracleAS Portal)
Help Mode (JPS and OracleAS Portal)
Link Mode (OracleAS Portal)
In some ways, navigation between different sections or pages of a single portlet is identical to navigation between standard Web pages. Users can submit forms and click links. In the case of typical, simple Web pages, both of these actions involve sending a message directly to the server responsible for rendering the new content, which is then returned to the client. In the case of portlets, which comprise only part of a page, the form submission or link rendered within the portlet does not directly target the portlet. It passes information to the portlet through the portal. If a link or form within a portlet does not refer back to the portal, then following that link takes the user away from the portal, which may not be the desired behavior.
The portlet developer does not need to know the detailed mechanics of how the parameters of a form or link get passed around between the user, portal, and portlet. Ensure the portlet developer does not write links in a portlet the same way as for typical, simple Web pages.
For PDK portlets, use the methods from the UrlUtils class (oracle.portal.provider.v2.url.UrlUtils) as it will render the HTML links appropriately.
OracleAS Portal is capable of rendering its pages for both HTML and non-HTML (mobile) devices. When rendering for a mobile device, OracleAS Portal requires portlets to generate content in a universal markup language called OracleAS Wireless XML.
Many portlets, known as desktop portlets, generate only HTML responses and, as such, can only render themselves in standard Web browsers. Some portlets, known as mobile portlets, generate only OracleAS Wireless XML responses. These portlets can render themselves on any device, including standard HTML browsers. Many portlets, though, take a hybrid approach that renders either HTML or OracleAS Wireless XML depending on the environment. These hybrid portlets can render themselves on any device, but they render best on standard HTML browsers. Although OracleAS Wireless XML is sufficient for HTML responses, it is not as expressive as HTML. Since portlets running in both a desktop and mobile environment are typically accessed through the desktop, developers commonly choose to create hybrid portlets that can provide the best possible rendition in the desktop environment.
The Oracle Application Server Portal Developer Kit (PDK-Java) contains numerous examples and documents regarding the usage of the OracleAS Portal APIs, such as personalization and caching. The integration of the application flow and business logic is not part of the portlet APIs. By using the Struts framework, however, you can leverage the Model-View-Controller (MVC) architecture to create and publish applications within your enterprise portal.
To create a Struts portlet, you must use the OracleAS Portal JSP tags, which are extensions of the default Struts JSP tags. This development process is similar to that of creating a standalone Struts application. Also, since the portlet and struts application must also be in the same Servlet Context, you must create a single Web application that contains both elements.
Implementation Details
|
See Also: Section 7.3, "Building Struts Portlets with Oracle JDeveloper," in the Oracle Application Server Portal Developer's Guideto learn how to build a Struts portlet |
In the event that you have to create a portlet that displays the content from a remote Web site as it is presented at the source location, the best tool to use is Web Clipping. Web Clipping can tolerate the changes of the source HTML page to some extent. If a clipped table moves from one place to another in the source page, the Web Clipping engine can find the table again using the internal "fuzzy match" algorithm. Portlets built with Web Clipping can also maintain sessions to the remote Web sites. Web Clipping also supports the end user personalization of HTML form values.
Web Clipping has URL rewriting support to achieve this functionality: it can process the links, originating from the source Web site, and modify (rewrite) them to achieve the desired functionality.
You can choose from the following three options:
You can select not to rewrite the URLs within the portlet, in which case clicking the links takes the users out of Portal to the Web site providing the clipping. If the Web Clipping provider is registered with an External application, this may require that the user enter login information before navigating the Web site.
If the Web Clipping provider is registered with an External Application and the clipping requires authentication, you can instruct Web Clipping to rewrite all URLs within the portlet to point to the Login Server. In this case, navigation will cause the user to leave OracleAS Portal, while also using the Login Server to log the browser into the External Application.
You can select to rewrite all URLS within the portlet (inline rendering) to point back to the portal page so that all browsing within the Web Clipping portlet remains within OracleAS Portal. If the Web Clipping provider is registered with an External Application, this will cause the Web Clipping provider to log itself into the External Application. In this case, the navigation within Portal through the Web Clipping provider is authenticated in the External Application.
Meant for page designers and portlet developers, the OracleAS Portal OmniPortlet is a declarative portlet-building tool that enables you to build portlets against a variety of data sources, including XML files, comma-delimited value files, such as spreadsheets, Web Services, databases, Web pages, and SAP data sources. OmniPortlet users can also choose a pre-built layout for the data. Pre-built layouts include tabular, news, bullet, form, or chart.
Like Web Clipping, OmniPortlet supports proxy authentication, including support for global proxy authentication and per-user authentication. You can specify whether all users will automatically log in using a user name and password you provide, each user will log in using an individual user name and password, or all users will log in using a specified user name and password.
There are three types of parameters in OracleAS Portal: page parameters, public portlet parameters, and private portlet parameters.
Page parameters
You can use a page parameter to pass a value to a page. Using page parameters, the information that displays on a page can vary depending on where the page is called from and who is viewing the page. Using page parameters, page designers can synchronize the portlets on a page by passing them the same values. This provides the ability to reuse and tailor portlets on pages by merely integrating them with page parameters. Without this functionality, you would have to code portlets individually to use different parameter values.
Public portlet parameters
You can use a public portlet parameter to pass a value to a portlet. Using portlet parameters, the information that displays in a portlet can be specific to a particular page or a user. Portlet parameters are created by the portlet developer and are exposed to the page designer through the user interface. After adding a portlet to a page, page designers can assign values to the public portlet parameters to make the information that displays in the portlet specific to the page.
Page designers can assign values to public portlet parameters by providing a specific value (constant), a system variable, such as the portal user name, or a page parameter. At run time, the portlet receives the values from the sources specified. In this way, page designers have complete control over the source of the parameter, whereas you have complete control over how the data is used after it is transmitted to the portlet.
Private portlet parameters
You can use private portlet parameters to implement internal navigation in your portlet. You can pass parameters to your portlets every time the page is requested. The portlet instance can exclusively pass private portlet parameters to the same portlet instance.
Portlets supporting public portlet parameters enable page designers to tailor the portlets' data input for each portlet instance. In this case, the portlet developer can focus on the portlet logic, while page designers can easily reuse portlets and address the interaction between the page and the portlets.
OmniPortlet, Web Clipping, Java portlets, Portlet Builder, and PL/SQL portlets support public portlet parameters. OmniPortlet, Web Clipping, and Portlet Builder provide complete support through their wizard interface. You can add public portlet parameter support to your Java portlets programmatically or with the Java Portlet Wizard. PL/SQL portlets support public parameters only programmatically.
An event is a user action that you define to display a portal page. User actions include clicking a link or a button in a portlet. Page designers specify what to do when an event occurs in a portlet on a page. When an event occurs, page designers can either redisplay the current page or navigate the user to another portal page, optionally passing values to that page's parameters. Web Clipping, OmniPortlet, and Java portlets built with the PDK-Java support events Portlet Builder and PL/SQL portlets do not support events.
The Oracle Application Server Portal Configuration Guide describes how to build portlets for OracleAS Portal using a variety of tools and technologies. This manual includes information that helps understand the various technology choices, helps choose the technology that best meets requirements, and advise on how to use the appropriate tools to build and deploy portlets.
This manual is intended primarily for portal developers, but page designers may also find it useful. This manual guides through the process of first understanding and choosing a portlet technology, and then building portlets with that technology.
