Build a Release for virtual portal installations

Overview

For source virtual portals we use ReleaseBuilder with a slightly different procedure to...

• Prevent redundant updates of the resources shared between the virtual portals
• Prevent update conflicts of virtual portal scoped resources

Build a release using new installations

1. Install portal on source server.

2. Install portal on target server.

   If an additional portal profile is created after installation...

   cp -r $ORIG_WP_PROFILE/PortalServer/deployed/archive /tmp/PortalServer/deployed/archive

3. From the profile to be used as the target server, empty portal contents...

   cd WP_PROFILE/ConfigEngine

   
   ./ConfigEngine.sh empty-portal

   If the target server profile is not the original default WP_PROFILE, restore contents...

   cp -r /tmp/PortalServer/deployed/archive/* $NEW_WP_PROFILE/PortalServer/deployed/archive

4. Create the same virtual portals on both source and target servers using the command...

   ./ConfigEngine.sh create-virtual-portal

   If create-virtual-portal is not used, the virtual portal instance is not empty, and cannot be used to import a fresh release as a baseline.

5. Develop the releases of the default portal and the virtual portals on the source server.

6. Export the releases of the default portal and the virtual portals on the source server.

7. Import the releases into the target server portals:
   1. Import the default portal release into the default portal on the target server.
   2. Import the virtual portal releases into the respective virtual portals on the target server.

If we already have a target server without a source system:

1. Export the target server releases:

   1. Export the release of default target server.

   2. For each virtual portal, export the virtual portal release of target server.

2. Install and configure the source server:

   1. Install and configure the source server, and then run...
      ./ConfigEngine.sh empty-portal

   2. Create corresponding virtual portals on the source server...
      ./ConfigEngine.sh create-virtual-portal

3. Import the target releases onto the source server:

   1. Import the target release onto the default source server.

   2. For each virtual portal, import the virtual portal release from the target server onto the source server.

We have now a source server that is synchronized with the target system.

Build a release using established installations

1. Export the configuration of the base portal on the source server.

   cd WP_PROFILE/PortalServer/bin 
   ./xmlaccess.sh -in ExportRelease.xml 
                  -user wpsadmin 
                  -password foo 
                  -url http://host:port/wps/config
                  -out rev1.xml
   

2. For each virtual portal, export the source server configuration...

   cd WP_PROFILE/PortalServer/bin 
   
   ./xmlaccess.sh -in ExportRelease.xml 
                  -user wpsadmin 
                  -password wpsadminpwd 
                  -url http://source.example.com:port/wps/config/vpcontext 
                  -out rev1_vpcontext.xml
   

   The exported configurations are now stored in the file rev1.xml and multiple files rev1_vpcontext .xml, one each for the virtual portals.

3. Develop new functions and portlets on the source server.

4. Export the configuration of the base portal on the source server.

   cd WP_PROFILE/PortalServer/bin 
   ./xmlaccess.sh -in ExportRelease.xml 
                  -user wpsadmin 
                  -password foo 
                  -url http://host:port/wps/config
                  -out rev2.xml
   

5. For each virtual portal, export the source server configuration...

   cd WP_PROFILE/PortalServer/bin 
   
   ./xmlaccess.sh -in ExportRelease.xml 
                  -user wpsadmin 
                  -password wpsadminpwd 
                  -url http://source.example.com:port/wps/config/vpcontext 
                  -out rev2_vpcontext.xml
   

6. Copy relevant war files. From source server...
   scp WP_PROFILE/PortalServer/deployed/archive/mywars*.war user@host:/path/to/PortalServer/deployed/archive

   For Windows the name of the WAR file must be 25 characters or less.

7. Generate differences files...

   cd WP_PROFILE/PortalServer/bin 
   ./releasebuilder.sh -inOld rev1.xml 
                       -inNew rev2.xml 
                       -out output.xml 
                       -virtualPortalMode
   ./releasebuilder.sh -inOld rev1_vpcontext.xml 
                       -inNew rev2_vpcontext.xml 
                       -out diff_vpcontext.xml 
                       -virtualPortalMode
   

8. Import output.xml into target portal environment.

   ./xmlaccess.sh -in output.xml 
                  -user wpsadmin 
                  -password wpsadminpwd 
                  -url http://target.example.com:port/wps/config
   

   The base difference file must be imported before the virtual portal difference files.

9. Import diff_vpcontext.xml files

   ./xmlaccess.sh -in diff_vpcontext.xml 
                  -user wpsadmin 
                  -password wpsadminpwd 
                  -url http://target.example.com:port/wps/config/vpcontext
   
   
   

If portlet parameters are deleted from a configuration, the output script generated by ReleaseBuilder does not remove those parameters on the target system.

XML files generated by ReleaseBuilder do not have any transaction levels set. To set a transaction level edit the XML file generated by ReleaseBuilder and add the transaction level to the XML file.

Parent

ReleaseBuilder
Build a release
Checklist for ReleaseBuilder

+

Search Tips   |   Advanced Search