This article describes the SystemWeaver Split Server and how to replace an existing swServer installation. If you are already running a split server architecture and are upgrading, refer to How to Upgrade SystemWeaver to a Newer Version instead.
The split server concept splits the traditional SystemWeaver server structure into two processes for better stability.
Examples of the Split Server
Together with a swSlaveServer:
The Split Server consists of two executables:
The swDBServer.exe is the main process which contains the connection to the database, cached data and all API logic.
The Systemite.SystemWeaver.TcpSubServer.exe manages the communication through TCP with all the clients and their connections. You should never start the Systemite.SystemWeaver.TcpSubServer.exe directly. It is automatically started by the swDBServer.exe when it is running.
The swDBServer.exe is the main executable. For compatibility with swServer.exe and swTestServer.exe, it uses the same .ini and .props files:
The Systemite.SystemWeaver.TcpSubServer.exe does not need an .ini file. It gets its settings from the swDBServer.exe. It does, however, need its own .prop file for logging:
So, with a split server, there are two .log files – one for the swDBServer (swServer.log) and one for the Systemite.SystemWeaver.TcpSubServer (TCPSubServer.log).
Instructions for Upgrade
- You have received a delivery of the SystemWeaver SplitServer from Systemite Support
- You have received a new license file, if applicable, from Systemite Support
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 to the Split Server
Follow the below steps to set up the required files and run the new split server. The SplitServer directory you received is meant to replace your current Server/Server64 directory. It contains some entirely new files. They are:
(Note: This may depend on which version you are upgrading to. Contact firstname.lastname@example.org to verify contents, if desired)
- Copy and then paste all of the files from the new SplitServer directory to the server directory where your existing swServer.exe is located. Any files in the existing server directory that are named the same should be overwritten.
- The existing swServer.ini and swServer.props should remain in the existing server directory, as they will continue to be used by the new swDBServer.exe. The swServer.exe will no longer be used, but we recommend that you leave it in the directory for now. If you want to make changes to the path for the log file, you will need to update the path in the swServer.props file.
- In the Split Server directory, open the Systemite.SystemWeaver.TcpSubServer.exe.nlog file and update the fileName= line to indicate the TCPSubServer.log file name and the correct path to it in your installation. This will differentiate it from the swServer.log and ensure two separate log files.
- Save your changes.
Note: Make sure that the actual log file specified in the new Systemite.SystemWeaver.TcpSubServer.exe.nlog file is different from the log file specified in swServer.props.
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.
Upgrading Admin, Architect, Explorer (Client), and API
- Replace your existing directories with the new directories.
- Be sure to distribute the new API files to those responsible for any in-house developed APIs so that they can recompile them.
- 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.
Activating DLQ Logging
When a split server is initialized for the first time, we typically recommend that you turn on DLQ logging before restarting your new split server. See Activating DLQ Logging.
Updating the Server Monitor Service Settings
If you are running the SystemWeaver server as a Windows service, you will need to update the settings file.
- Open the installation’s existing swServerMonitorService.settings file.
- Replace ‘swServer.exe’ with ‘swDBServer.exe’.
Save your changes.
When you are ready to run the new split server, restart the SystemWeaver Monitor Service.
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.
In Case of Error
If you are in need of support relating to the Split Server, feel free to contact email@example.com. We can assist with SystemWeaver server application related issues. We may ask for you to provide the log files:
If you are running DLA logging, it may be sufficient to provide us with that alone.