The Plumtree database stores a range of settings. These settings can be used by portlets and Web services to provide personalized functionality and seamless access to back-end systems. Portlets use six types of settings to personalize content. Other Web services use a smaller collection of settings. Each type of setting is intended for a specific range of use, and each is treated differently by the Portal Server. Differences between the types of settings might seem insignificant, but the implications on functionality are integral to the successful implementation of your Web services.
SETTING TYPE |
APPLIES TO: |
||
User |
Portlet |
Web Services | |
Administrative Setting |
All |
1 specific |
1 specific |
User Setting |
1 specific |
All |
All |
Portlet Setting |
1 specific |
1 specific |
N/A |
CommunityPortlet Setting |
All in a specific Community |
1 specific |
N/A |
Community Setting |
All in a specific Community |
All in a specific Community |
N/A |
User Information Setting |
1 specific |
All |
All |
Each type of setting is described in detail in the sections below. For details on additional settings used by the portal, see the next page, Portal Settings (Headers). For details on using settings in portlets, see Portlet Settings and Preferences.
Administrative settings apply to one particular object for all users in all instances of the object. Every instance of a specific object will have the same Administrative settings. Administrative settings are never shared between different services.
Administrative settings should be used for any configuration information that applies in all implementations of an object. Administrative settings can be modified only by users with administrative access to the portal and read/write access to the object.
Administrative settings can be set from a Service Configuration page, an Administrative Preferences page (Portlets only) or Portlet Template Preferences page (Portlets only).
TYPICAL USE
Configuring back-end connection settings for a service (for example, to a database or application)
Setting limits for all users (for example, maximum file size for e-mail attachments)
WARNINGS
Only users with administrative permissions in the portal and read/write access to the object can set Administrative settings.
Administrative settings apply to all users in all instances of a object.
Administrative setting cannot be shared between services.
EXAMPLES
Specifying the ODBC string used by the service to connect to the appropriate database
Configuring LDAP authentication information for a Profile Source
Determining the maximum number of links shown for all users who view a MyLinks Portlet
Building portlet frameworks that use the same set of scripting files
User settings apply to one particular user, but can be accessible to all portlets, crawlers and search services in a user’s portal. Every portlet on a specific user’s My Pages has access to the same User settings. For this reason, User settings must be uniquely named (see the first item under Warnings for User settings below).
Note: Services must be configured to use these shared settings (see the second item under Warnings for User settings below).
Most enterprise-level applications require several services to capture different areas of functionality. User settings are indispensable for sharing login information among multiple services. Each user enters the appropriate settings once, and all services have access to the same settings. This allows associated services to authenticate with the back-end application without multiple entries by the user.
User settings can be set by a user from a User Configuration page or via a portlet’s User Preferences page.
TYPICAL USE
Storing user-specific information that is shared among services that access the same application (for example, the username and password)
WARNINGS
User settings must be given names that are unique among all services; a wide range of services leverage User settings, and the names of these settings must be different or name collisions will result.
Shared User settings must be specified by name on the Preferences page of the associated Web Service editor or they will not be sent to the service.
User settings that must be secure should be encrypted because they can be shared among different servers (for example, encrypt the password, but not the username).
EXAMPLES
Specifying the personal username and password for the Inbox, Calendar, and Contacts portlets in the Plumtree Portlet Suites for Exchange or Lotus Notes, or the login information used by the Documentum portlets and search services
Refreshing content in all portlets in the Siebel Portlet Suite based on user entry in one portlet from the suite (a change in settings causes the portlet display to refresh)
Portlet settings apply to one particular user and one particular Portlet object. Every user with the same portlet displayed on a My Page has unique Portlet settings. Portlet settings are never shared between different portlets and are never used by any other type of service. Portlet settings should be used for user-specific information that is not relevant to any other portlet.
Portlet settings can only be set from a Portlet Preferences page.
TYPICAL USE
Personalizing the portlet display (per user)
WARNINGS
Use Portlet settings efficiently. If everyone in a large deployment has access to a Portlet object, Portlet settings can require a large amount of database storage space. If the information used by a portlet does not need to be persistent, consider using the Session or Application object on the remote server instead of storing settings in the Plumtree database.
Portlet settings are the same for a specific Portlet object on all pages in a single Community or single user’s My Pages. To allow different Portlet settings on different pages in the same Community or one user’s portal, you must use the PageID or register the portlet multiple times.
EXAMPLES
Setting how many items to display in a list (for example, tasks or e-mail messages)
Selecting which specific items to display in a personal list (for example, the MyPublications portlet)
CommunityPortlet settings apply to one particular Portlet object in one particular Community, for all Community users. CommunityPortlet settings are the same for all users who have access to the Community. CommunityPortlet settings are only relevant when a portlet is displayed in a Community, and they can be set only by a Community owner. These settings are not available to portlets displayed on a My Page.
CommunityPortlet settings are similar to Administrative settings in that they are set by one user (Community owner) and viewed by all users of the Portlet object. The key difference is that CommunityPortlet settings are distinct for each Community in which the Portlet object appears.
CommunityPortlet settings can be modified from the Community page but are accessible only to Community owners.
TYPICAL USE
Modifying the content displayed in a Community portlet
Specifying the connection or source of information for a Community portlet
WARNINGS
CommunityPortlet settings can only be changed only by a Community owner.
CommunityPortlet settings are applicable only when a portlet is displayed in a Community.
CommunityPortlet settings apply to all users who have access to the Community and to all implementations of the Portlet object within that Community. To allow different CommunityPortlet settings on different pages of the same Community, you must use the PageID or register the portlet multiple times.
EXAMPLES
Editing display parameters in a Community portlet (for example, a calendar or discussion)
Choosing the Excel file from which to pull data for a Community portlet (for example, a sales report or product schedule)
Community settings apply to all users in one particular Community and are accessible to all Portlet objects in that Community. Community settings are only relevant when a portlet is displayed in a Community and can be set only by a Community owner. These settings are not available to portlets displayed on a My Page.
Note: As with User settings, a Portlet object must be configured to use shared Community settings (see the first item under Warnings for Community settings below).
Community settings are similar to Administrative settings in that they are set by one user (Community owner) and viewed by all users of the Portlet object. However, Community settings are also similar to User settings because they can be shared between different Portlet objects. Community settings only apply within a specific Community; they are distinct for each Community in which the Portlet object appears.
Community settings can be modified from the Community page but are only accessible to Community owners.
TYPICAL USE
Storing Community-specific information that is shared among multiple portlets
WARNINGS
Shared Community settings MUST be specified by name on the Preferences page of the Portlet editor, or they will not be sent to the portlet.
Community settings can be changed only by a Community owner.
Community settings are applicable only when a portlet is displayed in a Community.
Community settings apply to all users who have access to the Community and all implementations of the Portlet object within that specific Community, and are accessible to all portlets in the Community. Every page in a Community shares the same Community settings. To allow different Community settings on different pages in the same Community, you must use the PageID or register the portlet multiple times.
EXAMPLES
Specifying the ODBC string for a set of Community portlets (for example, to a particular bug or product database used by several portlets in the Community)
Setting the Exchange login and password for the Community Calendar and Contacts portlets
User Information allows administrators to pass properties about a user (such as e-mail address, employee ID, or department) from centralized repositories like LDAP, SSO, or company databases to Plumtree services. User Information can be imported using a profile service (Profile Source), and can be used by any service with the necessary access privileges.
The settings selected in the User Information screen in the Web Service editor will be sent to the service if they are available to the Portal Server (PS). In the Web Service editor, you can select standard User Information or configure additional User Information properties to be sent to the service.
TYPICAL USE
Using user-specific information that is stored in an external repository
WARNINGS
You must select the User Information properties to be sent to the Web service in the Web Service editor or they will not be sent to the service.
The Portal Server must have access to the external repository.
EXAMPLES
Specifying the personal username and password for internal applications
For details on additional settings used by the portal, see the next page, Portal Settings (Headers).
Next: Portal Settings (Headers).