Peopletools 8.52 hardware and software requirements

Because it is a standard page, the extension page can use a grid to retrieve and display a longer list of tasks. In addition, the extension page is also better suited to display more details because it is wider than the pagelet and can show more columns.

Pagelet Personalizations Like homepages, pagelets can be personalized in different ways. The data displayed can be filtered automatically to show only data that is relevant to a particular user. The user can also explicitly personalize the data shown by setting options on a personalization page.

Personalization pages are another type of pagelet extension. However, personalization page pagelet extensions are different from previously discussed pagelet extensions in the following ways:.

You do not click a button or link on the pagelet to access personalization pages. Instead, clicking the Personalize icon on the pagelet header accesses a personalization page where you can define user options that are specific to that pagelet. Setting values on the personalization page will change the way data appears on the pagelet for the user. Detail pages usually display data in read-only mode or allow you to change application data. Any text that the pagelet developer enters during Step 3 in Pagelet Wizard appears as instructions on the Personalize page.

You can use the Personalize Tasks personalization page for the Tasks pagelet to change the type and number of tasks shown on the pagelet. Clicking Save stores these values and returns you to the homepage.

The Tasks pagelet now reflects these changes. 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 these primary portal components of the PeopleSoft Pure Internet Architecture:. 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 a PC is the most common internet client. The PeopleSoft internet application server simply serves HTML and JavaScript to the web browser and the end user navigates through the PeopleSoft application as if he or she were navigating any other website.

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 manages communication with the browser. Two key PeopleSoft servlets run on the web server—the presentation relay servlet and portal 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. 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 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. 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. It uses portal templates to wrap the contents of the assembled document into a single page that fits into the context of the site.

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 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:. 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. Portal Processor tasks include:. 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. In general, PeopleSoft Application Portal 9. 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. 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. 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. Pagelets optionally can be assigned a user personalization settings page.

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. The portal uses a search engine to quickly search for registered content in the portal registry.

This is a popular means of portal navigation. Verity, the industry leading search engine, is packaged with the portal technology. 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.

Managing General Settings for Portals. This section provides a high-level overview. 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. Do not provide any filter, sort, or refresh buttons because they also require trips to the application server. If you enable the cache homepage option in the web profile, the pagelet must be display-only and cannot be interactive.

Because the portal servlet performs page assembly and proxying only on blocks of HTML, a pagelet must:. The pagelet's width should conform to the narrow or wide guidelines discussed in the Sizing section in this document. See Pagelet Sizes. If you write custom JavaScript code, ensure that JavaScript from multiple portlets can coexist on the same page. Only one namespace is shared by all portlets on a portal page. However, these requirements are not exclusive to PeopleSoft.

This enables users to sign in once when accessing the portal and not have additional sign-ins for each system that is referenced in your portal. See Understanding Single Signon and Pagelets. Leave more than 20 percent spacing between field labels and field edit boxes because the rendered styles are larger in the browser than they appear in PeopleSoft Application Designer.

Before bringing your pagelet into the portal, view it in PeopleSoft Application Designer. Select Layout, View in Browser. The appearance of objects on pagelets, such as text, links, tables, and so forth, should be modified by means of the PeopleSoft style classes to retain a consistent appearance and character between your pagelet and the rest of the portal.

PeopleSoft uses cascading style sheets CSS. Style sheets are useful because they enable developers to change page attributes across multiple pages quickly and easily. Each style sheet is composed of individual classes, which affect the formatting of each page. Classes control a broad range of characteristics, including font size, spacing, alignment, border width, weight, and color. When creating the page, select the Use Default Style Sheet option. For any controls on the page, select the Use Default Style option.

All style sheets used in each pagelet on the page are referenced on the final page that is assembled by the portal. Therefore, a pagelet should not redefine any class that might be shared by other pagelets on the assembled page.

