Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

7.
1
Getting Started with Studio for ASAP
1
Studio is an optional Activation component that simplifies the creation, assembly, and
deployment of services across multiple domains. It is a powerful graphical tool that
dramatically reduces the time-to-market for new services. Studio offers support for the
activities performed by a wide variety of users including business analysts, service
modelers, network element administrators, deployment managers and cartridge
developers. Studio functionality includes:
■
Create, deploy and manage cartridges.
■
Extend cartridges into customer specific service configurations.
■
■
■
Manage and deploy complex multi-domain services to production, test and
development environments.
Rapidly model network element instances using pre-defined network element
instance and connection attributes.
Support for creation and deployment of patches.
The services that can be modeled in Studio are typically those that are provided to end
users of telecommunications networks, such as voice services (including wireless,
voice over IP), data services (including digital subscriber line, IPTV), or any other
services that require controlled and coordinated activation in the network. These
services are modeled in Studio by defining and relating objects at different levels of
abstraction.
Related Topics
Understanding ASAP Users and Tasks
Configuring Activation Network Cartridges
Configuring Activation Service Cartridges
Understanding ASAP Users and Tasks
The users of Studio Activation belong to the following user groups:
Business Analysts
Business analysts are responsible for describing the features and services associated
with marketing products and communicating this to the users responsible for building
these products. The business analyst may simply name and describe products and
pass this product description to a service modeler, or may perform basic service
modeling tasks in Studio. This involves the following tasks:
Beta Draft
Getting Started with Studio for ASAP
1-1

10.
Configuring Activation Network Cartridges
a.
Create service actions, atomic actions, and action processors as elements for
the model. See Creating Model Elements for more information.
The elements can be created with a wizard, but you would normally use the
simpler and more efficient Cartridge Generation feature, which creates the
elements and also links them. See Generating Framework Models for more
information.
b.
For elements that you created with a wizard, define their relationships by
manually linking service actions, atomic actions, and action processors, and
define the element parameters.
For elements that you created with the Cartridge Generation feature, the
linking process is automated, and elements are automatically created and
linked.
See Understanding Model Element Relationships for more information.
c.
Add information that will be used for auto-generation of documentation for
the model.
See Documenting Cartridges for more information.
3.
Implement the action processor.
a.
Define a java action processor implementation.
Use the Java with code generation implementation to write the logic in the
execute method of the processor class (the proxy automatically performs
several steps of code generation). See Understanding Java with Code
Generation and Understanding the Java Processor Class for more information.
Configure java libraries. See Understanding Java Libraries in Studio for more
information.
b.
Use the Unit Test procedure to generate a test case, which enables you to test
the processor outside of the ASAP environment.
Configure a Unit test for the processor. See Testing ASAP Cartridges in Studio.
4.
Configure the user-defined exit types (UDET). See Configuring User Defined Exit
Types for more information.
a.
b.
5.
Create UDETs as elements for the model.
Configure the UDETs in the editor to define the content.
Implement the connection handler.
Write a Java Connection Handler. See Generating a Telnet NE Connection Handler
Implementation and Generating a Custom NE Connection Handler
Implementation for more information.
6.
Define the network element (NE) model. See Modeling Network Elements for
more information.
You must create and configure at least two of the following elements (all three
concepts are related as they involve connection to equipment):
a.
NE templates.
A template that can be copied to create one or many specific NEs.
b.
Network elements.
An NE represents one specific piece of equipment (a single instance) in the
network. A connection pool contains one or more connections that can be use
1-4 Modeling Activation
Beta Draft

11.
Configuring Activation Service Cartridges
to connect to the network element (possibly simultaneously). Each network
element has a single connection pool associated with it.
c.
Dynamic NE templates.
In some cases it is not ideal to configure static network element instances for a
specific customer solution. In such cases, dynamic NE templates can be
configured allowing network element attributes to be dynamically sent to A5
on work orders. Dynamic NE templates are used when upstream systems
(such as Inventory) contain the necessary information to connect to the
network element instance. Passing this information to A5 dynamically avoids
having to configure it in multiple locations (e.g. in A5 as well as in an
inventory system).
7.
Package the cartridge.
See Packaging Activation Cartridge Implementations for more information.
a.
Model the packaging.
Use the Cartridge editor to specify which elements will be included in the
cartridge (SAR file).
b.
c.
Include JARs in the SAR.
d.
8.
Create the JAR with ANT.
Put external JARs in the NEP classpath on the ASAP server.
Deploy the cartridge.
See Deploying Cartridges and Managing the ASAP Environment for more
information.
a.
Create an Activation Environment project and an Activation Environment in
the Cartridge view (use the corresponding wizards for both tasks).
b.
On the Connection Details tab of the Activation Environment editor, specify
how to connect to the activation environment.
c.
On the Connection Details tab of the Activation Environment editor, add
cartridges for deployment, deploy them to the environment, undeploy them
from the environment, and remove them from the list of cartridges that were
added for deployment.
d.
Use the NEP Map editor to deploy and manage Network Elements.
Related Topics
Getting Started with Studio for ASAP
Configuring Activation Service Cartridges
Studio supports three types of Activation cartridges:
■
■
■
Activation Network cartridges. See Understanding Activation Network Cartridges
for more information.
Activation Service cartridges. See Understanding Activation Service Cartridges for
more information.
Activation SRT cartridges. See Understanding Activation SRT Cartridges. for more
information.
Beta Draft
Getting Started with Studio for ASAP
1-5

12.
Configuring Activation Service Cartridges
The procedure below, with links to detailed topics, outlines the basic steps you need to
follow to configure an Activation Service cartridge.
To configure a service model cartridge
1.
Load the cartridges.
Import Activation Network cartridges (from a cartridge project, from a SAR file, or
from an environment) containing components you can use for your Service
cartridge. See Importing Cartridges from Cartridge Projects, Importing Cartridges
from SAR Files, and Importing Cartridges from Environments for more
information.
2.
Create an Activation Cartridge project and set up the Activation Service cartridge.
See Setting Up Activation Cartridges for more information.
a.
b.
3.
Create an Activation Service Cartridge project and display it in the Cartridge
view of the Design Perspective.
Configure the cartridge details in the Activation Service Cartridge editor.
Design the service model.
a.
Determine what type of service model you need. Options are:
The vendor, technology and software load-specific service model. See
Understanding Vendor, Technology, and Software Load-Specific Service
Models for more information.
The common service model. See Understanding Common Service Models for
more information.
The mixed service model. See Understanding Mixed Service Models for more
information.
b.
Create elements for the service model.
Service actions can be created with a wizard or with the Cartridge Generation
feature. You can create the necessary atomic actions with a wizard (this is
called a common service model) or use atomic actions from imported
Activation Network cartridges (this is called a mixed service model). See
Creating Model Elements and Generating Framework Models for more
information.
c.
Define the relationship between model elements by linking them manually
and defining their parameters.
See Understanding Model Element Relationships for more information.
4.
Extend the user-defined exit types.
See Configuring User Defined Exit Types for more information.
5.
Create custom action processors.
See Understanding Custom Action Processors for more information.
6.
Configure network elements.
a.
Define a network element.
A NE represents one specific piece of equipment (a single instance) in the
network. A connection pool contains one or more connections that can be use
to connect to the network element (possibly simultaneously). Each network
element has a single connection pool associated with it. See Understanding
Network Elements for more information.
1-6 Modeling Activation
Beta Draft

