This chapter contains the following topics:
A portal is an application that aggregates portlets into pages and provides authentication, authorization and administration tools. A portlet is a single piece of portal content; it is the window through which users interact with the application while using a portal. Portlets provide information and act as gateways to full-blown applications. Portlets cannot communicate to one another, only to an application.
The principle value of a portlet to a user is that, compared to launching an application and searching for data manually, a portlet can significantly shorten the number of clicks required to get from the portal to the desired information or transaction.
This section discusses the three portlet types:
Alerts
Menus
Shortcuts
These types of portlets are typical of "dashboard" portal configurations used for business intelligence. They show a single dimension of data, provide a description for that data, and have a threshold value, which is often user configurable. If the threshold is breached, some event usually occurs to alert the user to the condition.
As a rule of thumb, limit each portlet to a single data dimension. Users who want to monitor several dimensions should have several portlets available on their portal—one for each dimension to be monitored.
Often, these types of portlets also provide a link to a transactional application that enables the user to see more detail and then change the situation that has caused the alert. If you provide such a link, be sure to prepopulate the transactional application with the data driving the portlet display result. Ideally, the user should not need to perform any queries for the initial data view when the application launches.
These types of portlets contain task-based links and shortcuts to web locations and applications. The value of such portlets is that the links should be highly tailored to the job role. The links you create to applications should therefore preload as much data as possible, based on the user's role. The idea is to reduce the amount of repetitive data entry the user must perform before entering a frequently-used application.
For example, a sales representative might want a portlet with a menu comprising his or her top 10 accounts. By clicking an account, the user launches an application in a view that shows an overview of all account activity for the last three months.
These types of portlets facilitate information lookup. Typically, they accept a limited amount of information, one or two fields of data. Just as with menu portlets, you should build in as much as possible based on the job role of the user to reduce data entry and target the result set as much as possible.
Frequently, these types of portlets display the results in an application, not the portlet itself. However, the application is often one that facilitates filtering the results and is not necessarily a full-blown transactional application. Based on your context, you might want to make it easy for the user to launch such an application from the filtering view.
This section discusses:
Portlet form features.
Portlet personalization.
Portlet form events.
Edit portlet form design-time considerations.
Portlet forms are the form types you use to create portlets intended for use in the Oracle Portal or the Collaborative Portal.
Note:
Portlet forms are supported in JD Edwards EnterpriseOne version 8.11 and might not function correctly in older versions of the software.Portlet forms have these general characteristics:
All regular controls can be placed on portlet forms.
Multiple tab controls are permitted.
Toolbar and form/row exits are not permitted on a portlet form.
You must add action buttons to a portlet form.
No default action buttons are defined by Form Design Aid (FDA).
Default actions can be placed anywhere on the portlet form.
Portlet forms do not contain scroll bars; you must display all controls within the form.
Portlet forms support the Fetch on Business View and Update on Business View form property options.
You can nest reusable and embedded subforms in portlet forms.
JD Edwards EnterpriseOne Tools provides two types of portlet forms: browse portlets and edit portlets. Browse portlets enable the display of and queries for information. Edit portlets enable user edit functions—adding, changing, and deleting table information.
If you include a form interconnection in a portlet, the portal containing it will automatically resize the portlet to its maximum size when the user triggers the interconnection. When the user closes the application, the portlet returns to its normal size.
One feature of portlet forms that is unique among FDA form types is portlet personalization. Users can toggle between standard mode (where they interact with the application) and personalization mode, where they can select different options that affect how the application runs while in standard mode.
For example, say that the application by default displays all accounts that are overdue by 30 days or more. Users might be able to choose instead to view accounts that are overdue by 60 days instead, or by accounts in a certain region that are overdue. Alternatively, they might have an option which displays the information in a summarized format instead of showing all the data you show by default. Personalization values are user specific.
You control what options users have. Every option you provide, be it as simple as a filtering function or as complex as invoking additional functionality, is a data dictionary (DD) item passed in with the data structure. The DD items appear when the user toggles to personalization mode, and the user can trigger them by choosing the options and then returning to standard mode. If you do not include any such items in the data structure, then personalization mode is disabled for that portlet.
Because the available options are based on the form's data structure, those values are passed in by runtime to the form if they have been set.
Runtime provides three events that are specific to portlet form types:
This event occurs when runtime initializes the portlet form and before it initializes any forms which the portlet might contain.
This event occurs immediately after initialization to apply previously-saved personalization data. It occurs again when the user clicks the Save button in personalization mode.
This event occurs when the portlet is unloaded by the container. Typically, this occurs as the user logs out or the session times out.
In addition to the portlet-specific events, portlets support the general events in this table:
| Event | Browse Portlet | Edit Portlet |
|---|---|---|
| Grid Record is Fetched | Yes | Yes |
| Write Grid Line-Before | Yes | Yes |
| Last Grid Record Has Been Read | Yes | Yes |
| Notified By Child | Yes | No |
| Grid Record is Fetched | No | Yes |
| Write Grid Line-Before | No | Yes |
| Last Grid Record Has Been Read | No | Yes |
| Add Record to DB - Before | No | Yes |
| Add Record to DB - After | No | Yes |
| Update Record to DB - Before | No | Yes |
In addition to standard form properties, you can control the transaction boundary for edit portlets. You can choose to process each action (that is, insert, update, or delete) on the form separately (Transaction Disabled), or you can process all of the actions at once (Portlet Only Transaction). Choose the latter if processing each action separately would cause data integrity issues. Transaction processing for edit portlets is identical to that for subforms.
This section provides an overview of generating portlets and discusses how to deploy an FDA-created portlet.
Before you complete the tasks in this section:
Create or obtain a portlet application that was created in FDA.
Generate the application using eGenerator.
Generating an application based on portlet form types is similar to generating an application based on other form types, the difference being that you must also generate a portlet descriptor file, portlet.xml, that tells the portal which applications are available for the portlet (the WebClient_Portal.war file). This is an overview of the high-level tasks you must complete to create and view a portlet using FDA:
Create an application in FDA using the portlet form types.
Generate the application (that is, the portlet) with eGenerator.
Generate the portlet.xml file into WebClient_Portal.war file with eGenerator.
Install the .war file in Collaborative Portal.
To view it, add the portlet to a page in the portal.
This section discusses how to deploy an FDA-created portlet so that you can install it in Collaborative Portal.
To deploy an FDA-created portlet:
Launch eGenerator and select Generate, Portlet Deployment.
Select the .war file to generate.
Typically, the .war file for the local version of Collaborative Portal resides in C:\B9\system\Generator\WebClient_Portal.war.
eGenerator reads the local specifications for JD Edwards EnterpriseOne and lists all portlets it discovers.
Clear the check box next to any portlet that you do not want to generate, and click the Start button.
If multiple versions of an application exist, each version is listed.
Select the version you want to generate.
eGenerator creates a new portlet descriptor file and bundles it into a new WebClient_Portal.war file.
This section provides an overview of updating an FDA-created portlet after initial installation and discusses how to:
Add a new portlet application.
Delete an existing portlet application.
When you modify an existing FDA-created portlet in FDA, you need only regenerate the JD Edwards EnterpriseOne application to promote the application to the Collaborative Portal. However, if you are removing existing portlets or are adding new FDA-created portlets to Collaborative Portal, you must use eGenerator to update the portlet descriptor, portlet.xml, in the WebClient_Portal.war.
To add a new FDA-created portlet:
Launch eGenerator and select Generate, Portlet Deployment.
Select the .war file to update.
Select the same war file that you deployed previously.
Clear the check box next to any portlets that you do not want to generate, and click the Start button.
You should always select all portlets you want to be deployed to Collaborative Portal because after installation, the new WebClient_Portal.war replaces any previous version that exists on Collaborative Portal server.
eGenerator modifies the portlet descriptor file, portlet.xml, in the .war file.