Mixed service models combine common service actions and vendor, technology, and software load-specific atomic actions, and should be used with discretion when implementing solutions. Consider the following example:
C_HLR_ADD_SUB --> A_NT-HLRPS_MSP8_ADD_CFB --> A_NOK-HLR_9-0_ADD_CFB
Common service actions (shown in blue) map to multiple vendor, technology, and software load-specific atomic actions (shown in red). The common service actions are shown alongside vendor, technology, and software load-specific service actions from delivered cartridges (in gray) and other solution extensions (shown in orange) that will be discussed in subsequent sections.
Consider the use of common service actions with vendor, technology, and software load-specific atomic actions when the same services are implemented differently across different vendor equipment (resulting in many optional atomic action parameters using a common model) and service actions must be agnostic to avoid exposing network specific details to upstream systems. This model requires that spawning logic spawn the correct atomic action.
Note:
When implementing solutions, discard from the cartridges those service actions and atomic actions that are not used. Include in your production environment only those service modeling entities that you intend to use. Unused actions are exposed through the OCA client during fallout management, and may create confusion and unnecessary overhead when starting and stopping the ASAP system.