General Design Principles
The service logic design is based on key principles aimed at achieving the following objectives:
- Enable the service provider and delivery team to validate scenarios through simulations during the design and delivery phases
- Support the service provider and support team in easily debugging potential issues when the service is live
- Simplify customization of the routing logic
These design principles are detailed in the following chapters.
WARNING
To guarantee a robust, future-proof solution, it is essential to adhere to the design principles outlined in this guide. These principles are carefully defined to ensure that with every new Fusion product release, the service logic and data model remain fully compatible and continue to support all new features.
Following these guidelines not only minimizes the risk of routing disruptions but also simplifies upgrades, reduces maintenance, and ensures a smooth integration of future enhancements.
Service Logic Hierarchy and Depth Constraints
The service logic on SRE can be structured so that a parent service logic invokes one or more child sub-service logics. These, in turn, can also invoke their own sub-service logics, forming a hierarchical chain. To facilitate testing and debugging, the Fusion service logic is limited to a maximum depth of two child levels from the main service logic.
Main Service Logic Integrity
The main service logic must remain unmodified. All customizations should be implemented exclusively through child service logics.
Child Service Logic Design and Integration Strategy
As a general rule, child service logics are designed to set specific variables that are later used by the main service logic or other child service logics during execution to determine subsequent actions. As a result, most child service logics have a single exit point. In the main service logic, this exit is typically connected either directly to the next child service logic or to a condition node that determines the next step. This approach enables customization of child service logics without modifying the main service logic, as the single exit point remains consistent.
Example
The main service logic expects the Analyze Destination Number child service logic to set the variable validate_destination_number to either True or False, and to assign the destination_number variable with the number to be validated against the blacklist, whitelist, and dial plan services. Therefore, if this child service logic is customized to detect calls to emergency numbers that should bypass dial plan validation, it must set validate_destination_number to False. This ensures that when control returns to the main service logic, the appropriate actions are taken.
Variables Cleanup
To prevent cluttering the call descriptor with unnecessary variables (which can result in excessive logging and complicate scenario simulation, validation, and debugging) child service logics are designed to clean up temporary variables that are no longer relevant for the execution of the main service logic. For customized child service logics, it is also recommended to use the node Unset Variables to perform this cleanup.
Naming Conventions for Custom Variables
When customizing child service logics, it may be necessary to set additional variables beyond those expected by the main service logic, especially if these variables will be used by other customized child service logics called later during execution. To prevent potential conflicts with existing variables or those introduced in future versions of the Fusion product, it is recommended to prefix such variables with a unique identifier (e.g., c_).