4 Configuring Service Request Processors

This chapter provides information about the C and C++ service request processors (SRPs).

About Service Request Processor Servers

An SRP is an Oracle Communications ASAP server that controls service request reception and translation from an upstream system and service activation notifications from ASAP back to the upstream system.

With an SRP, you can:

Generate and submit work orders
Subscribe and manage work order events
Query work order information

The SRP accepts and translates native service requests (work orders) into Common Service Description Layer (CSDL) commands. Using information from the work order, the SRP determines the parameters that are associated with the CSDL command and sends them to the Service Activation Request Manager (SARM) for provisioning.

Figure 4-1 SRP Processing Sequence

ASAP provides the following SRPs:

C SRP Emulator: A generic C based SRP server/client located in the ASAP_Home/programs/srp_emul file that can submit work orders to and receive orders from the SARM. It is used for performance benchmarking, system testing, and the prototyping of new SRPs. See "Configuring a C SRP Emulator" for more information.
C ++ Csol SRP Emulator: A sample C++ based SRP client located in the ASAP_Home/programs/csolsrp_emul file that can submit work orders to the SARM. Used to support C and C++ object-oriented technologies. See "Configuring the C++ Csol SRP Emulator" for more information.

ASAP provides the following two SRP APIs:

C SRP API: Used to support C-based SRPs.
C++ SRP API: Used to create C++ object-oriented-based SRPs. For more information about the C++ API, see "Using the C++ SRP API".

SRP Translation of Native SRP Work Orders to ASAP Work Orders

Generally, a work order or service request in its native format has one or more service elements. Each element identifies a service to be provisioned and an associated action such as add, remove, change, query, and so on.

Possible service elements include the following:

Universal Service Order Code (USOC), which is used by many telephone companies.
Service Offering (SOFF)

The SRP receives a work order or service request (SRP work order) from the originating system in its native format. It locates the service identifiers and associated data actions specified in the order, and then constructs the following SRP work order components:

Native SRP work order header information, which can include details particular to the originating system that may or may not be required in the provisioning process.
SRP work order parameters that are global to all services on the work order. For example, the main directory number (DN) or line equipment number (EN/LEN) may be specified here.
One or more SRP work order service elements and associated parameters. Such service element specific parameters may override the Global SRP work order parameters on that particular service element.

The SRP determines these service elements and parameters in an SRP-specific manner that is highly coupled to the order originating system.

This SRP work order format may not model the service request format of particular customers. For example, some service requests model the services under the individual line, which adds an additional level to this SRP work order.

ASAP can contain several SRPs that are receiving work orders and service requests in different native formats. Each SRP performs custom translations for each work order or service request source to produce the same sets of CSDL commands and parameters representing the provisioning activity to be performed.

Each SRP must translate the same provisioning request received from different sources, such as work orders or service requests, into the same set of CSDL commands and parameters. This allows the SRP to insulate the rest of ASAP from the details of external systems.

Note:

This section refers to an SRP that translates work orders into formats that the SRP can process using custom C or C++ scripts. The ASAP Service Request Translator (SRT) provides this functionality for XML messages and passes the information to the JSRP. For more information about SRT, see ASAP Service Request Translator User's Guide. SRT cannot be used with a C SRP or a C++ SRP.

Configuring a C SRP Emulator

You can configure C-based SRP emulator using the Service Activation Configuration Tool (SACT) or using stored procedures (see "Stored Procedures (Deprecated)"). This section describes the SRP configuration steps using the SACT.

The C SRP emulator makes use of the SRP, Interpreter, Server Application, and Common API libraries. SRP configuration information is located in static tables in the ASAP Control server database and the SARM database.

You can start the C SRP emulator using the start_asap_sys command. For more information see ASAP System Administrator's Guide.

Adding a C SRP Emulator

To add an C SRP emulator to the system:

Export the current database using export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML").

For example:
```
export_tool.sh -m -p abc -t config
```
Open the transOut2_config.xml file using a text editor.

For example:
```
gedit transOut2_config.xml
```

Remove all elements except for the existing SRP.

<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig 
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
 