13.
Configuring Activation Service Cartridges
b.
Define a dynamic NE template.
If you do not intend to configure static network element instances for a
specific customer solution, you can configure dynamic NE templates to allow
network element attributes to be dynamically sent to A5 on work orders.
Dynamic NE templates are used when upstream systems (such as Inventory)
contain the necessary information to connect to the network element instance.
Passing this information to A5 dynamically avoids having to configure it in
multiple locations (for example, in A5 as well as in an inventory system). See
Creating NE Templates for more information.
7.
Package the cartridge.
See Packaging Activation Cartridge Implementations for more information.
a.
Model the package.
Use the Cartridge editor to specify which elements will be included in the
cartridge (SAR file). If the service model you have created depends upon
elements in an Activation Network cartridge it is also necessary to specify
which elements of the Activation Network cartridge should be deployed. Only
deploy those elements that are required in the dependent Activation Network
cartridges. For example, if you are not reusing the service actions and network
actions in an Activation Network cartridge, then deselect those elements.
b.
c.
Include JARs in the SAR.
d.
8.
Create the JAR with ANT.
Put external JARs in the NEP classpath on the ASAP server.
Deploy the cartridge.
See Deploying Cartridges and Managing the ASAP Environment for more
information.
a.
Create an Activation Environment project and an Activation environment in
the Cartridge view (use the corresponding wizards for both tasks).
b.
On the Connection Details tab of the Activation Environment editor, specify
how to connect to the ASAP environment.
c.
On the Connection Details tab of the Activation Environment editor, add
cartridges for deployment, deploy them to the environment, undeploy them
from the environment, and remove them from the list of cartridges that were
added for deployment.
d.
Use the NEP Map editor to deploy and manage network elements.
Related Topics
Getting Started with Studio for ASAP
Beta Draft
Getting Started with Studio for ASAP
1-7

15.
2
Creating Activation Cartridge Projects
2
Three types of Activation cartridges are supported in Studio:
■
■
■
Activation Network Cartridge projects, required for creation of an Activation
Network cartridge.
Activation Service Cartridge projects, required for creation of an Activation
Service cartridge.
Activation SRT Cartridge projects, required for creation of an Activation SRT
cartridge.
Additionally, an Activation Environment project is required for deployment of all
Activation cartridges.
Related Topics
Understanding Source Control
Understanding Activation Network Cartridges
Understanding Activation Service Cartridges
Setting Up Activation Cartridges
Understanding Cartridge Export
Importing Cartridges
Removing Cartridge Projects
Renaming Cartridge Projects
Understanding Activation SRT Cartridges
Understanding Source Control
Adding projects and other resources to source control enables you to track changes
and share work among team members. Cartridge developers can use source control
when building cartridges. Service modelers, once they have created the basic
framework for a customer-specific service model and are confident that no significant
changes need to be made, can place all elements in the cartridge under source control.
Studio supports both ClearCase and CVS for use as source
control. Refer to the Eclipse online Help for more information about
source control.
Note:
Beta Draft
Creating Activation Cartridge Projects 2-1

16.
Understanding Activation Network Cartridges
Related Topics
Creating Activation Cartridge Projects
Understanding Activation Network Cartridges
Cartridge developers can create new Activation Network cartridges in Studio to
support a single type of network equipment (for example, for a DMS-100 switch), or
import existing cartridges into Studio and modify them. You configure Activation
Network cartridges for a single vendor, technology, and software load. Typically, a
cartridge developer will deliver Activation Network cartridges to service modelers
and solution teams, who use the Activation Network cartridge components to create
customer-specific service models.
Related Topics
Creating Activation Cartridge Projects
Understanding Activation Service Cartridges
Service modelers develop Activation Service cartridges to create a service model that
can activate services on different types of network equipment, as the service actions
and network actions within the Activation Service cartridge may be missing one or
more of the vendor, technology and software load tokens. Modelers can use elements
of Activation Network cartridges in Activation Service cartridges for implementation
when creating common service models. Service modelers purchase and then import
Activation Network cartridges, to build one or more Activation Service cartridges that
link down into components within network cartridges and that are specific to an
offered service. Service cartridges incorporate the many different types of equipment
used to set up and provide telephony services.
You can use Activation Service cartridges to create customer-specific service models.
These cartridges can contain customer-specific service modeling elements as well as
links to elements in other cartridges. While an Activation Network cartridge always
has the three associated attributes (a vendor, such as Ericsson; a technology, such as
DMS; and a software load, which references the release number), an Activation Service
cartridge does not necessarily contain all these attributes. Activation Service cartridges
have elements that generally span multiple types of vendor equipment, can run
multiple software loads, and may or may not include one or more of the Activation
Network cartridge attributes.
When creating an Activation Service cartridge, there are two required attributes that
you must specify: a service attribute (for example, Prepaid) and a Domain attribute
(for example, Mobile).
Related Topics
Creating Activation Cartridge Projects
Setting Up Activation Cartridges
You use the New Studio Activation Cartridge Project wizard to set up Activation
Network and Activation Service cartridge projects and to specify cartridge attributes
(vendor, technology, and software load). After you create the cartridge project, you can
add additional details using the Cartridge editor.
To create Activation Cartridge projects
2-2 Modeling Activation
Beta Draft

17.
Understanding Cartridge Export
1.
From the main menu, select Studio, Show Design Perspective.
2.
In the Design perspective, right-click in the Cartridge view and select New,
Activation Cartridge Project.
Alternately, from the main menu select Studio, New, Activation Cartridge Project.
The New Studio Activation Cartridge Project wizard appears, displaying the
Activation Cartridge Info dialog.
3.
Enter a name for the project.
4.
Accept the default location or browse for another location.
5.
In Studio Settings, select Activation Network Cartridge or Activation Service
Cartridge, as appropriate.
6.
Select the appropriate ASAP version, and enter the package name.
7.
Click Next.
The Cartridge Details dialog appears.
8.
For Activation Network Cartridge projects, specify the vendor, technology and
software load attributes for the cartridge.
When specifying vendors, for example, you might use its stock symbol, such as
ERIC (for Ericsson). Examples of technology include HLR (home location register)
and DMS (digital multiplex system). You might represent software loads with he
release number and dash combination, such as R11-0.
9.
For Activation Service Cartridge projects, specify the service and domain
attributes for the cartridge.
Examples of services:
Service: Prepaid Domain: Mobile Service: Postpaid Domain: Mobile Service:
Residential Domain: POTS Service: VPN Domain: IP
10. Click Finish to complete the cartridge project.
Or, click Next to change the Java configuration in the Java Settings dialog. For
example, you can add libraries in the Libraries tab (you can decide to change the
configuration later).
If you modified the Java settings, click Finish to save changes and complete the
Cartridge project.
A new Activation Network Cartridge or Activation Service Cartridge project
appears in the Cartridge view. The project contains an entity that represents the
network cartridge and also has a Documentation group (which provides access to
the Cartridge Guide generation feature for documenting the completed cartridge).
See Documenting Cartridges for more information.
Related Topics
Creating Activation Cartridge Projects
Understanding Cartridge Export
To export cartridges from a workspace, zip up the cartridge projects (into zip or TAR
files) and export the files to an archive file. Users can then import the cartridges from
these cartridge projects to their workspace. Importing from a cartridge project is a
more powerful way of importing data into studio because it is possible to obtain an
entire workspace, including one or more environments as well as one or more SAR
Beta Draft
Creating Activation Cartridge Projects 2-3

