Oracle® Communications ASAP Server Configuration Guide
Release 7.2
E24629-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

6 Managing the Service Activation Request Manager

This chapter describes the Service Request Activation Manager (SARM).

About Managing Service Activation Request Manager Servers

The SARM performs the following tasks:

The SARM manages all of these tasks based on the configuration data contained in an ASAP cartridge. These cartridges define required work order parameters, that the SRP turns into a CSDL command and sends to the SARM. The SARM processes the CSDL based on the information contained in the cartridge.

SARM to SRP Event Notification

The SARM to SRP functional interface consists of work order event notifications transmitted by the SARM to the SRP as the work order is being provisioned. When it receives these notification events, the SRP processes each event in the manner appropriate to the SRP for that particular event. The SRP can choose to ignore some of these event notifications.

SRP Work Order Event Management

As the SRP transmits the ASAP work order to the SARM for provisioning, the SARM returns several notification events to the SRP related to the provisioning activity. The SRP passes these events to the originating system in the native format of that system. This provides the originating system with extensive feedback about the order provisioning progress.

In addition to the notification events that the SRP passes back to the originating system, the SRP also transmits the following SRP originated events:

  • SRP WO Acknowledgement Event – Acknowledges the successful receipt of the work order.

  • SRP WO Translation Error Event – Signifies that the SRP was unable to translate the SRP work order successfully. In most cases, the work order is transmitted to the SARM with a Translation Error status, and then the SARM holds it and waits for manual intervention.

  • SRP WO Rejection Event – Notifies the originating system that either the SRP or the SARM rejected this copy of the work order. The causes of this event vary from customer to customer, but it generally results from an attempt to update an existing order in ASAP when it is either In-Progress or Completed.

The SRP, which is generally under your control, can define additional events back to the originating system. However, you can set up the system to exclude certain SARM-originated events from being transmitted back to the originating system.

Using this data structure, the SRP performs a translation from the native SRP work order format to the ASAP work order format. Figure 6-1 describes this translation.

Figure 6-1 SRP Work Order Translation


The various ASAP work order components created by this process are outlined in the following section.

NEP to SARM Event Notifications

The SARM's main function regarding NE queue management is the maintenance of NE status information. The SARM maintains status information for each NE in ASAP. This information includes:

This information is available in real-time from the SARM and SARM database through an internal NE monitor table that reflects the present state of all NEs in the system.

For information on viewing the monitor table, see Appendix A, "asap_utils.".

Table 6-1 shows the notifications that the NEP sends to the SARM.

Table 6-1 NE Notifications

Notification Description

NE Available

The NEP transmits this notification to inform the SARM that a particular NE is available. This prompts the SARM to begin transmitting ASDLs to the NEP.

Auxiliary Connection Failure

The NEP notifies the SARM that the auxiliary connection request could not be completed.

NE Port Failure

The NEP transmits this notification to the SARM to inform it that the connections to a particular NE are down. This can happen at any point during the provisioning process. The SARM marks its internal NE status as Port Failure, and then moves the ASDL commands from the In Progress queue to the Pending queue. The NEP periodically attempts to re-establish the primary connection to the NE.

Device Error

The NEP sends this notification to the SARM when a particular connection to the NE is down.

The SARM moves the ASDL command that was being provisioned on that port from the In Progress queue to the Pending queue. If no other connection is available to the NE, the SARM marks its internal NE status as 'NE Unavailable Due to Port Failure', and then moves the ASDL commands from the In Progress queue to the Pending queue. The NEP periodically tries to reestablish the primary connection to the NE.

NE Maintenance Mode

Upon receipt of this notification, the SARM sets its internal NE status to Maintenance and queues all ASDL requests to the NE in the Pending queue. The NEP periodically tries to establish a connection to the NE. Once the NEP reestablishes this connection, it transmits an NE Available notification to the SARM which triggers the SARM to resume provisioning ASDLs to the NE.

If no other connection is available to the NE when the SARM receives Maintenance Mode notification, it sets the internal status of the NE to Maintenance and queues all ASDL requests to that NE in the Pending queue. Once the NEP re-establishes the connection to the NE, it transmits an NE Available notification to the SARM, which prompts the SARM to resume provisioning ASDLs to that NE.


When the SARM receives one of the above notifications from the NEP, it sets the NE status before moving all ASDLs from the In Progress queue to the Pending queue for that NE.

Returned Parameter Types and Formats

The NEP generates various parameters in conjunction with the State Table Interpreter or the JInterpreter, and transmits them back to the SARM.

The SARM can receive the following types of parameters from an NEP:

  • Information Parameters – Generated by the NEP State Tables or the Java methods and returned to the SARM when the ASDLs or the methods complete. These are the only parameters that the SRP can retrieve from the SARM. Information parameters usually contain data requested by the originating system.

  • Global Parameters – Generated by the NEP State Tables or the Java methods and returned to the SARM when the ASDLs or the methods complete. These parameters are used to maintain context between different Common Service Description Layer (CSDL) commands on the same work order.

  • CSDL (Local) Parameters – Created by the NEP State Tables or the JInterpreter provisioning methods while processing ASDLs and returned to the SARM upon ASDL or method completion. CSDL parameters maintain context between different ASDLs on the same CSDL.

  • ASDL Rollback Parameters – Generated by the NEP State Tables or the JInterpreter as the ASDL command is processed. These parameters maintain any information required in the rollback operation of a particular ASDL.

    When the ASDL completes, the SARM automatically adds all ASDL parameters from the forward provisioning leg to the list of Rollback parameters. If rollback is required on this ASDL, the SARM transmits the rollback ASDL command to the NEP with these rollback parameters.

For more information about these parameters, see the ASAP Cartridge Development Guide.