Moving from a test to production server using the XML configuration interface

 


Often a test server is used to create the portal environment before it goes into production mode. The XML configuration interface allows you to export the portal settings from the test server and import them to a production server. This topic is a guideline detailing the steps that should be taken to accomplish the move.

Users and groups are not exported or imported automatically. If you are exporting users and groups, perform the steps in Moving users and groups with the XML configuration interface below before importing the configuration.

These guidelines make the following assumptions about the test and production environments:

There are three machines on a company intranet used in this scenario:

Server Description
Test Has a complete instance of WebSphere Portal installed. Portlets may have been added to this machine, the server has been tested, and the configuration represents what you plan to put into production. No special modifications are required to export the portal.
Production Has WebSphere Portal installed, but the selected install option has prevented the deployment of portlets. Some modifications must be made to this machine to prepare for the import.
Administrator Used to connect with both the test server and production server and issue commands during export and import. Because the portal administrator's password is sent unencrypted during XML configuration, all three machines should be within a protected intranet. Some modification must be made to this machine to prepare for the import.

 

Install WebSphere Portal on the production server

This configuration import described here requires that the production portal be installed without portlets. A special command must be issued to launch the WebSphere Portal installation without deploying portlets. Use one of the following commands from the root directory of the setup CD:

 

Exporting the test server configuration

Several steps must be taken on the administrator machine to prepare for the portal configuration to be exported. Be sure that the connection between the test server and the administrative machine is maintained throughout these steps.

  1. Copy the WAR files of any portlets that were deployed to the test server after the WebSphere Portal installation. WAR files must have names that are less than 25 characters. Place the WAR files in the <wp_root>/installableApps/ on the production server.

  2. If you have extra JAR files, these must also be copied to the production machine and added to the WebSphere Portal application server classpath on the production machine.

  3. Copy any new or modified themes and skins folders from <was_root>/installedApps/hostname/wps.ear/wps.war/themes/markup on the test server to the same location on the production server.

  4. Copy the following files from the WebSphere Portal root directory on the test server to the administrator machine:

    • <wp_root>/bin/tools.jar

    • iSeries: <wp_root>/bin/xmlaccess.sh

  5. Edit the following items in xmlaccess.bat or xmlaccess.sh file:

    • Change set JAVA="C:/WEBSPH~1/APPSER~1/java/bin/java" to point to the Java instance you are using. For example, if using the Java instance on the test portal, the value might be "R:/WEBSPHERE/APPSERVER/java/bin/java" where R represents that drive letter mapped to the test portal.

    • Change %WPS_HOME%/bin/tools.jar to point to the location of the tools.jar file that was copied onto the administrator machine. For example, if tools.jar was copied to C:\wpconfig on the administrator machine, so the value is C:\wpconfig\tools.jar.

    Save and close the file.

  6. Create export.xml with a text editor and save the file. This file should contain the following contents to export the test server configuration without users and user groups:

    <?xml version="1.0" encoding="UTF-8"?>
    <request
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
        type="export"
        export-users="false">
    
        <portal action="export"/>
    </request>

    If this file is not saved to the same directory, the full path must be provided when issuing the export command.

  7. From the directory that contains the xmlaccess file on the administrator machine, enter the following from the command line:

    • iSeries: xmlaccess.sh -in export.xml -user user -pwd password -url http://yourco.testserver.com:port -out testserver.xml


    where user is the portal administrator ID, password is the password for the administrative ID, yourco.testserver.com:port is the test server URL and port number, and testserver.xml is the name of output file that will hold the test server configuration. export.xml is the XML file created in previous step. Note: The full path name is required if this file does not reside in the same directory as the xmlaccess file.

    Note: You must have Java on the administrator machine or point to the Java used by WAS. If you point to the WAS instance of Java, the connection with that machine must be maintained whenever the XML configuration interface is run.

  8. The configuration content is displayed in the command line window. When a command prompt returns, open testserve.xml, the output file, and verify that the file ends with the following:

    <status element="all" result="ok">
    </request>

    If this tag exists, the export was successful. If you receive an error, see Troubleshooting the XML configuration interface.

 

Importing the configuration to a production server

After the export has generated the testserver.xml output file, the portal configuration is ready to be imported to the production server. Be sure that the connection between the production server and the administrator machine is maintained throughout these steps.

