About Vendor, Technology, and Software Load-Specific Service Models

Vendor, technology, and software load-specific service models are provided out-of-the-box with delivered cartridges. Entities within the service model containing the vendor, technology, and software load tokens and there is generally a one-to-one relationship (or limited one-to-many relationship) between service actions and atomic actions as shown in the following example and diagram:

C_NT-HLRPS_MSP8_ADD_CFB --> A_NT-HLRPS_MSP8_ADD_CFB
C_NT-HLRPS_MSP8_ADD_3WC --> A_NT-HLRPS_MSP8_ADD_3WC
C_NT-HLRPS_MSP8_ADD_SUB --> A_NT-HLRPS_MSP8_ADD_SUB

C_CSCO-CCM_4-1-X_GET_VOIP-INFO
     --> A_CSCO-CCM_4-1-X_GET_LINE
     --> A_CSCO-CCM_4-1-X_GET_PHONE
     --> A_CSCO-CCM_4-1-X_GET_USER

Diagram of relationship between service and atomic actions

Service models designed in this way enable upstream systems to directly access device-specific operations. Using out-of-the-box service model design preserves simplicity in the Oracle Communications ASAP service model and requires less service modeling work within ASAP in the short term. However, it also forces upstream systems, which will be required to make selections of service actions based on the vendor, technology, and software loads being activated, to collate service actions together into meaningful work orders. Additionally, vendor equipment changes may create future maintenance.

Note:

When utilizing an out-of-the-box cartridge service model, consider consolidating service actions into meaningful building blocks to avoid pushing additional logic to upstream systems.

Consider the use of cartridge (vendor, technology, and software load-specific) service models when:

Services are implemented very differently across vendors (for example, use of preconfigured profiles vs. passing of raw parameters to a network element) or next generation services whose standards are evolving (multiple vendors at different phases of support for new technologies, for example, and who have different interface specifications).
One single type of vendor equipment is present in the network (for example, a specific vendor for HLRs, a specific vendor for voice mail) without future plans to introduce additional vendors into the network.
Atomic actions are technology oriented (for example, nail up a relay point) rather than service oriented (for example, add a subscriber).
Significant knowledge of the network infrastructure exists in upstream systems, such as Inventory.
Highly complex domains (IP-VPN, ATM) with homogeneous networks (for example, Cisco) are used.
Different activation steps (API calls) are required in order to activate the same services across different vendor equipment.

Lastly, if you have customer-specific parameter values that you want to expose to upstream systems, you can create new atomic actions with customer-specified atomic action parameters defined as defaults. This approach exposes only a subset of the cartridge atomic actions via the service actions. However, to use this variant you must create duplicate service actions and atomic actions with minor differences, which may create maintenance challenges.