3 Planning Your Portal

3.1.1 Approaching Your Portal

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 OracleAS Portal seems to fall into three categories:

• Self-learning. Many users new to OracleAS 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 OracleAS 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 OracleAS Portal Education page on OTN (http://portalcenter.oracle.com).

• 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.

3.1.2 Knowing Your Audience

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, OracleAS 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 OracleAS Portal concepts with concrete examples taken from your own portal, thus solidifying the association in users' minds.

• Content Contributor - Publishes content to a portal page. Needs to know how to add and edit content; depending on privileges, may also need to know how to manage them.

  Chapter 15, "Working with Items" and Chapter 16, "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 7, "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 OracleAS 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 Application Server Portal Configuration Guide. 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 OracleAS Portal; may frequently consult the Knowledge Exchange or the forums for advice or inspiration.

  Let your developers know of the new Oracle Application Server Portal Developer's Guide, on the OracleAS Portal Documentation page on OTN (http://www.oracle.com/technology/products/ias/portal/documentation.html). 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.

3.1.3 Key Concepts and Terms

This section introduces fundamental OracleAS 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:

Figure 3-1 Anatomy of a Page Group

Let's examine this diagram section by section: Hierarchy of Pages, Anatomy of a Page, and Reusable Objects.

Hierarchy of Pages

One of the first things you need to know is that in OracleAS 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. OracleAS 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.

Anatomy of a Page

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.

Figure 3-2 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:

Figure 3-3 Sample Page

In OracleAS Portal, all three of these elements are called navigation pages. (You can use OracleAS 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 OracleAS 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 OracleAS 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 OracleAS 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 Application Server Portal Developer's Guide on OTN (http://www.oracle.com/technology/products/ias/portal/documentation.html).

  But you don't have to create your own portlets. Simply by installing OracleAS 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 OracleAS 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 OracleAS 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 Application Server Metadata Repository for ongoing management and publishing. If you plan to use OracleAS Portal as a content management solution, you'll no doubt rely heavily on the use of items.

Reusable Objects

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.

Figure 3-4 Page Groups Portlet

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.

Layout and Appearance

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

Content attribution concerns you much more if you're building a page group that supports collaboration among your users. Collaboration is chiefly supported through OracleAS 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 OracleAS 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 OracleAS 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 OracleAS 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, OracleAS 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, OracleAS 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.

3.2.1 Understanding the Planning Process

This section is intended to give you an idea of the things you'll need to consider as you set up your portal, in the rough order in which you'll need to consider them.

• Deciding how to structure your portal is perhaps the biggest and most difficult challenge you'll face. Consider the breadth of content you have, as well as each discrete group of users you're trying to satisfy as you decide whether you need multiple page groups, a single page group, or perhaps even an Oracle Instant Portal.

  • Is your portal for internal use only? Will your users be happy with a very simple portal, with a pre-defined set of items and styles and preconfigured pages that offer no flexibility in terms of layout? If your internal users want to exchange content only with each other, consider creating an Oracle Instant Portal, rather than a page group. Although Oracle Instant Portals provided a limited subset of functionality, the trade-off is that the usage and administrative costs are much lower than a typical portal. In fact, you can start loading content into the portal as soon as it's created. See Chapter 5, "Understanding Oracle Instant Portal" for more information.

  • What is the relative size of your user base? Does it make sense to contain your portal in a single page group, with a home page and perhaps one page (or one page with sub-pages) devoted to the needs of each user group? Is your user population small enough so you can develop the entire site in a single page with tabs? Section 3.2.2, "Using Page Groups Effectively" can help you decide how many page groups you need.

  • It is fairly likely that you will have users who wish to publish business documents and other information to the page group (that is, content contributors), as well as users who will merely consume that information (in other words, viewers). How should those two groups interact? Do you want content contributors to create, edit, and publish the content on the same page where it is viewed? Or do you want to have a separate area in which content contributors can work, then use page portlets and custom searches to present relevant information to viewers? To help make this decision, consider whether the creators of the information are vastly different from the consumers of the information.

    For example, suppose you have a group of engineers that will be producing a great deal of content. You want them to be able to create their page structure naturally, without having to yield to a formal set of guidelines and standards. Because the consumers of much of this information are not engineers, however, the potentially unwieldy page structure that might result could well be distracting or confusing to its non-technical audience. In this case, it's best if the developers are allowed to publish as they wish, and for you to superimpose a structure that is natural and pleasing to the consumers using custom searches and page portlets. If the consumers and the creators are the same, however, there's no reason that content creation and consumption can't occur on the same page(s).

    See Section 3.2.3, "Configuring a Page Group for Content Management" for more information on how to create a page group devoted to content management.

  • Will different groups expect their search results to be confined to their own areas? By default, the search feature combs all pages belonging to the entire page group to which the current page belongs.^Foot 1  If your entire portal is housed in a single page group, someone in Human Resources looking for a particular HR document may be overwhelmed by search results reflecting the entire page group. If you think each group will want their search to be limited to just the data that is relevant to them, consider creating separate page groups for each group within your enterprise.

  If you do decide to create multiple page groups, you'll probably want to develop some common objects and place them in the Shared Objects page group so that you can achieve some consistency across work performed by the different groups. Only objects (navigation pages, templates, styles, and so on) in the Shared Objects page group can be used across multiple page groups.

Once you make your decision about what kind of portal makes sense for your organization, it's time to contemplate how to go about actually building your portal. Here are some things you should consider before doing so:

• Do you want each of the pages within your portal to look similar? One way to accomplish this is through the use of templates. You can build a Portal Template that has a common navigation bar, footer, and banner, then leave it up to individual content contributors to populate the remainder of the page with content. You might also want to create one template for each user group to clearly identify the page as belonging to that group.

  Note: Although you cannot force your page designers/builders to use your template, you can make it the default so that it is the first template listed in the drop-down list in the Page Creation wizard.

• Establish page group wide properties, such as the amount of space to allocate to uploaded files, the default style, navigation page, and Portal Template, and what type of items contributors can add to pages in the page group. You can identify such things as:

  • What level of access will each user or user group have on the pages created within this page group?

  • What template will be selected by default when a new page is created?

  • What navigation page will be selected by default for use as a banner when a new page is created?

  • What style will be applied by default when a new page is created?

  • Will users of this page group have access to HTML Templates, which are built using your own HTML code? (HTML Templates include both Page Skins and Content Layouts. Page Skins place a border or wrapper around a page. Content Layouts format the content of individual regions on the page.)

  Page group-wide settings are made either through the Navigator, or from the toolbar that appears along the top of your page while in edit mode.

• Get started on acquiring the portlets you'll need to populate your pages. You may want to have developers start building portlets to encompass data provided by legacy applications, and you may have a need for portlets provided by Oracle's Partner Program or other third party vendors. See Section 3.2.4, "Deciding What Content To Publish" for some ideas on how to make these decisions. Visit otn.oracle.com for more information on acquiring externally available portlets.

• Create, or have your graphics designer create, a style for your portal to determine the colors and fonts used by the pages in the page group. Later on, you can indicate whether page designers can change this style as they develop their pages and whether users who are viewing the pages can apply their own style preferences to the page.

• Create your home page.

  • Decide how many regions you will need.

  • Create, or have your graphics designer create, a navigation bar and banner. You may also want to consider using a footer for links to related sites and Web pages.

  • Add portlets and items to your page.

  • Establish security for the page.

  Repeat this process for each page you want to create.

• Remember, as page group administrator, you are in charge of not only making decisions that affect the page group as a whole, but also for developing the procedure by which the content on your portal is developed and maintained. You'll probably want to delegate a good deal of the authority for page creation to others so you don't become a bottleneck. You can do this by assigning the appropriate privileges to other users on the page group's Access tab.

3.2.2 Using Page Groups Effectively

A portal is simply a collection of one or more page groups. This section will give you some pointers to help you decide how many page groups you'll need, but keep in mind that each page group usually has a focus that is largely determined by its viewership:

• Page groups devoted to viewers tend to focus on the presentation of the content itself, as opposed to managing that content. Because viewers don't have the privileges necessary to publish content, they become the consumers of information that is published by others. Where that content is managed—in the same or in a different page group—is completely irrelevant to the viewers of the content.

  Content typically produced for the consumption of viewers includes:

  • Announcements of corporate programs, events, quarterly earning reports, and so on

  • Reports that enable users to acquire information and make key business decisions

  • News, weather, and stock quotes from syndicated content feeds

  • Availability of email, calendar, meeting scheduling tools, and other heavily used business applications

  • Smaller portals created and maintained by independent departments within the company

  • Business documents and other information published by fellow employees

  The following illustration depicts the convergence of many disparate information sources on a single page:

  Figure 3-5 Many Data Sources On a Single Page

  
  

  The presentation of this information is frequently augmented by typical portal services like personalization (the ability for users to specify their own preferences for color schemes, the content that appears, and the layout and content of a page), as well as a sophisticated search engine to help users locate critical information quickly.

• Page groups can also be configured to meet the needs of content contributors working in a collaborative manner. In this type of page group, which is tuned for content management, self-service publishing features allow end users to post and share any kind of document or Web content with other users, even those geographically dispersed. For example, consider a development group consisting of engineers, product managers, and quality assurance engineers working at locations scattered all over the world. Each has documents they need to share with members of their own teams as well as the other groups. Nearly every user has the ability to add documents to the page group; certain users have privileges to modify documents produced by other users or groups.

  Unlike more generalized page groups, a content management page group relies heavily on OracleAS Portal's assortment of collaboration features:

  • Check-in/check-out capabilities, so that users cannot overwrite each others changes

  • Version control, so that successive versions of a particular item can be retained or overwritten

  • A security mechanism, by which content can be protected from unauthorized view or manipulation

  • Workflow, which establishes a process through which a document or request flows among users

  • Organizational mechanisms to create a content structure that is easily browsed by the portal user

  If you're operating in a small environment, with no company firewall or no plans to make content available outside your firewall, you may find that a content management page group is sufficient for your needs. Or, you may want your content contributors to produce and edit their business documents in such a page group, and use the page portlet (or the autoquery feature of the custom search portlet) to expose those documents to viewers, either within a set of pages just for them or within a different page group entirely.

  You'll probably want to read this chapter thoroughly before deciding how many page groups you'll need and the focus of each. Your ability to make these key decisions wisely will have a profound impact on the final usability of your portal.

3.2.3 Configuring a Page Group for Content Management

If you're wondering if you should use OracleAS Portal as your content management system, or if you should seek out or perhaps continue to use a third party solution, you may want to read the white paper "Manage, Integrate, and Publish Your Enterprise Content" on the Oracle Technology Network (OTN).

Building a content management page group involves many of the same considerations as any other type of page group. There are some additional things you need to consider that are unique to an environment in which users are creating content. These things include:

• Will a single page group meet your content management needs? Or will you need more than one? Consider the following:

  • How many groups of content contributors do you have? How different are their needs?

  • Are the content attribution needs different for each group of content contributors? Your Travel department might require categories such as Hotels, Air Fares, and Rental Cars, while your Financial group needs categories like Statements, Forecasts, and Data Sheets. Then again, you may deliberately want to develop a taxonomy that is general enough to satisfy all users, regardless of departmental role.

  • What is the amount of information produced by each group? Does the amount suggest that each group or department may require its own page group?

  • Do you need to implement different controls for different groups within your organization? If so, you'll want to set up multiple page groups to address these needs. For example, one group may need to keep multiple versions of their files intact, while others don't require this capability. Or you may want to limit the amount of space a particular group can consume on your server. To get an idea of the kinds of settings you can control at the page group level, click Properties in the Navigator next to your default page group and take a look at the fields on each tab.

  If you do decide to create multiple page groups to support content management, you'll probably want to develop some common objects and place them in the Shared Objects page group so that you can achieve some consistency across work performed by the different groups. Only objects (navigation pages, templates, styles, and so on) in the Shared Objects page group can be used across multiple page groups.

• Within a page group, can you keep the editing experience fairly simple? Doing so may make it easier for content contributors to add content to your portal. For example, consider creating a Portal Template consisting of a very simple layout: a banner, a navigation area along the left side, a footer, and a content region in the center. For all regions except the main content region, you can de-select the check box Enable Users To Include Content In This Region (one of the region properties). When content contributors access this page, they will see edit controls only in the main content region, thus providing a more streamlined, simplified editing experience.

  Another way to simplify the editing experience is to configure the page group so that editing mode is displayed in List view by default (or you can suppress the other options, Graphical and Layout, entirely). List view organizes all items on the page into a simple list that you can sort according to the most relevant criteria. You can also perform an action on multiple objects simultaneously while in List view.

• Examine the item types provided by OracleAS Portal. Are they sufficient for your needs? Will you require additional attributes, or would you like to remove some attributes defined by default? For example, files may have authors, create dates, or keywords associated with them. You may want to include additional attributes, so that you can use the Custom Search portlet to build preconfigured searches based on a given attribute. With the Custom Search portlet, you can collect data together irrespective of category, perspective, item type, and so on. For example, you might want to regularly publish all reports belonging to the category For Review on a weekly basis. To do that, you can use the Publish attribute to specify dates greater than the previous week's publish date. If you construct your attributes wisely, you'll have a great deal of flexibility when creating custom searches.

• How much control do you want to give your page designers and content contributors? Should your page designers be allowed to create sub-pages?

• Establish page group wide properties, including:

  • What level of versioning do you want to enable for all pages in the page group?

  • How do you want to handle the deletion of items? Should the items be "soft-deleted" so that a page manager can "undelete" them later?

  • What template will be selected by default when a new page is created?

  • How long should the New and Updated icons appear beside new and updated items?

  • What navigation page will be selected by default for use as a banner when a new page is created?

  • What style will be applied by default when a new page is created?

  • What item types will be available to users creating new pages?

• Will your users want to use Web Folders to add content to their pages? Web Folders is a Microsoft extension that supports the WebDAV protocol. After configuring Web Folders on a user's computer, the user can browse the contents of any page group through Windows Explorer and drag and drop files into any page to which they have access.

• Do you need to establish any approval or other types of workflow chains so that documents or requests can move from one user to another?

For more detailed information on the features that make OracleAS Portal a viable Content Management System (CMS), see "Oracle Portal 10g Release 2 (10.1.2) Technical Overview", available on OTN. If you decide you want to manage your content in an external CMS but publish that content using OracleAS Portal, there are at least two methods for doing so:

• Move and copy content from your CMS into the Portal repository. For more information, see the white paper "Using WebDAV Clients to Replicate External Content" on OTN.

• Use a query-based method for exposing your data. For example, you may want to use custom portlets to publish content within a portlet, or you might want to rely on Omniportlet. If you prefer the latter option, consider licensing the FAST Data Search application and taking advantage of their Omniportlet integration. Or use the PDK or Omniportlet to build a custom solution.

3.2.4 Deciding What Content To Publish

Although your work as page group administrator may not require you to actually create the content displayed in your portal, you no doubt will have a role in determining what kind of content is required and possibly assisting others in producing that content. You will most likely need to work closely with developers at your site, who have the responsibility of building components and portlets for others to include on their pages. Some of the things you should consider in terms of content creation are:

• Are there any reports, charts, forms, or other components you'd like to display? Assuming that the data required is already in the OracleAS Portal or another enterprise database, you can create these components yourself without the assistance of a developer.^Foot 2  Just go to the Portlet Builders folder in the Portlet Repository and click Additional Portlet Builders.

• You may need to sift through hundreds or thousands of Web sites to find appropriate content. Make your job easier by using Web Clipping portlet. Web Clipping portlet offers an easy, intuitive way to capture content and functionality from existing Web sites and present them as portlets. Create Web clippings on the fly by navigating to the source Web page and selecting the portion of the page to clip. You can find the Web Clipping portlet in the Portlet Repository's Portlet Builders folder. (Note: Web Clipping may be used outside of OracleAS Portal only.)

• Publish Web Service, SQL, XML, or CSV (comma separated value, also known as spreadsheet) data easily using OmniPortlet, or let an existing Web content be your data source. OmniPortlet essentially separates the content publishing from the content layout. Whereas changing a portlet's layout often involves regathering the data, with OmniPortlet you can experiment with layouts at will, without ever having to regenerate the data itself. See the Oracle Application Server Portal Developer's Guide or the online help for more information. OmniPortlet is available in the Portlet Repository's Portlet Builders folder.

• Browse through the Portlet Repository and see if any of the portlets provided by OracleAS Portal will be useful to you. You may also want to check, or have someone else check, the Knowledge Exchange to see if you can incorporate any of the work done by other OracleAS Portal developers. In addition, be sure to peruse the Oracle Partner Network Solutions Catalog, an impressive collection of portlets and services offered by our Oracle Partner program. You can see the full list of partners and get a brief description of their offerings at http://www.oracle.com/webapps/opus/pages/SimpleSearch.jsp.

• To publish static information, such as corporate announcements or press releases, use text items. OracleAS Portal provides an integrated Rich Text Editor that provides a WYSIWYG interface for creating formatted HTML.

• Much of your content will probably come from documents produced by fellow employees. If their work has been loaded into OracleAS Portal and the correct attributes have been supplied, you'll find that the Custom Search portlet is an excellent means for gathering documents together based on a common set of criteria and displaying them in a portlet. In a nutshell, the Custom Search portlet enables you to define a complex set of portal search criteria that executes a search each time the page is rendered. You may want to display all documents created by the Human Resources department in one portlet, for example, and create another portlet with all the internal forms employees may need to reference, irrespective of which department created them. To use the Custom Search portlet, add it to your page from the Portlet Repository, then use the Edit Defaults action to establish your search criteria.

• What kinds of applications are required? Do you have third-party or in-house applications you want to make accessible to your user base? If so, your developers can choose among several paths, ranging from simple to complex:

  • Include the application in the External Applications portlet, then add the portlet to a commonly accessed page.

  • Assuming that the application is Web-enabled, use a Web Clipping, iFrame, or URL portlet to display the application's home page.

  • Use the Portal Developer Kit (PDK) to transform the application into a portlet provider. By doing so, discrete areas of the application can then become portlets that can be manipulated individually.