IDO Cached Settings

In the current Mongoose-based applications, many forms depend on settings such as feature flags, optional module availability, permission checks, and various parameters. These settings may be loaded at UI session startup and stored as global variables or retrieved individually by each form every time it runs. Forms use these settings within conditional actions, “when” expressions, and scripts to dynamically adjust their behavior and appearance.

With the ongoing “code out” initiative, more behavior is being shifted to the IDO tier. This transition creates a requirement to reference similar settings directly within the IDO tier. Different use cases exist for Data Rules to use settings within activation conditions, filter conditions, and actions.

Additionally, extension class methods could benefit from reusing these settings in the IDO tier. Due to the stateless nature of IDO requests, these settings must currently be retrieved every time an extension class method is executed.

About IDO Cached settings

  • Functionality in the IDO Middle Tier where reusable rule elements can be defined by IDO for the Site or a specific User. If it is a property-based IDO Cached Setting it can be created on the IDO where property exists. Data Rules on other IDOs can then look at that cached setting and evaluate it as a part of Data Rules filters and Actions.
  • Activation Conditions
    • Feature Active Status - Some applications like Syteline use features that can be conditionally activated on the Feature Manager form. This Activation Condition checks if a given feature has been activated in determining whether an IDO Data Rule will be used for a specific IDO.
    • Licensed Module Status - This Activation Condition checks if a given module has been licensed in determining whether an IDO Data Rule will be used for a specific IDO. This listing of licensed modules can be seen on the License Management form, Licensed Modules tab.
    • Current User Is Licensed for Module - This Activation Condition checks if a given Module has been licensed in determining whether an IDO Data Rule will be used for a specific IDO. This listing of licensed modules can be seen on the License Management form, Licensed Modules tab.
    • Current User Memeber of Group - This Activation Condition checks if the current user logged is a member of a specific Group in determining whether a given IDO Data Rule will come into effect for a specific IDO. These groups are listed on the Users form on the Groups tab.
    • Cached Setting - a setting or value that can be stored/cached for an IDO, and then used in a data rule that exists on another IDO in Filter Conditions and Actions, reducing trips to the database.

Goals behind the use of IDO Cached Settings

Create a system within the IDO tier to:

  • Define reusable settings in IDOs.
  • Load settings on demand, reducing unnecessary pre-loading overhead.
  • Support caching of settings for reuse based on scope level, site or user.
  • Enable use of cached settings in data rules and extension class code to avoid repetitive queries.
  • Enabling data rules to reference these settings in activation conditions and filter conditions for comparison and in actions for values.
  • Implementation of caching mechanisms to reuse settings efficiently based on scope level, site or user.
  • Providing specific support for commonly used settings such as module licensing status, user licensing for modules, and user group role membership.

Limitations of IDO Cached Settings

  • No usage or availability of IDO-tier cached settings in the UI tier
  • IDO Cached Settings cannot make changes to existing UI session startup methods or global variable management
  • IDO Cached Settings are not session-specific values that could be used for session state in the IDO tier. Cache scope levels for this project are site or user only.
  • No base IDO Cached Settings will be provided by the toolset, for Mongoose.
  • Method-based cached setting method parameters only support literal values being passed to the method.

The two ways the application and customers can define the settings

  • You can use the Load Collection for a straightforward static settings such as parameters.
  • You can use a Method-based Definitionfor a complex settings that require procedural logic to retrieve values.

On-demand loading and caching

Settings are loaded on request rather than at session start to improve performance. Once loaded, settings are cached based on scope level, site or user, to enable reuse and reduce redundant retrieval.

  • IDO Cached Setting values can be cleared with IDO Cache Clear.
  • IDO Cached Setting values are automatically cleared when updates are made to IDOs that define settings.

Support for the commonly used IDO Cached Settings in data rules activation conditions

Data Rules are enhanced to support activation conditions based on common settings, including:

  • Is Module Licensed - checks if a specific module is licensed.
  • Is User Licensed for Module - verifies if the logged-in user is licensed for the module.
  • Is User in Group - determines if the user is assigned to a specified user group or role.

Support for IDO Cached settings in data rules

Data Rules are extended to allow referencing IDO Cached Settings in the following ways:

  • Activation conditions can compare a cached setting to a fixed value.
  • Filter conditions can compare a cached setting to a property value.
  • Actions can use the cached settings as property values in the Set Property Value and Default Property Value actions.
  • When Data Rules are inherited to the UI tier, the setting values are substituted into the inherited rules allowing rules to function as intended in the UI.

Support for IDO Cached settings in extension class code

Extension classes can retrieve and reuse cached settings, avoiding repeated queries and improving execution efficiency.

Examples for cached setting from Syteline

We may not be able to create these examples in the class, but these examples are useful for illustration.

  • Example: Customer credit hold access
    • Use case: Using a commonly used setting as a data rule activation condition.
    • Description: SyteLine’s Customers form uses a permission group to control access to the Credit Hold checkbox.
    • Current implementations: The form runs a method on form open to determine group membership, stores the result in a form variable, and uses it in enabled-when expressions.
    • Proposed implementation: A data rule is added to the IDO with an activation condition that checks group membership and an action to enable the credit hold property. The IDO property credit hold is set to read-only as the default state.
  • Example: Customer currency with domestic currency
    • Use case: Using a cached setting as a data rule filter condition.
    • Description: SyteLine’s Customer Currency Codes form compares entered currency to domestic currency for enablement and defaulting.
    • Current implementation: A startup method sets a global variable with the domestic currency. Components raise custom events and use enabled-when expressions and form scripts for comparison logic.
    • Proposed implementation: A cached setting is added to the currency parameters IDO for the domestic currency. Data rules are added to the customer currency codes IDO with filter conditions comparing the currency code property to the cached setting, and actions to set and enable the exchange rate property.
  • Example: Customer credit hold user
    • Use case: Using a cached setting to set another property's value.
    • Description: SyteLine's Customers form sets a Credit Hold User property to the user's initials from a SyteLine users table when Credit Hold is set.
    • Current implementation: A startup method sets a global variable with user initials. Components raise customer events and a form script sets the initials.
    • Proposed implementation: A cached setting is added to the SyteLine users IDO for user initials, UserCode. A data rule is added to the customers IDO with filter conditions for credit hold change and value, and actions to set the credit hold user and allow the property to be update.
  • Example: Module availability startup methods
    • Use case: Reusing cached settings within extension class.
    • Description: SyteLine startup method checks optional module availability for approximately twenty modules on each UI session startup.
    • Current implementation: GetStartupAvailParms calls GetAvailValue for each module, checking user licensing, module licensing, and module enablement through separate IDO calls.
    • Proposed implementation: The cached settings for module availability are added to the optional modules IDO with user scope. A cached setting method checks user licensing using the commonly used setting with caching across sessions. GetStartupAvailParms is updated to use cached settings, reusing values across sessions.