Reference: Portal administration portlets
This section provides you with information on installing and administering portlet applications and portlets supplied with WebSphere Portal.
- Introduction: Web modules, portlet applications, and portlets
- Overview of administration portlets
- Install portlets
- Manage portlet applications
- Manage portlets
Introduction: Web modules, portlet applications, and portlets
A Web module represents a Web application. It is used to assemble servlets and JSP files as well as static content, such as HTML pages, into a single deployable unit. Web modules are stored in Web ARchive (WAR) files, which are standard Java archive files. The standard file extension for WAR files is .war. A Web module can contain one or more portlet applications, servlets, JavaServer Pages (JSP) files, and other files. A deployment descriptor, stored in an Extensible Markup Language (XML) file, declares the contents of the modules, information about the structure and external dependencies, and a description of how the components are to be used at run-time.
Portlet applications are created implicitly when a WAR file is deployed. The portlet application holds one or more related portlets that come packaged in the same installation file. These portlets can share resources and send messages among themselves to communicate events. A portlet application may consist of a single portlet or multiple portlets. An example of a single portlet application is the WorldClock portlet application, which contains a single portlet named World Clock Portlet. An example of a portlet application with multiple portlets is EIP, which contains EIP Federated Search and EIP Advanced Search.
You can add portlets to a running system at any time. After installation, the new portlets are immediately available to administrative users. They can assign the appropriate user roles to the required groups and users so that these can access and use the portlets. Once available, the portlets can be selected for display on the portal pages of users and can be edited as appropriate. Identification information of WAR files is stored in a database for easy deployment in complex server environments with multiple portal servers. By allowing all files associated with a portlet to be packed into a single file, distribution and deployment of new portlets is made easier. Portlets can be distributed in WAR file format through Web sites and other means.
Overview of administration portlets
WebSphere Portal has additional administration portlets that assist in managing portal resources. The following list of the administration portlets includes an overview of the tasks you can perform with each portlet as well as hints to additional resources.
In the portal the portlets are arranged under Administration in five groups as follows:
- Portal User Interface
- Portlets
- Access
- Portal Settings
- Global Settings
- URL Mapping
- Custom Unique Names
- Supported Markups
- Supported Clients
- Search Administration
- Portal Analysis
Several administrative portlets have a new table feature, which is used to list the available portal resources pertaining to the selected portlet. The layout of the table may vary, depending on the portlet. You can customize the table by clicking the configure icon in the portlet title bar. In configure mode, you can alter the total number of items that appear on the table and the number of rows that appear on each page of the table. Some portlets allow you to add optional columns to the table.
The search feature allows you to search available resources within that portlet. To limit the search, you may click the plus sign above the text field to display a drop down menu of other search options. These options include title contains, description contains, markup contains, last modified, unique name, and all available.
Wild characters are not supported in this search feature, including the asterisk (*).
Portal User Interface
Manage Pages
The Manage Pages portlet allows you to create, edit, activate, order, and delete pages as well as external Web pages and labels. Available tasks depend on which item is selected. Each page can contain multiple pages.
Themes and Skins
The Themes and Skins portlet allows you to install, edit, and delete themes as well as install and edit skins. You can also select a default theme and skin using this portlet.
Portlets
Install
The Install portlet allows you to install a portlet. During this process, a Web ARchive (WAR) file is uploaded to the server and the portlet is installed, added to the portlet catalog, and activated.
Manage Portlet Applications
The Manage Applications portlet allows you to manage Web modules and portlet applications. A Web module is a war file containing portlet applications.
Manage Portlets
The Manage Portlets portlet allows you to activate, deactivate, rename, copy, and delete portlets and modify portlet parameters.
Web clipping
The Web Clipping Editor allows you to identify and extract specific portions of a document for display in a portlet. You can choose to display an entire document by referencing a URL or tag only a key section.
Access
Users and Groups
The Users and Groups portlet allows you to search for, edit, and delete existing users and groups. You can also create new users and groups and modify group membership.
Resource Permissions
Resource Permissions allows you to set portal access roles. You can assign access roles to associate users and groups with resources to determine the level of interaction a user can have with a resource.
User and Group Permissions
The User and Groups Permissions portlet allows you to assign roles to users and groups.
Credential Vault
Credential Vault allows you to perform tasks specific to vault management. You can add or manage vault segments and vault slots.
Portal Settings
Global Settings
Use the Global Settings portlet to define what the user sees in the portal, including the default language and the Find link. The default language specified in Global Settings applies to all users when the language preference specified in their browser is not supported by WebSphere Portal. For example, if WebSphere Portal supports English, German, and Spanish, with English as the default language in Global Settings, a user whose browser language preference is set to Italian would see English because Italian is not supported in this case. A user can also select a preferred language when registering with WebSphere Portal.
Global Settings also determines what users see when returning to the portal on subsequent visits. For example, you can choose to display the most recently visited page rather than a default page. You can allow users themselves to choose what they see when logging on to the portal, or if they see the default page or the most recently visited page. You can also determine a URL for the Find link.
URL Mapping
The URL Mapping portlet allows you to create user friendly URLs and map them to portal pages. You can define human readable names for them. These can be easily remembered and are therefore more user friendly. The self defined URLs can be published externally and thereby made available to portal users.
Custom Unique Names
The portal uses object IDs to identify portal resources unambiguously even between different portals. They consist of an extended alphanumeric string that may be difficult to remember. The Custom Unique Names portlet enables you to assign unique names, or human readable names, to portal resources. You can select names for them that are easy to remember. These custom unique names are easier to handle than the object IDs assigned by the portal. They make identification of portal resources easier, for example when porting resources from one portal to another.
Supported Markups
The Supported Markups portlet allows you to determine which markups the portal recognizes. You can add, edit, activate or deactivate, and delete a markup. The installation default is HTML.
Note: Removing or changing the HTML markup will cause portal access problems. The XML configuration interface must be used to recover from this error.
Supported Clients
With Supported Clients you can determine what types of devices can access the portal. You can add, edit, order, or delete clients. To test a portlet with a device simulator you may need to add the user agent string of the device simulator to the WebSphere Portal client list. Consult the documentation included with the device simulator to determine the user agent strings the simulator supports and add these using the Supported Clients administration portlet.
Search Administration
WebSphere Portal has three portlets related to Search, two administrative portlets for administering search facilities, and one user search portlet. Searchable resources include various document types, for example HTML and text documents.
Portal Analysis
Frequent Users
The Frequent Users portlet shows how many users are currently logged in.
Enable Tracing
The Enable Tracing portlet allows you to enable or disable the tracing logs.
Other portlets
WebSphere Portal also provides a variety of productivity portlets for users to access and customize to suit their needs. For information on portlets provided with WebSphere Portal refer to Working with portlets.
Portlet templatesare also packaged with WebSphere Portal. These are predefined portlets that enable you to easily create your own portlets.
Install portlets
WebSphere Portal includes Install Portlets on the portal page of Portal Administration for easy installation of portlets and portlet applications. An administrator must have the Manager role on the portal to install portlets. If the Manager role on the portal exists, the administrator selects a WAR file that is made available to the running system after installation. Each WAR file includes descriptive information about the portlet, which is placed in a database that can be queried by other portal components. During installation, Application Server unpacks the WAR file and places the portlet classes and resources in a file system.
During the installation, the portlet state is set to active, and a new rule is automatically added to Access Control that defines the user who installed the portlet as the owner, granting management access for that portlet. The user must assign the appropriate user roles to the required users and groups so that these can access and use that portlet.
You cannot install a portlet more than once. If you want two instances of a portlet application or portlet, use the copy command to create a second instance.
Choosing a JDBC JNDI name that corresponds to a JDBC resource reference: When you install regular Web applications, you can code one WAR file for many environments by using a JDBC resource reference. You need a separate WAR file for each environment if the JDBC names are not the same. The reason is that portal does not provide a screen for selecting which JNDI name to use when you later install the Web application.
Web Services
In addition to installing from a local file system, you can also install portlets published on a remote server. Use the installation option on the Web Services portlet to install remote portlets. Remote server installation enables you to search a UDDI (Universal Discovery, Description and Integration) registry for portlets that other enterprises have published. Rather than requiring the portlet to reside on the local server, WebSphere Portal allows you to create a bind with a remote portlet selected from a registry. Users can install, edit, and interact with the portlet as if it was on the local server, but the portlet actually resides on the remote server. Web Services automatically creates a new credential vault entry for every UDDI registry that is added.
However, communication with remote portlets does not support more than 69KB for the return markup, so any messages larger than that are not returned. Portlet updates or changes at the remote site are implemented on all portals running that portlet.
Portlets that use the credential vault service or portlet messaging should not be published as a remote Web service.
WebSphere Portal includes portlets that allow you to work with Web Services. With Manage Web Services, you can create and manage UDDI registries. Manage Web Services help contains instructions on setting up and managing registries. The Web Services portlet allows you to authenticate with registries, manage businesses, publish and unpublish portlets, and integrate a Web Service as a remote portlet. Steps for publishing your portlets as Web services are in Web Services help.
Manage portlet applications
The Manage Applications portlet in Portal Administration gives you complete control over portlet applications. Manage Applications displays a list of all Web modules and associated portlet applications installed on the portal. You can view and change portlet application settings from this portlet. Tasks include activating and deactivating, renaming, modifying configuration parameters, and deleting portlet applications.
Activating and deactivating portlet applications
By default, portlet applications are set to an active state after installation. Pages also have an active and inactive state. You can deactivate a resource to prevent users from accessing it without changing their user roles. When a portlet application is in the active state, portal users with a user role to use this portlet can include it on their personal pages and customize it. You can toggle portlet application states to active or inactive from Manage Applications.
Copying portlet applications
With Manage Portlet Application, you can copy a portlet application. The copy should be given a new name. A copy of a portlet application includes some or all of the portlets from the original portlet application. If you want additional instances of a portlet application, make a copy.
When a portlet application is copied, the portlet data and the portlet application data are copied, but the copied portlet application uses the same resources as the original portlet application. When a copied portlet application is copied, the new portlet application also uses the same resources as the original portlet application. However, only portlets in the copied portlet application will be in the new portlet application. For instance, if the copied portlet application contains four portlets and the original contains five portlets, only the four portlets are copied to the new portlet application.
Copying can be useful when different portlet configuration parameters are required for different instances of a portlet. A copy of the portlet application can be used to configure the portlet instance for each portlet application. For example, the administrator might want to have multiple RSS portlet applications. Each copied application would have a different URL, accessing a different content channel, configured for its RSSPortlet.
Update portlet applications
Manage Applications can also update Web modules. The newer version of the resource in the WAR file updates the existing portlet application, without breaking the links between user data and the resource. User-specific settings for portlets within the updated resource remain unchanged.
Before a selected Web module is updated, WebSphere Portal checks for an identical resource name in the selected WAR file. If the name of the selected object and the object name in the deployment descriptor of the WAR file do not match, the update is not performed, and a message is displayed.
When a Web module is updated, WebSphere Application Server removes the existing files and installs the updated application in the same directory. Updating the configuration parameters from portlet.xml is controlled by the setting of update.portlet.preserves.config.settings in DeploymentService.properties. New parameters that are introduced by the updated Web module are always added to the Web module. However, changed parameters are updated only if the following value is set:
update.portlet.preserves.config.settings=falseBy default, this setting is true, preventing configuration parameters in the updated portlet.xml from updating existing parameters.
Configure portlet applications
Many portlet applications have associated configuration parameters that must be changed after deployment. Manage Applications allows you to modify configuration parameters. The original configuration is determined by settings in the portlet.xml deployment descriptor file. Configuration changes apply to each specific instance. WebSphere Portal does not validate configuration modification to portlet applications. Writing portlets contains additional information on portlet configuration.
Deleting or uninstalling portlet applications
Web modules and portlet applications can also be uninstalled or deleted from WebSphere Portal using the Manage Applications portlet. After selecting an object for deletion, the system waits until all outstanding requests for the portlet have been completed and then removes all related files and resources from the portal server. Before removing a portlet application, first delete all of its copied portlet applications. If you have the portlet WAR file, you may reinstall the portlet components after deleting it from the system.
Manage portlets
Manage Portlets gives you complete control over portlets. Manage Portlets displays a list of all portlets installed on the portal. Manage Portlets allows you to view and change portlet settings, including activating and deactivating, renaming, modifying configuration parameters, and deleting.
Activating and deactivating portlets
By default, new portlets are set to an active state. Pages also have an active and inactive state. You can deactivate a resource to prevent users from accessing it without changing their user roles. When a portlet is in the active state, portal users with the appropriate user roles to use this portlet can include it on their personal pages and customize it. Users that have active references to those inactive portlets on a portal page will see a message stating that the portlet is temporarily disabled. If you begin working on a portlet, WebSphere Portal automatically changes the state to deactivated. After completing work on the resource, remember to activate it so that others with appropriate permissions can use it.
Copying portlets
With Manage Portlets, you can copy a portlet. You should give the copy a new name.
If a portlet is copied or a remote portlet is integrated, a new portlet application is created by the portal that holds the new portlet. The user must have an Administrator, Manager, or Editor role for public pages and an Administrator, or Privilege User role for private pages for both portlets and portlet applications.
When a portlet is copied, the portlet data is copied, but the copied portlet uses the same resources as the original portlet. When a copied portlet is copied, the new portlet also uses the same resources as the original portlet.
Configure portlets
Many portlets have associated configuration parameters that must be changed after deployment. Manage Portlets allows you to modify configuration parameters. The original configuration is determined by settings in the portlet.xml deployment descriptor file. Configuration changes apply to each specific instance. WebSphere Portal does not validate configuration modifications to portlets. Writing portlets contains additional information on portlet configuration.
Deleting portlets
You can also use the Manage Portlets portlet to delete portlets from WebSphere Portal. After you select an object for deletion, the portal waits until all outstanding requests for the portlet have been completed. The portal then removes all related files and resources from the portal installation. If you have the portlet WAR file, you can reinstall the portlet components after deleting it from the system. You do this by updating the portlet application. If you do not want to do it this way, be sure that all portlet applications installed in the portlet WAR file have been removed and that the WAR file has been uninstalled. Only after that you can reinstall the deleted portlet.
Do not delete any administrative portlets.