Use the Virtual Portal Manager administration portlet

After completing a regular portal installation, the portal is ready and enabled for implementing virtual portals. For improved manageability of virtual portals, WebSphere Portal provides a portlet for administering virtual portals. It is named Virtual Portal Manager. It enables the creation of extra virtual portals as we need. We can also use it to list, modify, or delete virtual portals in our portal.

Create a virtual portal

When creating a new virtual portal, we enter or select the following properties for the new virtual portal as required:

• The title for the new virtual portal. The title is later displayed in the list of virtual portals in the Virtual Portal Manager portlet. The title is not visible for users of the virtual portal. This field is limited to 255 characters.

• A description of the new virtual portal. Optional. This field is limited to 255 characters.

• Either a host name or a context for the virtual portal:

  • A human readable URL context used for accessing the virtual portal. We can set a URL that can be easily remembered and is therefore more easy to use than the actual full portal URL. The portal maps the friendly URL to the internal URL of the virtual portal. To do this mapping, it uses the portal URL Mapping feature. The string entered is used as the last part of the URL of the virtual portal and is appended to http://www.example.com/wps/portal/.

    • The URL context for each virtual portal must be unique.

    • All virtual portal URL contexts must be built from the root context for the portal server and must be unique. They cannot be subcontexts. For example, this URL is invalid:
      http://www.example.com/wps/portal/vp1/vp2

      The correct format:

      http://www.example.com/wps/portal/vp2

    • Use only ASCII characters for the URL Context of the virtual portal. Non-ASCII characters are not allowed for the URL Context. Examples: språk or Düne. Using non-ASCII characters results in an error message such as the following one:
      EJPAH2009E: Invalid characters were found in a context name or label

      Similarly, do not use escaped URL encoding either. For example, a URL Context of spr%E5k is not allowed.

  • A host name for the virtual portal. Optional. Use it to add a host name of the choice for the virtual portal. The portal uses that host name for the friendly URL of the virtual portal as follows: http://your_host_example:port/wps/portal. We can pass that friendly URL to the portal users for easier access to the portal.

    • This URL is used internally to access the virtual portal instance, even if specified a context URL that is easy to use. Make sure the host name specified here is accessible.

    • We cannot use the same virtual portal host name twice in the same portal installation.

    • After creating the virtual portal, we cannot change the host name specified for the virtual portal. If wee a different host name for a virtual portal, see the topic about Use a new host name for an existing virtual portal.

    • If we use web content libraries, do not specify a context URL for the new virtual portal that matches the name of a library on the server. If the name of a library and the URL context of a virtual portal have the same value, incorrect rendering of web content can result.

  • We must specify either a host name or a context.

  • If we specify both a host name and a context, the host name takes precedence and the context is ignored.

  • There are some strings we cannot use as URL mappings for virtual portals, for example vp. These strings are reserved names and correspond with URL codec names. For a list of these reserved strings, see Shaping the user experience.

  • Use only ASCII characters for the URL Context. For example, we cannot use a URL Context such as språk. If we use non-ASCII characters, the portal shows an error message such as the following EJPAH2009E: Invalid characters were found in a context name or label. Similarly, we cannot use escaped URL encoding either. For example, a URL Context such as spr%E5k.

• The Virtual Member Manager realm containing the user population of the virtual portal. This entry field is only shown if the portal installation supports realms. If we leave the realm field blank, the user population is the same as for the default realm. If we use a single common user repository for all virtual portals, for example the WAS LDAP custom user registry, this entry field is not shown.

• The initial subadministrator user group for the virtual portal. The portal gives this group administrator access rights on the Content Root node of the new virtual portal and all its child pages. This group must be within the realm specified for the virtual portal.

• The Default theme that is applied to the pages of the virtual portal. We select the default theme from a pull-down list. By the default configuration for virtual portals a subadministrator cannot change that default theme, unless we change the roles and access rights give to the subadministrator.

After we enter this information, we create the new virtual portal. With that information the portlet triggers a sequence of processes to establish the new virtual portal. These processes include:

• Create a new root content node for the virtual portal.

• Create the new URL mapping to point to the new root content node.

• Assign the selected theme to the new root content node.

• Granting the specified administrator group the action set for the Administrator role on the new root content node and on the new virtual portal.

• Calling xmlaccess.sh script to create the initial content tree. This includes virtual portal specific instances of the following portal resources: Favorites, Administration, Home, Manage Portlets, and Page Customizer with the corresponding concrete portlets. To change the content globally and before creating a virtual portal, modify the XML script that specifies the initial content for virtual portals. See Pre-configuring the default content for virtual portals.

• Assign default roles and access rights to subadministrators and users on the created resources.

Modify or edit a virtual portal

We can modify the title and description of the virtual portal. We can also set locale-specific titles and descriptions.

Reinitializing a virtual portal

Applies the InitVirtualPortal.xml script again and re-creates the default content of a virtual portal. If we replaced the default XML script with the own and configured the Virtual Portal Manager portlet accordingly, the custom script is reapplied. Resources that you removed from the default content are re-created.

Resources that you added to the default content remain in the virtual portal.

Delete a virtual portal

Deletes the virtual portal, its initial URL mapping, and all the corresponding scoped resources.

This does not delete the unscoped resources from the initial portal installation or extra URL mappings that administrators created.

Parent Work with the Virtual Portal Manager portlet

Related concepts:

Shaping the user experience

Related tasks:

Pre-configuring the default content for virtual portals

Related reference:

Use a new host name for an existing virtual portal

Related information

Technotes for virtual portals