Does this site look plain?

This site uses advanced css techniques

Evolution Logo

The Evolution payroll service-bureau software from iSystems, LLC is typically installed on a handful of servers, providing both middle-tier (Windows) and database-tier (Linux) machines supporting the Windows desktopclients. At least two server machines are required, but additional machines for database and Package Server support can be added to spread the load.

But one is naturally reticent to be adventurous with some kind of payroll processing on a test system, especially with operations that cannot be easily reversed. In addition, the IT staff often finds it daunting to contemplate a major Evolution upgrade when it's done on the live system.

Some Service Bureaus have implemented a test Evolution system that provides a completely separate environment for testing, and it's proven to be really helpful for several reasons:

This Evo Tip describes some of the issues involved in setting up a test system.

The Servers

These servers are set up in much the same manner as the live system, though the Registration Daemon requires a separate license key from iSystems (the serial number starts with 2 instead of 1). No part of the test system shares payroll resources with the live system save for general network infrastructure (Ethernet, nameservice, etc.)

Unlike the live network, which may have many machines to provide a robust and scalable processing environment, the test system can be as few as two machines, neither of which need be particularly powerful. The goal is to provide a test platform, not a production one, and it won't ever have the same user load as production.

Network Diagram

We presume that the machines will be named in an obviously different way (say, TESTWIN and TESTLINUX), so that no user is ever confused about which system s/he is hitting.

It's not at all clear that the test network would ever have to support Evolution Remote (via the Remote Access Server) unless remote clients have a specific need for testing or previewing a new release. We think this is generally unlikely.

Data is copied from the live servers to the test system at periodic intervals so that users have relatively fresh data to work with, though of course the SYSTEM database has to always match the software on each server.

Evo Local Issues

[Evolution logo]

It's with the Evolution client that the differences show up, and we must elaborate now how this is optimally configured. In short, two full copies of Evolution are installed on each user's workstation, with nearly identical configuration, and this permits the payroll officer to use LIVE and TEST versions of Evolution simultaneously

The reason for the dual-installation to provide Evolution with a place to store separate sets of auto-updates from the server. When Evolution connects to the Registration Daemon (perhaps indirectly through the Remote Access Server), it presents a list of all its components along with version information:

Evo module versions
...     Evolution.exe     EvdRWLocalReports.bpl     EvdSystem.bpl     EvPayrollShared.bpl     G113_r70.bpl      ibxpress73.bpl     indy70.bpl      inet70.bpl
4000.0.2.2   ip4000v7.bpl     ISClasses.bpl     isReportWriterDesigner.bpl

If the server has any components with different versions (either higher or lower), it will send down the full set of components to bring the local installation up to date. This process is well known.

But if a single installation of Evolution is used on servers with different versions - even minor version differences - it will continually upgrade or downgrade depending on which server it's connected to. This is time consuming and annoying.

One solution to this is to install EvoLocal twice: once with all the defaults to c:\Program Files\Evolution, and again to the alternate location c:\Program Files\EvoTest. At this point, both installations are identical in every way save for the install location.

To differentiate them we need two separate shortcuts, and - this is crucial - they must include the hostname on the command line. This is done by creating two shortcuts to Evolution on the desktop (or copied from a preconfigured place on the network), with two separate command lines:

Shortcut config

Missing "-hostname": A vicious cycle of updates

If the -hostname parameter is not provided, Evolution will enter a vicious cycle of updates that won't ever complete, and it was exasperating until the reason for it was discovered.

Checking your current conf

We'll step through the process in a particular -- and not uncommon -- scenario where the user had just exited the LIVE system: in this case, Evolution updates the registry to helpfully remember the last place it visited. Now the user wishes to visit the TEST system.

  1. Evolution launches and sends its module version information to the server defined in the registry, this is the live system.
  2. The live server replies with a list of updated modules, and EvUpdate.exe is launched to put them in the proper place (Evolution.exe can't do this itself because it's not allowed to update modules in use).
  3. Evolution.exe is launched again, which performs the version check again to the live server from the registry, but finds that it's up to date. This step is very quick.
  4. Evolution displays the login dialog box.
  5. The user enters a login id, password, and the name of the test server, clicking [OK].
  6. Evolution performs a version check against the test server, and is given a list of updated modules which are installed by EvUpdate.
  7. EvUpdate launches Evolution again, which peforms the version check against the server named in the registry. This is the live system, not test.
  8. Evolution resynchronizes with the live server, effectively discarding the updates from test, installing them with EvUpdate.
  9. Go back to step 3.

As far as we can tell, there is no escape from this endless cycle - the user is never actually logged into the test system.

The workaround is to always provide a -hostname parameter on the command line, which overrides the setting stored in the registry. With this flag, Evolution only queries the machine of interest and allows for a login in short order. This is ultimately the right answer anyway, because each installation location (...\Evolution\ or ...\EvoTest\) should be strictly associated with one system or the other.

This Evo Tip is not produced or endorsed by iSystems, LLC.

First published: 2005/07/24