Portal, Express Beta Version 6.1
Operating systems: i5/OS, Linux,Windows
|
Portal, Express Beta Version 6.1
Operating systems: i5/OS, Linux,Windows |
Before you make portlets or portlet applications available to your users by putting them on portal pages, you need to prepare them. This topic gives an overview of tasks that you might perform to prepare the portlets and portlet applications. This includes installing, deploying, and configuring portlets and applications.
You can further work with portlets by using the administration portlets that are available under the portal . Refer to the portlet helps for details. After you have completed preparing your portlets, you can make them available for your users.
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 Portlet Manager Application, which contains Manage Web Modules, Manage Applications, and Manage Portlets. For additional information on working with WAR files, see the information center for WebSphere Application Server.
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 desired 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.
This section has the following topics:
IBM® WebSphere® Portal Express includes Manage Web Modules 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.
Note: As Windows limits the maximum path length to 260 characters, the name of the WAR file must be 25 characters or less. Installing a WAR file with a name that is more than 25 characters will result in an error.
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 desired users and groups so that these can access and use that portlet.
Note: 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.
By default, portlet applications and portlets 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 or portlet is in the active state, portal users with appropriate access 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 Express 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.
You can toggle portlet application or portlet states to active or inactive by using the portal XML configuration interface. For details about how to do this refer to Working with the XML configuration interface and Reference: Sample XML configuration files. For more general information about how to work with the XML configuration interface refer to the XML configuration interface.
Many portlet applications and portlets have associated configuration parameters that must be changed after deployment. Manage Applications and Manage Portlets allow 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 of the portlet. WebSphere Portal Express does not validate configuration modification to portlet applications.
For more information about the configuration of portlets and applications refer to the following sources:
A
portlet is initially displayed in the View mode. A user can apply customizations
to individual, selected, or all instances of the portlet by leaving the View
mode and entering into the Personalize, Edit Shared Settings, or Configure
mode as appropriate. To access these other modes, hover over the portlet
title bar, click 
to display the portlet menu, and select the appropriate
mode. Refer to the descriptions below for more information about the Personalize,
Edit Shared Settings, and Configure modes.
It depends on the portlet which selection options are available in the portlet menu.
For more information about portlet modes refer to Configuration levels for portlets.
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, you should 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. An example of portlet data is the portlet configuration parameters needed for a particular instance of a portlet An example of a portlet resource is an image that the portlet displays in the user interface. While the portlet configuration parameter is associated with each instance of the portlet, all instances of the portlet use the same image.
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.
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.
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. An example of portlet data is the portlet configuration parameters needed for a particular instance of a portlet An example of a portlet resource is an image that the portlet displays in the user interface. While the portlet configuration parameter is associated with each instance of the portlet, all instances of the portlet use the same image.
Update a portlet application by updating the WAR file in Manage 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 Express 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 the portlet deployment descriptor is controlled by the setting of update.portlet.preserves.config.settings in the Deployment Service. 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=false
By default, this setting is true, preventing configuration parameters in the updated portlet deployment descriptor from updating existing parameters. For more information about settings in the deployment service refer to Portal configuration services.
Web modules can be deleted or uninstalled in Manage Web Modules and portlet applications can be deleted using Manage Applications. Portlets can be deleted using Manage Portlets. After selecting an object for deletion, the system waits until all outstanding requests for the portlet application or 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 by updating the WAR file in Manage Web Modules. You can reinstall the deleted portlet after ensuring all portlet applications installed in the portlet WAR file have been removed and that the WAR file has been uninstalled.
Note: Do not delete any Administration portlets.
WebSphere Portal Express supports the Web Services for Remote Portlets (WSRP) standard. Producers can provide portlets as WSRP services for Consumers who integrate and use them. For more information about WSRP refer to Using WSRP services.