18.
Importing Cartridges
files. This approach is useful when working with projects that contain complex
configurations with multiple dependencies between cartridges (for example, one or
more Activation Service Cartridges that depend on one or more Activation Network
Cartridges).
In a team, a workspace should only get set up once (at the
beginning of the project) by one person, and then everybody shares
this workspace.
Note:
When importing a project, Studio recreates the workspace as it was originally created,
including any custom artifacts. Alternately, you can manually recreate the
configuration by individually importing each of the SAR files corresponding to the
original cartridges. However, there is a potential for data loss as not all artifacts
(custom ones you have created) will have been captured within the SAR file when it
was originally created.
Currently, the way Activation Network Cartridges are
obtained from Oracle is by retrieving individual SAR files from the
portal and loading them into Studio. This approach is sufficient as
there are no dependencies between such cartridges (each cartridge is
self-contained).
Note:
Related Topics
Exporting Cartridges
Creating Activation Cartridge Projects
Exporting Cartridges
To export cartridges from the Studio workspace
1.
From the main menu, select File, Export to open the Export-Select dialog.
2.
Select General, Archive File.
3.
Click Next.
The Export-Archive File dialog opens.
4.
In the Export-Archive File dialog, select the projects and items you want to export.
Select your options, and click Browse to specify the location of the new archive file
that will contain your zipped projects.
5.
Click Finish to start the export.
The zipped archive file appears in the specified location.
Related Topics
Understanding Cartridge Export
Creating Activation Cartridge Projects
Importing Cartridges
The import functions are used to import data from an external source into your Studio
workspace. For example, if you have purchased cartridges from Oracle, you can
2-4 Modeling Activation
Beta Draft

19.
Importing Cartridges
import them into Studio and reuse their components when you build Activation
Service cartridges. Additionally, if an Activation Service cartridge has already been
created by a co-worker, you can obtain the configuration by importing it into your
Studio workspace. Lastly, you can load data directly from an ASAP environment. This
approach is useful when you want to obtain a complete snapshot of all the data in an
ASAP environment.
You can use the following methods to import data into your Studio workspace:
■
■
■
Import from a cartridge project. See Importing Cartridges from Cartridge Projects
for more information.
Import from a SAR file. See Importing Cartridges from SAR Files for more
information.
Import from an ASAP environment. See Importing Cartridges from Environments
for more information.
You import Activation Network cartridges (from a location outside of your
workspace) to set up your workspace. Cartridges can be imported in a zipped (zip or
TAR files) or unzipped format.
Service modelers can import several network cartridges into the workspace to utilize
their components (such as atomic actions, action processors, and NE templates) when
setting up Activation Service cartridges. Service modelers can also import a suitable
service cartridge as a starting point and modify it as needed.
Cartridge developers can import one or more network cartridges into their workspace
(instead of building them from scratch) to use as starting point for creating new
cartridges (for example, to make minor changes to cartridges for the next release) or to
compare with other cartridges. See Setting Up Activation Cartridges for more
information about creating new cartridges.
To import cartridges into your workspace, you can zip up
cartridge projects in ZIP or TAR format and export them to an archive
file. This method produces a snapshot of the entire workspace as
originally created (including one or multiple environments and SAR
file) and includes any custom artifacts.
Note:
This method is useful when you have a project that contains a
complex configuration with multiple dependencies between
cartridges (for example, one or more Activation Service cartridges that
depend on one or more Activation Network cartridges).
While it is possible to manually recreate the configuration by
importing each of the SAR files from the original cartridges, some data
loss may occur if you have custom artifacts that were not included in
the original SAR file.
To obtain Activation Network cartridges from Oracle, you can
retrieve individual SAR files from the portal and import them into
Studio. Each cartridge is self-contained (no dependencies exists).
Note:
Related Topics
Understanding Sealed Cartridges
Understanding Cartridge Read-Only Status
Beta Draft
Creating Activation Cartridge Projects 2-5

20.
Importing Cartridges
Importing Cartridges from Cartridge Projects
Importing Cartridges from SAR Files
Importing Cartridges from Environments
Activation Cartridge Editor
Creating Activation Cartridge Projects
Understanding Sealed Cartridges
After importing a cartridge, the cartridge is marked as Sealed in your Studio view. The
cartridge is sealed to preserve its integrity during the import.
To rebuild the imported cartridge (and obtain a new SAR file before deploying), you
must unseal the cartridge. On the Cartridge Details tab of the Cartridge editor, click
Unseal and confirm that you want to unseal the cartridge by clicking Yes when
prompted.
Related Topics
Importing Cartridges
Creating Activation Cartridge Projects
Understanding Cartridge Read-Only Status
Studio imports all files as read-only, and enables you to make change to cartridges
shipped as product in a separate Activation Network or Activation Service cartridge,
providing you with a clean separation between your shipped and custom cartridges.
Maintaining this separation enables you save time when downloading eFixes and
upgrades for the core cartridge.
You can change the file properties of shipped cartridges to
read-write, but this is not recommended. Additionally, it is
recommended that you maintain a separation between shipped and
customized cartridges if you intend to customize cartridge source
code.
Note:
Customizing Cartridges
To customize a cartridge, create a second cartridge in Studio with the same
vendor/technology/software load (or, create a service cartridge if you do not want to
specify these settings) and place all the customizations in this second cartridge. The
new cartridge extends the productized version, and can reference entities in the
productized cartridge and there are facilities built into Studio that enable your atomic
actions to obtain parameters from the productized cartridge. Additionally, you can
copy and paste the service actions and atomic actions into the extension cartridge.
When and upgrade or eFix to the cartridge is available, you can replace the cartridge
project if the new version of the core cartridge affects your extensions (for example, if
there are new required parameters or if names have changed on parameters). In
addition, on the server you can redeploy just the eFixed cartridge without changing
your extensions.
2-6 Modeling Activation
Beta Draft

21.
Importing Cartridges
Changing the Read-Only Status on Cartridges
If you intend to define the files in your productized cartridge as read-write on
Windows XP), navigate to the root folder of the project and set the read-only attribute
to false recursively. This sets all the read-only attributes to false.
If you are not using Windows XP, you can use the attrib command from a command
prompt. Refresh the project (select it and use the F5 key, or use the File menu
command) and then make your changes.
Note: This method is not recommended and is not advisable if you
are using source control for your project.
Related Topics
Importing Cartridges
Creating Activation Cartridge Projects
Importing Cartridges from Cartridge Projects
To import cartridges into your workspace, you can zip up cartridge projects in ZIP or
TAR format and export them to an archive file. This method produces a snapshot of
the entire workspace as originally created (including one or multiple environments
and SAR file) and includes any custom artifacts.
You can import cartridges from a cartridge project into studio to obtain an entire
workspace, including one or multiple environments and SAR files. This method is
useful when you have a project that contains a complex configuration with multiple
dependencies between cartridges (for example, one or more Activation Service
cartridges that depend on one or more Activation Network cartridges).
To import a cartridge from a cartridge project
1.
From the main menu bar, select File, Import to open the Import-Select dialog.
2.
Select General, Existing Project into Workspace and click Next to open the Import
Projects dialog.
3.
Depending on where the project is located, select Select root directory or Select
archive file.
4.
Click Browse to locate the directory or file containing the projects.
5.
Select the projects to import.
6.
Click Finish to start the import.
The projects all appear in your workspace.
Before working with an imported cartridge, refer to the About
Cartridge Import topic for more information about read-only statuses
and working with sealed and unsealed cartridges.
Note:
Related Topics
Importing Cartridges
Creating Activation Cartridge Projects
Beta Draft
Creating Activation Cartridge Projects 2-7

