Virtual portals reference

1. Configuration tasks for administering virtual portals
   • create-virtual-portal
   • list-all-virtual-portals
   • modify-virtual-portal
   • delete-virtual-portal
2. Administer multiple virtual portals by a single configuration task
3. Information overview for configuring user populations for virtual portals
4. Hints and tips
5. Known limitations

Configuration tasks for administering virtual portals

The following sections lists and describes the configuration tasks for administering virtual portals. Before you use these configuration tasks to administer virtual portals, read the topics...

• Plan for virtual portals
• Administer virtual portals

The tasks described here take the listed inputs as they must be specified in the property file wkplc.properties.

The property file must be encoded in the ISO 8859-1 character encoding format.

create-virtual-portal

Create a virtual portal.

Invoked as part of the ConfigEngine script file as follows:

./ConfigEngine.sh create-virtual-portal -DPortalAdminPwd=foo -DWasPassword=foo

The following inputs apply:

VirtualPortalTitle	The title of the virtual portal. This input is mandatory.
VirtualPortalRealm	The realm of the virtual portal. This input is mandatory if you have realms enabled in the portal installation. If you do not have realms enabled, do not specify a value for the realm.
VirtualPortalHostName	The host name of the virtual portal. If you specify the host name, the portal sets the host name, and the portal parameter context is ignored. You cannot use the same virtual portal host name twice in the same portal installation. After you have created the virtual portal, you cannot change the host name that you have specified for the virtual portal. If you need to use a different host name for a virtual portal, refer to the information about Use a new host name for an existing virtual portal.
VirtualPortalContext	The portal context of the virtual portal. This input is mandatory. The context must be unique. If you set the host name parameter above, the portal context is ignored.
VirtualPortalNlsFile	The national language support (NLS) file for the virtual portal. This input is optional. You input the path and file name of national language support file. You can create own national language support file to specify additional titles and descriptions in other languages for virtual portal. For more details about the format of this file refer to Command reference for the Portal Scripting Interface under Property file format. If you do not specify an NLS file, the virtual portal is created with the title that you give as the value to the VirtualPortalTitle parameter only, but without titles in other languages and without descriptions. For a list of the languages that are available with WebSphere Portal and their language codes refer to Language support. If you specify no NLS file, the value that you specify by the VirtualPortalTitle input parameter will show to users as the title of the virtual portal in all language environments, independent of the system and browser locale and the user preferences. If you specify an NLS file, the value given for the virtual portal title in that NLS file overrides the title that you specify by the VirtualPortalTitle input parameter. If you specify an NLS file, do not use prefixes in that NLS file.

Assumptions/Prerequisites:

• WebSphere Portal is running.
• Error Conditions: None
• Task dependencies: None
• Tasks invoked: None

You pass the parameters listed above for the virtual portal to the configuration task.

To pass a description for the virtual portal to the configuration task, you have to specify this in the NLS file.

The task creates the virtual portal itself, but it does not create any default content for the virtual portal or grant any access permissions to the virtual portal administrators. You need to perform these tasks separately after creating the virtual portal, for example by using the XML configuration interface. For details about the access permissions required for virtual portal administrators refer to sub-administrators of a virtual portal and their access roles and rights. For details about how to use the XML configuration interface refer to xmlaccess.sh.

list-all-virtual-portals

List all virtual portals.

Invoked as part of the ConfigEngine script file as follows:

./ConfigEngine.sh list-all-virtual-portals -DPortalAdminPwd=foo -DWasPassword=foo

Inputs: None

Outputs: This tasks lists all virtual portals, together with the following information:

• The title of the virtual portal
• The description of the virtual portal
• The realm of the virtual portal
• The object ID of the virtual portal.

Assumptions/Prerequisites:

• WebSphere Portal is running.
• Error Conditions: None
• Task dependencies: None
• Tasks invoked: None

The context of a virtual portal as specified by using the configuration task create-virtual-portal with the input parameter VirtualPortalContext cannot be shown by using the configuration task list-all-virtual-portals.

modify-virtual-portal

Modify a virtual portal by using its object ID. To determine the correct object ID of the virtual portal, use the task list-all-virtual-portals .

Invoked as part of the ConfigEngine script file as follows:

./ConfigEngine.sh modify-virtual-portal -DPortalAdminPwd=foo -DWasPassword=foo

The following inputs apply:

VirtualPortalObjectId	The object ID of the virtual portal. This input is mandatory for identification of the virtual portal that you want to modify.
VirtualPortalRealm	The realm of the virtual portal. You can only specify a realm if you have realms enabled in the portal installation.
VirtualPortalNlsFile	The National Language Support file of the virtual portal. You input the path and file name of national language support file. You can create own national language support file to specify additional titles and descriptions in other languages for virtual portal. For more details about the format of this file refer to Command reference for Portal Scripting Interface under Property file format. If you specify an NLS file, do not use prefixes in that NLS file.

