Staging a virtual portal overview
A virtual portal shares several resources with the main portal installation, including code artifacts and the JVM. When we 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 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:
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, we would stage this information to a production server that also contains the base portal, VP1, and VP2.
- Stage the base portal.
We can split the PAA file for the base portal into unique and shared components....
- To export shared artifacts, use...
exportUniquePortalPAA=false
- To export unique artifacts, use...
exportSharedPortalPAA=false
- 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, create a new production server containing only VP2.
- Stage the shared components of the base portal only.
- Stage the unique content (for example VP2) of required Virtual Portal into the base portal of the new server.
This sequence results in a server with only VP2 content.
Before running build-initial-release-paa, after creating realms to define the user populations, create a super realm that spans all other realms. This is also known as the default realm.
To log on to a virtual portal, users must be a member of a virtual portal's realm. To allow a user access to more than one virtual portal, that user, and the VMM 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 super administrators 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.
Parent Overview of staging to productionRelated concepts:
Parameters to customize the release