22.
Importing Cartridges
Importing Cartridges from SAR Files
A SAR file is one method for storing an ASAP configuration within a single artifact.
Import cartridges from SAR files when you want to load into Studio cartridges that
have been packaged in a SAR file. For example, when new Oracle Activation Network
cartridges are available, they are packaged into a SAR file and posted to the portal in a
zipped format (TAR file) for download. You can download the TAR file, then extract
the SAR file from the TAR file.
Additionally, when you create a new Activation Service cartridge, Studio
automatically generates a SAR file. When you have finished creating the service
model, you can email the SAR file to another Studio user for import or check it into a
source control system.
To import a cartridge from a SAR file
1.
Right-click in the Studio view of the Design perspective and click Import
Activation Archive.
Alternately, from the main menu select File, Import to display the Import-Select
dialog, then select Studio Wizards, Activation Archive (SAR) and click Next. The
Activation Archive Import wizard appears in both cases.
2.
In the Activation Archive Import wizard, click Browse to search for a suitable SAR
file that contains the network cartridge you need to create your service cartridge.
After you select a SAR file, the fields in the wizard populate automatically for
your cartridge.
Cartridges that were created in Studio populate the Cartridge
Type field automatically with the correct type (this is a non-editable
field). For cartridges not created in Studio, you must select the type of
cartridge you are importing.
Note:
3.
Click Finish to start the import.
A new Activation Service Cartridge project appears in the Studio view.
Before working with an imported cartridge, refer to the About
Cartridge Import topic for more information about read-only statuses
and working with sealed and unsealed cartridges.
Note:
Related Topics
Importing Cartridges
Creating Activation Cartridge Projects
Importing Cartridges from Environments
If you have an existing ASAP implementation, you can point Studio at an ASAP
environment and import the configuration (service model, JAR files, and network
elements) contained in that environment. This feature eliminates the need to manually
run scripts that extract data from an environment into a SAR file and import that SAR
file into Studio.
You can use this feature to obtain a snapshot of an environment configured from
multiple sources, such as insert scripts, XML, or multiple Studio instances. In this
2-8 Modeling Activation
Beta Draft

23.
Importing Cartridges
scenario, it is possible to load the service model and network element configuration
into Studio directly from an ASAP environment.
Additionally, importing from an existing ASAP environment is useful when you have
just begun using Studio as a service modeling tool and you have an existing ASAP
implementation.
To import a cartridge from an environment
1.
From main menu, select File, Import.
The Import dialog box appears.
2.
Expand the Studio Wizards directory.
3.
From Environment, select Activation Project.
4.
Click Next.
The Activation Environment Import wizard appears.
5.
Select an environment connection method.
Select Get connection info from Activation Environment Editor and select an
Activation environment from the corresponding list if you want to obtain the
necessary connection information from an existing environment object.
Select Specify connection information below if you have not yet created an
appropriate Activation Environment editor, or if you are importing from an ASAP
5.2.4 environment (Activation Environment editor supports up to ASAP 5.2.3).
When you select this option, you must also populate the corresponding fields with
connection information. See Creating Activation Environment Projects for
information about creating and configuring ASAP connection details.
6.
Click Next after you have specified all of the connection information.
Enter the user name and password in the login dialog to connect to the ASAP JMX
service. If the system is able to successfully connect, the system prompts you to
enter the project name.
7.
Click Finish to import the environment project.
Related Topics
Importing Cartridges
Creating Activation Cartridge Projects
Activation Cartridge Editor
After creating Activation Cartridge project, you can configure the cartridge
specifications and parameters in the tabs of the Cartridge editor (click the Activation
Cartridge entity icon in the Cartridge view to display the Cartridge editor).
Table 2–1
Activation Editor Tab Overview
Editor Tab
Description
Blueprint
Read-only. Displays the generated documentation of the project,
including cartridge properties, service actions, atomic actions,
action processors, connection handlers, and network element
configuration (for network cartridges) or service configuration
(for service cartridges).
Cartridge Details
Displays cartridge properties (the build number increases
automatically every time you save) and network element details.
Beta Draft
Creating Activation Cartridge Projects 2-9

24.
Importing Cartridges
Table 2–1 (Cont.) Activation Editor Tab Overview
Editor Tab
Description
Cartridge Layout
For network cartridge, this tab enables you to generate a
framework model, which creates the service action, atomic
action and action processor for any combination of action and
entity and creates the appropriate association for the three
elements in a 1:1:1 relationship. See Generating Framework
Models for more information about framework models.
For service cartridges, this tab enables you to generate service
actions. You can create a service model that is appropriate for a
specific customer.
Packaging
Enables you to specify which elements to include in the
cartridge SAR file. See Packaging Activation Cartridge
Implementations for more information about packaging.
For service cartridges, usually all elements are deployed.
Locations
Displays where items get stored. In the Target Platform section,
you can change the ASAP version by selecting predefined ASAP
versions or by entering new version numbers.
Testing
Enables you to view ASAP test cases that you created for your
projects and enables you to run them individually or
simultaneously.
If you change the ASAP version in the Locations tab to a
version different than the version you selected during cartridge
project creation, you must also update all dependent JAR files, such as
asapcommonlib.jar, JInterp.jar, Studio_2_6_0.jar, and any other
related JAR files. These files are required when the cartridge depends
on third-party libraries. Additionally, you must delete any generated
code. Lastly, you must perform a clean and full build to regenerate the
code.
Note:
Studio uses the default implementation package name as a
prefix for generated code. It is recommended that you accept defaults
and follow recommended naming conventions for all entities that you
create.
Note:
Network elements and environments for ASAP are not
defined inside Activation Cartridge projects. Only those items that are
bundled for deliver included in the cartridge project.
Note:
Activation cartridge projects are also Java projects (builds on
functionality of Java project). Java development can be done inside
Activation Cartridge projects; you do not need a separate Java project
for development.
Eclipse online documentation for Java projects and its
configurations, properties, and settings also applies to the Java
configuration of an Activation Cartridge project. Refer to the Eclipse
online documentation when setting up a cartridge.
Note:
2-10 Modeling Activation
Beta Draft

25.
Renaming Cartridge Projects
Related Topics
Importing Cartridges
Creating Activation Cartridge Projects
Removing Cartridge Projects
You can remove a cartridges from Studio when you no longer need it them.
To remove a cartridge project
1.
Select the project (representing the cartridge) from the Cartridge view of the
Studio Design perspective or from the Package Explorer view of the Java
perspective.
2.
From the main menu, select Edit, Delete.
Alternately, you can right-click on the project and select Delete.
The Confirm Project Delete dialog appears and prompts you to confirm the project
deletion.
3.
Select the method of deletion.
■
■
4.
Select Do not delete contents to remove the cartridge from your workspace
without deleting the content from the file system.
Select Also delete contents under pathname to erase the cartridge from the
file system completely (in which case it will no longer appear in your
workspace).
Click Yes to delete the project from your workspace.
Or, click No if you do not want to delete the project at this time.
Related Topics
Creating Activation Cartridge Projects
Renaming Cartridge Projects
You can rename a cartridge project to create a new version.
To rename a project
1.
From the main menu, select Window, Open Perspective, Java.
2.
In the Package Explorer view, right-click a project to access the context menu.
3.
Select Refactor, Rename.
Follow the instructions to rename the project.
4.
From the main menu, select Studio, Show Design Perspective.
5.
In the Cartridge view, right-click the project's cartridge icon and select Rename.
Change the cartridge name to the same name you gave the project in the other
view.
6.
Restart Studio to refresh all cached information
Related Topics
Creating Activation Cartridge Projects
Beta Draft
Creating Activation Cartridge Projects 2-11

