Requesting an Upgrade Package
Email firstname.lastname@example.org to request an upgrade package and include the following information in your request:
- Current version #, e.g., R27
- Version # to upgrade to, e.g., R28
Our SystemWeaver upgrade packages are generally delivered to IT Administrators via our SystemiteNAS. When your delivery is ready, the location of your delivery and the contents of your delivery will be noted in the upgrade ticket. If you are having trouble downloading or accessing your delivery, contact email@example.com.
Release notes for the four official releases made each year are posted under What's New. Depending on your current version and the version you are upgrading to, you'll want to read the applicable release notes thoroughly and share them with representatives of each user group so they can plan accordingly.
Note: Special attention should be given to the items highlighted in yellow as they will require additional planning/steps for your organization pre and/or post-upgrade if the view/tool is being used in your installation.
Instructions for Upgrade
Below are the instructions for your upgrade in both test and production environments. Recommendations for testing are also included for your test environment.
If the release you have received requires that you update the database, this will be noted in the upgrade ticket. This does not happen frequently.
If you have been informed that the upgrade includes a database version update, before getting started, take a backup of the database. (See How to Back Up the Database)
If the upgrade does not include an update to the version of the database, you do not need to take a backup of the database.
Stop all Servers and Clients
Prior to getting started with the upgrade, you will want to stop all servers, e.g., swServer, swSlaveServer, etc. (see Stopping and Starting a SystemWeaver Server) and clients. In other words, there should be no active sessions via swExplorer, swAdmin2, swArchitect clients nor the API. Once all servers are stopped and you have verified that there are no active sessions, proceed with the below steps.
Take an Installation Backup
Be sure to make a backup copy of your current SystemWeaver installation in the event you have to rollback.
Upgrading the Server Installation
Server directory (depending on your SystemWeaver architecture, this may be called Server64 or SplitServer)
- Copy all of the files from the delivered server directory to your existing server directory. Any existing files with the same name should be replaced. Note: Any other files in your existing server directory, e.g., all .ini, .props, .settings, .nlog files should remain in place.
Note: It is important that all files from the new server delivery be placed in the server directory in the same directory location that they were delivered in, i.e., moving files from the Server top-level directory to a self-created sub-directory may cause the server not to start properly.
- If you have been informed that you are upgrading from a non-split server to a split server, see How to Upgrade to a SystemWeaver Split Server. It describes the split server and includes instructions on how to set up and run the split server in an existing installation. Basically, you will be copying the files from the new Server directory to your existing server directory replacing any files that are named the same. Note: Any other files in your existing server directory should remain in place.
- If you have been informed that you are upgrading to a new database version, see Upgrading Database Version below.
Upgrading Database Version (only if noted in the upgrade delivery)
- Be sure that you have taken a backup of your database before continuing.
- In the server directory, open the swDatabaseManager application and Select Type and Select Database.
- Click the Update v1.41 to v1.42 button. The version of the database that you selected has now been updated.
Confirm Configuration of Log Files
- If you are upgrading from a non-split server to a split server, see How to Configure Logging for the TcPSubServer to configure the swTcpSubServer log file. The configuration for the existing swServer.log file should remain unchanged.
- If there are no changes to the architecture of your server, i.e., you are upgrading from a split server to a split server, you should not need to make any changes to the log file configurations (unless paths have changed).
- Once log file configurations are confirmed, start the new server (see Stopping and Starting a SystemWeaver Server). If you updated the database version, be sure you run the new server against the new database version.
Upgrading the Slave Server Installation (skip if no slave server is deployed)
- Copy the files from the new swSlaveServer directory to your existing swSlaveServer directory/directories so that only those files are replaced. Note: Any other files in your existing swSlaveServer directory should remain in place.
- Start the slave server(s) again.
Upgrading Admin, Architect, Explorer (Client), and API
- Replace your existing directories with the new directories.
Note: If the API has been upgraded to a new version, developers of in-house applications will need to recompile them.
Notification Server (skip if no notification server is deployed)
- Copy the files from the new Notification Server directory to your existing Notification Server directory so that only those files are replaced.
- If you want to make changes to the path for the swNotificationServer.log file, you will need to update the path in the swNotificationServer.props file.
For more detailed administration information, see the SystemWeaver Help or SystemWeaver Server Installation Manual.
Testing the New Version
Testing of all new and modified functionality is done at Systemite by our testing department prior to official release. However, we still recommend that your user acceptance testing done in a test environment include the following:
- API users should test any internally developed API code. If the version of the SystemWeaver API was upgraded between your current version and the new version, API applications developed in-house must be recompiled with the newer version of SystemWeaverClientAPI.dll. Typically, this is done in a test environment first and is staged and ready for roll-out to production. API upgrades will always be noted in the release notes and should be reviewed.
- Architect users should go to File>Configure the explorer and confirm that no views have configuration errors. They will be indicated in red. An error occurs because the configuration requirements have changed for the the view in the new version. Follow the instructions in the release notes to resolve.
New and modified functionality affecting Architects is always noted in the release notes and should be reviewed.
- For end-user testing, test all enabled, configured views, especially those that are frequently used in work processes. To determine which ones these are for your organization, see File>Configure the explorer in the swExplorer client. Then, check if configuration is used by selecting the view and clicking Edit configuration to confirm the existence of a configuration. Those with configurations could be tested.
Configure the explorer:
- Architects could also do a review of implemented config items (e.g., for grids, graphs, pie charts, reports, filter settings, etc.) and regression test those configurations. Config items are displayed by item in the swArchitect client.
- Ensure User Acceptance Testing is completed of all non-standard extensions included in your upgrade package that are in use in your production environment. A list of delivered extensions can be found under Welcome>About. Example:
- Test login to server via all three clients, i.e., swExplorer, swAdmin2, swArchitect.
Client and API Distribution to Users
swExplorer Client Distribution
Make sure that ALL system users in all environments (Citrix, etc.) receive the new client version. No users should continue to use older versions of the client applications.
Make sure all API users receive the new API files.
Versioning of SystemWeaver Applications
The following parts of SystemWeaver have managed versions:
- Version of application
- Version of client server API
- Version of Database
The compatibility of different versions in a SystemWeaver configuration is monitored and managed automatically by the SystemWeaver applications. If versions do not match, the client should detect this and inform the user of the problem and the required action.