If a class needs to be changed, define a new one. In the same way that PeopleTools supports subrecords to enable shared definitions between records, you can define substyle sheets to share a common set of classes. A substyle sheet has all of the properties of a style sheet. Style sheet definitions are stored in the database. They are accessed and modified by means of PeopleSoft Application Designer. The value in the Style Sheet Name field designates the style sheet used by the database.

Two ways are available by which you can see the style classes defined in a style sheet. If you access PeopleSoft Application Designer, you can open the designated style sheet and view its definitions in a graphical interface.

For example, on WebLogic you'll find the file in this directory:. For example, it might have a different numbered suffix. When processing page-based templates, the portal servlet uses a process called proxying to help ensure that users always stay within the context of the portal and that familiar portal features such as the universal navigation header do not disappear when a user clicks a link.

When a user signs in to a PeopleSoft portal, he or she signs in to a web server on which the portal servlet is running. The portal servlet proxies all links and all form actions in this manner. For example, assume that a user requests a page from an external website through a proxied link in the portal. The request arrives at the portal web server, invoking the portal servlet. The portal servlet then programmatically retrieves the page from the web server associated with the requested page.

It proxies all the links on the retrieved response and sends the page the contents of the HTTP response back to the browser, formatted as the user would expect within the portal. When a URL is invoked on a target page, as opposed to the homepage, the content associated with the URL is rendered within the target frame. The PeopleSoft Application Portal and header and left-hand area will remain. The browser does not access the web server after the homepage is initially retrieved. You can enable or disable this feature, and also adjust the time interval before the web server is accessed again to get a fresh homepage.

In any case, if a user clicks the browser Refresh button, the homepage is accessed from the web server again, overwriting the homepage cached on the browser. If any homepage pagelet in your implementation uses interactive mode, you must disable browser homepage caching in the web profile. Additionally, the following configuration properties are associated with homepage caching. Any changes to these settings are applied to all users signing in to the web server. If set to True, the homepage is cached on the browser.

If set to False, the homepage is not cached on the browser. A homepage cached on the browser is considered stale after the specified number of seconds. The next time a user accesses the homepage by clicking a link, the web server is accessed and the homepage is refreshed on the browser. Because different browser versions do not process HTML in exactly the same way, the browserprops. This can be useful if you have one or two supported browsers and want to disable cache for nonstandard browsers that could pose an administration problem.

Follow the instructions in the file to disable caching for certain browser types. Set the Time page held in cache option by navigating to My Personalizations and clicking the Personalize Option button for the General Options personalization category. Note that this option is set in minutes, not seconds. A change to this option is picked up by the application server immediately. However, because the users' browsers already have cache control set by the previous value of the option, you must delete the browser cache for the new Time page held in cache value to take effect.

Oracle enables you to prevent the system from caching PeopleSoft pages to the browser. You control browser caching using the EnableBrowserCache property in the configuration. Being able to control browser caching is useful for situations in which PeopleSoft applications are deployed to kiosk workstations where multiple users access the applications. Enabling you to prevent caching means that users can't click the Back button to view another individual's transaction or view any other sensitive data.

The side effect of completely disabling caching is degraded performance. For each new page, the system must access the database. You can enable browser caching for the navigation pages that remain relatively static.

This option applies to PeopleSoft Pure Internet Architecture navigation pages, portal homepages, and navigation pages. Use it to take advantage of the performance gains of caching while limiting the amount of time that navigation pages—the menu pages—remain in cache.

The Time page held in cache option is set to 20 by default. To disable this option, enter 0 in the Override Value edit box. The minimum value in minutes for this option is 0 disabled and the maximum value is , which is one year. If the Time page held in cache option is set to 20, and if you assume that the time is 7 p. This header information indicates that in 20 minutes the system needs to check for a new page.

This reduces the performance degradation when no caching occurs at all. The system never caches pages. When a user clicks the browser Back button, she receives a Page Expired message in. No caching. For more information about how you can use this Pagelet Wizard feature to facilitate passing runtime parameters, such as language, see Pagelet Wizard documentation in this PeopleBook.

