Implementation Guide › Case Study Examples › Writing Effective Business Logic Examples

Writing Effective Business Logic Examples

Best practice recommendations on how to write effective business logic are given on the following subjects:

• Clustered Metrics
  • When evaluating the volume of system, count a clustered metric as the number of items in the metric and remember that everything is multiplied.
  • Recalculation of one cluster item means recalculation of the whole cluster. Therefore, remember to consider it when planning the clustering, the way adapters are configured and when changing the resources structure
  • Same Raw Data events that go to many cluster items have high performance cost (context switching)
• Global Variables
  • Get parameters and attribute values at each place in the code that they are need. Avoid keeping them in a global variable, especially in clustered metrics (it increases the size of the “states”)
  • Avoid logic that processes big maps. Instead, process each event in the OnXXEvent method
  • Remove items from maps as early as possible. For example, when a ticket is closed and not at period end
• Design Patterns

  The Predefined Content package contains several design patterns for common scenarios. Using these design patterns can improve performance

• Built-in Functionality

  ACE has built-in functionality and tools for various purposes as follows:

  • Timeslot Functionality
    • NetTime
    • IsWithinTimeslot
  • Time of Events
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Context Object
    • Contains many environment-sensitive methods
    • Use these methods and avoid “Safe ODBC”
• Business Logic Outputs

  Keep the structure in T_SLALOM_OUTPUTS. This means that if you have several logical tables in T_SLALOM_OUTPUTS that have a similar structure, it is very useful to place similar logical fields in the same physical field. This allows easy indexing for improved reports performance

• Event Reusability

  Use when:

  • Several metrics are performing first phase calculation, which is by itself needed for the contract, and send events to a summary metric that calculates the result (e.g. financial calculation, high level KPI)
  • A single metric performing a preliminary aggregation on raw data and sends events to several other metrics. Reasonable when the metric sends considerably less events than it gets or performs significant calculations which otherwise are performed many times

  Avoid when:

  • Significantly increasing the number of metrics
  • Implementing more than three levels
  • The complexity of the implementation increases and maintenance becomes harder
• Recalculations
  • Avoid massive recalculations as part of the normal operation of the system
  • The reasons for recalculations are:
    • Raw data with a timestamp in the past
    • Event singularity that changes raw data in the past
    • Corrections
    • Exceptions
    • Changes in business logic modules
    • Changes in a contract
    • Event reusability events with a timestamp in the past
    • Changes in the resources structure
  • Consider using the Calculated Data Lock functionality
• Business Logic Modules
  • Business logic modules should be written in a way that once fully reviewed, do not need to be changed
  • The guideline is: one module equals one generic logic
  • Business logic modules that are very specific cannot serve many metrics and do not promote code and logic reusability
  • Business logic modules that are too generic are difficult to maintain. In addition, if a business logic module implements many complex logics, a fix in one flow (used by part of the metrics), causes recalculation of all metrics
• Registration
  • Perform all filtering of events using registration. Leaving the filtering to the code has a huge performance impact
  • Make it simple
  • For code that is not the registration itself, use the dispatcher.IsRunTimeMode and OnResourceStructureChange methods, especially when there are many resources changes
  • Avoid using the RegisterByEventType method
  • In business logic modules, use a generic form (by contract party, service, resource type) or use parameters or leave the registration to be performed using the user interface (preferred option for Event Reusability)