Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle Portal
11g Release 1 (11.1.1)

Part Number E10235-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3.2 Making Key Decisions

Now that you have an understanding of the basic concepts underlying portal development, you're ready to begin considering the needs of your particular enterprise.

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.

Note:

Although it may be quite tempting to simply dive in and start creating pages, you'll find that the more time you invest in planning and making considered decisions in the beginning, the less likely it is that you'll have to go back and reconstruct portions of the portal—or the very structure of the portal itself—later on. Each decision you make at the page group level can have far-reaching effects on the pages residing within.

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

    • 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

    Information from many data sources consolidated on one 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 Fusion Middleware Developer's Guide for Oracle Portal 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 Oracle 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 Oracle 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. Oracle 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 Oracle 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.



Footnote Legend

Footnote 1: Although it is possible to use the custom search feature to search multiple page groups, less sophisticated users may not be comfortable doing that.
Footnote 2: If you are relying on data in another enterprise database, make sure your portal administrator has established the proper database links from the Oracle Portal database to that data source before you begin your work.