In addition, Java classes delivered with PeopleTools enable you to call PeopleCode from your Java program and access contextual information from the runtime system. If needed, language can be retrieved through a PeopleCode function that is accessible from Java.

Further information about this feature can be found in this document. See Developing Java-Based Pagelets. You can create a pagelet using several ways. Some methods leverage PeopleTools, while other options allow pagelet creation without PeopleTools. One set of options is to develop pagelets with PeopleTools. This is the most straightforward approach if you are dealing solely with data from PeopleSoft applications.

The two types of PeopleTools-based pagelets are:. This is the most straightforward approach when the data being rendered is in a PeopleSoft application database. This allows more control over data retrieved and enables you to conditionally render HTML. This approach gives you maximum flexibility, but unlike the PeopleSoft Pure Internet Architecture page approach, you must code for things such as multilanguage and browser support.

The focus of this document is a set of options that can be used to create a pagelet application with one of the many technologies that generate HTML. Here you see ways that you develop in a PeopleSoft environment using technology other than PeopleTools:.

Pagelet Wizard walks you through a series of steps involved in creating and publishing a pagelet. Portal administrators and nontechnical users can integrate and transform data from a wide variety of data sources, both internal and external to PeopleSoft applications. You do not need to have PeopleSoft-specific application development tools or skills to be able to create pagelets. The homepage layout can vary based on end-user personalization.

These two layout choices are available for homepages and dashboard pages:. The three-column layout divides the homepage into three equally-sized columns. In PeopleSoft applications, these are called narrow columns. The two-column layout divides the homepage into two differently-sized columns: one narrow column and one wide column, which is twice the width of the narrow column. Because pagelets must function in two possible homepage layouts, it is column size that drives pagelet size.

This fact is evident in the three categories of pagelet widths that are listed here:. With three-column layout, all pagelets are rendered as narrow pagelets.

Narrow pagelets are designed to be approximately pixels wide. Subtracting the border and the internal margin leaves pixels for the content. A narrow pagelet appears in a column that is one-third the width of the portal homepage. Because the pagelet is narrow, you should provide a succinct list of values that users can quickly traverse. Select the minimum set of data that best encapsulate the pagelet content. A narrow pagelet typically accommodates a single character field.

A pagelet that has been designed to fit in a narrow column can be rendered in a wide column as well. However, user interface issues can occur when a pagelet that has been designed to render in a wide column only is rendered in a narrow column.

Therefore, a pagelet should always be able to operate in a narrow format. Generally, all pagelets should be developed with the narrow column size as the default. However, a pagelet can be designed to take advantage of the additional space when it is rendered in a wide column. With two-column layout, the first column allows spacing for a narrow pagelet and the second column allows spacing for a wide pagelet.

Wide pagelets are designed to span two-thirds of the width of the homepage. Although you can fit more data on the pagelet, the data must remain meaningful. Developing a wide version of a pagelet is optional. The function pgltAtion does not check or use this parameter, the narrow pagelet will just be rendered in a wider area.

Banner pagelets are the widest of all pagelets. Banner pagelets extend across the entire width of the homepage or dashboard page and span all columns regardless of layout. Both the two-column and three-column layouts enable you to add one banner pagelet that is positioned at the top of the page.

Banner pagelets are designed to be pixels wide. The actual number of pixels that are available for content varies based on the resolution of your display and the rendering engine of your browser.

You must manually enter this attribute name and its accompanying value. Homepages and dashboard pages can display one banner pagelet only. See Creating Banner Pagelets. Pagelet extensions are standard pages. They can be registered with a template that allows it to use the entire width of the browser with no side frame for navigation, or with a template that includes a side frame.

In the former case, no inherent sizing requirements are imposed. PeopleSoft pages are designed for browsers running with a resolution of at least x Therefore, when a side frame is not included, a pagelet extension should not be wider than pixels, accounting for borders and so forth. Avoid large borders or a design that creates extraneous white space.

