12 The Transport Provisioning Activation API

Sample Solicited Message Process Flow

When MetaSolv Solution is the client, the overall process flows as follows:

1. The API client binds to the third-party server to get a WDIRoot object reference.

2. The API client invokes the connect operation of the WDIRoot interface, and the connect operation yields a WDIManager object reference.

3. The API client invokes the startSignal operation of the WDIManager interface to get a WDISignal object reference.

4. The API client invokes the eventOccurred operation of the WDISignal interface passing a WDIEvent structure to notify the third-party vendor that an event registered to them has occurred within MetaSolv Solution.

5. The API client invokes the destroySignal operation of the WDIManager interface.

6. The API client invokes the disconnect operation of the WDIRoot interface.

7. Once the third-party server completes processing, possibly involving additional unsolicited messages to the MetaSolv Solution Application Server, the third party binds to the application server and follows the same process described above for the MetaSolv Solution 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.

Sample Unsolicited Message Process Flow for Exporting Transport Provisioning Activation Information

The overall process flow for exporting Transport Provisioning Activation is as follows:

1. The third-party application binds to the MetaSolv Solution Application Server to get a WDIRoot object reference.

2. The third-party application invokes the connect operation of the WDIRoot interface, which yields a WDIManager object reference.

3. The third-party application invokes the startTransaction operation of the WDIRoot interface to get a WDITransaction object reference and starts a database transaction.

4. The third-party application invokes the startDLRSession operation of the WDIManager interface to get a DLRSession object reference.

5. The third-party application instantiates a third-party implementation of a WDINotification object.

6. The third-party application invokes the getTransportProvisioning operation of the DLRSession object, passing the WDINotification object.

7. The TransportProvisioning data structure is returned asynchronously through invocation of the transportProvisioningGetSucceeded/Failed operation of the WDINotification object.

8. The third-party application invokes the destroyDLRSession operation of the WDIManager interface.

9. The third-party application invokes the destroyTransaction operation of the WDIManager interface.

10. The third-party application invokes the disconnect operation of the WDIRoot interface.

Equipment Administration Module

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.

Infrastructure Module

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.

Product Service Request Module

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 user can use the Product Specifications window to determine if the values or parameters appear on the tech translation sheet.

Service Provisioning Subsystem

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.

Work Management Subsystem

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.

Signal Handler

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 MetaSolv Solution 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.

Implementation should conform to the outbound signals gateway events pattern. See "Outbound Signals – Gateway Events" for more information. The signal handler module should implement a WDIDLR module with all the interfaces and operations listed in Table 2-6, "Outbound Gateway Event Operations Required For All APIs". Event status updates are performed through DLRSERVER.

Upon receiving an outbound signal conveying gateway event information from the MetaSolv Solution 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.

Request Handler

The request handler module retrieves activation data from the MetaSolv Solution database by invoking the getTransportProvisioning operation on DLRSERVER to retrieve transport provisioning data

The operations are standard data export operations. See "Synchronous Interaction Pattern" for more information. This provisioning operation accepts a WDIEvent parameter that allows the request handler to retrieve provisioning data from the database in a single step. The request handler passes in 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 operation listed above. Data type definitions can be found in file WDIDLRTYPES_v5.IDL. The following Transport Provisioning data structure is returned to the caller (through callback invocation):

typedef sequence<DLR> DLRSeq;
typedef sequence<MetaSolv::CORBA::WDIVLRTypes::VLR> VLRSeq;
struct TransportProvisioning {
    char type;   //  CIRCUIT.TYPE CHAR(1)
    DLRSeq       dlr;
    VLRSeq       vlr;
    ActivationCommandPlanSeq   activationCommandPlans ;
};

Formatting/Translation Module

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.

Response Handler

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.