This articles describes the steps for upgrading to a newer version of SystemWeaver.
- Requesting an Upgrade Package
- Release Notes
- Instructions for Upgrade
- Database Backup
- 1. Stop all Servers and Clients
- 2. Take an Installation Backup
- 3. Upgrading the Main Server Installation
- 4. Upgrading the Mirror Server Installation (skip if not in use)
- 5. Upgrading Database Version (only if noted in the upgrade delivery)
- 6. Upgrading the Monitor Service (skip if not in use)
- 7. Confirm Configuration of Log Files (skip if not in use)
- 8. Notification Server (skip if not in use)
- 9. In-house Developed Applications (skip if not in use)
- 10. In-house Developed Extension Views (skip if not in use)
- 11. Upgrading Admin, Architect, and Explorer Clients
- 12. Starting the New Server
- Recommendations on Testing the New Version
- Testing of In-house Developed Applications and Extensions
- A Note on Versioning of SystemWeaver Applications
- In Case of Error
Requesting an Upgrade Package
Email email@example.com to request an upgrade package and include the following information in your request:
- Current version #, e.g., R39
- Version # to upgrade to, e.g., R40
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 firstname.lastname@example.org.
Release notes for the 3-4 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.
Instructions for Upgrade
Below are the instructions for upgrading SystemWeaver, in both test and production environments. Recommendations for testing are also included at the bottom of this article for your test/QA environment.
If the release you have received requires that you update the database, this will be noted in the upgrade delivery instructions. 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 you need to move any data files (e.g., SQLite database file, file repository, etc., we strongly recommend that you zip the files first, before moving them to avoid the files becoming corrupt.
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.
1. Stop all Servers and Clients
Prior to getting started with the upgrade, you will want to stop all servers, e.g., mirror server, main server, 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.
2. Take an Installation Backup
Be sure to make a backup copy of your current SystemWeaver installation in the event you have to rollback.
3. Upgrading the Main Server Installation
- 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.
- Any configuration files in your existing Server directory, e.g., all .ini, .props, .settings, .nlog files will remain in place. However, as changes are sometimes made to the configuration files in a release, compare your configuration files with the ones provided in the Configuration files directory in the delivery and migrate/update if a file has a newer version.
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 in your installation may cause the server not to start properly.
- If you have been informed that your upgrade includes a new database version, see Upgrading Database Version below.
- Once you have copied over and replaced your server files, you can right-click on each executable to confirm that the updated server application is in place in your installation. Alternatively, check the Last Modified date on them to ensure they are the new files.
|Upgrading from R28 or earlier versions: If you have been informed that you are upgrading from a non-split server to a split server, contact email@example.com for upgrade instructions.|
5. Upgrading Database Version (only if noted in the upgrade delivery)
If you have been informed that the database version has changed, see Updating the Database Version for instructions.
6. Upgrading the Monitor Service (skip if not in use)
The SystemWeaver Monitor Service files are delivered in the Server directory.
- As noted above in step 3, verify that the old swServerMonitorService.exe is replaced with the new version in the Server directory.
- Uninstall the current SystemWeaver Monitor Service. See Uninstalling the SystemWeaver Monitor Service.
- Then, install the newer version. See Installing the SystemWeaver Monitor Service.
- Next, go to Services on the server machine and confirm that the installed swServerMonitorService.exe that will be run is the updated version in the expected path.
7. Confirm Configuration of Log Files (skip if not in use)
Main Server Log Files
There are three optional log files for the main server:
- SwServer.log (recommended)
- TcpSubServer.log (recommended)
- Systemite.SystemWeaver.TcpSubServer_YYYY_MM_DD_mmss.dlq (DLQ) (only recommended for troubleshooting purposes in consultation with Systemite Support)
If there are no changes to the architecture or location of your main server installation, you should not need to make any changes to the log file configurations. However, if you have or want to change the paths to the log file generation location, you will need to update the paths in the corresponding .props configuration file. See How to Configure and Start Logging.
Notification Server Log File (skip if no notification server is deployed)
If there are no changes to the architecture or location of your notification server installation, you should not need to make any changes to the swNotificationServer.props file configuration. However, if you have or want to change the path to the log file generation location, you will need to update the path in the configuration. See How to Configure and Start Logging.
Monitor Service Log File
If there are no changes to the architecture or location of your monitor server installation, you should not need to make any changes to the swServerMonitorService.props file configuration. However, if you have or want to change the path to the log file generation location, you will need to update the path in the configuration. See How to Configure and Start Logging.
You can read more about these log files in Overview of Server Log Files.
9. In-house Developed Applications (skip if not in use)
Make sure all API users receive the new API files located in the delivered API directory.
|If the API has been upgraded to a new version or to access new enhancements or bug fixes, developers of in-house applications will need to recompile them.|
Tip: As of release R31, the API files are also available via . and are available for use in .Net Core.
10. In-house Developed Extension Views (skip if not in use)
Make sure all extension developers receive the new Extension API files. They are located in the delivered Client/swExplorer directory:
|If the API has been upgraded to a new version or to access new enhancements or bug fixes, developers of in-house plugins will need to recompile them.|
11. Upgrading Admin, Architect, and Explorer Clients
Replace all existing client application installations with the new versions. The new version should be used once the upgraded server is up and running.
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.
swAdmin2 Client Distribution
Distribute the new Admin directory to users with the Administrator role.
swArchitect Client Distribution
Distribute the new Architect directory to users with the SW Architect role.
12. Starting the New Server
Recommendations on 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.
Testing of In-house Developed Applications and Extensions
Test all recompiled in-house developed applications and extension views.
A Note on 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. See Software Releases with Client API and Database Versions.