27.
3
Modeling ASAP Services
3
When configuring Activation cartridges, you must first create model elements.
Elements used in modeling services are:
■
Atomic actions.
■
Service actions.
■
Action processors.
Additionally, you must define relationship parameters for the atomic actions, service
actions, and action processors, and then associate these three elements. The Cartridge
Generation feature expedites and simplifies these steps by automatically generating a
framework model.
The steps you take to model services for an Activation cartridge depend on the type of
cartridge (Activation Network or Activation Service cartridge) and, when modeling
Activation Service cartridges, the type of model (mixed or common).
After you model a service, complete the parameter descriptions for entities by opening
each editor and providing data (for example, open the Cartridge editor to configure
the cartridge and its elements). Also, complete any documentation information that
needs to be included in the cartridge auto-generated documentation.
Related Topics
Modeling Services for Activation Network Cartridge
Modeling Services for Activation Service Cartridges using a Common Service Model
Modeling Services for Activation Service Cartridges using a Mixed Service Model
Understanding Vendor, Technology, and Software Load-Specific Service Models
Understanding Common Service Models
Understanding Mixed Service Models
Creating Model Elements
Understanding Model Element Relationships
Configuring Element Properties
Generating Framework Models
Documenting Models
Beta Draft
Modeling ASAP Services
3-1

28.
Modeling Services for Activation Network Cartridge
Modeling Services for Activation Network Cartridge
The following steps describe how to model services for an Activation Network
cartridge.
To model services within an Activation Network cartridge
1.
Create service actions (with the vendor, technology, and software load tokens).
2.
Create atomic actions (with the vendor, technology, and software load tokens).
3.
Create action processors.
4.
Create Java methods.
5.
Associate elements (service actions, atomic actions, action processors, Java
methods in a 1:1:1 relationship).
While creating and associating these elements can be done
manually, it is more common to use the Cartridge Generation feature
for Activation Network cartridges. See Generating Framework Models
for more information.
Note:
Related Topics
Modeling ASAP Services
Modeling Services for Activation Service Cartridges using a Common
Service Model
The following steps describe how to model services for Activation Service cartridges
that use a common service model.
To model services for Activation Service cartridges that use a common service model
1.
Create service actions (common).
2.
Create common atomic actions.
3.
Associate service actions, atomic actions and action processors from Activation
Network cartridges in a 1:many:many relationship (action processors are already
linked to Java methods).
Related Topics
Modeling ASAP Services
Modeling Services for Activation Service Cartridges using a Mixed
Service Model
The following steps describe how to model services for Activation Service cartridges
that use a mixed service model.
To Model Services for Activation Service Cartridges that Use a Mixed Service Model
1.
Create service actions (common).
2.
Associate service actions to atomic actions from Activation Network cartridges in
a 1:many:1 relationship (atomic actions from Activation Network cartridges are
already linked to action processors and Java methods).
3-2 Modeling Activation
Beta Draft

29.
Understanding Vendor, Technology, and Software Load-Specific Service Models
Note: Using the Cartridge Generation feature, you can generate only
service actions, you must select which atomic actions (one or possibly
more) will be associated with the service actions in the cartridge.
You may need to create (for all types of Activation Service
cartridges), customized action processors and Java methods to
implement solution- specific behavior. See Creating Custom Action
Processors for more information.
Note:
Related Topics
Modeling ASAP Services
Understanding 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 contain 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 diagram:
Example 3–1 Service Model Relationship Example
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
Figure 3–1 Service Model Relationship Example
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 ASAP service model and requires less service modeling work within
ASAP in the short term. However, it also forces upstream systems, which will be
Beta Draft
Modeling ASAP Services
3-3

30.
Understanding Common Service Models
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.
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.
Note:
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.
Related Topics
Modeling ASAP Services
Understanding Common Service Models
Common service actions are most often associated with common atomic actions to
create a consistently abstract service model (both service actions and atomic actions are
common). In common service models one or more of the vendor, technology, and
software load attributes are left out of the names of both service actions and atomic
actions to indicate that they may be used to activate services on equipment from
multiple vendors. ASAP has a built-in mechanism to map common atomic actions to a
specific vendor, technology, and software load implementation based on the vendor,
technology, and software load of the network element on which the service is being
activated (see tbl_nep_atomic action_prog for mapping details). The following
example shows a common service that adds a subscriber regardless of whether it is a
Nortel DMS 100 (POTS) or a Nortel CS2K (VoIP):
3-4 Modeling Activation
Beta Draft

31.
Understanding Common Service Models
C_ADD_SUB --> A_ADD_SUB
Figure 3–2 Common Service for Adding Subscribers
Common service actions map to one or more common atomic actions (both shown in
blue). The atomic actions map to multiple vendor, technology, and software
load-specific implementations allowing for multiple technologies to be activated. The
common atomic actions may simply be a renaming of the cartridge atomic actions to
exclude one or more of the vendor, technology, software load attributes. In some cases,
when a common service model is implemented in which many similar atomic actions
across various network elements are required, the technology token must be
maintained in the atomic actions to distinguish between the types technologies being
activated.
Consider use of common service actions with common atomic actions when:
■
■
■
There exists a subscriber and service oriented domain where services are
implemented uniformly across vendor equipment. Similar activation steps are
used to activate similar services uniformly across different vendor equipment.
Changes may occur to the types of vendor equipment in the network or there is
significant churn in the software loads. Limited change to the service model is
desired despite changes to the network equipment.
Inventory systems containing information about the equipment in the network are
not available, or little information about the network is stored in upstream
systems.
Common Service Model Example
The following wireless example demonstrates how a GSM subscriber is activated on
the authentication center (AUC), flexible number routing NE (FNR), voice mail server
(VMS) and home location register (HLR). This service model can be implemented to
support technologies from many different vendors (for example, Nokia AUC, Ericsson
AUC, etc.):
Example 3–2 Common Service Model Wireless Example
C_ADD_GSM-SUBSCRIBER -->
A_AUC_ADD_SUB
A_FNR_ADD_SUB
A_VMS_ADD_SUB
A_HLR_ADD_SUB
Beta Draft
Modeling ASAP Services
3-5

32.
Understanding Common Service Models
Common Service Model Challenges
Consider the following challenges when implementing a common service model:
■
■
Different activation steps are required even when implementing simple subscriber
oriented features.
Significant parameter deltas can exist for similar services. For example, one service
may require that you configure a subscriber by assigning a preconfigured profile
to a subscriber on one network element (which is identified by its profile name);
another may require that you configure a subscriber on a network element by
passing all the details of the subscriber and services. In this case the atomic action
parameters sets are dissimilar.
The following diagram shows an example of the some of the complications that can be
involved in using a common service model even when the activating simple services.
This example illustrates how to add a feature to a subscriber on an Ericsson HLR by
first adding and then activating the feature (these are implemented as separate atomic
actions); meanwhile, adding a feature on the Nortel HLR is a single atomic action. In
order for a common service model to work in this case, you must configure spawning
logic on the activate atomic action so that it does not execute when activating services
on the Nortel HLR. The diagram also shows that PARM C is needed only when
activating a service on the Nortel HLR. Therefore, it must be made optional so that a
failure of the atomic action does not result when activating services on the Ericsson
HLR (in which case PARM C will not be present on the work order).
Figure 3–3 Common Service Model Challenges Example
While it is ideal to use a common service model, multiple
service activation differences on different vendor equipment often
result in increased maintenance, complicated spawning logic, and
numerous atomic actions per service action if using this method. In
such cases, consider implementing logic upstream to select the correct
vendor, technology, and software load-specific service actions.
Note:
Related Topics
Modeling ASAP Services
3-6 Modeling Activation
Beta Draft

