All That You Need Is Love and Care!
VistaFresh is a friendly and powerful beast, similar to a dog.
A well- trained dog can be a very helpful friend (protecting your house, fetching your newspaper, etc). However, if you don’t provide enough attention and discipline he could get bored and eat your couch.
VistaFresh won’t eat your couch. However there is the distinct possibility, without some effort on your part, it WILL eat your Vista customizations.
One of the most valuable aspects of the PDS Vista system is the open architecture and ability to customize the base system to add and modify functionality. AECI has taken this to the extreme with hundreds of customizations in our system. Some of these are simple wording changes that can’t be handled by translation, others are functional changes to database stored procedures. We even have several custom modules that we developed for Salary Administration, Wellness Incentive Tracking, Medical Leave Tracking and others.
With this flexibility comes the risk of losing track of customizations or having them overwritten with base system functionality during a PTF installation using VistaFresh.
For those unfamiliar with VistaFresh, it is an automated tool for applying PTF updates to your PDS Vista environment. In simple terms, it compares the official base system files and database objects stored at PDS to the corresponding files in your system. When it finds differences, VistaFresh downloads those files and applies them to your system. You can see how anything you customize would be considered a “difference” and would be overwritten when VistaFresh runs.
Fortunately for all of us, PDS took this into consideration when developing VistaFresh. There are Skip File lists that you can define in the VistaFresh configuration screens. These lists tell VistaFresh which files on your system to “leave alone” during updates so as to avoid overwriting customizations. You can see these lists on the Database and Web component screens below.
This is awesome… until you have hundreds of customized files to wrangle. Then it becomes a nightmare to maintain this list manually.
Early in our implementation of PDS we made a consistent practice of marking all customizations (code and database) with comments that contained the text AECI CUSTOM. There are several reasons for this:
- This identifies where we have made an intentional change to the system.
- This allows us to add detail in the comment to explain the “why and how” of the customization.
- Most importantly, this gives us a consistent tag to help us locate these changes in an automated fashion.
Several years ago, as our Skip File lists were growing unruly, we developed an ES process to locate and catalog all of our customs for reference. The AECI Customs Inventory does the following:
- First, two database views are executed to identify any database objects (views, stored procedures and triggers specifically) that contain AECI in their OBJECT_DEFINITION. One is run on the Vista database and the other is run for the XA database. The results are written to a text file on the Enterprise Server with opening and closing XML <FILE> tags. You will see why later.
- Next, a batch file is executed that does a full-text search of the PDS web tree to identify all code pages that contain AECI in their source code. All of the file names are exported to the same text file in which the database objects were written.
- Last, each code file that is in the list has an opening <FILE> tag added and the full path is modified to be reference the E: drive.
At this point, we now have a text file with a listing of all database objects and code pages that contain customizations in our environment. They all have opening <FILE> tags and the database objects have closing </FILE> tags.
So what is the point of the tags? These tags match the XML formatting that is present in the VistaFresh definition file that maintains the Skip File lists. Having the <FILE> tags allows the comparison to match more closely and streamline synchronization of the lists.
There are several tools out there that allow you to do file comparisons and my favorite is Beyond Compare. Using this tool, I can compare the customization inventory text file with my VistaFresh definition file and easily make adjustments to the Skip File list.
Below are a couple screenshots of a Beyond Compare session (customs inventory is on the left, VistaFresh definition file is on the right).
Database
You can see that there are several discrepancies between the two lists. Beyond Compare provides a simple interface to move the differences from my text file to the definition file and vice versa.
Web Pages/Code
For the web files, you can see in the screen shot below that everything matches up (except for the missing </FILE> in my inventory text file). Again, if there are differences, the comparison tool provides an easy way to make sure that the two sides are synchronized.
Once I verify all of the customizations and synchronize the definition file, I can be sure that my customizations won’t be overwritten.*
If you do any significant amount of customization of the Vista HRMS system, I highly recommend implementing something similar to this to streamline the process of identifying and protecting your effort and time investment.
With a little attention and discipline, VistaFresh will behave like a well-trained four-legged friend and you won’t have to wonder where your customizations got buried in the back yard.
* Keep in mind that any file or database object defined in the Skip File list will need to be manually merged with any changes that are delivered in future PTFs. The VistaFresh log file (VistaClient.txt) will identify those files that were intended to be updated but were appropriately skipped. Using the log file you can manually review and modify any that need to be updated.
Derek Hime
Development Team Supervisor, Human Resources Services Team
Associated Electric Cooperative, Inc.
dhime@aeci.org