<genericServer name="SRP_envid" xsi:type="SRPServerType">
         <description>SRP Emulator Server</description>
         <system>envid</system>
         <territory>envid</territory>
         <diagnosticFilename>SRP_envid.diag</diagnosticFilename>
         <diagnosticLevel>LOW_LEVEL</diagnosticLevel>
         <autoStart>true</autoStart>
         <controlServer>CTRLenvid</controlServer>
         <interfaceHostname>
                  <hostname>test.system.com</hostname>
         </interfaceHostname>
         <interfacePort>40012</interfacePort>
         <protocol>OPEN_SERVER</protocol>
         <program>srp_emul</program>
         <serverType>SRP</serverType>
         <SRPListenPort>40012</SRPListenPort>
</genericServer>
 
</activationConfig>

where envid is the environment ID for your ASAP instance.

Modify the SRP element with new values where required.

For example:

<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig 
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
 
<genericServer name="SRP_2envid" xsi:type="SRPServerType">
         <description>SRP Emulator Server</description>
         <system>envid</system>
         <territory>envid</territory>
         <diagnosticFilename>SRP_2envid.diag</diagnosticFilename>
         <diagnosticLevel>LOW_LEVEL</diagnosticLevel>
         <autoStart>true</autoStart>
         <controlServer>CTRLenvid</controlServer>
         <interfaceHostname>
                  <hostname>test.system.com</hostname>
         </interfaceHostname>
         <interfacePort>40052</interfacePort>
         <protocol>OPEN_SERVER</protocol>
         <program>srp_emul</program>
         <serverType>SRP</serverType>
         <SRPListenPort>40052</SRPListenPort>
</genericServer>
 
</activationConfig>

Add configuration parameters for the SRP element where required (see "SRP API Parameters"). For example:

<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig 
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
 
<genericServer name="SRP_2envid" xsi:type="SRPServerType">
         <description>SRP Emulator Server</description>
         <system>envid</system>
         <territory>envid</territory>
         <diagnosticFilename>SRP_2envid.diag</diagnosticFilename>
         <diagnosticLevel>LOW_LEVEL</diagnosticLevel>
         <autoStart>true</autoStart>
         <controlServer>CTRLenvid</controlServer>
         <interfaceHostname>
                  <hostname>test.system.com</hostname>
         </interfaceHostname>
         <interfacePort>40052</interfacePort>
         <protocol>OPEN_SERVER</protocol>
         <program>srp_emul</program>
         <serverType>SRP</serverType>
         <SRPListenPort>40052</SRPListenPort>
</genericServer>
 
</activationConfig>

Save the file.
Update the file using sactConfig as described in "Running the SACT Scripts".

Deleting a C SRP Emulator

To delete a C SRP emulator:

Export the current database using export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML").

For example:
```
export_tool.sh -m -p abc -t config
```
Open the transOut2_config.xml file using a text editor.

For example:
```
gedit transOut2_config.xml
```

Remove all elements except for the SRP you want to delete.

For example:

<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig 
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
 
<genericServer name="SRP_envid" xsi:type="SRPServerType">
         <description>SRP Emulator Server</description>
         <system>envid</system>
         <territory>envid</territory>
         <diagnosticFilename>SRP_envid.diag</diagnosticFilename>
         <diagnosticLevel>LOW_LEVEL</diagnosticLevel>
         <autoStart>true</autoStart>
         <controlServer>CTRLenvid</controlServer>
         <interfaceHostname>
                  <hostname>test.system.com</hostname>
         </interfaceHostname>
         <interfacePort>40012</interfacePort>
         <protocol>OPEN_SERVER</protocol>
         <program>srp_emul</program>
         <serverType>SRP</serverType>
         <SRPListenPort>40012</SRPListenPort>
</genericServer>
 
</activationConfig>

where envid is the environment ID for your ASAP instance.

Save the file.
Update the file using sactUnconfig as described in "Running the SACT Scripts".

Adding Configuration Parameters to a C SRP Emulator

To add configuration parameters to a C SRP emulator:

Export the current database using the export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML").

For example:
```
export_tool.sh -m -p abc -t config
```
Open the transOut2_config.xml file using a text editor.

For example:
```
gedit transOut2_config.xml
```

Remove all elements except for the SRP you want to add configuration parameters to. For example:

<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig 
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
 