33.
Creating Model Elements
Understanding Mixed Service Models
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
Figure 3–4 Mixed Service Model Example
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.
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.
Note:
Related Topics
Modeling ASAP Services
Creating Model Elements
You can use atomic action, service action, and action processor elements when
modeling services for an Activation Cartridge project.
Beta Draft
Modeling ASAP Services
3-7

34.
Creating Model Elements
Follow the steps in this procedure to create elements for
Activation Service cartridges. After you create the elements, you must
link the elements manually. Elements for Activation Network
cartridges are usually created and linked with the Cartridge
Generation feature.
Note:
To create an action element
1.
From the main menu, select Studio, Show Design Perspective.
2.
Right-click in the Cartridge view and select New.
Select the type of action you want to create.
Alternately, from the main menu select Studio, New. The Studio Model Entity
wizard appears.
The vendor, technology, software load fields of the wizards are
non-editable for elements of Activation Network cartridges, but are
writable for those of Activation Service cartridges. Activation Service
cartridges may contain different types of service models, some of
which do not identify a specific vendor, technology, or software-load
attribute to indicate that they may be used to activate services on
equipment from multiple vendors.
Note:
3.
Select the applicable project.
4.
Enter an action or select a previously defined action from the list (for example,
ADD, MOD, DEL, or QUERY).
5.
Enter a name for the entity (for example, SUBSCRIBER, GSM-SUBSCRIBER,
ROUTE, TRUNK, or LINE).
An updated name and a location name appears in non-editable fields based on the
information in the Vendor, Technology, Software Load, Action, and Entity fields.
6.
To manually edit the name and browse for a location, deselect the Use
recommended name and location option.
7.
Click Finish.
The new action entity appears in the Project folder in the Cartridge view.
You must correct any problem markers on any entities before
you deploy the cartridge. Refer to the Problems view for a short
description of existing problems. For best results, set the Problem view
filter to On selected element and its children to view problems in
their full context.
Note:
If problem markers seem invalid (for example, if they continue to
reappear after you fix the problem in the configuration), you can
usually remove these problems by selecting Project, Clean from the
main menu. Select one or all listed projects and click OK. Studio
discards all build problems and build states of the selected projects
and rebuilds the projects from scratch.
3-8 Modeling Activation
Beta Draft

35.
Understanding Model Element Relationships
Related Topics
Understanding Activation Network Cartridges
Understanding Activation Service Cartridges
Generating Framework Models
Modeling ASAP Services
Understanding Model Element Relationships
After you have created the three types of elements required for modeling (service
actions, action processors and atomic actions), you can define their relationship by
linking them. For Activation Network cartridges, the three types of elements are
generally in a 1:1:1 relationship. For Activation Service cartridges, the three types of
elements are most commonly linked in a 1:1:many or 1:many:many relationship.
For more information about service models, see Modeling ASAP Services.
In most cases, you will not use the service models created for
Activation Network cartridges in customer specific solutions. For
Activation Network cartridges, these elements mainly provide a
complete service model that can be used to test the cartridge action
processors upon cartridge delivery.
Note:
About Activation Network Cartridge Relationships
For fast and convenient modeling of Activation Network cartridges, use the Cartridge
Generation feature to generate the three element types for any combination of action
and entity and to map them in the appropriate 1:1:1 relationship. See Generating
Framework Models for information about the Cartridge Generation feature.
About Activation Service Cartridge Relationships
For Activation Service cartridges, you can use the Cartridge Generation feature only to
generate service actions (the Cartridge Generation feature cannot determine which
atomic actions (one or possibly more) must be spawned for each service action). To
obtain the necessary atomic actions and action processors, you either create these with
element wizards, or utilize appropriate ones from imported Activation Network
cartridges. You then map each service action to several atomic actions, each of which
need to be mapped to one or more action processors (1:1:many or 1:many:many
relationship).
An atomic action from an imported cartridge is already
mapped to one action processor. If you reuse the atomic action from
the cartridge, do not change this mapping and do not map additional
action processors to the atomic action. An atomic action that you
create is not yet linked to other elements (service actions and action
processors) and therefore always needs to be mapped. To link
elements (action processors to atomic actions, and atomic actions to
service actions), drag an element from the Studio view to the mapping
tab in the editor of the element to which you want to link. For
example, select an action processor from a cartridge in your Studio
view, then drag the action to the Action Processor Mapping tab in the
editor of the appropriate atomic action. Similarly, you can drag atomic
actions to the Atomic Action tab of a Service Action editor.
Note:
Beta Draft
Modeling ASAP Services
3-9

36.
Understanding Model Element Relationships
Related Topics
Modeling Services Example 1
Modeling Services Example 2
Creating Model Elements
Importing Cartridges
Modeling ASAP Services
Modeling Services Example 1
In this example, you model a service to create a postpaid mobile subscriber with the
following constraints:
■
■
■
Only Ericsson Home Location Registers (HLRs) are used, but there are multiple
software loads present in the network for this NE type (release 11-0 and release
12-0).
Each time a subscriber is added, the subscriber must also be added to the Flexible
Number Register (FNR) for number portability purposes.
Only Ericsson FNRs are used, but there are multiple software loads present in the
network for this NE type (release 8-0 and release 9-1).
Given these constraint, you determine that an activation network service model is
inappropriate and decide to implement a common service model, as there are multiple
software loads and technologies involved.
When different vendors exist in the network, it may not be
possible to use a common software load. See Understanding Common
Service Models for information about advantages and disadvantages
of using a common service model. Additionally, refer to Modeling
Services Example 2.
Note:
To model a service to create a postpaid mobile subscriber
1.
Import the required cartridges:
■
■
Ericsson HLR R12-0
■
Ericsson FNR R8-0
■
2.
Ericsson HLR R11-0
Ericsson FNR R9-1
Create a common service action that is vendor, technology, software load agnostic.
This service action will be required to activate services on different vendor
equipment (Ericsson HLR and Ericsson FNR) running different software loads
(multiple software loads for each technology):
C_CREATE_POSTPAID-SUBS
3.
Create common atomic actions for the Ericsson HLR and Ericsson FNR to create
the subscriber.
These should be software load agnostic to take advantage of the fact that there is
only one vendor with the need to support multiple software loads:
■
3-10 Modeling Activation
A_ERIC-HLR_CREATE_SUBSCRIBER
Beta Draft

