Administer virtual portals


  1. Overview
  2. Administrator access to WAS assets
  3. Preconfigure the default content
  4. Preconfigure sub-administrator roles and access rights
  5. Create a virtual portal
  6. Fill a virtual portal with content
  7. Configure access rights for sub-administrators
  8. List all virtual portals
  9. Modify a virtual portal
  10. Delete a virtual portal
  11. Administer portal content and resources
  12. Administer the users for virtual portals
  13. Administer content and search
  14. Virtual Portal Manager administration portlet
  15. Preconfigure the Virtual Portal Manager portlet
  16. Use configuration tasks for administering
  17. Use xmlaccess.sh


Overview

Configure sub-administrators Access control portlets --- X Create a virtual portal Virtual Portal Manager X --- Fill a virtual portal with initial content Virtual Portal Manager --- X List all virtual portals Virtual Portal Manager X --- Modify a virtual portal Virtual Portal Manager X --- Delete a virtual portal Virtual Portal Manager X ---
Administrative task Portlet for this task Configuration task xmlaccess

The following two administrative tasks are manual tasks:


Administrator access to WAS assets

If you have WebSphere Portal V7.0.0.1 with fix pack 9 installed or a later version, you do not need to perform this procedure. To grant the necessary WAS roles...

  1. Log in to Deployment Manager console and select...

      Users and Groups | Administrative user roles | Add

  2. In the Role(s) box, highlight the role Monitor.

  3. In the search results list, search for the required user and select that user.

  4. Click Add.

  5. Repeat steps 3 to 5 for each WebSphere Portal administrative user who you want to be able to create virtual portals.

  6. Click OK.

  7. Save updates to the master configuration.

  8. Restart the portal server for the new roles to take effect.
When you enable security on a portal installation, by default you will have Federated Security as WebSphere Security provider.

As an alternative choice, the portal also supports the stand-alone WAS LDAP user registry. You enable the user registry by using the configuration task...

In this case you can use only the default realm.


Preconfigure the default content for virtual portals

The Virtual Portal Manager portlet pre-fills virtual portals with default content using an initialization file such as...

To determine the xml file used by virtual portals...

This shows the asset name and the XML file name inside the asset.

The file is found in the WAS asset VirtualPortal.zip. To review the file, from WAS Console, select...

We can customize the default content for virtual portals as required by modifying the XML script. The following resources are mandatory, and must be included in any customized XML initialization script...

Depending on the functionality that you want to make available, more content is required. For example, in order to allow templating, include...


Replace the default XML script with custom XML script

  1. Add custom XML script to a WAS asset...

    1. Locate the file VirtualPortal.zip on the portal server:

      • On a standalone system, the file is located here:

          WP_PROFILE/config/cells/cellname/assets/VirtualPortal.zip/aver/BASE/bin/VirtualPortal.zip

      • In a cluster, the file is located under the Deployment Manager:

          DMGR_PROFILE/config/cells/<cellname>/assets/VirtualPortal.zip/aver/BASE/bin/VirtualPortal.zip

    2. Make a copy of this .zip file, and name the copy my_VirtualPortal.zip or similar.

    3. Add custom virtual portal script to copy of the .zip file. For example, the script file can be my_InitVirtualPortal.xml . To add the script, use a utility program for .zip files.

    4. Log in to the WebSphere Integrated Solutions Console and run...

        Applications | Application Types | Assets | Import

    5. Select updated copy of the .zip file, for example my_VirtualPortal.zip .

    6. Click Next -> Next -> Finish.

    7. Save changes to the master configuration.

  2. Open the Manage Portlets portlet...

      Administration | Portlet Management | Portlets | Virtual Portal Manager | Configure Portlet (wrench) icon

  3. Edit the SCRIPT_INIT_VP parameter of the portlet.

  4. Replace the value...

      InitVirtualPortal.xml

    .with the name of custom XML script and custom asset zip file. This can be specified as a file inside a WAS asset by using a syntax such as this:

      WebSphere:assetname=my_VirtualPortal.zip:my_InitVirtualPortalScript.xml

    .where my_VirtualPortal.zip is the name of asset and my_InitVirtualPortalScript.xml is the name of a file inside the asset. Do not update the default asset VirtualPortal.zip installed with WebSphere Portal. Instead, create and maintain a separate second asset independent of the default asset VirtualPortal.zip .

  5. Click OK twice to save changes.


