Configuring Services Using Stored Procedures

B Configuring Services Using Stored Procedures

This appendix describes stored procedures used to create Oracle Communications ASAP service models.

Note:

Stored procedures have been deprecated.

Configuring ASAP Services Using Stored Procedures

The configuration of ASAP services using stored procedures consists of the following steps:

Configuring Service Actions

Use the following stored procedures to define, list, and delete service action commands:

SSP_new_csdl_defn – Defines a service action command in the SARM database.
SSP_list_csdl_defn – Lists configuration information for the service action command you specify from the SARM database. This information includes the rollback flag, service action command service action level, fail and completion events, and a description of the command. If you do not specify a service action command, the procedure returns information on all service action commands currently defined in the SARM.
SSP_del_csdl_defn – Deletes service action definitions from the SARM database.

For more information on these stored procedures and tbl_csdl_config, refer to the ASAP Developer's Guide.

Configuring Atomic Actions

Use the following stored procedures to define, list, and delete atomic actions:

SSP_new_asdl_defn – Defines an atomic action configuration record in the SARM database.
SSP_list_asdl_defn – Lists all or specific atomic action definitions from the SARM database. You can use wildcards in this procedure. If you do not specify a parameter, all atomic action definitions are listed.
SSP_del_asdl_defn – Deletes atomic action definitions from the SARM database.

For more information on these stored procedures and tbl_asdl_config, refer to the ASAP Developer's Guide.

Configuring Atomic Action Parameters

Use the following stored procedures to define, list, and delete atomic action parameters:

SSP_new_asdl_parm – This stored procedure defines up to nine atomic action parameters in a single stored procedure call for the specified atomic action starting at base_seq_no.
SSP_list_asdl_parm – This stored procedure lists atomic action parameters from the SARM database by atomic action name and/or atomic action parameter label.
SSP_del_asdl_parm – This stored procedure deletes an atomic action parameter from the specified atomic action.

These stored procedures populate tbl_asdl_parm. For more information, refer to the ASAP Developer's Guide.

Configuring Service Action-to-Atomic Action Mappings

The following stored procedures update tbl_csdl_asdl. tbl_csdl_asdl is a static table that is used by the SARM and contains the mapping between service action commands and atomic actions. For each atomic action associated with a service action, the SARM verifies whether the atomic action should be spawned for the specified service action. The final determination of whether the atomic action is spawned depends on the atomic action parameter translation process specified by tbl_asdl_parm.

Use the following stored procedures to define, list, and delete service action to atomic action mappings:

SSP_new_csdl_asdl – This stored procedure defines up to nine service action-to-atomic action mappings at a time from a service action command to one or more atomic actions with consecutive numbers starting at base_seq_no=1 in the SARM database.
SSP_new_csdl_asdl_idx – This stored procedure allow multiple conditions to be inserted into tbl_csdl_asdl_eval.
SSP_list_csdl_asdl – This stored procedure lists service action-to-atomic action mapping definitions.
SSP_del_csdl_asdl – This stored procedure deletes service action-to-atomic action mapping definitions from the SARM database.

These stored procedures populate tbl_csdl_asdl and tbl_csdl_asdl_eval. For more information, refer to the ASAP Developer's Guide.

Configuring Atomic Action-to-Program Mappings

Use the following stored procedures to define, list, and delete atomic action-to-program mappings:

SSP_new_asdl_map – This stored procedure defines a mapping from an atomic action to a program based on the technology and software load in the SARM database.
SSP_list_asdl_map – This stored procedure lists atomic action-to-program mappings according to various criteria.
SSP_del_asdl_map – This stored procedure deletes atomic action-to-program mappings. The mapping is based on the technology and software load.

For more information on these stored procedures and tbl_nep_asdl_prog, refer to the ASAP Developer's Guide.

Configuring Network Elements Using Stored Procedures

The definition of host network elements (NEs) consists of the following procedures:

Configuring Host Network Elements

tbl_host_clli is a static table that contains the host NE, the technology, and the software load of each NE in the ASAP system. It also contains records for each host NE to which the NEPs interface. You must populate this table to determine which NEs the NEP interfaces with.

Use the following stored procedures to define, list, and delete host NEs:

SSP_new_ne_host – This stored procedure defines a host NE with its technology type, software version, and inventory manager in the SARM database.
SSP_list_ne_host – This stored procedure lists host NE definitions.
SSP_list_host – This stored procedure retrieves host-related information from tbl_resource_pool, tbl_ne_config, and tbl_clli_route.
SSP_del_ne_host – This stored procedure deletes a host NE definition from the SARM database.

Note:

You cannot delete a host NE that has a mapping relationship with either an NEP or a remote NE. Any mapping relationship must therefore be deleted prior to deleting the host NE.

