|
Oracle® Application Server Portal User's Guide
10g Release 2 (10.1.4) B13809-04 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal User's Guide
10g Release 2 (10.1.4) B13809-04 |
|
|
Previous |
Next |
If you are responsible for building a portal for others to populate with content, this chapter can help you. As the page group administrator, your job is to think about the portal as a whole and the needs of the community it will serve. Among other things, you must decide how many page groups your portal should comprise, how to approach portal development, and how to optimize a given page group for the purposes it will serve.
|
Note: Before you begin your work, make sure that the portal administrator has already completed all the necessary portal administration tasks, described in the Oracle Application Server Portal Configuration Guide. (If you're unfamiliar with either of these highlighted terms or what's meant by them, see Section 3.1.2, "Knowing Your Audience"). |
To build an effective portal, it's important to arm yourself with knowledge and to do some careful planning before embarking upon the actual work of creating the portal. Section 3.1, "Getting Up to Speed" contains three sections to help you acquire the knowledge you need:
Approaching Your Portal discusses the ways in which people tend to tackle the portal-building process, and offers some recommendations to help you get off on the right foot.
Knowing Your Audience defines the different user groups typically found at most enterprises.
Key Concepts and Terms gives you an overview of the components comprising OracleAS Portal. After reading this section, you'll be well positioned to take advantage of the wealth of features available to you in this product.
Once you've digested the information in Getting Up to Speed, you'll be ready to start tackling the job of creating the portal itself. You'll find that you can build your portal in less time, and achieve far more sophisticated results, if you take the time to study the information in Section 3.2, "Making Key Decisions", which contains:
Understanding the Planning Process sketches out the decisions you need to make, in the rough order you'll need to make them.
Using Page Groups Effectively introduces the concept of devoting page groups to discrete groups of users, rather than having a possibly diverse set of users share a single page group.
If you decide that you need to create a portal specifically for content management purposes, Configuring a Page Group for Content Management discusses some points you'll want to consider.
Deciding What Content To Publish helps you understand the different places from which content can originate and how best to bring them into your portal.
While it may be tempting to skip the preliminary information presented in this chapter, it is strongly recommended that you read through it carefully.
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 OracleAS Portal, how to truly understand your audience, and, most important, leads you through all the key concepts you need to know about OracleAS 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 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.
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.
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:
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.
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 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.
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. |
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.
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.
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. 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.
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:
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.
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.
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.
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.