Preconfigure sub-administrator roles and access rights

  1. Open...

      Administration | Portlet Management | Portlets | Manage Portlets | Virtual Portal Manager | Configure Portlet (wrench) icon

  2. Change the list of portlets to which the sub-administrators have access:

    1. Edit the parameter: portletListNeedAccess

      Remove those portlets for which you want the sub-administrators of virtual portals to have no access rights.

    2. Add portlets as required by adding the unique names of the portlets to the list. You might have to take a note of the list and remove the parameter, and then enter the parameter with updated list.

  3. To change access rights granted to sub-administrators on the portlets of virtual portals, edit parameter actionSetName of the portlet.

    The default role is EDITOR. You might have to take a note of the parameter and remove it, and then re-enter the parameter with the updated value. You can enter the following values:

    • Administrator
    • Security Administrator
    • Delegator
    • Manager
    • Privileged User
    • User

  4. Click OK to save changes.


Create a virtual portal

As a master administrator you can create virtual portals by using the Virtual Portal Manager portlet...

.specifying the following attributes...


Virtual portal content

The Virtual Portal Manager portlet fills the new virtual portal with content using an XML script file for initializing virtual portals. To have different content, configure a custom script file.

The task create-virtual-portal creates a virtual portal without content. To fill with content you can either...

The create-virtual-portal does not assign roles to sub-administrators. Assign the required roles manually or with xmlaccess.sh.


Configure access rights for sub-administrators

The Virtual Portal Manager portlet requres that we specify a sub-administrator user group, which is used to creates a set of necessary access rights for members of the sub-administrator, including EDITOR role access rights on the virtual portal administration portlets. Sub-administrators perform administrative tasks on the virtual portal with these administration portlets.


Delegate Portal Access Control administration

To delegate Portal Access Control administration within the virtual portal to sub-administrators of the portal, assign those sub-administrators additional permissions in the main portal to the virtual resources, in the main portal, go to...

.and add virtual portal administrative users or user groups to the role.

Go to...

Portal Administration | Resource Permissions Portlet | Virtual Resources | USER GROUPS | Delegator Role | Edit Role button

.and add virtual portal administrative users or user groups to the role.

The Manage Search portlet requires assigning the following additional role and access rights on it to the virtual portal administrators:

Editor@Virtual Resource PSE_SOURCES

Do not grant the sub-administrators of virtual portals the access rights to perform any installation related tasks, such as installation of portlets or themes. An unstable or malicious portlet that is installed in one virtual portal can destabilize the entire portal installation, as all virtual portals share the same Java Virtual Machine. Typically, installation related tasks should only be done by the master administrator of the portal installation.


Grant virtual portal administrators access to web content libraries

Virtual portal administrators do not automatically have access to work with web content libraries when using the administration portlet. To enable a virtual portal administrator to work with web content libraries you will need to assign them access to either the JCR content root node or individual web content libraries:


List all virtual portals

You can list all virtual portals by using either the Virtual Portal Manager portlet or using a configuration task.


Modify a virtual portal

You can use the Virtual Portal Manager portlet to change the following settings of an existing virtual portal:

As an alternative, you can perform the same modifications by using a configuration task.


Delete a virtual portal

You can delete a virtual portal by using the Virtual Portal Manager portlet.

You can also delete a virtual portal by using the appropriate configuration task.

You cannot delete the initial portal installation.

After the virtual portal resource has been deleted, the scoped resources of that particular virtual portal are deleted at a later time by a scheduled cleanup service. The URL mapping that was created when the virtual portal was created is also deleted. The following resources are not deleted:

