Does this site look plain?

This site uses advanced css techniques

Steve Friedl's Evo Tips

Running Evolution on a TEST network

• Home
• Contact
• About
• TechTips
• Tools&Source
• Evo Payroll
• CmdLetters
• Research
• AT&T 3B2
• Advisories
• News/Pubs
• Literacy
• Calif.Voting
• Personal
• Tech Blog
• Evo Blog

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:

• It provides a place to stage routine patches: payroll staff can try an iSystems update before deploying it on the production servers.
• It allows payroll staff to train and/or try things that are hard to reverse: this has been particularly helpful with multiclient tax-related processing, and with training of new staff.
• It allows the IT staff to test a major upgrade (say, Franklin to Garfield) and perfect the techniques required, as well as allowing the payroll staff to investigate the new features in a safe environment.
• It can provide hot-standby backup equipment in the event of main-system failure.

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.

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

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:

...
6.0.12.3     Evolution.exe
6.0.12.3     EvdRWLocalReports.bpl
6.0.12.3     EvdSystem.bpl
6.0.12.3     EvPayrollShared.bpl
1.13.0.0     G113_r70.bpl
7.2.0.8      ibxpress73.bpl
9.0.4.18     indy70.bpl
7.0.0.0      inet70.bpl
4000.0.2.2   ip4000v7.bpl
6.0.12.3     ISClasses.bpl
6.0.12.3     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:

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.

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