37.
Understanding Model Element Relationships
■
4.
A_ERIC-FNR_CREATE_SUBSCRIBER
Drag the action processors (from the imported cartridges) to the common atomic
actions.
By reusing cartridge action processors, the parameters for the atomic action will be
automatically generated:
A_ERIC-HLR_CREATE_SUSBSCRIBER -> I_ERIC-HLR_R11-0_CREATE_SUBSCRIPTION
A_ERIC-HLR_CREATE_SUSBSCRIBER -> I_ERIC-HLR_R12-0_CREATE_SUBSCRIPTION
A_ERIC-FNR_CREATE_SUBSCRIBER -> I_ERIC-FNR_R8-0_ADD_FNF-SUBSCRIBER
A_ERIC-FNR_CREATE_SUBSCRIBER -> I_ERIC-FNR_R9-1_ADD_FNF-SUBSCRIBER
5.
Drag each of the common atomic actions you have created onto the common
service action you have created to link all elements together:
C_CREATE_POSTPAID-SUBS -> A_ERIC-HLR_CREATE_SUSBSCRIBER
C_CREATE_POSTPAID-SUBS -> A_ERIC-FNR_CREATE_SUSBSCRIBER
The linked elements should now appear in the Relation Graph view:
Figure 3–5 Relation Graph View
If the customer has additional software loads to support in the
future, these can be added by dragging the action processors to the
atomic actions (the parameter set is rationalized automatically but
should be verified manually to ensure accuracy of parameter
attributes).
Note:
Related Topics
Understanding Model Element Relationships
About the Relation Graph View
Modeling ASAP Services
Beta Draft
Modeling ASAP Services 3-11

38.
Understanding Model Element Relationships
Modeling Services Example 2
In this example, you model a service to create a PSTN subscriber with the following
constraints:
■
■
There are two vendors, Lucent 5ESS and Nortel DMS 100.
There is currently only one software load in the network for each (16 and SN06,
respectively).
Given these constraints, you determine that it may be too challenging to use an
exclusively common service model if the atomic action from each cartridge is different
(for example, if the action contains different parameters sets). One possible way to
model this is to use a common service action but reuse the atomic actions from the
cartridges.
To model a service to create a PSTN subscriber
1.
Import the required cartridges:
■
■
2.
Lucent 5ESS 16
Nortel DMS 100 SN06
Create a common service action (vendor, technology, software load agnostic).
This service action will be required to activate services on different vendor
equipment (Lucent and Nortel):
C_ADD_PSTN-SUBS
3.
Drag the atomic actions from the cartridges to the service action you have just
created:
C_ADD_PSTN_SUBS -> A_NT-DMS100_SN06_ADD_LINE
C_ADD_PSTN_SUBS -> A_LU-5ESS_16_ADD_POTS-LINE
The linked elements now appear in the Relation Graph view:
Figure 3–6 Relation Graph View
4.
Create the appropriate spawning logic using the vendor, technology, and software
load to ensure the correct atomic action runs for each work order.
3-12 Modeling Activation
Beta Draft

39.
Configuring Element Properties
Alternately, you could implement this service model using
logic in the SRT component to execute the correct vendor specific
service model, as this configuration has performance inefficiencies
due to the need for conditional spawning logic. Moreover, the
configuration has complexities that are introduced into the service
model when multiple software loads require support (for example, a
dedicated atomic action is required for each).
Note:
Related Topics
Understanding Model Element Relationships
About the Relation Graph View
Modeling ASAP Services
Configuring Element Properties
After defining the element relationships, you need to define the properties and
parameters for the linked elements in their respective editors (you can also do this
before linking the elements).
To access the editors, double-click the entity in the Cartridge view.
Note: You can maximize the editor view to see all editor content by
double-clicking the view's title bar.
If you create compound parameters, it is recommended to
define the members for every compound parameter. This is beneficial
once the code is generated during implementation. Ensure your
parameters are valid Java parameters. See Understanding Java with
Code Generation for more information.
Note:
Related Topics
Defining Action Processor Properties
Defining Atomic Action Properties
Defining Service Action Properties
Modeling ASAP Services
Defining Action Processor Properties
You can configure action processor properties using the Action Processor editor. To
access the editor, double-click an Action Processor entity in the Cartridge view.
To define properties and parameters for action processors
1.
Enter a description and select the type.
Java Action Processor (with Code Generation) is the default value.
2.
Depending on the type you selected, define the remaining parameters.
For example, if you select the Java Action Processor, define the class and method.
Beta Draft
Modeling ASAP Services 3-13

40.
Configuring Element Properties
3.
Click File, Save to save the changes.
Related Topics
Configuring Element Properties
Modeling ASAP Services
Defining Atomic Action Properties
You can configure atomic action properties using the Atomic Action editor. To access
the editor, double-click an Atomic Action entity in the Cartridge view.
To define properties and parameters for atomic actions
1.
Enter a description.
2.
In the Parameters tab, use the check boxes to select one or more Routing
Supports.
3.
In the Parameters tab, depending on the routing supports you selected, enter the
appropriate Parameter Details (Service Action Label and Atomic Action Label
are automatically defined).
For example, if you selected Dynamic Routing, enter a description and data
restrictions in the respective fields.
4.
For each compound parameter defined in the Parameters tab, identify the
compound parameter as multi-instance by checking the corresponding check box.
If the compound parameter will have only one instance, then the check box should
be unchecked.
See Understanding Java with Code Generation for more information about
compound parameters.
5.
In the Properties tab, use the check boxes to select one or more Atomic Action
Properties.
6.
If you select Rollback Atomic Action, click Select to display the Rollback Service
Selection dialog. Use this element selection dialog to select or create an atomic
action for rollback.
7.
To create an atomic action entity, on the Rollback Service Action Selection dialog,
do the following:
a.
Click New to open the Atomic Action Wizard.
b.
Enter an action or select a previously defined action from the list (for example,
ADD, MOD, DEL, or QUERY).
c.
Enter a name for the entity (for example, SUBSCRIBER, GSM-SUBSCRIBER,
ROUTE, TRUNK, or LINE).
d.
To manually edit the name of the entity and browse for a location, deselect
Use recommended name and location.
e.
Click Finish.
The new atomic action entity appears in the Atomic Actions folder in the
Cartridge view.
8.
Click File, Save to save the changes.
3-14 Modeling Activation
Beta Draft

41.
Generating Framework Models
Related Topics
Configuring Element Properties
Modeling ASAP Services
Defining Service Action Properties
You can configure service action properties using the Service Action editor. To access
the editor, double-click a Service Action entity in the Cartridge view.
1.
Enter a description.
2.
In the Properties tab, enter the level, use the check box to set rollback, and select or
type parameters for Service Action Completion Event and Service Action Failure
Event.
3.
If you have configured rollback for a service action, you can configure a Point of
No Return (PONR) for one of its associated atomic actions.
In the Atomic Actions tab, click in the Rollback Point column for the atomic action
that you want to set as PONR. From the list, select State or Stop
In addition to the default behavior of fully rolling back all
executed atomic actions (ASDLs) of a failed work order if rollback is
both configured and enabled, the Point of No Return (PONR) setting
enables you to specify a PONR for an individual atomic action of a
service action (CSDL). Depending on the setting you choose, this
either results in no rollback at all if the work order fails beyond this
point (if PONR is "Stop"), or results in a rollback to the PONR if the
work order fails beyond this point (if PONR is "State"). Only one
atomic action should be specified as a PONR, and a PONR can only be
specified if the service action has rollback enabled (the check box in
the Properties tab is checked).
Note:
4.
Click File, Save to save the changes.
Related Topics
Configuring Element Properties
Modeling ASAP Services
Generating Framework Models
To simplify and expedite the creation of cartridges, a Cartridge Generation feature is
available in Studio. The cartridge generation feature works differently depending on
the type of cartridge you are creating. For Activation Network cartridges, service
actions, atomic actions, and action processors are created and linked in a 1:1:1
relationship for all combinations of the actions and entities you specify. For an
Activation Service cartridges, only service actions are created, as the feature cannot
determine which atomic actions (one or possibly more) you want to associate with the
service actions in the cartridge you are creating. For Activation Service cartridges, a
decision must also be made about the type of service model you will create for the
customer (common, mixed or vendor/technology/software load-specific) which will
affect the naming convention used for the atomic actions.
Beta Draft
Modeling ASAP Services 3-15

