Before you dive in and start building your portal, it's essential that you have the background information you need to make informed decisions. This section discusses the learning process associated with Oracle Portal, how to truly understand your audience, and, most important, leads you through all the key concepts you need to know about Oracle Portal itself.
The way in which you go about building your portal is often a reflection of how you as an individual tend to approach any project of large proportions. The learning process for Oracle Portal seems to fall into three categories:
Self-learning. Many users new to Oracle Portal who have nonetheless been given complete responsibility for creating something of value to his or her constituency, prefer to immediately begin experimenting with the product, often implementing a small-scale project just to get the feel for what's involved before launching into the larger task of creating a portal for users. While this may be the most immediately satisfying approach for some, bear in mind that it is also the approach that will probably call for the most patience and the most re-work. There are many decisions that, poorly made, will have far-reaching impact on your portal down the line.
Attending formal education classes, or using self-paced tutorials. Oracle offers a variety of instructor-led training sessions, which can help bring you up to speed on Oracle Portal quickly. Or you can choose from many OBEs (Oracle By Example), self-paced educational units that are free and available 24 hours a day, 7 days a week. Contact Oracle University for more details, or visit the Oracle Portal Education page on OTN (
Working with an Oracle consultant. You may want to consider establishing a contract with Oracle Consulting to assess your business needs and develop a portal specifically for you. Once your portal is complete, the consultants will help you learn how to maintain and extend your portal. The advantages of this approach are that your learning process will be centered on your own portal (as opposed to formal training, which is based on generic scenarios); plus, since the learning curve is not an issue, your portal will no doubt be completed more quickly than if you attempt to build it on your own. The disadvantage, of course, is that the size of your organization and its budget may not make Oracle Consulting an option.
Keeping your audience firmly in mind as you design and implement your portal is key to creating something that will be truly useful. In working with various companies and moderating our own development process, we've identified six fundamental user groups that you are likely to have in your midst:
Viewer - Consumes information; does not publish it. Requires little, if any, Oracle Portal-specific knowledge or skills. Must know how to search to find desired information; may need to know how to customize the display to hide or reveal content.
Chapter 2, "Interacting with Your Portal" contains information that will be of use to the viewers of your portal. You may want to give a copy of this chapter to your users; however, it may be more practical for you to use it as an information source as you prepare your own tutorials and how-to guides. That way, you can illustrate Oracle Portal concepts with concrete examples taken from your own portal, thus solidifying the association in users' minds.
Chapter 14, "Working with Items" and Chapter 15, "Working with Portlets" contain information that will be of use to those who will contribute content to your portal. You may want to use the material in this chapter as the basis for creating or augmenting your own user's guide, based on real-life examples from your portal.
Page Designer/Builder - Creates pages, usually for others to populate with content. Extends pages with simple wizard-created components; feeds portlet requirements to developers. May populate page with content through such means as OmniPortlet and WebClipping. Grants page access to appropriate users and user groups. May set up some reusable components (navigation pages, styles, templates, and so on).
Chapter 6, "Creating Pages", in particular, contains information targeted to the page designers/builders at your site.
Page Group Administrator - If you are reading this, you're probably a page group administrator. Your tasks include: deciding how to implement the portal: whether to use one page group or many, deciding how deeply to nest pages, and so on; determining the need for and creating custom item and page types; creating categories and perspectives; establishing workflow processes; policing the content contribution effort; feeding requirements to page designers. To maintain consistency, you may have complete or partial control over developing reusable objects (navigation pages, styles, templates, and so on.)
All of the information in this volume, Building Your Portal, was developed to help you do your job successfully.
Portal Administrator - Installs and configures Oracle Portal and its subsystems. Sets up users and user groups; monitors performance and maintains acceptable levels; manages the Portlet Repository; performs upgrades and adds software patches; registers portlet providers.
Portal administrators should refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Portal. The tasks in this User's Guide assume that all necessary configuration activities have already been completed.
Developer - Builds things, such as components and portlets, for others to include on their pages. Relies heavily on the APIs to extend the capabilities of Oracle Portal; may frequently consult the Knowledge Exchange or the forums for advice or inspiration.
See Oracle Fusion Middleware Developer's Guide for Oracle Portal. This book describes the technologies available for portlet developers, discusses how to choose the best technology to meet the given requirements, and guides developers in using the appropriate tools to deploy their developed portlets.
This section introduces fundamental Oracle Portal concepts and weaves them together so you'll have a good working knowledge of their importance; however, each concept is treated much more exhaustively elsewhere in this book. Much of what you need to know is depicted in the following diagram:
Let's examine this diagram section by section: Hierarchy of Pages, Anatomy of a Page, and Reusable Objects.
One of the first things you need to know is that in Oracle Portal, a portal is a collection of one or more page groups. At its core, a page group is a hierarchical collection of pages. A page is the face of the portal—what the user interacts with to access information and applications. Oracle Portal pages are flexible enough to contain any HTML content. They can be created and structured declaratively, through browser-based wizards, or defined programatically as JavaServer Pages. Information on portal pages is published as either portlets or items, both of which are described later in this chapter.
A page group is exactly what it sounds like: a group of pages for which common attributes and mechanisms can be established that govern the behavior of the pages it contains. You can construct your entire portal within one page group, or use different page groups as sub-portals targeted at specific communities within your organization. Many vital decisions and configurations are specified at the page group level by you, the page group administrator.
At the far left of the diagram, notice that the top of the page group is called a root page. Every other page within a page group is a sub-page of the root page. When you create a page group, a root page is automatically created for you using the same name as the page group itself. Root pages are often used to construct your portal's (or sub-portal's) home page.
Another important concept to the development of any portal is that of security. As page group administrator, you can grant varying levels of access to entire page groups, individual pages, tabs, or even discrete items on a page. You can either make these objects publicly available, or control them through an access control list, which states which users and groups can interact with the object and to what extent. You can also grant permission to manipulate the access control list to other users as required.
In this section of the diagram, three essential concepts are illustrated: regions, portlets, and items.
Every page can be carved up into one or more regions. You accomplish this using tools that are available when editing a page. The following picture shows three pages with three different region configurations.
Each region has its own set of options that control how the content within it is displayed. For example, you can specify the width of the region relative to the page, what kind of content the region can contain, and whether to display borders around the portlets in a portlet region. Regions can also include one or more tabs.
Regions make it easy to devote areas of the page to specific functions. For example, it is quite common to use the top region of a page for a banner, one alongside the left for a navigation bar, and perhaps another along the bottom for a footer, as shown in this example:
In Oracle Portal, all three of these elements are called navigation pages. (You can use Oracle Portal to create navigation pages, or have your graphics designer develop HTML to fulfill this need.) The remaining regions, such as the one shown to the right of the navigation bar in this picture, are the placeholders for the content your portal displays. In Oracle Portal, there are two types of content: portlets and items.
Think of a portlet as a reusable building block for easily publishing information and applications. You can instantly deliver new content to thousands of users by simply adding a portlet to the users' view of the portal. All portlets come from a data source registered within Oracle Portal, called a portlet provider.
The information displayed within portlets comes from a number of sources. Some portlets are as easy to create as checking a box within a wizard; others require knowledge of PL/SQL or Java. You can create portlets in a various ways:
Publish pages and navigation pages as portlets. While in the creation wizard, simply check a box to indicate that you want to publish the page as a portlet. That way, you can re-use the page on other pages, or make the page available for others to use.
Use Oracle Portal's wizards to easily create reports, forms, charts, and other types of dynamic components and publish them as portlets. No programming knowledge is required.
Use your own tools to turn your legacy applications and Web sources into portlets and integrate them through Portal's Application Programming Interfaces (APIs), available in the Portal Developer Kit (PDK). See the Oracle Fusion Middleware Developer's Guide for Oracle Portal.
But you don't have to create your own portlets. Simply by installing Oracle Portal, you instantly have access to portlets created by a wide range of third-party vendors registered through Oracle's Partner Program. In addition, by subscribing to the Oracle Portal Developer Services, you can access a number of services and resources available exclusively to the Portal developer community. Not only will you be able to access the development team within Oracle, but you can tap into the greater community of Portal developers who have acquired expertise in working with portlets. And you can publish Portal development knowledge and experience of your own.
An item is the other basic Oracle Portal building block. More specifically, an item is an individual piece of content (text, hyperlink, image, and so on) that resides on a page in an item region. There are two types of items: content item types, which display user-managed content such as text, files, images, and URLs; and navigation item types, which are used to provide navigation and to access or execute various portal-specific functions. Items are added to the portal through simple wizards and stored in the Oracle Metadata Repository for ongoing management and publishing. If you plan to use Oracle Portal as a content management solution, you'll no doubt rely heavily on the use of items.
Reusable objects are created at the page group level and can be used for any page within the page group. For example, you may want to create a consistent color scheme (called a style) for every page within your portal. Even though the graphic doesn't depict it, pages themselves can be considered reusable objects, as any page can be published as a portlet and reused/shared elsewhere in the portal, or in remote portals.
Some objects control how pages are laid out and how they appear. Others help users organize and classify information so that others can locate it quickly. The following screen shot depicts the Page Group portlet, which is used to create and manage all reusable objects. The Page Group portlet is an important workspace that you'll use a great deal as you develop your portal.
In most cases, each time a page is displayed it is dynamically assembled and formatted according to the content (portlets and items) and the reusable objects chosen for that page.
Note:Whether or not the page is rebuilt each time it is displayed depends on the caching options in place at the time the page request is made.
A template is a type of page from which other pages can inherit layout, style, privileges, and even content, thus enforcing consistency across multiple pages. A Portal Template might include a corporate logo, frequently used links at the top, a navigation bar, and a footer that shows the location of the current page within the page group. When you create a new page, you have the option of selecting a Portal Template on which to base it, or to choose no template at all. Styles control the colors, fonts, and backgrounds of pages or regions within pages.
When you use the Create Page wizard, you are asked to supply the navigation page, template, and style you want to apply. If you choose not to apply these objects when you create the page, you can always do so later when you edit the page.
Content attribution concerns you much more if you're building a page group that supports collaboration among your users. Collaboration is chiefly supported through Oracle Portal's content management features, which center on the use of items. Content attribution refers to the process of associating various attributes with each item and page in your portal. These attributes store information and make it easy to group logically related items and pages together. Attributes also enable advanced metadata searches.
When you add a file to the portal, for example, you use the Add Item Wizard. This wizard prompts you for an item type. The kinds of item types that are exposed through the Add Item Wizard are determined by the page group administrator. Suppose you choose the File item type, which comes with Oracle Portal by default. The File item type has certain default attributes, like File Name, Description, Author, and so on, which you as the publisher of the file are expected to supply in order to complete the publication process. These attributes not only supply information about the file you're adding, but allow you (or others) to later construct custom searches so that you can, say, display all the content published by a given author. (Custom searches are easy to build in Oracle Portal.)
But suppose the attributes that come with the File item type aren't sufficient for your needs. Suppose you want to add another attribute called Group Name, to identify the group from which the file originated. With Oracle Portal, you can easily create your own custom attributes using the Create Attribute wizard. At a minimum, simply identify the Group Name attribute as a Text attribute, add it to the definition of the file item type, and you're done.
You may also want to create custom item types specifically for your needs. For example, if you're managing an entertainment portal, you might create a custom item type called Movie Review, which includes custom attributes such as Rating, Reviewer, and Producer. You can even specify which attributes are mandatory and which are optional.
Custom page types operate on the same principle. By default, Oracle Portal comes with several different page types optimized for use with different types of content. For example, the Standard page type is used to display both portlet and items, and thus is used for the majority of all portal development. Other page types include JSP pages, which display the results of executing a JavaServer Page, and URL pages, which allow you to include any Web-accessible page within your portal. However, you may encounter situations where you want to modify the page types already in existence, or require additional page types. For example, you might want to create a Performance Review page for use by managers, which contains attributes for Rating, Employee Name, Employee Rank, and so on. Like custom item types, custom page types are easy to create to meet your specific requirements.
Categories and perspectives represent a different type of content attribution at the item level. Both are a means of classifying your content into discrete groups, making it easy for users to locate content. A Human Resources page group might contain categories such as Benefits, Policies, and Payroll. Each time a user adds a piece of content, that content must be assigned to one and only one category (assuming that the Category attribute is exposed for the item type). Users can also search by category and perspective or browse through content that is organized into category and perspective hierarchies.
Perspectives work best when they cut across multiple categories. Because each item can be assigned many perspectives, it's best to reserve them for classifications that take advantage of this strength. In our Human Resources page group, you might choose to make your perspectives reflect the various user groups at the company: Engineers, Design Analysts, Sales Representatives, and so on. It's easy to imagine how the same piece of content, like the company's holiday schedule, would interest all users regardless of their user group. When a user submits a search based on Engineers, Oracle Portal would locate all the content tagged with that perspective, irrespective of category. Engineers would see the holiday schedule, as well as all other content from the Benefits, Policies, and Payroll that had been flagged as being of particular interest to that group. Or, on a portal devoted to travel, the perspectives Inexpensive, Moderate, and Luxury would neatly cut across the categories Lodging, Restaurants, Air Fare, and Rental Cars.
Deciding how to construct all of your attributes is an important part of building your portal taxonomy, and making these decisions should be attended to with care. One of the main benefits of creating a sound attribution model is that it provides you with more flexibility if you choose to publish content dynamically, using the autoquery capability of the custom search portlet. The autoquery feature is extremely powerful, especially when you configure it to display the results in place. Effective use of autoquery gives you tremendous control over how and where you manage and publish content within your portal. In fact, in many cases it is best to manage content in one area or page group and publish it dynamically throughout the portal. See Section 3.2, "Making Key Decisions" for more information.