The Switch Provisioning Activation API provides the IDL for switch provisioning activation. The Switch Provisioning Activation API retrieves Design Layout Records (DLRs), switch translation, and flow-through information for a given WDIEvent.
Your application is responsible for managing all database transactions, including commit and rollback processing.
The Switch Provisioning Activation API facilitates flow-through provisioning for switched orders initiated from the PSR module of the Order Management subsystem, and enables flow-through provisioning of dialtone orders. The Switch Provisioning Activation API is directly involved with Oracle Communications MetaSolv Solution and invokes the same rules.
Table 11-1 lists the terms that identify information and concepts that are required to understand the flow-through provisioning using the APIs.
Table 11-1 Switch Provisioning Terminology
| Term | Definition |
|---|---|
|
Activation product |
A network management system (NMS), such as Lucent Technology's ACTIVEVIEW product line. |
|
Activation server |
An application developed by you or a third party that integrates with MetaSolv Solution to export provisioning data and communicate the data to one or more activation products. |
This section provides information about the Switch Provisioning Activation interface.
Table 11-2 lists the operations available in the DLRSession of the WDIDLR.IDL file that is used by the Switch Provisioning Activation API.
Table 11-2 DLRSession Interface Operations
| Operations | WDINotification |
|---|---|
|
getSwitchActivation_v2 |
switchActivationGetSucceeded_v2 switchActivationGetFailed |
|
getSwitchActivation_v4 |
SwitchActivationGetSucceeded_v4 SwitchActivationGetFailed_v4 |
|
getSwitchActivation_v5 |
SwitchActivationGetSucceeded_v5 SwitchActivationGetFailed_v5 |
This section contains sample process flows for each type of message: solicited and unsolicited. Use the sample flow as a template for developing your own process flows.
A solicited message is a message initiated by MetaSolv Solution. MetaSolv Solution plays the role of the client, and the third-party activation server plays the role of the server.
Table 11-3 lists the interfaces and operations that the third-party application implements using the IDL file provided with the DLR API.
Table 11-3 Switch Provisioning API Interfaces Solicited Messages Operations
| Interface | For Implementing These Operations |
|---|---|
|
WDIRoot |
connect disconnect |
|
WDIManager |
startTransaction destroyTransaction |
|
WDITransaction |
N/A |
|
WDISignal |
eventOccurred eventTerminated |
|
WDIInSignal |
N/A |
When MetaSolv Solution is the client, the overall process flows as follows:
The API client binds to the third-party server to get a WDIRoot object reference.
The API client invokes the connect operation of the WDIRoot interface, and the connect operation yields a WDIManager object reference.
The API client invokes the startSignal operation of the WDIManager interface to get a WDISignal object reference.
The API client invokes the eventOccurred operation of the WDISignal interface to notify the third-party application that an event registered to them has occurred within MetaSolv Solution.
The API client invokes the destroySignal operation of the WDIManager interface.
The API client invokes the disconnect operation of the WDIRoot interface.
Once the third-party server completes processing, possibly involving additional unsolicited messages to MetaSolv Solution, the third party performs a bind to the MetaSolv Solution Application Server and follows the same process described above for the client with the exception that the eventCompleted/Errored operations are invoked passing the original WDIEvent structure.
If the third-party application encounters an error, it throws a WDIExcp as defined by the IDL. The client handles CORBA system exceptions and WDIExcp exceptions.
An unsolicited message is a message initiated by the third-party application. MetaSolv Solution plays the role of the server and a third-party application plays the role of the client with the exception of the callback processing.
Table 11-4 lists the interfaces and operations that MetaSolv Solution implements using the IDL file provided with the Switch Provisioning Activation API.
Table 11-4 Switch Provisioning Interfaces Unsolicited Messages Operations
| Interface | For Implementing These Operations |
|---|---|
|
WDIRoot |
connect disconnect |
|
WDIManager |
startTransaction destroyTransaction |
|
WDITransaction |
commit rollback |
|
DLRSession |
getSwitchActivation_v5 |
Table 11-5 lists the interfaces and operations for which the third-party application is responsible.
Table 11-5 Switch Provisioning Third-party Application Interfaces and Operations
| Interface | For Implementing These Operations |
|---|---|
|
WDINotification |
switchActivationGetSucceeded_v5 switchActivationGetFailed_v5 |
The overall process flow for exporting a DLR follows:
The third-party application binds to the MetaSolv Solution Application Server to get a WDIRoot object reference.
The third-party application invokes the connect operation of the WDIRoot interface, which yields a WDIManager object reference.
The third-party application invokes the startTransaction operation of the WDIRoot interface to get a WDITransaction object reference and start a database transaction.
The third-party application invokes the startDLRSession operation of the WDIManager interface to get a DLRSession object reference.
The third-party application instantiates a third-party implementation of a WDINotification object.
The third-party application invokes the getSwitchActivation operation of the DLRSession object, passing the WDINotification object.
The SwitchActivation data structure is returned asynchronously via invocation of the switchActivationGetSucceeded/Failed) operation of the WDINotification object.
The third-party application invokes the destroyDLRSession operation of the WDIManager interface.
The third-party application invokes the destroyTransaction operation of the WDIManager interface.
The third-party application invokes the disconnect operation of the WDIRoot interface.
This section describes the issues that you must be familiar with when building a mediation server application for flow-through provisioning.
Network nodes are the equipment that manages the circuits in the network. They are identified by a unique target identifier (TID). TIDs are used to search for devices on the network. Commands are sent to the network node for flow-through provisioning. For example, a user might designate one network node as the host network element that communicates with the network management system. Essentially, a network node is any device that can be provisioned through software. Network nodes can contain one or more pieces of equipment, and can be directly associated with flow-through provisioning plans on the Network Node Type window in the Infrastructure module.
If flow-through plans are used, the flow-through provisioning process cannot occur without network nodes. Network node types are used in the flow-through provisioning process to categorize network nodes into groups. Network node types represent the activation vendor's requirements for activating the network element, and they are used in the flow-through provisioning process to limit the number of flow-through provisioning plans required.
Flow-through provisioning plans and flow-through provisioning commands are MetaSolv Solution concepts that define optional additional parameters used in the flow-through provisioning process that are not a part of MetaSolv Solution. Below are examples of some of the types of flow-through provisioning plans and commands that can be created:
Plan
Activate a DACS
Command
Config Port A
Config Port B
Parameters
Direction: 1 way
Direction: 2 way
Alarming
The number of flow-through provisioning plans, commands, and parameters that are created will vary according to the requirements of the activation product used for the flow-through provisioning process. The nature of flow-through provisioning plans and commands is to allow MetaSolv Solution to work with any selected activation product. That is, MetaSolv Solution only captures TID, port addresses, and cross-connects for flow-through provisioning. Flow-through provisioning plans and commands provide the ability to capture all the information the activation vendor requires.
Note:
If the selected activation product only requires the defaults for flow-through provisioning, then it is not necessary to use the PSR module in the flow-through provisioning process at all.A design layout record (DLR) is a document that contains the technical information that describes the physical layout of a circuit at a given location.
The tech translation sheet defines the items required to provision the service in the switch. For switch provisioning activation, once the order is entered, the product and options ordered are the basis for the tech translation sheet.
A virtual layout record (VLR) is a MetaSolv Solution-defined document that contains the technical information that describes the layout of the physical components of an ATM or Frame Relay virtual circuit, and the relationship of the physical components to the logical components (the cloud) of that circuit.
The Switched Provisioning Activation and Transport Provisioning Activation APIs use the following modules and subsystems in the to complete the flow-through provisioning process:
Equipment Administration module
Infrastructure module
Product Service Request (PSR) module
Service Provisioning subsystem
Work Management subsystem
The flow-through provisioning process uses the Equipment Administration module to define the following:
Target identifier (TID) that the activation vendor recognizes
Network node with which the equipment is associated
Note:
A network node must be associated with every piece of equipment (or at a higher level in the equipment hierarchy) used for flow-through provisioning. A network node type must be associated with every network node used for flow-through provisioning.The Infrastructure module is used in the flow-through provisioning process to:
Define new network node types
Associate network node types with flow-through provisioning plans and rate codes
Additionally, the user can access the PSR module's Product Catalog function through the Infrastructure module. The user will only use the Infrastructure module for flow-through provisioning if they need to specify additional data for a network node.
The Product Service Request (PSR) module is used in the flow-through provisioning process to:
Set up flow-through provisioning plans and commands
Enter a service request
Provide service request information related to flow-through provisioning on the tech translation sheet for switch translations
More specifically, the PSR module's Product Catalog function is used in the flow-through provisioning process to define the features that appear on the PSR, as well as the options on those features. Options on the service request used for the flow-through provisioning process include flow-through provisioning plans and commands. These options often have default values, and when a PSR is entered with these options, the service request includes the required default values (also referred to as parameters). The MetaSolv Solution user can use the Product Specifications window to determine if the values or parameters appear on the tech translation sheet.
Note:
All parameters necessary to the flow-through provisioning process (except equipment parameters) are defined in the Product Catalog function.The flow-through provisioning process uses the Service Provisioning subsystem to:
Design the circuit(s) on the PSR used for flow-through provisioning
Verify and modify the flow-through provisioning parameters that are set up in the PSR module
The Service Provisioning subsystem also provides the flow-through provisioning information (such as network node type and network node address) that appears on the CLR, DLR, VLR, and tech translation sheet.
The Work Management subsystem is used in the flow-through provisioning process to:
Associate a gateway event with a provisioning plan task
Initiate a gateway event
Verify the gateway event is complete
Gateway events define when MetaSolv Solution should send flow-through provisioning information to the activation application for processing.
The flow-through provisioning process is used in MetaSolv Solution to:
Order and provision services associated with the line side of a switch
Engineer a service request and provision it without re-entering activation information
Note:
Line side activation includes provisioning dialtone services through a switch. The activation process occurs outside of MetaSolv Solution.See the online Help for detailed instructions on using the flow-through provisioning process.
The signal handler module implements the interfaces required to handle standard gateway events from MetaSolv Solution clients. This module is also responsible for updating gateway event status to ”In Progress”.
The outbound signals sent by the client to your activation server are the flow-through provisioning gateway events. These events are defined at the service item level. Each service item (for example, a phone line, a WATS line, or an ATM/Frame circuit) on the order will have the flow-through provisioning gateway event associated with it. As a result, when an order is processed by the Work Management subsystem, your activation server can potentially receive as many gateway events as there are service items in the order. For example, if a transport provisioning order for ASR equipment comprises six special access circuits, your activation server receives six separate gateway events from the client.
Each gateway event associated with a service item in a service request can be processed independently of the gateway events for any other service item.
Ensure that the implementation conforms to the pattern described in "Outbound Signals – Gateway Events". The signal handler module should implement a WDIDLR module with all the interfaces and operations specified in Table 2-6, "Outbound Gateway Event Operations Required For All APIs". Event status updates are performed via DLRSERVER.
Upon receiving an outbound signal conveying gateway event information from the client, the signal handler module activates the request handler module and hands off the event information that was received. In order to avoid locking up the client, it is recommended that the signal handler should return control to the client immediately upon activating the request handler module and updating the event status.
The request handler module retrieves activation data from the MetaSolv Solution database by invoking the operation getSwitchActivation on DLRSERVER to retrieve switch activation data.
The operation is a standard data export operation that conforms to "Asynchronous Interaction Pattern". This provisioning operation accepts a WDIEvent parameter. This allows the request handler to retrieve provisioning data from the database in a single step.The request handler passes the gateway event structure that was received from the client, and DLRSERVER retrieves the required provisioning data.
It is important to understand the data types that are involved in the two operations listed above. Data type definitions can be found in file WDIDLRTYPES_v5.IDL. The following Switch Activation data structure is returned to the caller (via callback invocation):
The formatting/translation module handles two-way data translation and format conversion required for communicating with the activation product. This module's services are used by the other modules.
The response handler module handles responses received from the activation product. It performs the necessary reverse translation/formatting using the formatting/translation module and then determines the operation status. Based on the success or failure determination, this module updates gateway event status to ”Completed” or ”Errored”. Design of this module depends upon factors such as the synchronous/asynchronous and online/batch nature of the interaction with activation product.
Dates are returned using the MetaSolv:CORBA:WDIUtil:MSVDate structure, which stores the date and time information as a string of the form YYYYMMDDHHMMSS.
The CORBA specification does not allow uninitialized values for structures or types embedded within other structures. In the case of no data, a sequence of length "0" is returned.
To obtain the full benefit of the automated flow-through capabilities of these APIs, gateway events must be associated with tasks in Work Management provisioning plans. MetaSolv Solution is pre-configured with gateway templates and gateway event templates for Switch Provisioning.
See the online Help for detailed instructions on using the flow-through provisioning process.
In order to ensure that the provisioning information provided by the Switched Provisioning Activation API is sufficiently completed to be used by your network management system, care must be used when ordering the service.
The PSR module captures default values for items that have pick lists. With flow-through provisioning, defaults are also needed for editable fields. If defaults are not provided, a user would be required to manually enter the same value on every line for an order. Providing a default value in the product catalog for product specifications that are required for flow-through provisioning streamlines the ordering process.
For transport provisioning activation, the network node target identifier (TID) and the equipment port address assignment identifier (AID) in the database identify the equipment and port address. These items should either be used directly by your application or your application should maintain a cross-reference between the identifiers used by your application and the MetaSolv Solution-supplied TID and AID.
Just as the provisioning of switch features requires additional parameters, the provisioning of transport equipment requires additional parameters as well. The transport equipment for dialtone lines is usually digital loop carrier. The MetaSolv Solution CLR represents the provisioning information for this type of equipment. The CLR captures the TID and the AID for the DLC equipment, which is part of the information that is required for activating the service. The TID is determined by identifying the Network Node to which the equipment belongs. The AID is determined using the assignment information that is gathered on the CLR. To provision transport equipment, additional parameters are usually required. These parameters will vary by type of equipment, by transmission rate, and by activation vendor.