This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
  • Created by Former user, last modified by Former user on May 05, 2015
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Current »

The followings steps describe how to upgrade from ESB 4.6.0 to ESB 4.7.0. For more information on release versions, see the Release Matrix.

Upgrade procedure

Follow the instructions below to upgrade the system.

The upgrade should be done when there is low traffic on the system.

  1. Stop the current server.

  2. To migrate deployment artifacts (including ESB message flow configurations):

    • Copy the <ESB_HOME>/repository/deployment/server directory from ESB 4.6.0 to ESB 4.7.0.

      If you do not have axis2 modules or axis2 services, you can copy the  <ESB_HOME>/repository/deployment/server/synapse-cofigs/default directory instead of all the contents in the <ESB_HOME>/repository/deployment/server directory.

    • Perform any configurations required for the server, e.g., external user stores, clustering, mounting.

  3. If there are any external applications used with ESB 4.6.0 that you want to migrate, copy the following directories from ESB 4.6.0 to ESB 4.7.0:
    • ESB_HOME/repository/components/lib 
    • ESB_HOME/repository/components/dropins
  4. If you have multiple tenants defined in ESB 4.6.0, copy the ESB_HOME/repository/tenants directory from ESB 4.6.0 to ESB 4.7.0.
  5. If you have not mounted the registry space to an external database you should manually copy the registry entries in ESB 4.6.0 to ESB 4.7.0. However. note that it is recommended to mount the registry entries to an external database. See Sharing Registry Space Among Multiple Products.
  6. Start the server.

Going into production

The following are a few recommended tests you may carry out to test whether the upgrade has been successfully performed.

If you can open the management console:

  • Create multiple user stores and try adding users to different user stores.
  • Create multiple tenants and add different user stores to the different tenants. Thereafter, add users to the various user stores.
  • Check whether the list of proxy services, REST APIs, sequences, endpoints, message processors, message executors and priority executors you could view when running ESB 4.6.0 management console could also be viewed when you run ESB 4.7.0.

  • Test the integrations with other products e.g., see 2-legged OAuth for Securing a RESTful Service.

     

The following tests can be performed even if you operate as a worker in a worker-manager cluster and you cannot access a management console:

  • Send a request to a proxy service you migrated and check whether you get a valid response.
  • Send a request to a REST API and check whether you get a valid response.

Once the above tests are run successfully, it is safe to consider that the upgrade is ready for production.  However, you should also test any features that are being used in production.

Downtime

The downtime is limited to the time taken for switching databases.

  • No labels