A virtual portal shares several resources with the main
portal installation, especially all the code artifacts and the JVM.
When you deploy a portal solution release to a virtual portal, these
types of artifacts must not be deployed again.
Redeploying can break the references in other virtual portals.
Shared resources must be deployed only to the base portal. It is important that
the shared resources are deployed to the base portal before they are
referenced from the Virtual Portal. Because of these requirements,
staging virtual portals needs to be done in the following sequence:
Note: Follow
this sequence if the base portal assembly and the Virtual Portal are
the same on the source and target server. For example, the staging
server has the base portal, VP1, and VP2. Then, you would stage this
information to a production server that also contains the base portal,
VP1, and VP2.
- Stage the base portal. This step includes the shared and unique resources for the base portal.
You can split the Portal Application Archive (PAA) file for the base portal into two
components. One is for the unique components and the other for the shared components. When you build
the PAA, use the exportUniquePortalPAA=false to export shared
artifacts. Or, use exportSharedPortalPAA=false to export the
unique artifacts. For more information, see Parameters to customize the release.
- Stage the unique artifacts for the Virtual Portal. This step is
repeated for all Virtual Portals.
If the source and the target server are not structured the same,
then modify the sequence. For example, if the original production
server is not capable of carrying the entire base portal load, VP1,
and VP2, then you create a new production server that contains only VP2.
- Stage the shared components of the base portal only.
- Stage the unique content (for example VP2) of the required Virtual
Portal into the base portal of the new server.
This sequence results in a server with only VP2 content.
Note: Before you run the build-initial-release-paa, and you have
created realms to define the user populations, you must create a super realm. In addition to the
realms that you create to define the user populations of the individual virtual portals, you must
create a super realm. This super realm spans all other realms and contains all the users of those
other realms. It is also known as the default realm. To log in to a virtual portal, the virtual
portal administrator and all users must be a member of the realm for that virtual portal. To allow a
user access to more than one virtual portal, that user, and the Virtual Member Manager node to which
the user belongs in the hierarchy of the user directory, must be a member of all the realms
associated with these virtual portals. This applies to a super administrator who is responsible for
all virtual portals within an entire Portal installation. To administer the virtual portals, the
master administrator must be a member of the realms of these virtual portals.