| Oracle® Communications ASAP Cartridge Development Guide Release 7.2 E22486-01 |
|
 Previous |
 Next |
| Oracle® Communications ASAP Cartridge Development Guide Release 7.2 E22486-01 |
|
Previous |
Next |
This chapter describes how to define an Oracle Communications ASAP cartridge project.
ASAP provides two cartridge types that support the three service models (see "About Service Modeling"):
Network cartridges
Service cartridges
Network cartridges can be used to implement the vendor, technology, and software load-specific service models. Service cartridges can be used to implement both common and mixed service models.
|
Note: You can select the cartridge type and all components described in this chapter using the New Studio Activation Cartridge Project Wizard in Design Studio for ASAP. For more information about this wizard, see the discussion on setting up an activation cartridge in Oracle Communications Design Studio for Activation Help |
Network cartridges target a single vendor, technology, and software load. The development process starts with the network element (NE) interface documents, identifying the services and commands supported and then deciding which set of services to be implemented. Specific customer business logic has no impact, because the solution layer must be implemented as a service cartridge. The scope is to develop generic, reusable libraries of atomic actions, which can then be used for custom solutions projects.
Network cartridges typically support a one to one mapping between service action and atomic action commands, simplifying service modeling; however, this pushed back the problem of creating meaningful services to the work order level. For more recommendations about scenarios where network cartridges are appropriate, see the Oracle Communications Design Studio for Activation Help.
You can purchase network cartridges from Oracle, or you can create your own network cartridge.
Defining network cartridge project parameters includes the following tasks:
Name each network cartridge using elements that uniquely identify it. The following items are included in a cartridge name:
Vendor
Technology
Software load
|
Note: You define these three elements using the New Studio Activation Cartridge Project Wizard in Design Studio for ASAP. For more information about this wizard, see the discussion on setting up an activation cartridge in the Oracle Communications Design Studio for Activation Help. |
The Vendor token is a string that uniquely identifies the manufacturer of the NE: for example, ALU for Alcatel-Lucent, or ERIC for Ericsson. It is embedded in the service modeling object names and Java method names. Use Table 2-1 to select a vendor token, otherwise check the NASDAQ symbol for hints but do not use symbols that are cryptic, for example the SONUS NASDAQ symbol is SONSE which is not as meaningful as SONUS.
The technology token is a string that identifies the category of services or vendor classification of equipment to which the NE belongs: for example, HLR for Home Location Register or DSLAM for Digital Subscriber Line Access Module. In some cases, a vendor specific term (such as DMS or STINGER) may be used in place of the technology token.
See Table 2-2 for technology token examples.
Table 2-2 Technology Token Examples
| Vendor | Technology Token | Description |
|---|---|---|
|
Generic |
|
Home Location Register NE |
|
Generic |
|
Digital Subscriber Line Access Module |
|
Generic |
|
Voice Mail Server |
|
Generic |
|
Short Message Server |
|
Nortel |
|
Digital Multiplex System Voice NE |
|
Alcatel-Lucent |
|
Digital Subscriber Line Access Module |
The software load is an alphanumeric string representing the software load of the element management system (EMS) that manages the NE, or the software load running on the NE itself. The selection of the software load to be supported is based on the entity (EMS, Network Management System (NMS), or NE itself) that the cartridge is designed to interface with.
A software load containing a minor release number (for example, 1.2) has a corresponding software load token of 1-2. This is the same token used in the name and configuration of the sample NE and in the atomic action to Java method mapping (see the sftwr_load token of tbl_nep_asdl_prog). Do not use periods in the name of the software load token, use dashes instead.
A cartridge only supports one technology and software load. When the software load for a particular technology changes, build a new cartridge to support the new software load.
In general, create a new cartridge release when a major or minor change in the software load occurs, and specifically when the changes between these releases is significant. Some vendors make significant changes in their software between minor releases (for example 1.2 to 1.3); other vendors make the significant changes in their cartridges between major releases (for example 3.0 to 4.0).
Using an x in the second or third digit of the cartridge software load value indicates that the release does not have significant changes for any releases that change the digit marked as x. For a example, a cartridge marked with software load 1-2-x, assumes that small changes occur in the third digit. Changes in the cartridge may be needed if additions are made to the NE software as part of such a release, but the cartridge software load remains intact and the cartridge remains backward compatible.
Two approaches can be taken in determining the scope of the network cartridge:
Comprehensive - aimed at supporting as much functionality as provided by the NE. You may develop more than one service package (see "Selecting Entity Tokens") for the various services supported on an NE (for example, Frame Relay, FRATM, and ATM services). For cartridges supporting many different types of services, the comprehensive approach can require significant development effort.
Service-specific – often driven by a customer request or market demand for support for a particular set of services on an NE: for example, ATM PVCs. Because the scope of the cartridge is limited to a subset of functionality, this approach often requires less development effort. Additional services in the form of sub-cartridges can be supported on the NE in the future.
Factors influencing the approach that is taken include the time available to implement the cartridge, customer priorities and the number of services provided by the NE.
Design Studio for ASAP automatically creates your directory structure for you as you add new service actions, atomic actions, and action processors.
The project name should identify the name of the vendor, the technology, and the software load to differentiate your cartridge from other cartridge projects.
Service cartridge can select components from any network cartridge to create customized service models that can simultaneously activate and configure diverse NEs from any vendor, technology, and software release.
For more information about the kinds service cartridges, see the Oracle Communications Design Studio for Activation Help.
Service cartridges extend and customize the services provided in network cartridges. To access the service action, atomic actions, action processors, network connections, user exit types, and event templates configured in network cartridges, you must import the network cartridges in Design Studio before creating a service cartridge project.
For more information about importing cartridge projects from SAR files, see Oracle Communications Design Studio for Activation Help.
|
Note: You can reuse service actions, atomic actions, action processors, network connections, user exit types, and event templates configured in network cartridges purchased from Oracle in a customized service cartridge; however, the source code for Java action processor classes, methods, or State Tables are not provided. If you require access to specific code in order to extend existing network cartridge, Java, or State Table implementations, request access by raising a service request with Oracle Support. |
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|