<genericServer name="SRP_envid" xsi:type="SRPServerType">
         <description>SRP Emulator Server</description>
         <system>envid</system>
         <territory>envid</territory>
         <diagnosticFilename>SRP_envid.diag</diagnosticFilename>
         <diagnosticLevel>LOW_LEVEL</diagnosticLevel>
         <autoStart>true</autoStart>
         <controlServer>CTRLenvid</controlServer>
         <interfaceHostname>
                  <hostname>test.system.com</hostname>
         </interfaceHostname>
         <interfacePort>40012</interfacePort>
         <protocol>OPEN_SERVER</protocol>
         <program>srp_emul</program>
         <serverType>SRP</serverType>
         <SRPListenPort>40012</SRPListenPort>
</genericServer>
 
</activationConfig>

where envid is the environment ID for your ASAP instance.

Add the configuration parameters. For example:

<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig 
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
 
<genericServer name="SRP_envid" xsi:type="SRPServerType">
         <description>SRP Emulator Server</description>
         <system>envid</system>
         <territory>envid</territory>
         <diagnosticFilename>SRP_envid.diag</diagnosticFilename>
         <diagnosticLevel>LOW_LEVEL</diagnosticLevel>
         <configurationParameters>
            <configurationParameter xsi:type="WO_MGR_DELAY">
                  <value>5</value>
            </configurationParameter>
         </configurationParameters>
         <autoStart>true</autoStart>
         <controlServer>CTRLenvid</controlServer>
         <interfaceHostname>
                  <hostname>test.system.com</hostname>
         </interfaceHostname>
         <interfacePort>40012</interfacePort>
         <protocol>OPEN_SERVER</protocol>
         <program>srp_emul</program>
         <serverType>SRP</serverType>
         <SRPListenPort>40012</SRPListenPort>
</genericServer>
 
</activationConfig>

Save the file.
Update the file using sactConfigNR as described in "Running the SACT Scripts".

Configuring the C++ Csol SRP Emulator

The C++ Csol SRP emulator is a standalone program designed to use the C++ SRP libraries to create and submit work orders to the SARM. The emulators retrieve work order information and receive events from the SARM. The events are collected from the SARM and are logged to the SRP database and the diagnostic file.

The C++ SRP emulators use the C++ SRP libraries.

For the SARM to communicate with the C++ SRP emulator, you must configure the emulator in tbl_asap_srp in the SARM database. Enter the following information:

Set the srp_conn_type field to O so that the SARM can make Open Client connections to the emulator.
Set the srp_host_name field to the name of the UNIX host that the emulator is running on.
Set the srp_host_port field to the socket port number that the emulator and SARM can communicate with.

For more information, see "tbl_asap_srp" in ASAP Developer's Guide.

Starting the C++ Csol SRP Emulator

To start the C++ Csol SRP emulator:

Source the ASAP_home/Environment_Profile:
```
. ./Environment_Profile
```
Start ASAP if it is not already running.
```
start_asap_sys
```
Enter the following command:

csolsrp_emul svr_name ctrl_password -c ctrl_svr_name -l diag_level [-f diag_file]

where:

svr_name: The name of the SRP server.
ctrl_password: The control server password.
ctrl_svr_name: The name of the control server.
diag_level: The diagnostics level. For more information on diagnostic levels, see ASAP System Administrator's Guide.
diag_file: The name of the diagnostics file.

For example:

csolsrp_emul $SRP abc -c $CTRL -l KERN -f CSOL

Using the C++ SRP API

The C++ SRP API provides you with an interface with the SARM. It allows C++ SRPs to generate, manipulate, and submit ASAP work orders, handle events, and access SARM databases in a multi threaded environment.

The C++ SRP receives requests from external systems and translates them into ASAP work orders using the C++ SRP API. The C++ SRP submits the work orders to the SARM. The SARM sends a confirmation to the C++ SRP for each work order it receives and then generates events and forwards them to the C++ SRP to identify the progress of the work order.

The C++ SRP uses native threads to support symmetric multiprocessing and to provide maximum scalability of ASAP across multiple CPUs.

ASAP libraries:
- Common Object-Oriented Library (liboo_asc) – Provides common utilities and database access
- Thread Framework Library (libthreadfw) – Provides the underlying thread framework
Third party libraries:
- Open Client (Sybase)

For information on ASAP libraries, see the ASAP Developer's Guide.

After the work order is created, you can submit it to ASAP through the C++ SRP. The C++ SRP provides interfaces for you to process events and access ASAP orders. It also insulates the user from most exceptional condition handling.