Screen area on a homepage is valuable and data should be maximized. Avoid designs that make the pagelet wider than the prescribed size. This undesirable design forces the user to scroll horizontally, so you should design your HTML to be vertically oriented.

For instance, radio buttons should be arranged vertically, not side-by-side. When you create a form, buttons should appear below a text box, not next to it. Because this is a business-oriented portal, avoid extravagant or extraneous graphics. If you use graphics, they should be purposeful and unobtrusive. No graphic should be wider than pixels, which would force the pagelet to be wider than a narrow pagelet. Avoid using any text or HTML tags that force the pagelet to a width that is greater than pixels.

In general, avoid explicit sizing. Let the browser render content in the space that is available, which should allow your text and graphics to fit appropriately. For example, place text in an HTML table to enable the table to wrap any long strings. When appropriate, use the PeopleSoft style sheet to ensure that the appearance and character of your pagelet is consistent with the rest of the PeopleTools portal content.

If a pagelet has personalization options, the pagelet should have a default mode. In default mode, ensure that the pagelet includes a standard set of data and a message conveying that default data can be personalized. Events beginning with on are naively combined, so if one of them issues a return, the following events will not run. All other attributes are not examined; rather they are used in order of precedence.

For example, if both the template and a content component contain topmargin, the template attribute will be applied. Avoid large borders or anything that creates extraneous white space. Avoid implementing anything that will make the pagelet width wider than the prescribed size.

Making the user scroll horizontally is undesirable. Make your HTML vertically oriented. For instance, radio buttons should be placed vertically, not side-by-side. When you create a form, any buttons should appear under a text box, not next to it. Avoid using graphics that do not have thoughtful purpose. This is a business-oriented portal, so extravagant or extraneous images should not be used. If any are used, they should be purposeful and unobtrusive.

No graphic should be wider than pixels. A graphic larger than this size will force the width of the pagelet to exceed the size of a narrow pagelet. In general, avoid explicit sizing and allow the portal to set the width. Your text and graphics should then fit appropriately. For instance, placing text within an HTML table will allow it to wrap any long strings. When appropriate, use the PeopleSoft style sheet to ensure that the appearance and character of your pagelet is consistent with the rest of the Application Portal content.

As mentioned earlier, this is a business-oriented portal. Although content and name recognition are important, they are secondary to the primary goal of enabling end users to perform their work in a more efficient manner. Thus, any branding should be subtle and never detract from the pagelet content or the rest of the portal. Thus, for a user to operate within the PeopleSoft Application Portal product, a pagelet developed outside of PeopleSoft can credit the source developer, but must follow these standards:.

Branding on a homepage pagelet should be done by means of text only and should be placed at the bottom of the pagelet.

No organization logos can be placed on the pagelet without permission from Oracle. Also, XXX can be a link to an appropriate web page. Organization logos and further information about your organization, products, and services should be located on the pagelet personalization page or other pagelet extensions.

Generally, graphics for organization logos should not be larger than pixels wide x 40 pixels high. If you wanted to create a pagelet that an associate could use to search for keywords on another website, it might look like the following example.

Remember that pagelets should be as easy and intuitive to use as possible. It uses a table to help wrap words, rather than allowing long strings to dictate the width of the pagelet.

The branding is small and no graphics are used, thus adhering to the branding standards mentioned previously. The examples shown thus far have used publicly-available URLs. Even if the examples represent third-party applications, the discussion has concentrated on retrieving data and rendering a pagelet.

The chapter has not yet discussed the possible need to sign in to a non-PeopleSoft system. When two or more systems need separate authentication, automating the sign in process is preferable. Needing to manually sign in to several different systems each day is inconvenient and annoying. Users often expect a business portal to be similar to accessing a variety of internet websites. Once signed in to the portal, a user should rarely if ever need to sign in to another system.

