header title imageheader spacer image

Inside This Issue

    VCS Practice Expertise
    Cerner

  • HNA Classic™
  • HNA Millennium™
  • Project Management
  • Integration
  • Vitalize Logic Library

Cerner Practice Newsletter
Volume 4 Issue 1, Page 2

CERNER'S RDDS IN A NUTSHELL
By Katie MacLeod


RDDS stands for Reference Data Domain Sync, and it allows you to have a centralized domain for build activity to prevent performing the same reference data updates multiple times. The main purpose of RDDS is to simplify the addition of new products or solutions by minimizing the number of build steps. RDDS keeps track of all changes made in the source domain, then compares each change with the corresponding record in the target database and updates the row accordingly. These build changes are moved during uptime.

What does it involve - technically?

The latest Install Tools are installed into production. A reference only copy of production is then created. RDDS is “turned on” to log all maintenance updates that occur in production and move them to the build domain. Reference data changes for the new solutions are made to this domain, which becomes the build source. After the database updates and integration testing are completed, the mock process can begin. A full copy of production is made and then RDDS moves the changes into the new mock or test domain while uptime regression testing is conducted. Once the move process is complete, validation is done to ensure all expected data has been moved and is functioning properly. Since RDDS is still in development, it is recommended that at least two mocks are performed. Before the final move to production, the process logging changes from production to the build source domain will be turned off. Once a successful mock has been completed, reference data can be moved from the build source to the production domain.

What’s the catch?

  • Install tools 2005.02.24 or later must be installed in order to utilize RDDS; however, it is recommended to have the latest version to take advantage of corrections and enhancements.
  • The source and target domains must be on the same Millennium code level.
  • The RDDS process must be monitored closely by technical staff to prevent issues caused by tables reaching the limit of their storage allocation.
  • Not all of the build is moved by RDDS. Some changes will still have to be made manually.
  • Depending on the number of processors available to allocate to RDDS, the process can take a significant amount of time. And it is extremely resource-intensive for the
    node(s) even with multiple cpu’s.
  • Reference data cannot be filtered; any data that is built in the source will be moved to the target.