For more information on these stored procedures and tbl_host_clli, refer to the ASAP Developer's Guide.

Configuring Host to Remote Network Element Mappings

tbl_clli_route is a static table that contains the mapping between a remote NE and its host NE. You must populate this table to specify remote NE to host NE mappings.

Use the following stored procedures to define, list, and delete mappings from a remote NE to a host NE:

SSP_new_clli_map – This stored procedure defines a mapping from a remote CLLI to a Host CLLI in the SARM database.
SSP_list_clli_map – This stored procedure lists remote CLLI-to-Host CLLI mapping definitions.
SSP_del_clli_map – This stored procedure deletes a remote CLLI to host CLLI mapping.

For more information on these stored procedures and tbl_clli_route, refer to the ASAP Developer's Guide.

Any changes you make to the mapping relationships between host NEs to remote NEs, only take effect at runtime. All other changes require that you restart the SARM.

Configuring NEP-to-Host NE Mappings

NEP to host NE mappings are defined in tbl_ne_config.

Use the following stored procedures to configure NEP to host NE mappings.

SSP_new_net_elem – This stored procedure defines a host NE in the SARM database and identifies the logical name of the NEP that connects to this host NE. It also defines the loopback setting for the NE.
SSP_list_net_elem – This stored procedure lists NE definitions based on the host NE and/or NEP server you specify.
SSP_del_net_elem – This stored procedure deletes an NE definition for an NEP from the SARM database.
SSP_set_ne_loopback – This stored function is called by NEP server to update the table tbl_ne_config when the loop back state is set to ON, OFF, or GLOBAL through the utility tool asap_utils.

For more information on these stored procedures and tbl_ne_config, refer to the ASAP Developer's Guide.

Configuring Resource Pools

tbl_resource_pool is a static table that defines the collection of command processors (devices) that the NEP uses to establish connections to NEs. Groups of command processors are called resource pools. Each NE configuration determines a primary resource pool that defines one or more devices the NEP uses to connect to that NE. These devices are not used to connect to other NEs. Each NEP has an auxiliary resource pool that contains devices used by the NEP to establish connections to any NE managed by the NEP. These primary and auxiliary resource pools are defined in this table. You must populate this table to add command processors.

Use the following stored procedures to define, delete, and list command processors:

