Understanding the Portal Registry
The portal registry is a tree structure in which content for a portal is organized, classified, and registered. The portal registry classes (API) are used to update the portal registry. The Portal Administration pages provide a GUI access to the portal registry API. You can also access them using a PeopleCode program you write yourself. How you access the portal registry depends on the type of updates required. Your organization will likely use both methods of updating the portal registry. This topic focuses on accessing the portal registry classes using PeopleCode.
A portal is a website that helps you navigate to other web-based applications and content. The PeopleSoft Portal is a business portal. It is similar to general purpose portals, except that its main purpose is to help end-users be more effective in accessing information to perform their jobs.
Each PeopleSoft Portal is defined by one PeopleSoft portal registry. The PeopleSoft portal registry consists of a number of system tables and associated data in a PeopleSoft database. The portal registry must reside within one PeopleSoft database. There can be more than one portal registry in a PeopleSoft database, but only one portal registry is associated with a PeopleSoft Portal.
The portal registry consists of the following primary parts:
Folders and content references make up the majority of the portal registry, and provide a hierarchical tree structure to describe various content that is registered as part of a PeopleSoft portal.
Nodes provide a logical name to a specific webserver and database, so content can be registered independent of specific webservers. It is used when the portal servlet attempts to retrieve content—both internal PeopleSoft content as well as external content—and to assemble pages.
The primary function of the portal is to take a target URL (generally a URL for a PeopleSoft component) that comes in from a user's browser, and assemble a page with that content and any other content. The layout and what content to assemble on the page is defined by the node template, which is composed of HTML. The portal attempts to find the content reference associated (that is, registered) with the target URL to get the template, or uses a series of default templates if it cannot get the template from a content reference.
Folders are how a hierarchical structure is created within a portal registry. Each folder has a parent, except the root folder, which is the top-level folder in a portal registry. Each folder can also contain child folders and content references. Folders are roughly analogous to directories within a file system. A folder can be further defined by a number of attributes (description, security, when it expires, and so on) that are useful within the portal environment.
A content reference is simply a reference to a URL. After you create an entry for a content reference in the portal registry, it's considered registered. A content reference can be further defined by a number of attributes (description, security, when it expires, and so on) that are useful within the portal environment.
There are a number of distinct types of content references that can be broken down into the following broad categories:
A target type of content reference describes a registered URL that a user might reference. Typically, these would be a PeopleSoft Pure Internet Architecture component, such as a page in a transaction. When a user references a URL, the URL is looked up in the registry to find the target content reference.
A template type of content reference describes what, if any, other content to put on the page, and where to place that content. The portal attempts to find a template for every URL that is requested.
A component type of content reference describes a component that is typically placed on a target page or homepage.
When a content reference is created to register some content (that is, a URL) the specific URI (that is, the scheme, webserver, and so on) can be specified in the content reference. However, this has the drawback that every time the URI for a content reference changes (the webserver name changes, and so on), the content reference must be changed. Nodes are a way to create a logical name for a specific webserver, scheme, and so on. When the content reference is created you can specify a node name.
For example, suppose the name of a webserver changed. If you don't use nodes, you must check all your content references and change them accordingly. If you use nodes, you have to change only the webserver name in one place, and all the content references that use that node now automatically reference the correct webserver.
Nodes can be optional for content where the specified URL is already a complete URL, such as for external content. Nodes can be categorized as:
The same security mechanism is used for folders, content references, content reference links, tab definitions, pagelets, and user homepages. All of these items can be marked as public, owner accessible, or can have explicit PeopleSoft permission values set, including cascading the permissions to its child objects (that is, the child objects have the same permissions as the parent objects, when applicable.)
When marked as public, the item is accessible by any user. Public access cannot be cascaded, that is, passed down, to child objects.
When marked as owner accessible, an item is accessible only by the same user that created that item. Owner accessible cannot be cascaded, that is, passed down, to child objects.
Items can be marked as accessible by PeopleSoft permissions. This means that if a user is a member of a role, and the role contains the permission list that the item is also associated with, the user has access to that item. Additionally, when applied to folder permissions the permission can be cascaded. This means that any child of that folder, including a content reference, automatically has that permission added to its permission list.
Role-based security can applied to the portal objects (folders, content references and content reference links) using the RolePermissions collection.
Note: You can only use role-based security for content references, folders, and content reference links that are not components or iScripts.
You can specify which roles are allowed to access the objects. This works similarly to permission lists. If a user has a specified role, authorization is granted.
A role collection is the same as the PermissionValue collection, though there are additional properties on PermissionValue.
Folders, content references, content reference links, PageletCategory objects, and Pagelets can have any number of attributes added to them. Attributes are simply name/value pairs. These name/value pairs are defined and used by many portal-aware applications, such as the search engine, navigational display, and so on.
See Using Attributes.
Using the PortalRegistry, you can also add and customize other items in your portal, such as tabs, homepages, and favorites.
The TabDefinition is a homepage tab that has been defined to the portal. It is what an administrator creates when they want to define a new homepage tab. The TabDefinition is based on content references.
The User Homepage is a personalized homepage for a user. It contains all the tabs and pagelets the user has selected for their homepage. The User Homepage is based on folders.
A Favorite represents a content reference that the user wants to keep a shortcut to. It contains the name of the content reference, and the label the user wants displayed for this favorite.
A Pagelets is an area on a page that contains content, and the template used to specify the style for that content. Pagelets are a type of content reference.