If you delete a virtual portal and you want to create a new virtual portal immediately after the deletion using the same URL context, you do not have to wait for the scheduled cleanup service. Run the cleanup task for deleting resources by running the XML script Task.xml of xmlaccess.sh. Then you can create the new virtual portal.
Prepare the deletion of virtual portals: Virtual portals can be created in environments where multiple portal installations share database domains, such as Community or Customization. This can be in a staging environment or for different lines of production. In this case some portal resources, such as page customization within a virtual portal, can be visible in several of these installations. If you delete a virtual portal, then this portal installation cannot determine if the corresponding resources can be deleted or if they are still valid in the context of other portal installations and need to be preserved. It is the responsibility of the portal administrator to decide whether clean up of related resources that reside in shareable database domains is required before deleting a virtual portal. The administrator needs to decide whether these resources are obsolete or still in use. You can perform the cleanup in two ways:

For a list of database domains that can be shared refer to the topic about Shareable database domains
Cleaning up remaining resources if a virtual portal has been deleted already:

If a virtual portal has been deleted already without prior cleanup of resources in shareable database domains, and if these resources cannot be accessed by any other portal installation that shares the database domains, to remove the remaining resources:

  1. Run the cleanup task for deleting resources by running the XML script Task.xml of xmlaccess.sh.

  2. Re-create the virtual portal that has been deleted using the identical URL mapping.

  3. Follow the instructions to delete a virtual portal including cleanup of resources in shareable database domains as described above under Preparing for the deletion of virtual portals.


Administer the portal content and resources for virtual portals

The Virtual Portal Manager portlet creates portal content and resources for the virtual portal based on the XML script used for initialization.

Scoped portal resource types are assigned to only one portal. Sharing of scoped resource types between virtual portals is not possible.

Non-scoped resources are shared among all virtual portals of the same installation. To restrict visibility, use use Portal Access Control.


Self-referencing content

If when you pull up a portal page, you get self-referencing content (i.e. a page pops up that looks like the page you left), instead of the target content, try exporting the page from the base portal, and importing into the virtual portal.

For example, if a new modal window with authoring template should open, but we get a self-referencing link that opens up the current page, to fix... .

  1. Login to the base portal and go to...

      Administration | Manage Pages | Search by: Unique name contains

  2. Enter Search: com.ibm.wps.hiddenpage.wcm.Authoring_Portlet

  3. Click the export button to the right and save the xml export

  4. Login to the virtual portal

  5. Go into Administration

  6. Click Import XML under Portal Settings

  7. Import the XML from the base portal


Change the content of virtual portals

To change the content before creating a virtual portal, modify the initialization XML script that specifies the initial content.

To change content after creating a virtual portal, use either...

When creating a virtual portal, the portlets associated with Web Content Manager are not included in the virtual portal, even if you have deployed these portlets as part of original portal installation. To use any of these portlets in a virtual portal, manually create a page and add the portlets:


Administer the users for virtual portals

Virtual portal sub-administrators can manage the access rights of the user population of the virtual portal for which they are responsible. When you use realms to separate the user populations of the virtual portals from each other, configure the realms manually in a Virtual Member Manager configuration file.

Access rights configured for users on scoped resources of the initial portal installation are not passed on to similar resources of a virtual portal. This statement applies only to resources that are scoped for each virtual portal, such as pages or portlet instances, but not for shared resources. For example, if you restricted access rights to some pages or portlet instances for users on the initial portal installation, these restrictions do not apply for the users of the virtual portal.

The All Authenticated Portal Users group and the All Portal User Groups are valid over all portals that share the same realm. This means that users who are in a realm or user group that belongs to more than one virtual portal, these users have the assigned access rights on all virtual portals to which they have access.


Change default access rights for users


Administer content and search with virtual portals

Personalization is not aware of virtual portals. A document library that is available in the initial portal installation is also available in each virtual portal, if Personalization is available in that virtual portal and is configured to use that document library. Searching for a document in a document library will produce a document reference (URL) that is different in each virtual portal, but points to the same document in the document library. To provide separation of content within virtual portals, use separate document libraries for each virtual portal. To provide content collaboration between virtual portals, use the same document libraries between virtual portals.


Use the Virtual Portal Manager administration portlet

For improved manageability of virtual portals, WebSphere Portal provides a new administration portlet. It is named Virtual Portal Manager. It allows you to create additional virtual portals on demand. You can also use it to list the virtual portals that exist in the portal.

