Guidelines for synchronizing BOM changes

You can avoid synchronization errors by following these guidelines for synchronizing BOM changes in rule projects.

Changes to the BOM in Rule Designer can cause corresponding changes in rules through the Rule Designer refactoring mechanism. You must handle these changes cautiously to maintain synchronization with Decision Center.

For example, consider a project that is worked on and managed simultaneously in Rule Designer and Decision Center:

  • The project has a BOM class Customer verbalized as the customer with an integer member age verbalized as the age of the {this}

  • The project has the following rule named Legal Age:

    if
   the age of the customer is less than 21
then
   ...

If a Rule Designer user changes the verbalization of the class Customer to the client, Rule Designer refactors the rule Legal Age to read:

if
   the age of the client is less than 21
then
   ...

Suppose that, in the meantime, a Decision Center user creates a second rule named Senior:

if
   the age of the customer is more than 65
then
   ...

If the Rule Designer user updates from Decision Center, the new rule is added to the Rule Designer project, but is in error because “the age of the customer” is no longer part of the vocabulary in the Rule Designer project.

Similarly, if the Rule Designer user publishes the changes in the verbalization, all the rules in Decision Center referring to “the customer” are in error.

These occurrences are a natural consequence of simultaneous development of dependent artifacts; the rules depend on the BOM vocabulary. You can avoid these errors by following the development practices that are described here for synchronous and asynchronous changes.

Simplest case: synchronous vocabulary change

The simplest approach to managing vocabulary change during simultaneous development is to synchronize changes to the BOM and vocabulary. This approach might not be practical for large projects, but works with smaller groups and small changes after the initial setup of the BOM.

In this case, you make all the changes to the BOM or vocabulary on a fully up-to-date copy of the rule project. Do the following sequence of events:

  1. Before you make the changes, all the developers commit their projects to SCC.

  2. A single developer updates a copy of the project from SCC to make it current.

  3. The developer updates from Decision Center to get a current copy of all the rule changes.

  4. The developer makes the BOM and vocabulary changes, and refactors rules as required.

  5. The developer commits the modified project to both SCC and Decision Center.

  6. Simultaneous rule development in Rule Designer and Decision Center can then resume.

Managing asynchronous changes

For large teams, or when you must manage multiple versions of a project for extended periods, implement the following practices:

  • Developers who need to make BOM changes must not delete BOM classes or members. Deprecate obsolete classes and members (use the deprecated property in the BOM editor) during ordinary development. Remove them only when a fully synchronized copy of the project is available and all the rules are refactored.

  • Developers must avoid changing argument numbers and types in the BOM. If you need a new argument number or a type change, create a new method with the “corrected” arguments and deprecate the old member.

  • You do not need to place restrictions when you add classes or members to the BOM. However, you must establish processes to make sure that such additions are made only one time to a single copy of the project, and then propagated by synchronization to avoid having to merge incompatible additions.

  • As much as possible, defer vocabulary changes (other than additions) to occasions when you can use a fully synchronized copy of the project so that all the rules are correctly refactored.

    Change the vocabulary:

    • Deprecate the member for which the vocabulary is to be changed (the “original” member)

    • Add a new virtual member on the same class, with the required verbalization (the “new” member)

    • Use BOM-to-XOM mapping to map the new virtual member to the appropriate real method in the XOM

  • To resolve duplicate verbalizations when you have a fully synchronized version of the project:

    • Remove the new member and save the BOM entry that contains this member. All the rules that use the new verbalization are temporarily in error.

    • Change the verbalization on the old member to the required new verbalization, and save the BOM entry. Examine all aspects of the verbalization carefully to make sure that it exactly matches the new verbalization that you want. Rule Designer refactors the rules to use the new verbalization and rebuilds the project, clearing the temporary errors from the first step.