SSP_new_resource – This stored procedure defines an NEP resource (“device") to be used for NE access in the SARM database.
SSP_del_resource – This stored procedure deletes an NEP resource record from the SARM database.
SSP_list_resource – This stored procedure lists NEP resource records.

For more information on these stored procedures and tbl_resource_pool, refer to the ASAP Developer's Guide.

Configuring Communication Parameters

tbl_comm_param contains communication parameters required for the NEP to communicate with various external systems. You must populate this table to configure communication parameters.

For more information on tbl_comm_param, refer to the ASAP Developer's Guide.

Use the following stored procedures to define, list, and delete communication parameters:

SSP_new_comm_param – This stored procedure defines a communication parameter for a specified device type, host, and device into the SARM database.
SSP_list_comm_param – This stored procedure lists communication parameter information for dev_type, host, device, param_label, or for all of them.
SSP_del_comm_param – This stored procedure deletes communication parameter information from the SARM database.

Configuring Network Element Error Thresholds

Use the following stored procedures to define, list, and delete error thresholds.

SSP_new_err_threshold – This stored procedure defines error thresholds for a specific NE and atomic action.
SSP_list_err_threshold – This stored procedure lists the error thresholds for a specific NE and atomic action.
SSP_del_err_threshold – This stored procedure deletes error thresholds for a specific NE and atomic action.

For more information on these stored procedures, refer to ASAP Developer's Guide.

Configuring User Errors and Thresholds

Use the following stored procedures to define, list, and delete user errors.

SSP_new_err_type – This function configures the mapping between user-defined error types and the base-error types.
SSP_list_err_type – This function lists the mapping between user-defined error types and the base-error types.
SSP_del_err_type – This function deletes the mapping of user-defined error types.

Use the following stored procedures to define, list, and delete user error thresholds.

SSP_new_user_err_threshold – This stored procedure creates a new user-defined error threshold in the system for the specified NE, atomic action, and the user-defined error type.
SSP_list_user_err_threshold – This stored procedure is used to list the user-defined error thresholds for a specific NE, atomic action, and user error type.
SSP_del_user_err_threshold – This stored procedure deletes a user-defined error threshold or set of thresholds.

For more information on these stored procedures, refer to ASAP Developer's Guide.

Configuring Static Routing

Configuring Atomic Action Routings by ID_ROUTING Using Stored Procedures

The stored procedures that you can use as external interfaces are the following:

SSP_list_id_routing (RC1, host_clli) – Lists the host NE and ID_ROUTING mapping records in the SARM database.
SSP_new_id_routing (host_clli, asdl_cmd, id_routing_from, id_routing_to) – Defines the host NE and ID_ROUTING mapping records in the SARM database.
SSP_del_id_routing (host_clli, asdl_cmd, id_routing_from, id_routing_to) – Deletes the host NE and ID_ROUTING mapping records from the SARM database.

For more information on these stored procedures, refer to the ASAP Developer's Guide.

The following steps must be followed when routing by ID_ROUTING:

Populating the routing table (tbl_id_routing).
Defining the atomic action parameter. A sample is located in ..\samples\ASDL_ROUTE\oraRoutingServices.
Defining the work order. A sample is located in ..\samples\ASDL_ROUTE\RoutingSrpInput.
Starting ASAP and submitting the work order.

The following examples provide samples of how each step can be configured.

The following example displays how to populate tbl_id_routing.

sqlplus -s $SARM_USER/$(GetPassword $SARM_USER 2) 
<<HERE | grep -v "successfully completed"

set serveroutput on
var retval number

prompt Defining the ID_ROUTING Configurations

exec :retval := SSP_del_id_routing ;

exec :retval := SSP_new_id_routing ('BALTIMORE', '', 'BAL', ‘CAL');
exec :retval := SSP_new_id_routing ('BALTIMORE', '', 'DEL', ‘FAL);
exec :retval := SSP_new_id_routing ('BOSTON', '', '120000', ‘220000');

HERE

You can add new records to the database dynamically without downtime on the server by using the “Add new NE Configuration" command (113) of asap_utils. This command must be used after loading the ASAP database.

For more information on asap_utils, see the ASAP Server Configuration Guide.

For more information on the tbl_id_routing table, see the ASAP Developer's Guide.

Configuring Atomic Action Routings by USER_ROUTING

You can perform atomic action routing by using a user-defined procedure. Routing by user-defined procedure provides the following:

Allows for custom provided logic for atomic action routing.
Uses the atomic action parameter USER_ROUTING.
Uses the external interface SSP_get_user_routing.
Allows you to write your own routing logic using the predefined external user interface.

The USER_ROUTING parameter can be represented as any string of characters to a maximum of 255 characters. You can define it as part of a work order, or as a service action parameter.

If the atomic action parameter USER_ROUTING information is provided in the work order, then the user-defined stored procedure is called. The user-defined procedure takes the asdl_cmd and the value of USER_ROUTING as input arguments, and returns the host NE to be routed.

You can use the following stored procedure as an external interface:

SSP_get_user_routing (user_routing, asdl_cmd, host_clli, ret_val) – Returns a host NE (host_clli) that is used to route the atomic action. You must provide your own routing logic in the body of SSP_get_user_routing to find the host NE (CLLI) using the USER_ROUTING atomic action parameters, and the asdl_cmd if required.

For more information on the above stored procedure, refer to the ASAP Developer's Guide.

To use USER_ROUTING, perform the following steps:

Write the stored procedure SSP_USER_ROUTING. A sample is located in ..\samples\ASDL_ROUTE\user_routing_proc.sp.
Define and populate the routing table, if required. A sample is located in ..\samples\ASDL_ROUTE\user_routing_table.tbl and ..\samples\ASDL_ROUTE\oraLoadRouting.
Define the atomic action parameter. A sample is located in ..\samples\ASDL_ROUTE\oraRoutingServices.
Define the work order. A sample is located in ..\samples\ASDL_ROUTE\RoutingSrpInput.
Run ASAP and submit the work order.

When you choose a user-defined procedure with a database table, the database must be accessed every time the routing is requested. Consequently, there will be a slight performance degradation.

Configuring Atomic Action Routings by Distinguished Name

You can edit routing definitions provided the new routing definition does not already exist in ASAP.

SSP_new_dn_map – This stored procedure defines atomic action routings by directory number.
SSP_list_dn_map – This stored procedure lists directory mappings for atomic action, directory, exchange number, or for all of them.
SSP_del_dn_map – This stored procedure deletes a directory number mapping from the SARM database.

Configuring Network Element Blackout Periods (optional)

Use the following stored procedures to define, list, and delete blackout definitions.

SSP_add_blackout – This procedure configures the static and dynamic blackout periods for a specific NE host.
SSP_list_blackout – This procedure lists blackout periods for a specific NE host.
SSP_del_blackout – This procedure removes blackout periods for a specific NE host.

For more information on these stored procedures, refer to ASAP Developer's Guide.

Checking Network Element Blackout Periods

The stored procedure SSP_check_blackout enables you to check whether or not the specified NE is currently blacked out.

For more information on this stored procedures, refer to ASAP Developer's Guide.