After you complete a regular portal installation, the portal is ready and enabled for implementing virtual portals. You can create additional virtual portals for business as and when you need.

When you create a new virtual portal, you enter or select the following properties of the new virtual portal as required:

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

Besides creating a virtual portal, you can also use the Virtual Portal Manager portlet to perform the following tasks:


Preconfigure the Virtual Portal Manager portlet

You can change default content and access rights before creating the virtual portal:


Use configuration tasks for administering virtual portals

WebSphere Portal provides the following configuration tasks that you can use perform the following work with virtual portals:

The portal configuration tasks for administering virtual portal are documented under the topic about Virtual portal reference.


Use xmlaccess.sh to work with virtual portals

You can export and import the contents of individual virtual portals by using xmlaccess.sh. For example, you can use xmlaccess.sh to fill a newly created virtual portal with content. As each virtual portal has its own globally unique portal ID, all resources associated with that virtual portal can be clearly determined. To do this, address the virtual portal by the URL context or the host name that you specified when you created the virtual portal.

Specify the unique virtual portal URL or host name with XML request by either of the following options:

When you use xmlaccess.sh to work with virtual portals, be aware of the following rules:

  1. You cannot export or import a complete virtual portal by using xmlaccess.sh. You can only export or import the contents of a virtual portal. Consequently, if you want to transfer a virtual portal from a source server to a target server...

    1. Create the virtual portal on the target server.

    2. Export the contents of the virtual portal from the source server. Specify the URL context or host name of the source virtual portal as described above.

    3. Import the XML result script from the previous step to the target server. Specify the URL context or host name that you used to create the target virtual portal to which you want to import the content.

    For more details about how to export and import portal configurations by using xmlaccess.sh refer to the topic about Work with xmlaccess.sh.

  2. You can only export and import the contents of a single individual virtual portal at a time by using xmlaccess.sh. You cannot export or import multiple virtual portals at the same time or an entire portal installation with multiple virtual portals. You need to specify a separate XML request for each virtual portal. You can also export content from one virtual portal and import it into a different virtual portal.

  3. The access rights for xmlaccess.sh are limited to the master administrator of the portal installation as a whole. sub-administrators for the virtual portals cannot use xmlaccess.sh to export or import the virtual portal which they administer.

  4. Apply special care when you configure unscoped resources using xmlaccess.sh. Unscoped resources are shared between all virtual portals across the entire portal installation. A change of unscoped resources by xmlaccess.sh affects all other virtual portals. For example, this applies to the following tasks and types of XML processing:

    • Update URL mappings by using xmlaccess.sh: A URL mapping of a URL context in one virtual portal can be unintentionally updated by XML import into another virtual portal to point to a resource in that second virtual portal. Therefore, if you export the content of one virtual portal and import it into a different virtual portal, verify you do not to include the URL mappings of virtual portal URL contexts in the XML script. Otherwise, you might make the virtual portal unusable in the following two circumstances:

      • If the source virtual portal and the target virtual portal are on the same portal server, the URL mappings of the source virtual portal are updated to point to resources in the target virtual portal into which you imported the content. You can no longer use such a URL context to access the resource in the source virtual portal.

      • If the source virtual portal and the target virtual portal are not on the same portal server, but there is another virtual portal on the target portal server that has the same URL context as that of the source virtual portal. The URL mappings of this virtual portal will be updated to point to resources in the target virtual portal into which you imported the content. And you can no longer use such a URL context to access the resource in this virtual portal.

    • This is particularly critical for the URL mapping of a URL context that is created for a virtual portal during its creation. Update this initial URL mapping of a virtual portal URL context makes that virtual portal unusable.

    • Deploy portlet applications into a virtual portal by using xmlaccess.sh: If you deploy a portlet, this makes that portlet available to all virtual portals in the portal installation, unless you restrict this by using Portal Access Control. If that portlet has already been deployed in other virtual portals, errors can occur during the execution of the XML request.


Parent

Multiple virtual portals
Usage scenarios for virtual portals
Plan for virtual portals
Shared database domains


Related tasks


Set up a virtual portal in a portal farm
Virtual portals reference


Work with xmlaccess.sh


+

Search Tips   |   Advanced Search