Requesting an Upgrade Package

Email support@systemite.se to request an upgrade package and include the following information in your request: 

  • Current version #, e.g., R30
  • Version # to upgrade to, e.g., R31

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 support@systemite.se.


Release Notes

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 at the bottom of this article for your test environment.

Database Backup

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.

 

1. Stop all Servers and Clients

Prior to getting started with the upgrade, you will want to stop all servers, e.g., mirror server, slave 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

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

      Example


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

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


5. Upgrading Database Version (only if noted in the upgrade delivery)

  1. Be sure that you have taken a backup of your database before continuing.
  2. In the server directory, open the swDatabaseManager application and Select Type and Select Database.
  3. Click the Update v1.41 to v1.42 button. The version of the database that you selected has now been updated.


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. See Uninstalling the SystemWeaver Monitor Service for how to uninstall and then Installing the SystemWeaver Monitor Service to install the newer version.
  2. Next, go to Services on the server machine and confirm that the installed swServerMonitorService.exe that will be run is in the expected location (where the updated swServerMonitorService.exe is located).

    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


Slave Server Log File (skip if no slave server is deployed)

If running one or more slave servers, we recommend that you configure logging (for each slave server). 

  • swSlaveServer.log (recommended)

If there are no changes to the architecture or location of your slave server installation(s), you should not need to make any changes to the swSlaveServer.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


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. Upgrading the Slave Server Installation (skip if not in use)

  1. Copy the files from the new SlaveServer directory to your existing SlaveServer directory so that only those files are replaced. Do this for each slave server installation. Note: Any other files, i.e., configuration files, in your existing SlaveServer directory should remain in place.  
  2. Once you have copied over and replaced your SlaveServer files, you can right-click on the swSlaveServer.exe executable to confirm that the updated server application is in place in your installation.
  3. After the upgrade main server is up and running, you can start the upgraded slave server. Note that if you have multiple slave servers, start one at a time making sure that each one is up and running prior to starting the next.


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


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

 

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

  • RemObjects.Hydra.dll
  • RemObjects.Hydra.WPF.dll
  • Systemite.SystemWeaver.ExtensionControls.dll
  • SystemWeaverExtensionsAPI.dll


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.


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


11. 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 version and not the old version. 


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


In Case of Error

If you are in need of support, feel free to contact support@systemite.se. 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.