Configuration Syntax

The following standards are specific to transactions and business rules.

Transactions

Make sure new transactions are defined with the correct rule type.

    • Example: Don’t define Policy-Financial activities as Policy-Document activities.  

    • Names should not have spaces and should be camel case.  

    • Use the same icons for like transactions across products via TransactionCosmetics.

Attached Business Rules

  1. Attached business rules each have their own general structure.

  2. With the exception of TransactionCosmetics, PostAssignmentValidateExpressions, and SummaryFields, business rules attached to transactions need to be included in the TransactionBusinessRulePacket or they will not be processed by the transaction.

  3. TransactionCosmetics should not appear in the TransactionBusinessRulePacket.

  4. The rules listed in the TransactionBusinessRulePacket are processed top to bottom.

  5. ValidateExpressions should be the first rule in TransactionBusinessRulePacket. A business error generated by this rule will allow the system to bypass the other rules in the packet.

CopyBook and Function Business Rules

CopyBooks

  1. The naming standard for creating a CopyBook rule is CopyBook-CopyBookName.

    • This is when you are not copying a complete transaction section.

  2. Keep names generic so that they can be used across plans, but clear enough to identify how the CopyBook can be used.

  3. Configure comments in a CopyBook to define all required inputs and important outputs so it is easier to use.

  4. When creating a CopyBook, perform analysis to determine how flexible the CopyBook should be so it is most useful to other plans or business needs.  

  5. Remember that putting certain tags into a CopyBook will restrict how it is used.

  6. Using the following tags may make it impossible to reuse a CopyBook:

    • EffectiveDate  

    • Allocations

    • Suspense  

  7. Fields and math should be analyzed prior to placing in a CopyBook.

Functions

  1. Naming standard: Function-FunctionName.

  2. Prior to the function call, initialize all needed or useful outputs. If an output will not be used, it does not need to be initialized. 

  3. Use functions when a calculation or functionality can be broken out into discrete and logical pieces.

  4. Use functions when the majority of MathVariables do not need to be stored or used outside of the function.

  5. When possible use functions in the place of CopyBooks.

  6. Initialize all meaningful parameters and return variables prior to the function call. A meaningful parameter is a field that will be used in any manner after the function is called such as math, spawns, validations or passed to another function. 

Miscellaneous Best Practices

  1. When trying to use Issue State within a transaction, do not use a SQL query.  

    • Define a variable with TYPE=”FIELD” and use Policy:IssueStateCode for efficiency.

  2. During configuration development use <!-- TBD -- > for comments indicating future work will be done. Also, indicate the configuration that is missing.  

  3. Use comments in a business rule or transaction to explain functionality.