General Architecture-IVS
Figure 1: Version Table Structure
How IVS Works
Background
Many items modified through the Rules Palette are tracked by an Internal Versioning System (IVS). This system was designed to track creation, modification and deletion of system rules and configuration-
Functionality
A version of a rule represents a snapshot of that rule at a given point in time. Each version of a rule consists of data stored in two tables: IvsVersion and IvsVersionField. IvsVersion has a one-to-many relationship to IvsVersionField (see Figure 1). In the standard versioning scheme, each IvsVersionField record represents a column in the OIPA table containing the record being versioned. The figure below provides a detailed example of how this works.
Figure 2: OIPA Column and IVS Version Field Design
Not all rules are versioned using this design. Non-standard versioning strategies (strategies that do not rely solely on the OIPA Column:IVS Version Field design) generally use XML CLOBs stored in Version Fields. The XML Schema is determined by the Strategy team and can vary widely for different types of configuration. Some rules use a combination of the OIPA Column:IVS Version Field strategy combined with the XML CLOB strategy. An example of this is Rates. Rates are versioned by AsRateGroup. For each version of a Rate Group, you will see all of the AsRateGroup columns in IvsVersionField, and you will see an extra Version Field that represents the AsRate records within that group. Because there is the potential for an extremely large amount of rates within a Rate Group, the rates are versioned as a delta with the previous version. Only Version 1 of a Rate Group contains all of the rates in the XML Version Field. After that, only differences (deltas) between the rates are displayed.
Version History
IVS is designed to track data across multiple OIPA environments. It also keeps a detailed audit trail of all actions performed on each version of a rule. All of this is accomplished through the IvsVersionHistory table.
IvsVersion has a one-to-many relationship to IvsVersionHistory (see Figure 1). The following actions in Figure 3 can be performed on a version of a rule and will be logged in the IvsVersionHistory table (actions can also be found in IvsCode searching on the CodeName="IvsCodeActionType", Code Value is listed next to the action description in double quotes):
Figure 3 - Version History Actions
| Insert "01" - New rule is created | UndoCheckout "05" - Revert modifications/Undo Checkout |
| Delete "02" - Rule is deleted | Migration "06" - Rule was migrated to specified env/track |
| Checkout "03" - Rule is checked out | Conversion "07" - Version created by a Conversion Tool |
| Checkin "04" - Rule is checked in | VersionGenerator "08" - Version created by Version Generator |
All of these actions are logged on an environmental basis using the IvsVersionHistory.Environment and IvsVersionHistory.Track columns. The environment name should be a simple description of the environment (e.g. "DEV", "TEST", "PROD", etc.). The track is numeric and used to define a flow of data. A good analogy for a track in IVS is a branch in Subversion. Generally, environments labeled as being in Track 1 are part of the development trunk, and all other tracks define separate units of work. With our clients, Tracks 2 and greater are typically used for a new Plan implementation. Environments and tracks uniquely represent any given environment where configuration, testing, or live data may reside. Environment/Track combinations MUST be unique for each environment they represent.
Current versions of a rule are tracked in the IvsVersionHistory table. To find the current version of a rule in a given environment, query IvsVersion and IvsVersionHistory with the following criteria: RuleGUID (BusinessRuleGUID, TransactionGUID, etc.), environment, and track. The most recent CheckIn "04" record in the IvsVersionHistory table represents the current version.
