Managing RedPrairietm Data for version control system

This is a continuation of the article that discusses the idea of using version control system for RedPrairie source code

Why worry about the data?

RedPrairie™ solutions are made up of the following components:

File Based Objects

·         3GL source code files written in C, Java, and .NET

·         MOCA based source code files (mcmd and mtrg files)

·         Shell scripts

Data Based Objects

·         Integrator Transaction Mappings

·         Data Driven Applications (DDAs)

·         GUI and RF configuration settings (les_var tables)

·         Policy settings

·         Message Catalog

·         Help Messages

·         GUI Profiles and Criteria

·         Grid configurations

·         WMS Specific entities like reason codes, order types, etc.

The file based objects can be managed by operating on the objects directly via traditional tools like text editors and RedPrairie™ Server Command Maintenance application.  Since the objects are file system objects it is possible to control the content in a version control system or migrate individual objects.

The objects that are kept in the database pose a challenge.  RedPrairie ™ solution provides applications to manipulate this data.  Such applications include Integrator Explorer (this has become part of the core RedPrairie™ client in newer versions), “Ctrl-Shift-F5” interface, “Message Catalog Maintenance”, “Profile and Criteria buttons”, etc.  These applications are quite user friendly but that is what make it challenging – users can just click and change the object but later on when we need to migrate the changes to a different environment it becomes a challenge to figure out what was changed and why.

Oracular Solution

We take a holistic approach to this problem.  We consider all objects that need to be controlled via version control system as same.  In our view, just because one object is maintained via text editor and another through a GUI application does not imply that we need to handle them differently at the very basic level.

Our solution approaches the problem with the following philosophy:

• We need to have a version control system that tracks the various objects.
• We need to have an issue tracking system that tracks the reasons why objects need to be changed.
• The version control system and the issue tracking system need to be integrated.
• All objects, whether file or data, need to be pushed in the issue tracking system.

Our philosophy with respect to the data objects, where RedPrairie™ provides a GUI application, is as follows:

• A specific named RedPrairie™ user will be assigned to a set of issues in the issue tracking system.
• The user will indicate which issue she will be working on.  She may only work on a single issue at one time.
• After that, she may navigate through the RedPrairie™ client and make the various changes.
• As the changes are being made, our solution will track the objects that were changed in a database table.
• After completing the changes, she will mark the issue as complete.  This will export all of the objects in to their corresponding directories under $LESDIR/db/data folder.  The solution will also optionally check in the objects in to the version control system.  At this time we support integration with SVN repositories.

Developer Experience

The developer’s experience will be as follows:

1. Developer gets an assignment.  The assignment tells her the issue number in the issue management system.

We use bugzilla issue tracking system but our approach is compatible with any such system.

2. She signs on to the “Issue Assignment” application within RedPrairie™.
1. She adds an entry there and specifies the issue number.

3. Now she navigates to the various applications and modifies the data from those applications.
1. For example Integrator maintenance, “Ctrl-Shift-F5”, DDA, Code Master Maintenance, Custom Fields, etc.
2. We provide an extensive set of these hooks and our solution can be extended to include additional objects and even custom objects.
4. At any time anyone can audit to see what objects have been modified by that issue

5. When she is sure that change is complete, she signs on to the “Issue Assignment” application again and presses the “Complete” button.

The system then prompts the user if the data should also be checked in to the version control system.  Our solution is integrated with SVN repositories.  Version control integration is not required to export the data to files:

1. The system will go through all of the objects that she touched

                                                               i.      For add and change actions, export the data that she touched into the corresponding files.

                                                             ii.      For delete, if the list command does not return any rows then delete the file otherwise handle it like add/change.  Note that even though she deleted an entry the entry as a whole may still be controlled.  For example she could have removed a form override for les_var_config.

                                                            iii.      The system will then add all of the objects to version control and commit them with a comment that would link it to the issue.

2. Once all of the objects have been checked in to the version control system, the issue will be marked as complete.
3. If version control integration was being used, the data will show up under the corresponding issue as well:

These objects are policies that needed to be changed for this change request.

Conclusion

Managing the RedPrairie™ data is one of the most challenging aspects of change management.  Once the users see how easy it is to change various complex features, e.g. screen features, policies, integrations, etc. they are inclined to make such changes.  Once the changes are complete, they want to see the same changes in the other environments and that becomes a significant challenge because the data is scattered in various database tables.  Copying the whole database is not an option because that will end up copying transactional data as well. 

Our solution provides the control while keeping the flexibility that the RedPrairie™ solution provides.   Out solution empowers the users to make the changes in the environment that they are familiar with while keeping track of their changes at the lowest level.  We can then control the changes and migrate them easily to other environments.

Copyright Notice

·          RedPrairie is a registered trademark of RedPrairie (http://www.redprairie.com)

·          Oracular is a registered trademark of Oracular (http://www.oracular.com)

·          This document contains information about the RedPrairie software.  It is assumed that recipient has legal access to the said software.

·