Understanding PeopleSoft Portal Architecture
This section discusses:
PeopleSoft portal architecture.
The web server.
The application server.
The database server.
The portal registry.
When you develop pagelets, you need to understand the overall architecture of the PeopleSoft portal, as well as the PeopleSoft Pure Internet Architecture. This will enable you to integrate your pagelets in the most efficient manner.
The PeopleSoft Pure Internet Architecture is the server-centric architecture used to deploy PeopleSoft internet applications to end users who access the applications through a web browser. This next generation architecture leverages a number of internet technologies and concepts to deliver simple, ubiquitous access to PeopleSoft applications and to enable the open flow of information between systems.
Using PeopleSoft Pure Internet Architecture as the foundation, you can provide a wide range of end users with access to PeopleSoft applications over the web, as well as more easily integrate your PeopleSoft applications with existing internal systems and external trading partner systems.
The following diagram highlights the systems and the primary portal components of the PeopleSoft Pure Internet Architecture:
The web browser communicates with the web server over HTTP/HTTPS.
The portal servlet runs on the web server. The web server communicates with the application server over Jolt. The web server also communicates with other internet content providers over HTTP/HTTPS.
The portal processor runs on the application server. The search engine retrieves index entries from the portal registry cache on the application server. The application server communicates with the database server through SQL.
The portal registry data resides on the database server.
Warning! Always refer to the certifications section of My Oracle Support for supported configurations. Versions and products supported can change frequently.
PeopleSoft Pure Internet Architecture is a completely server-based architecture. Clients to this architecture can be nearly any kind of internet access device, such as:
A web browser running on supported operating system.
A wireless device or cell phone.
An external or third-party system with extensible markup language (XML)/hypertext transfer protocol (HTTP) protocols.
No PeopleSoft executables are on the client; thus the client can be any internet device that uses standard internet technologies such as HTTP, hypertext markup language (HTML), and XML to communicate with the PeopleSoft internet application server.
A key concept of PeopleSoft Pure Internet Architecture is that no complex client software installation is required. The internet client device accessing the internet architecture already has all of the software and configuration that it needs. No additional software must be installed on the client for interaction with PeopleSoft applications. For example, no Java applets, Windows .DLLs, or browser plug-ins are needed.
The web server acts as the front end of PeopleSoft Pure Internet Architecture. When a client connects to the server by way of a URL, the system displays a sign-in screen sent to the browser in HTML. The web server manages communication with the browser.
The following web server products can be configured to deploy your PeopleSoft applications: Oracle WebLogic server.
Two key PeopleSoft servlets run on the web server—the presentation relay servlet and portal servlet.
Presentation Relay Servlet
The presentation relay servlet is used to process all inbound and outbound HTTP requests for PeopleSoft transactions and queries. This very thin servlet acts as a relay between the client device and the core back-end services on the application server. It receives and serves HTML, XML, and wireless markup language (WML) requests over HTTP.
The portal servlet is a Java servlet that runs on the portal web server. It intercepts user requests for HTML pages, retrieves the requested page, wraps additional content around it, and then sends the resulting page to the user's browser. The servlet acts as an invisible browser that sits between the user's browser and requested content.
The portal servlet:
Provides a consistent user interface.
The portal servlet checks properties associated with each content reference, including the name of a portal template. When a user accesses content through the portal, the portal servlet wraps the target page with the portal template specified in the content reference. This template provides a consistent user interface.
Ensures that PeopleSoft-specific tags are processed correctly.
Developers create portal pages using a template-based layout system. In addition to traditional HTML tags, templates can contain PeopleSoft-specific tags that a normal browser cannot interpret. At runtime, the portal servlet can interpret these PeopleSoft-specific tags when constructing templates, as well as any other HTML content. The portal servlet then sends the resulting page to a browser as a single HTML document.
One of the most important aspects of portal technology is its role in integrating content from a wide variety of data sources and displaying that content on a single page in a coherent, understandable, and presentable way. We refer to this complex process as “page assembly and proxying.” Portal processing assembles the page to be displayed based on the content retrieved from various data sources. It uses portal templates to wrap the contents of the assembled document into a single page that fits into the context of the site.
For page-based templates, the portal servlet assembles pages for the browser.
It ensures that all URL references in the HTML on the assembled page are references back to the portal servlet itself. In some cases, each URL in the HTML document assembled by the portal servlet must be rewritten to reference the portal servlet, not the originally requested URL. This process of redirecting URLs so that they point to the portal servlet is called proxying.
For frame-based templates, the portal server updates the src tags in the frameset with the target content and sends it to the browser.
When working with a frame-based template, the portal servlet inserts a URL into each frame in the src tag and sends it to the browser rather than retrieving documents for the browser as it does with page-based templates.
The application server is the core of PeopleSoft Pure Internet Architecture; it carries out business logic and issues SQL to the database server. The application processing logic that ran on the client in previous releases now runs on the application server. The application server consists of numerous PeopleSoft services and server processes that handle transaction requests. These include requests to:
Build application pages.
Save application pages.
Run some PeopleCode.
Run SQL (prompts, page-specific SQL, validations, and so forth).
The application server is responsible for maintaining the SQL connection to the database for the browser requests and the Windows development environment. PeopleSoft uses Tuxedo to manage database transactions and Jolt, Tuxedo's counterpart, to facilitate transaction requests issued from the internet. Both Tuxedo and Jolt are products of Oracle Systems.
The Portal Processor runs as an application service of the PeopleSoft application server. It runs with the other application services, such as the Component Processor, Security Manager, and SQL Access Manager. Portal Processor tasks include:
Fetching content templates from the database.
Fetching content references from the database portal registry and caching them in the application server portal registry.
Interacting with other application services (lightweight directory access protocol (LDAP), role-based security, and so forth).
The PeopleSoft database is the repository for all information managed by PeopleSoft applications. Not only is application data stored in the database, but PeopleSoft metadata is also maintained in the database. PeopleSoft Application Designer enables you to define and maintain this metadata that the system uses to drive the runtime architecture. The application server carries out business logic based on the PeopleSoft metadata.
At runtime, the application server fetches the most recent application object definitions from the metadata repository, compiles and caches the application object into memory, and carries out the business rules based on the definition.
Note: In general, PeopleSoft Interaction Hub 9.x can retrieve content from any RDBMS-based application as long as the content that is being retrieved is URL-accessible and is HTML-based. Always refer to the certifications section of My Oracle Support for supported RDBMS products.
The portal registry is a key administrative component within the metadata of a PeopleSoft database. A portal registry is a hierarchical structure in which URLs accessed by way of the portal are organized, classified, and registered. Each portal registry consists of the following objects:
Folders group and organize content references into a hierarchy. Each folder can contain content references as well as other folders.
Every portal registry contains a root folder and a Portal Objects folder. The Portal Objects folder contains administrative objects specific to the portal and includes the following folders: Homepage, Navigation Collections, Pagelets, Template Pagelets, and Templates.
In addition to these standard folders, several folders typically are located directly under the root folder: one folder for PeopleTools (administrative references) and other main folders for each PeopleSoft application. These main application folders contain the folders and content references associated with each PeopleSoft application that you've licensed.
Content references are URLs that have been registered in a portal registry. They can be PeopleSoft application pages or external web pages. Content references fall into four main categories: pagelets, target content, templates, and homepage tabs.
In addition to specifying a URL, each content reference includes additional information such as its creator, effective dates, associated template, search keywords, and so forth. Registry URLs can point to any website that responds to HTTP requests with an HTML response—that is, a static or dynamic web page.
For example, a content reference could be a URL pointing to a page in a PeopleSoft application. Or a content reference could point to static HTML pages on an intranet site, such as a procurement or expense policy document, or dynamic pages created by an analytic or reporting system. Access to content references is controlled by security permission lists assigned to each content reference. Any portal content can be limited to a specified group of users, or made public and available to any authorized portal users.
Nodes refer to a source of HTML content. They primarily identify the universal resource indicator (URI). A URI is a subset of the URL that points to the location of the resource. It does not include the content information, such as the target file or application and any parameters passed to that resource.
The portal registry's hierarchical structure enables a portal administrator to more easily create a classification and navigation system in which content references can be registered and managed for all portal users. PeopleTools provides portal administration pages for this purpose. Additionally, the portal includes a registry application programming interface (API) for maintaining the portal registry from PeopleCode.
To improve performance, a copy of the registry is also stored on the application server in cache files. This is how the portal servlet accesses the registry at runtime.
The portal technology framework includes the following services:
Pagelets optionally can be assigned a user personalization settings page. This allows the user of the pagelet to specify selections, settings, or attributes specific to the pagelet’s content. These personalizations commonly alter the content of the pagelet. An example of this would be setting the city for which a weather pagelet displays forecast information. A personalization page is accessible to the user by means of clicking the Personalize button on the pagelet’s frame header.
The portal uses a search engine to quickly search for registered content in the portal registry. This is a popular means of portal navigation. PeopleTools search capabilities were built to assume multilanguage support, including double-byte languages.
PeopleTools portal technology provides a set of navigation components based on the portal registry. These components are the drop-down menu and Favorites. Navigation has been engineered to provide rapid access to complex information based on the role of the user.
PeopleTools portal menu navigation provides a consistent method of content access, categorization, and organization. The menu navigation presents a dynamic hierarchy-based view of the folders and references within the portal registry. Menu navigation is available through the Menu pagelet or from the Main Menu drop-down navigation depending on your portal settings.
The PeopleTools portal includes a My Favorites folder that you use to store frequently accessed pages. In the Menu pagelet, this folder is at the root level. In drop-down navigation, My Favorites appears under the Favorites drop-down menu.
The PeopleTools portal include a Recently Used listthat includes up to five of your most recently accessed components. This list appears under the Favorites drop-down menu.
Previous sections in this PeopleBook have described the individual components of PeopleSoft Pure Internet Architecture. This section provides a high-level overview.
An HTTP request is sent from the user's browser to the portal’s web server, which invokes the portal servlet. Assume that the browser is requesting a PeopleSoft application page.
The portal servlet makes a request to the Portal Processor to fetch the content reference for the link selected by the user. The Portal Processor fetches the content reference from the portal registry and passes a partially completed HTML document back to the portal servlet.
The content reference could be pointing to any or several of the content providers (specified by a node). Each content reference is referenced in a partially completed HTML document. The portal servlet issues the HTTP request to the appropriate web server and retrieves the HTML document.
The portal servlet then completes the page assembly process with the template, merging the content from the HTML document, and then serves the completed page back to the user’s web browser.