If you are exporting and importing users and groups, be sure to perform the steps in Moving users and groups with the XML configuration interface before importing the configuration to the production server.

  1. Verify that the WAR files of all portlets that were deployed after WebSphere Portal was installed on the test server have been copied to <wp_root>/installableApps/ on the production server.

  2. Verify that any new or modified themes and skins folders have been copied to <was_root>/installedApps/hostname/wps.ear/wps.war/themes/markups on the production server.

  3. From the directory that contains the xmlaccess file on the administrator machine, enter the following from the command line:

    • iSeries: xmlaccess.sh -in testserver.xml -user user -pwd password -url http://yourco.prodserver.com:port/wps/config


    where user is the portal administrator ID, password is the password for the administrative ID, yourco.prodserver.com:port is the production server URL and port number, and testserver.xml is the name of output file that contains the test server configuration that is being imported. Importing the portal configuration may take some time, particularly from a remote location. The full path name is required if testserver.xml does not reside in the same directory as the xmlaccess file.

  4. If portal configuration was a success, the following message appears in the command line:

    <status element="all" result="ok">
    </request>

    If you receive an error, see Troubleshooting the XML configuration interface.

 

Moving users and groups with the XML configuration interface

This section describes how to move from a test to a production server using xmlaccess to export the test system and then using xmlaccess to import to the production server. This export and import will not work correctly if the test system has LDAP enabled. To work around this problem, some groups must be deleted from the database and recreated in the LDAP environment.

Steps 1 and 2 below will delete the groups from the database, Step 3 will recreate the groups in the LDAP environment. These steps must be done on the test server before you import the configuration to the production server. Use the following steps to move users and groups from the test server:

  1. Create DeleteGroups.xml with a text editor and save the file. This file should contain the following contents to delete specific groups and users from the database:

    <?xml version="1.0" encoding="UTF-8"?>
    <request 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
      type="update" create-oids="true">
      <!-- sample for deleting users and groups -->
      <portal action="locate">   
       <user action="delete" name="WCPAdmin"/>
       <user action="delete" name="rob"/>
       <user action="delete" name="greg"/>
       <user action="delete" name="tara"/>
       <user action="delete" name="dave"/>
       <group action="delete" name="Domain Expert"/>
       <group action="delete" name="Project Lead"/>
       <group action="delete" name="Content Contributor"/>
       <group action="delete" name="Content Publisher"/>
       <group action="delete" name="WPCPUsers"/>
       <group action="delete" name="WPCPAdmins"/>
       <group action="delete" name="wpsDocReviewer"/>
       <group action="delete" name="wpsDocAuthor"/>
       <group action="delete" name="wpsDocAdmins"/>
       <group action="delete" name="wpsDocUsers"/>    
      </portal>   
    </request>
    

  2. From the directory that contains the xmlaccess.bat (or .sh) file on the administrator machine, enter the following from the command line for DeleteGroups.xml substituting the fully qualified filename for the xmlfilename:

    • iSeries: xmlaccess.sh -in xmlfilename -user user -pwd password -url http://yourco.prodserver.com:port/wps/config

    where user is the portal administrator ID, password is the password for the administrative ID, yourco.prodserver.com:port is the production server URL and port number, and xmlfilename is the fully qualified name of the xml file (use double quotes if the path contains spaces).

  3. Enable LDAP on the test machine.

  4. From the directory that contains the xmlaccess file on the administrator machine, enter the following from the command line for each of the following (6) xml files substituting the fully qualified file name for the xml file name:

    <wp_root>/wpcp/v5.0/author/portlet/wpcpGroups.xml 
    <wp_root>/wpcp/v5.0/author/portlet/wpcpworkspace.xml 
    <wp_root>/wpcp/v5.0/author/samples_v5/db2/sampleUtilities/samplePAC.xml 
    <wp_root>/wpcp/v5.0/author/samples_v5/db2/sampleUtilities/sampleUsers.xml
    <wp_root>/config/templates/DocumentManagerGroups.xml
    <wp_root>/config/templates/DocumentManagerPAC.xml

    • iSeries: xmlaccess.sh -in xmlfilename -user user -pwd password -url http://yourco.prodserver.com:port/wps/config

    where user is the portal administrator ID, password is the password for the administrative ID, yourco.prodserver.com:port is the production server URL and port number, and xmlfilename is the fully qualified name of the xml file (use double quotes if the path contains spaces).

  5. From the <wp_root>/wpcp/v5.0/config directory, run the following configuration task:

    WPCPconfig.bat action-cfg-author-security
    

 

Important note about Document Manager

After performing the steps described in this topic, the Document Manager portlet could be left in a state where it reports "The portlet is unavailable. Please contact the administrator". This problem occurs because the XML configuration interface does not move database contents or database connectivity information.

You will need to verify the following items:

 

See also