Implementation Guide › Implementation › Business Logic Scripting (Business Logic Expert) › Inside the Business Logic › Create Business Logic Modules

Create Business Logic Modules

Users can define independent business logic modules that can be used by multiple service level objectives (Metrics). To apply system-wide changes to business logic, the user changes the "base" logic component which can then be applied to all relevant SLAs with a single click.

A Business Logic Module is a component of code within which business logic can be defined and easily maintained, and which reduces redundancy. A single module can be used by multiple Metrics.

During the configuration stage, the formulas are configured to define the main Business Logic modules. (See the Design chapter: Business Logic templates and modules.)

There are three types of Business Logic Modules:

• Full Business Logic-used when a whole formula is required to be used as a module. The Result and OnRegistration methods must be implemented in the Module script.
• Class-module that contains a definition of a single VB class.
• Library-module that contains any collection of procedures, functions and classes.

Modules can be used from within any of the following:

• Metrics
• Other Modules
• Business Logic Templates
• Metrics inside Contract templates and service level templates.

Modules can use parameters which are driven from the Metric context Parameters("ParamName").

Note: To avoid runtime errors, always set a default value when using parameters in Business Logic Modules. The formula outputs a log error message for non-existing parameters.

If Parameters.IsExist("ReportedDowntimesNum") Then
    maxBufferSize = Parameters("ReportedDowntimesNum")
Else
    maxBufferSize = 3
    out.log "ReportedDowntimesNum parameter not set", "E"
End If

Business Logic Module Example

There is a service level object described as "helpdesk activity within threshold". The following helpdesk system has a ticket lifecycle with statuses of:

• Open
• Assigned
• Closed.

Two of the Metrics that can be defined in order to describe the helpdesk performance are:

• Metric name- Successful Ticket resolution on time.

  Objective statement-no less than 99% of the tickets should be resolved within 4 hours.

  Business logic-Resolution should be calculated from Open to Closed.

• Metric name-Successful ticket assignment on time.

  Objective statement-no less than 99% of the tickets should be assigned within 30 minutes.

  Business logic-assignment should be calculated from Open to Assigned.

Since the same logic can be identified for both of these Metrics, a module can be created to cater for both Metrics.

The module requires the following parameters within the Metric context:

• First status
• Second status
• Threshold.

Once the Business Logic module has been created, the defined Metrics can use a module as part of the definition.

Next, the logic can be changed. For example, a new status of "Customer Pending" should be considered. Customer Pending is set for a ticket when the helpdesk is waiting for additional information about the ticket from the customer. Within the business logic, for the duration of time that the ticket is in 'customer pending' it should not be considered as part of the calculation. Only the Business Logic module therefore needs to be changed to take into account the new status and logic. A new version of the module including the new logic is created.

When committing the change, you are prompted with a list of Metrics that employ the module. You can either apply the change to all Metrics collectively, or choose to apply the change to only specific Metrics in the list.

If you select only specific Metrics from the list, you are prompted to create a new module for the selected Metrics. The old module used by the selected Metrics is replaced by the new Business Logic module and the recalculation is done using the new logic.