This articles describes the steps for upgrading to a newer version of SystemWeaver. 

Requesting an Upgrade Package

Email [email protected] to request an upgrade package and include the following information in your request: 

  • Current version #, e.g., Gårda (R41)
  • Version # to upgrade to, e.g., Bagaregården (R42)

Delivery

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. 

Example


If you are having trouble downloading or accessing your delivery, contact [email protected].

Release Notes

Release note summaries 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.


Database Backup

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 you have been information that 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 you have verified that there are no active sessions, and the servers being upgraded are stopped, proceed with the below steps.

 

2. Take a Server Installation Backup

Be sure to make a backup copy of your current SystemWeaver Server installation in the event you have to rollback.


3. Upgrading the Main Server Installation

Server directory

  1. 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. 
  2. 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.

  3. If you have been informed that your upgrade includes a new database version, see Upgrading Database Version below.
  4. 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.
    • swDBServer.exe
    • Systemite.SystemWeaver.TcpSubServer.exe
    • swTestServer.exe
    • swServerMonitorService.exe
    • swDatabaseManager.exe

      Example


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 protected] for upgrade instructions.


4. Upgrading the Mirror Server Installation (skip if not in use)

Repeat the above steps for the mirror server with the exception of Upgrading Database Version.


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. 

  1. As noted above in step 3, verify that the old swServerMonitorService.exe is replaced with the new version in the Server directory. 
  2. Uninstall the current SystemWeaver Monitor Service. See Uninstalling the SystemWeaver Monitor Service.
  3. Then, install the newer version. See Installing the SystemWeaver Monitor Service.
  4. 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.

    Example 

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)
  • Statistics.log

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)

  • swNotificationServer.log


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

  • swServerMonitorService.log


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.


8. Notification Server (skip if not in use)

  1. Copy the files from the new NotificationServer directory to your existing NotificationServer directory so that only those files are replaced. 
  2. Compare your swNotificationServer.ini file with the one provided in the Configuration files directory in the delivery and migrate/update if a file has a newer version. 
  3. 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.
  4. Once you have copied over and replaced your NotificationServer files, you can right-click on the swNotificationServer.exe executable to confirm that the updated server application is in place in your installation.

    Example

For more detailed administration information, see the SystemWeaver Help or SystemWeaver Server Installation Manual.


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.

  • RVFUtility.dll
  • RVFUtility64.dll
  • SystemWeaverClientAPI.dll
  • SystemWeaverClientAPI.XML


Note: 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 NuGet. 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 ExtensionsAPI  directory:

  • SystemWeaverExtensionsAPI.dll
  • SystemWeaverExtensionsAPI.xml (documentation)


Note: 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.


Our latest SystemWeaver templates are attached to the Getting Started With swExplorer Extensions article.


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

Once all server applications have been upgraded and all users have received the upgraded versions of the client applications that they utilize, you are ready to start the new main server. If you updated the database version, be sure you run the new server against the new database and not the old one. 

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: 

  1. 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. 
  2. 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.
  3. 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: 
  4. 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.

    swArchitect: 
  5. 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 extensions can be found under Welcome>About. Example:
  6. 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.

In Case of Error

If you are in need of support, feel free to contact [email protected]. We can assist with SystemWeaver server application related issues. We may ask for you to provide the log files: 

  • swServer.log
  • swTCPSubServer.log


If you are running DLQ logging, it may be sufficient to provide us with that alone.