Move from a test to production server using xmlaccess

 

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

  1. Portal configuration will be exported from a test server.
  2. Portal configuration will be imported to a production server.
  3. Portal configuration will include moving portlets that were added after the WebSphere Portal installation.
  4. Any new or modified themes and skins will be included in the portal configuration.
  5. Users and groups will not be exported or imported.
  6. A remote administrator machine will be used to access both servers and perform the export and import tasks.

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

Test 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

The import process described below requires that the production portal be installed as an empty portal.

 

Export 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...

    <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 appserver classpath on the production machine.

  3. Copy any new or modified themes and skins folders from...

    $WAS_HOME/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
    • <wp_root>/bin/xmlaccess.sh

  5. Edit the following items in xmlaccess.sh:

    • Change...

      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 XML configuration interface file on the administrator machine, enter the following from the command line...

    ./xmlaccess.sh -in export.xml \
                   -user user \
                   -pwd password \
                   -url http://setgetweb.testserver.com:port  \
                   -out testserver.xml
    

    ...where user is the portal administrator ID, password is the password for the administrative ID, setgetweb.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 that the full path name is required if this file does not reside in the same directory as the XML configuration interface file.

    have Java on the administrator machine or point to the Java used by WebSphere Application Server. If you point to the WebSphere Application Server 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.

 

Import 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 Move 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_HOME/installedApps/hostname/wps.ear/wps.war/themes/markups

    ...on the production server.

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

    ./xmlaccess.sh -in testserver.xml \
                   -user user \
                   -pwd password \
                   -url http://setgetweb.prodserver.com:port/wps/config
    

    ...where user is the portal administrator ID, password is the password for the administrative ID, setgetweb.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. Note: The full path name is required if testserver.xml does not reside in the same directory as the XML configuration interface 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.

 

Move users and groups with the XML configuration interface

This section describes how to move from a test to a production server using XML configuration interface to export the test system and then using the XML configuration interface to import to the production server. This export and import will not work correctly if the test system has LDAP enabled. In order 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">   
       <group action="delete" name="wpsDocReviewers"/> 
       <group action="delete" name="wpsContentAdministrators"/> 
      </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:

    xmlaccess.sh -in "xmlfilename" \
                 -user user \
                 -pwd password \
                 -url http://setgetweb.prodserver.com:port/wps/config
    
    where user is the portal administrator ID, password is the password for the administrative ID, setgetweb.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 XML configuration interface file on the administrator machine, enter the following from the command line for each of the following (2) xml files substituting the fully qualified file name for the xml file name:

    <wp_root>/config/templates/ContentUserGroups.xml
    <wp_root>/config/templates/ContentUserGroupsPAC.xml
    

    xmlaccess.sh -in "xmlfilename" -user user -pwd password -url http://setgetweb.prodserver.com:port/wps/config

    ...where user is the portal administrator ID, password is the password for the administrative ID, setgetweb.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).

 

See also

Home |

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.