Assumptions/Prerequisites:

• WebSphere Portal is running.
• Error Conditions: None
• Task dependencies: None
• Tasks invoked: None

To modify the title or description of the virtual portal, you have to specify this in the NLS file accordingly.

delete-virtual-portal

Delete a virtual portal by using its object ID. To determine the correct object ID of the virtual portal, use the task list-all-virtual-portals .

Invoked as part of the ConfigEngine script file as follows:

./ConfigEngine.sh delete-virtual-portal -DWasPassword=foo

Inputs: VirtualPortalObjectId

The object ID of the virtual portal. This input is mandatory.

Assumptions/Prerequisites:

• WebSphere Portal is running.
• Error Conditions: None
• Task dependencies: None
• Tasks invoked: None

Administer multiple virtual portals by a single configuration task

You can administer multiple virtual portals by running a single configuration command. The following configuration tasks support working with virtual portals: create-virtual-portal, delete-virtual-portal, and modify-virtual-portal. You specify the virtual portal property sets in the file wkplc.properties used with the configuration tasks. When you run the configuration task, you pass the list of virtual portals by using the parameter -DvirtualPortalList.

Here is an example for creating two virtual portals:

1. Specify the two virtual portal property sets in the file wkplc.properties as follows:

   vp1.VirtualPortalTitle=vp1
   vp1.VirtualPortalRealm=vp1realm
   vp1.VirtualPortalHostName=vp1host
   vp1.VirtualPortalContext=vp1
   vp1.VirtualPortalNlsFile=
      
   vp2.VirtualPortalTitle=vp2
   vp2.VirtualPortalRealm=vp2realm
   vp2.VirtualPortalHostName=vp2host
   vp2.VirtualPortalContext=vp2
   vp2.VirtualPortalNlsFile=
   

2. To create both virtual portals by using a single configuration command, use the parameter -DvirtualPortalList to specify the two portals vp1 and vp2:
   ConfigEngine create-virtual-portal -DvirtualPortalList=vp1,vp2

Information overview for configuring user populations for virtual portals

This section gives an overview of the information that is available in the WebSphere Portal information center about configuring user populations, realms, and user registries for virtual portals. The following links move from the general to the detailed and specific.

Hints and tips

The following hints and tips apply to virtual portals in WebSphere Portal v7.0:

• Do not grant the subadministrators of virtual portals the access permissions to perform any installation related tasks, such as installation of portlets or themes. The isolation between the different virtual portals as provided by WebSphere Portal v7.0 is limited to some extent. All virtual portals share a common Java Virtual Machine (JVM). Therefore it is important to restrict the administration privileges of the virtual portal subadministrators and prevent them from installing their own code artefacts, such as themes or portlets. Unstable or malicious code that is introduced on one virtual portal can destabilize the entire portal installation and thereby all other virtual portals. A flexible way to introduce virtual portal specific portlets without impacting any other virtual portals is to use Web Services for Remote Portlets (WSRP). For more information about WSRP refer to Use WSRP services.

• Not all resources can be scoped to individual virtual portals. For example, all themes and skins are available to all virtual portals without restrictions. Credential vault, portlet services, and portal services are also common for an entire portal installation. They cannot be scoped to an individual virtual portal.

• The settings which are defined in the portal property files apply for the entire portal installation. You cannot specify separate settings for individual virtual portals.

• To make use of the single signon feature that is provided by WAS, you have to use the same common domain suffix for all virtual portals.

• Portal search, personalization, and templates, are not aware of virtual portals.

• There are no virtual portal specific enhancements to the published portal commands and application programming interfaces.

• A URL mapping that is defined for a resource in a particular virtual portal must use the same URL context as the human readable URL context for that virtual portal itself. Example: In a virtual portal that uses the human readable URL mapping wps/portal/vp_1, all URL mappings for portal resources must start with wps/portal/vp_1, for example wps/portal/vp_1/url_1 and wps/portal/vp_1/url_2. Within this virtual portal a URL mapping such as wps/portal/url_1 is not valid, as the portion vp_1 of the URL Context is missing.

• The administration portlet Virtual Portal Manager cannot delete all resources that are associated with a virtual portal. For example, it does not delete additional URL mappings that administrators might have created for the virtual portal. You can use the XML configuration interface to do this.

• All virtual portals on a portal installation share a common logging and tracing.

• When you re-initialize a virtual portal by using the Virtual Portal Manager portlet, this applies the XML script for the default virtual portal content (or custom script) again and re-creates the default content of the virtual portal. Resources that you removed from the default content are re-created. Resources that you added to the default content remain in the virtual portal.