42.
Generating Framework Models
Note: For Activation Service cartridges, you must create and
associate atomic actions with the service actions that you created with
the Cartridge Generation feature. For the atomic actions that you
create (regardless of the type of service model used), you can reuse the
action processors from cartridges. When using common atomic
actions (that you’ve created) you must manually link atomic actions
with action processors. If you are reusing atomic actions from
cartridges, the links between the atomic actions and action processors
will already exist.
To use the cartridge generation feature for generating a framework model of
Activation Network cartridges, you specify the actions that will be performed by the
cartridge (ADD, MOD, DEL, QUERY), and the entities on which these will be
performed (PORT, SUBSCRIBER, SUBSCRIPTION, LINE, etc.). Also, you enter
descriptions for the actions and entities, which are combined for each action and entity
combination (for example, add a single port on the device). After you have entered
this information into the Cartridge editor Cartridge Layout tab, you generate a
framework model by running the Cartridge Generation tool.
The Cartridge Generation tool does not overwrite a framework
that already exists. Rather, it adds to framework new and modified
actions and entities. Additionally, Studio does not delete old actions or
entities. You can however, delete them manually.
Note:
Related Topics
Generating Framework Models for Activation Network Cartridges
Generating Framework Models for Activation Services Cartridges
Understanding Common Service Models
Understanding Vendor, Technology, and Software Load-Specific Service Models
Understanding Mixed Service Models
Generating Framework Models for Activation Network Cartridges
You can use the Cartridge Generation tool to generate models for Activation Network
cartridges.
To Generate Framework Models for Activation Network Cartridges
1.
From the Cartridge view of the Studio Design perspective, double-click the
desired Activation Cartridge entity to open the Cartridge editor.
2.
Click the Cartridge Layout tab.
3.
In the Add area, click Add.
Studio prompts you to enter an action and description.
4.
In the Entity area, click Add.
Studio prompts you to enter an entity and description.
5.
Repeat steps 1 and 2 to add any additional action and entity combinations.
6.
Click Generate Cartridge.
3-16 Modeling Activation
Beta Draft

43.
Generating Framework Models
A dialog appears prompts you to confirm the generation.
7.
Click Yes.
Studio creates service actions, atomic actions, and action processors for all action
and entity combinations. The generated entities appear in the Cartridge view. You
can view the hierarchy and relationships in the Relation Graph view.
8.
To complete the modeling, adjust the properties and define parameters for the
atomic action.
9.
If necessary, add more elements to the model at a later time by repeating steps 1 to
6.
Related Topics
Generating Framework Models
Modeling ASAP Services
Generating Framework Models for Activation Services Cartridges
You can use the Cartridge Generation tool to generate models for Activation Service
cartridges.
To Generate Framework Models for Activation Service Cartridges
1.
From the Cartridge view of the Studio Design perspective, double-click the
desired Activation Service entity to open the Cartridge editor.
2.
Click the Cartridge Layout tab.
3.
In the Add area, click Add.
Studio prompts you to enter an action and description.
4.
In the Entity area, click Add.
Studio prompts you to enter an entity and description.
5.
Repeat steps 1 and 2 to add any additional action and entity combinations.
6.
Click Generate Cartridge.
A dialog appears prompts you to confirm the generation.
7.
Click Yes.
Studio creates service actions for all action and entity combinations. The generated
entities appear in the Cartridge view. You can view the hierarchy and relationships
in the Relation Graph view.
8.
Create or locate the appropriate atomic actions and link them to the generated
service actions.
If you use common atomic actions, link them to the action processors in the
Activation Network cartridges.
Related Topics
Generating Framework Models
Modeling ASAP Services
Beta Draft
Modeling ASAP Services 3-17

44.
Documenting Models
Documenting Models
Studio automatically generates documentation for Activation cartridge modeling in
HTML format and updates the documentation with each build. To access the
documentation within each of the editors, navigate to the Blueprint tab. The blueprint
displays documentation for the entity and provides links to the other entities.
There are some entities for which Studio does not generate documentation. You must
include text for the following:
■
■
■
■
For for each of the three modeling elements (service action, atomic action, and
action processor), you must define the Description field.
For the action processor, you must include documentation for commands used (in
the Command Overview), the output of the action processor (in the Output tab),
and comments (in the Development Notes tab).
For atomic actions, you must define the Data Restriction field, which enables you
to specify valid range and values for parameters within the atomic action.
For service actions, you must define any properties.
Related Topics
Modeling ASAP Services
3-18 Modeling Activation
Beta Draft

46.
Implementing the Action Processor
Understanding Java with Code Generation
The Java with code generation implementation for an action processor creates a Java
processor that composes messages to be sent to a device, evaluates the response for
errors, extracts output information from the response, and populates the information
into output parameters.
Figure 4–1 Java with Code Generation Flow
In the Java processor with code generation, the central class is the Processor, which is
editable by the developer. The Processor is generated only once and includes sample
code based on the associated parameters at creation time. You should delay the
creation of the processor until the action processor is associated with an atomic action
that has fully defined parameters. If parameters are not yet defined or the action
processor is not yet associated with the atomic action, then the generated sample code
will be incomplete and, because it is generated only once, would require additional
coding.
4-2 Modeling Activation
Beta Draft

47.
Implementing the Action Processor
Synchronized classes or interfaces are rebuilt every time you
save changes of atomic action parameters (for example, classes and
interfaces are synchronized with the model and reflect the model).
Therefore, you should never make code changes to any synchronized
class or interface. Studio overwrites these changes when you run the
next build (with changes in the model). Developers should write code
only for the processor class.
Note:
There are 2 methods in the Processor:
■
execute
■
init
The main method is execute. When invoked, it is provided with the following:
■
A number of classes to perform operations.
■
An input class that contains all input parameters.
■
An output class to populate the output parameters.
■
Access to a logger.
■
■
An implementation of the exit type to match responses against user-defined exit
types and to set the exit type for the processor.
Access to the connection handler to send requests and get responses from a
connected device.
Related Topics
About Processor Classes and Interfaces
Example: Typical Processor Call Sequence
Implementing the Action Processor
About Processor Classes and Interfaces
The following classes and interfaces are used by the Processor:
InputBean
The InputBean is generated and synchronized, tied to the parameters of the atomic
action (has set and get methods for all parameters of the atomic action), and provides
setters and getters for manipulating parameters.
If the parameter is a scaler (simple type), it is received as a string and can be used
immediately
CompoundBean
If the parameter is a compound parameter with named members, the input bean
returns another bean that represents the compound. The returned bean has
convenience methods to get the members within the compound. A compound bean for
every defined type of compound parameter is created. You also get a set of instances of
these beans based on the work order (you get a list of these). If the compound
parameter does not have named members, it provides a vector of the members.
Beta Draft
Modeling Implementations
4-3