Accomplishing single signon between PeopleSoft and other systems can be done in several ways. First, you need to determine the primary or master and secondary or slave authentication systems. Once a PeopleSoft user has signed in, an authentication cookie is sent to the browser's memory.

Other applications can choose to authenticate using this cookie. Oracle provides an API that other applications can leverage. This is the option that is discussed in detail in this section.

A variant of the previous option would be for all applications including PeopleSoft to leverage, or trust, a third-party authentication system such as Netegrity, Oblix, or Securant. If you are writing a pagelet for the PeopleSoft portal, you have no guarantee that all possible customers for the pagelet will have access to a third-party authentication system.

Thus, this option is not discussed in this PeopleBook. Before discussing how your pagelet could leverage PeopleSoft authentication, you need to understand the authentication process. After the first application server or node authenticates a user, the PeopleSoft application delivers a web browser cookie containing an authentication token.

PeopleSoft Pure Internet Architecture uses web browser cookies to store a unique access token for all users after they are initially authenticated. Your non-PeopleSoft application could do something similar. Single signon is critical for PeopleSoft portal implementations because the portal integrates content from various data sources and application servers and presents them in a unified interface. When users sign in through the portal, they always take advantage of single signon.

Users need to sign in once and be able to navigate freely without encountering numerous sign-in screens. Contains the user ID of the user to which the server issued the token.

When the browser submits this token for single sign-on, this is the user that the application server signs in to the system. Specifies the language code of the user.

When the system uses this token for single sign-on, it sets the language code for the session based on this value. Specifies the date and time that the token was first issued. The system uses this field to enforce a time-out interval for the single sign-on token. Any application server that accepts tokens for sign-in has a time-out minutes parameter configured at the system level.

A system administrator sets this parameter using the Single Signon page. Specifies the name of the system that issued the token. When it creates the token, the application server retrieves this value from the database. Specifically, it retrieves the defined local node. Single sign-on is not related to PeopleSoft Integration Broker messaging, except that single sign-on functionality leverages the messaging concept of nodes and local nodes.

You configure only a node to trust single sign-on tokens from specific nodes. Consequently, an application server needs an Issuing System value so that it can check against its list of trusted nodes to determine whether it trusts the issued token. Contains a digital signature that enables the application server using a token for single sign-on to ensure that the token hasn't been tampered with after it was originally issued.

The system issuing the token generates the signature by concatenating the contents of the token all of the fields that appear in this table with the message node password for the local node. The system then hashes the resulting string using the SHA1 hash algorithm for example,. Only one way is available to derive the bits of data that make up the signature, and that is by hashing exactly the same user ID, language, date time, issuing system, and node password.

If you are using digital certificate authentication, the signature of the digital certificate occupies this space. The preceding description applies only to using password authentication. You can store user credentials in an LDAP directory if desired, but it is not required. You can set the expiration of the cookie to be a matter of minutes or hours. This expiration option is a useful security feature. This component interface helps ensure that users who have already signed in to the portal don't have to sign in again for every system that you reference in your portal.

Component interfaces are the focal points for externalizing access to existing PeopleSoft components. They provide real-time synchronous access to the PeopleSoft business rules and data associated with a component outside the PeopleSoft online system. Component interfaces can be viewed as black boxes that encapsulate PeopleSoft data and business processes, and hide the details of the structure and implementation of the underlying page and data.

To take advantage of the Single Signon API, you need to create a custom API, which includes building the dynamic link libraries, classes, and registry settings necessary to enable an external application to communicate with the portal. This can be done automatically through PeopleTools. More information about building dynamic link libraries, classes, and registry settings, as well as other details about PeopleSoft component interfaces, can be found in the Enterprise PeopleTools 8.

See PeopleTools 8. PeopleCode programs do not require a component interface API and, in fact, Oracle does not recommend building a component interface API if the component interface is to be accessed from PeopleCode only.

