| 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 provides an overview of the cartridge contents and the creation process.
Oracle Communications ASAP supports the following methods for creating cartridges:
This guide does not provide details for creating ASAP C or C++ cartridges; however, the general work flow described in this book applies.
The recommended development environment for creating a cartridge is Design Studio. This guide describes the cartridge development process with Design Studio.
Design Studio simplifies the creation, assembly, and deployment of services across multiple domains. Design Studio functionality includes:
Creating, deploying, and managing cartridges
Extending cartridges into customer specific service configurations
Managing and deploying complex multi-domain services to production, test, and development environments
Modeling network element instances using predefined network element instance and connection attributes
Creating and deploying patches
Design Studio has been optimized for developing Java-based ASAP cartridges.
Even though activation cartridges can be built outside Design Studio, this is not the recommended approach. Design Studio speeds up the development process and optimizes cartridge design and implementation by providing:
Service model and Java stubs autogeneration feature
Enforced naming conventions and consistency
Cartridge documentation autogeneration
Standard Eclipse development editors for business logic implementation (Java classes)
Intuitive cartridge deployment/undeployment
Testing harness
Identifies problems and errors at development time
GUI interface
ASAP cartridges created in Design Studio are validated again the ASAP schemas described in "About Cartridge XML Schemas" during the build process and when deploying the cartridge service activation archive (SAR) file to the ASAP environment.
For more information, see the Oracle Communications Design Studio for Activation Help.
You can create ASAP Java, C, or C++ cartridges using XML that must conform to ASAP cartridge schemas (see "About Cartridge XML Schemas"). This is an older way of creating ASAP cartridges described in Appendix A, "Configuring Services Using XML".
Stored procedures have been deprecated.
You can directly add cartridge-specific information to the ASAP databases using SQL*Plus stored procedures. All cartridge-related stored procedures are described in Appendix B, "Configuring Services Using Stored Procedures".
ASAP cartridges are discrete software components developed for ASAP. An ASAP cartridge provides specific domain behavior on top of the core ASAP software. This domain behavior includes a part of, or all services on a network element (NE), element management system (EMS), or network management system (NMS). In this guide, all of these systems are collectively called NEs.
An ASAP cartridge is not a standalone component, but it operates in conjunction with the core ASAP software. Cartridges can be designed for a specific vendor, technology, and software load, and elements within each network cartridge can be reused in the creating of common or mixed service model cartridges. For more information, see "About Service Modeling".
An ASAP cartridge can be used to configure ASAP to provision the following:
NEs from a specific vendor (for example, Nokia).
Technologies, such as HLR and GSM.
Services that are supported on an NE, such as Wireless, Optical for VoIP, IPTV, or high speed internet.
An ASAP cartridge contains the following components:
An interface from ASAP to the NE that includes the following:
NE, NE template, or dynamic NE template containing connection protocol details, connection parameters required by the connection handler, and other services.
One ore more connection handlers with associated Java code to execute connection details provided in the NE, NE template, or dynamic NE template elements.
A mapping of NE generated user exit types that you defined in the action processor methods to one of eight ASAP base exit types. You can also optionally map your user exit types to a regular expression search pattern.
A set of action processors that include the following:
The action processor type: Either a Java processor class, or a State Table. The State Table option is available for backwards compatibility of older cartridges.
The action processor class: This Java class can be manually or automatically generated using Design Studio.
The action processor method: If you selected the option to autogenerate your Java code, Design Studio creates an execute method contained in the action processor class where you must implement the man-machine language (MML) commands that ASAP sends to the NE using the attributes and parameters specified in the atomic actions. You must also specify logic for your user exit types in this method. If you did not select the option to autogenerate your Java code, Design Studio allows you to create and select your own method.
A set of atomic actions in the form of Atomic Service Description Layer (ASDL) commands that include the following:
A list of user-defined attributes that include the kind of routing support required to route the atomic action to an NE, and any parameters required by the associated MML command that ASAP implements and sends to the NE
Rollback, retry, and index related atomic action configuration attributes
A list of associated action processors that implement the MML command that ASAP sends to the NE
A set of service action commands in the form of Common Service Description Layer (CSDL) commands that form meaningful service actions. Each service action can incorporate one or more atomic action commands.
Sample work orders
You should fully understand the functionality and attributes for each NE that your cartridge must manage before you start to develop an ASAP cartridge. With this understanding, you can develop a service model focused on capturing the re-usable behavior in each NE.
The following list outlines the workflow required to build a cartridge. For additional details, rules, and guidelines for each step in the cartridge creation process, refer to subsequent sections in this document.
Select your cartridge type: service or network cartridge.
Define your NE details (for example, connection protocol and the maximum number of connections the NE supports, and so on). You can also create NE templates and dynamic NE templates at this time.
Define the corresponding connection handler for your NE.
Implement one or more Java classes with methods to execute the NE connection details. You must associate your Java classes to your connection handler.
Identify the MML commands or API calls and parameters that your NE requires.
Map user-defined exit types (UDETs) to a base exit type.
Create corresponding atomic actions for each MML command or API call.
Specify the parameters used for the MML command or API call in the corresponding atomic action.
Create action processors and associated Java execute methods that implement the associated MML command.
Configure the Java execute method to handle MML response messages from the NE. Associate each NE response message to a UDET.
Associate the action processors to a corresponding atomic action.
Create a service action and associate it to one or more atomic actions to create a meaningful service.
Create sample work orders.
Deploy the cartridge.
Test the cartridge.
ASAP cartridges created using Design Studio or with XML must conform to the ASAP_Home/xml/xsd/ServiceModel.xsd schema. The SAR file structure (created automatically when you use Design Studio, or manually when you use XML) must conform to the ASAP_Home/xml/xsd/SA_Archive.xsd schema.
This section describes the uses and structure of ServiceModel.xsd and SA_archive.xsd.
The ServiceModel.xsd file defines the content and structure of one or more ServiceModel.xml files. This file ensures that the element hierarchy and document structure of the ServiceModel.xml file are correct and ensures that element and attribute content adheres to the defined datatype.
Figure 1-1 shows the element and structure of the ServiceModel.xsd schema as described in the Java Online Reference available with the ASAP installation files.
The ServiceModel.xsd file contains the elements and structure to define:
Atomic actions and their associated rollback conditions, timeout and retry settings, parameters and associated devices and software loads
Device mappings (atomicDeviceMap), which provide a type definition to map atomic actions to NE types
Service actions and their associated rollback conditions, priorities, provisioning events, and mappings to atomic actions
Base-exit-type-to-user-exit-type mappings
Event template mappings to return extended event information
|
Note: Design Studio automatically conforms to this schema when you generate a cartridge, although the Design Studio GUI screens do not necessarily map to each schema elements. |
Depending on the service modeling strategy, the service definition can be contained in one or more service model files. For example, all of your service definitions can be contained in a single service model file. Alternatively, larger organizations can distribute, add, modify, and delete service actions over three different service model files or create a service model file for each service.
The ServiceModel.xsd file is fully annotated, and the ASAP_Home/samples/sadt directory contains sample service models.
The XML files you create that contain the service models can have any name, provided the <ServiceModel> element in the activation model deployment descriptor (activation-model.xml) correctly references it.
The SA_Archive.xsd file is the schema upon which activation-model.xml is based. The activation-model.xml file identifies the components contained in the service activation archive to be deployed by the SADT or the installCartridge script.
|
Note: Design Studio automatically conforms to this schema when you generate a cartridge SAR file. |
These components include, at a minimum, one or more service models and the required State Tables or JInterpreter provisioning classes. You can optionally include other components, such as:
The cLibraryFile type (enables you to identify C or C++ library files)
Customized SQL (the SQLDeploy type allows you to add customer data to both the SRP and NEP schemas)
Documentation (including design guidelines, API documentation, and so forth).
The ComponentType attribute appears as follows in the SA_Archive.xsd file:
<xsd:complexType name="ComponentType">
<xsd:annotation>
<xsd:documentation>A component type can one of either a serviceModel, a Java EDD implementation, a customized SQL or a state table.
</xsd:documentation>
</xsd:annotation> <xsd:choice>
<xsd:element name="serviceModel" type="am:XMLFileType"/> <xsd:element name="javaProvisioningFile" type="am:ProvisioningClassFileType"/> <xsd:element name="cLibraryFile" type="am:CLibraryFileType"/> <xsd:element name="stateTable" type="am:StateTableFileType"/> <xsd:element name="srpSQLFile" type="am:SQLDeployType"/> <xsd:element name="nepSQLFile" type="am:SQLDeployType"/>
</xsd:choice>
The activation-model.xml file must reside in the META-INF directory.
The SA_Archive.xsd file is fully annotated, and the ASAP_Home/samples/sadt directory contains activation-model.xml files contained in the sample SAR files included with ASAP.
ASAP supports the following service models:
Vendor, technology, and software load-specific service model
This service model aligns common service actions and atomic actions with one vendor, technology, and software load. Design Studio for ASAP refers to this model as a network cartridge.
Common service model
This service model groups service actions and atomic actions for different vendor, technology, and software loads into one service cartridge. Each service action and atomic action combination supports only one vendor, technology, and software load. Design Studio for ASAP refers to this model as a service cartridge.
Mixed service model
This service model associates a service action to atomic actions created for different vendor, technology, and software loads. Design Studio for ASAP also refers to this model as a service cartridge.
For more information on these service models, see the Oracle Communications Design Studio for Activation Help.
You must design your cartridges to enable the use of the service models you require, for example, by applying naming conventions and parameter standards across cartridges so that merging of cartridge-specific objects into a common or mixed service model can occur on a customer project. This guide provides guidelines and best practices for creating each element using such consistent conventions and standards to facilitate service modeling.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|