• You have to run the wp-create-realm task to create realms for Virtual Portal. See the Adding realm support file for OS.

• The context of a virtual portal as specified by the configuration task create-virtual-portal and the input parameter VirtualPortalContext cannot be shown by using the configuration task list-all-virtual-portals.

• The Portal Access Control administration in the Resource Permissions portlet shows users from different realms who have role mappings on shared resources by their object IDs. Therefore, apply special care and consideration when deleting such portal resources: Do not delete resources on which users from other realms have role mappings, if they are required in other virtual portals. This applies to members of roles on portal resources that cannot be scoped and are therefore shared between the virtual portals. Role members who belong to the realm of local virtual portal are displayed as usual, but role members who belong to different realms are displayed in a different manner:

  • Role members for shared resources who belong to the realm of the virtual portal under which you are currently working are listed by their actual names under which they were created.

  • Role members for shared resources that do not belong to the realm of the current portal are listed by their portal object IDs. For example, a role member from a different realm might be represented as 8_0_B.

• You find the list of role members under Administration > Access > Resource Permissions > Select Resource Type > Assign Access for a resource > Edit Role, under the first column Members in the Role.

• You cannot create custom URLs in one virtual portal that address portal resource in another virtual portal. The reason is that both object IDs and unique names relate to resources of the local virtual portal. For details about how to create URLs refer to Create custom links to portlets and pages.

Known limitations

The following sections describe known limitations with virtual portals.

Change of theme for virtual portal might not take effect

If you change the theme for a virtual portal by editing the virtual portal in the Virtual Portals portlet, the following problems might occur:

1. The selected theme might not show the next time you go into the Edit mode for the virtual portal.

2. The selected theme might not be applied to the virtual portal, and the virtual portal might still be displayed with the original theme.

Use a new host name for an existing virtual portal

To use a new host name for an existing virtual portal...

1. Export the contents of the virtual portal by using the XML configuration interface.

2. Delete the virtual portal.

3. Clean up references to the deleted virtual portal by using the Task.xml of the XML configuration interface..

4. Create a new empty virtual portal by using the configuration task create-virtual-portal. Use the context of the deleted virtual portal, and specify the new host name as required.

5. Import the contents to the new virtual portal by using the XML configuration interface.

Portal supports up to 150 virtual portals

A single portal installation can support up to 150 virtual portals.

Create the portal site search collection fails

Problem: If the file path length for the location of search collections exceeds its limit, the collection cannot be created. This can occur particularly when the portal site collection is created under UNIX OSs.

Cause: The file path length for the portal search collection is limited to 118 characters. If this limit is exceeded, the default collection cannot be created. The following items contribute to the length of the file path:

• The installation directory path. Under UNIX OSs the installation directory path name can be longer than under other OSs.
• By default, the search collection for the portal site content is created under the path your_portal_install_directory/PortalServer/collections.
• The name of the virtual portal.
• The name of the search collection.

Solution: Proceed as follows:

1. Change the default directory location for the portal site search collection to a shorter path, so that the complete path and file name does not exceed a length of 118 characters. For details about how to do this refer to Configure the default location for search collections.

2. Recreate the portal site search collection. For details about how to do this refer to Create or resetting the portal site collection.

 Some categories for the theme's customize feature may be empty in virtual portals. 

Problem:  You may see "no results" for the Administration category of portlets or other categories. Cause: The Page Builder theme and Portal 7.0.0.2 Theme use tags to create these categories but these tags are not automatically added to virtual portals. Solution: Proceed as follows:

You can add these tags to virtual portal by running one of these tasks. If you have a Portal Enable or Portal Extend run this task.

ConfigEngine page-builder-tag-portlet-definitions-content -DPortalAdminPwd=foo -DWasPassword=foo -DXMLAccessUrl=http://localhost:10039/wps/config/vp1

If you have Portal Server run this task:

ConfigEngine page-builder-tag-portlet-definitions-server -DPortalAdminPwd=foo -DWasPassword=foo -DXMLAccessUrl=http://localhost:10039/wps/config/vp1

These task may fail if installation is missing certain portlets that the scripts expect to find. In this case you will need to use PortalServer/theme/wp.mashup.cc.theme/config/templates/TagPortletDefinitionsServer.xml as an example xml access script that you can use and adapt to own installation environment.  

Parent: Multiple virtual portals

Related
Usage scenarios for virtual portals
Plan for virtual portals
Language support
xmlaccess.sh
Use WSRP services

Related tasks
Set up a virtual portal in a portal farm
Configure the default location for search collections
Create or resetting the portal site collection

Related reference
Command reference for Portal Scripting Interface

Related information
Administer virtual portals
Create custom links to portlets and pages

+

Search Tips   |   Advanced Search