The registry file may also need to be run to update the registry with the new libraries. Your external authentication program distributes an authentication token that can be retrieved from a cookie in the browser.

The Authenticate function determines whether an authentication token is valid. If the token is valid, you use the GetUserID function to retrieve the user ID associated with the authentication token. If the sign-in to the portal application server is successful, the server generates a single signon token.

The web server receives the single sign-on token from the application server and issues a cookie to the browser. The user navigates in the portal and encounters a link to the external system. The user clicks the link. Authenticate Auth. In general, cookies are not transferable across domains. The only domain that can access the cookie is the domain that created it. Therefore, the web server for the non-PeopleSoft system must be on the same domain as the PeopleSoft system so that the cookies are passed appropriately.

Developers of external applications need to alter the sign-on process to conform to the following requirements:. If the cookie doesn't exist, continue with the normal sign-in process. Otherwise, bypass the sign-in page.

The following PeopleCode example shows the process of validating your authentication token and retrieving the user ID. GetCompIntfc CompIntfc. Please ensure Component Interface Security access is granted to this user.

This component interface is not mapped to data. The component interface is not mapped to data because the key field for the data would be the authentication token. Before you begin modifying or creating new translations of PeopleTools, ensure that you have the required files and software tools. When you install PeopleTools, you have the option to install the PeopleTools Language Development Kit when you install the file server.

The PeopleSoft system provides source code to the English language resource files and selected local language resources. It also supports header files that you need in order to produce alternate language DLLs.

The PeopleSoft system also provides batch files to automate the resource compilation process. In addition to the source code to the resource files that are delivered in the PeopleTools Language Development Kit, the PeopleSoft system delivers precompiled alternate language DLLs for each language provided by the PeopleSoft system. If you are translating any resources other than strings, you must use the Microsoft Developer Studio.

Although the majority of PeopleTools user interface elements viewed by the end user are stored in the database, PeopleTools executable modules do contain some translatable elements. The PeopleSoft system uses a naming convention that includes the name of the base executable an executable with English strings and the language code that identifies the language of the alternate language DLL.

An alternate language DLL is named as follows:. Three-character code that identifies the PeopleTools module associated with the alternate language DLL. The following diagram illustrates the structure and execution flow of a base module psmod. The base executable, psmod.

The alternate language DLL is used only to store translated resources. Program execution follows this flow:. If the session language is English, psmod. If the alternate language DLL exists, then psmod. If the alternate language DLL does not exist, psmod. Alternate language DLLs must be present on all application servers. PeopleTools development environments in a three-tier installation also must have the alternate language DLLs present.

Microsoft Windows application servers and PeopleTools development environment workstations use Microsoft Windows resources from the base language and alternate language DLLs. This file contains the same resources as the alternate language DLLs. The following table shows the content of the directories that are used to support translated resources.

These directories are distributed with PeopleTools and contain user-customizable resource files and other supporting files that are needed to compile, bind, name, and copy alternate language resource DLLs. The root directory for alternate language resource DLLs. The files in this directory include some batch files that are used in constructing alternate language DLLs. A prototypical alternate language development directory for the English language.

One of these directories exists for each alternate language. Copy this directory for each new alternate language that you create. Holds header. H files that are common to several DLLs and various icons and bitmaps. These directories contain the following file types:. To translate resource files into a new language, copy the source code for the English translations provided by the PeopleSoft system and use this as a starting point for the new language.

Alternatively, if you are only making minor modifications to an existing translation provided by the PeopleSoft system such as to change terminology , you can use any of the languages provided by the PeopleSoft system as a starting point. You must follow these steps only if you want to translate PeopleTools into a language that is not provided by the PeopleSoft system or if you want to modify one of the provided translations. In this example, QUE is the designation for Quechua. You can decide the appropriate three-letter code for your language, but you should ensure that it is consistently used across PeopleTools whenever you use this language.

See Adding New Languages.