3 Service Request Processor and Java Service Request Processor

The Service Request Processor (SRP) and Java SRP (JSRP) bridge external systems and the Service Activation Request Manager (SARM). The SRP and JSRP performs the following functions:

• Receives work orders from external sources

• Updates work order status requests to the SARM

• Deletes work order requests to the SARM

• Receives work order event notifications from the SARM

• Submits work order queries to the SARM for additional work order details

• Transmits work order provisioning notifications and details back to the originating system

The SRP and JSRP provide interoperability to interface with one or more Business Support Systems (BSSs) and Operations Support Systems (OSSs) in parallel. Oracle Communications ASAP can interface with one or more of these information systems in parallel using the object-oriented SRP toolkit, the Order Control Application (OCA) SRP, and the Java SRP. These SRPs are customizable to support communication with any upstream system.

Figure 3-1 represents the technology support provided by the SRP and Java SRP.

Figure 3-1 Technology Supported by the SRP

Telecommunications carriers can use ASAP to manage technologies from different vendors and to facilitate the flow-through of information from those devices, using either internal or external networks.

ASAP provides the following types of SRPs that are designed to accommodate a wide variety of upstream technologies:

The SRP provides the following interfaces:

• Web Services API – provides a Web Services interface through which external applications can manage service activation activities and operations. The interface is defined in the ASAP Web Service Web Service Definition Language (WSDL) file.

• Java SRP – Provides both an XML/JMS, Java Value Type, and Web Service interface into ASAP's provisioning functionality. The Java SRP adheres to OSS/J, an initiative that defines and implements an open, standard set of Java technology-based APIs for OSS.

  The Java SRP can operate with an optional ASAP component, the Service Request Translator (SRT). The SRT enables a variety of tasks within a transformation computation, including mapping, data lookup, and message transformation. The mapping of tasks allows upstream requests to be decomposed into one or more downstream requests, data lookup functions can involve the retrieval data from external systems (such as databases), and transformation actions can involve presentation formatting. The translator is triggered by an XML source document and generates an XML target document as its output. See SRT User Guide for more information.

• OCA SRP – Co-exists with Java SRP in WebLogic and shares some JSRP interfaces. The OCA Client application uses the OCA SRP.

• C++ SRP API – Provides a C++ API to interface with ASAP and is used to support object-oriented technologies. The Object SRP uses native threads to support symmetric multiprocessing and provides maximum scalability of ASAP across multiple CPUs. Refer to ASAP Developer Reference for C++ SRP API design guidelines.

• C SRP API – Provides a C API to interface with ASAP.

  
  

  Note: C SRP API and C++ SRP API enhancements are not supported.

  
  

SRP Order Properties

SRP order properties contain ASAP order details that are required for SARM provisioning. Some are optional. You can set and retrieve work order properties using SRP API calls.

The following are some major work order properties:

• Order types – Order type properties are used to pass provisioning instructions to the SARM, such as activating or canceling the order.

• Order scheduling – Order scheduling properties enable you to specify whether the SARM is to process orders immediately or based on a user-defined due date and time.

• Timeouts – The timeout function at the service-order level prevents a work order from staying in ASAP indefinitely. You can configure the timeout period so that a work order fails if it remains in the system longer than required.

  
  

  Note: The work order timer is set when the SARM starts provisioning the work order or when the work order is in progress. The order is failed after the current ASDL finishes provisioning.

  
  

  If the work order fails due to work order or ASDL timeout, ASAP rolls back ASDLs that have completed.

• Related order properties – An optional Related Order property is included in the SRP order to identify a prerequisite work order, such as a parent work order upon which a child order is dependent. The SARM activates the child only when the provisioning of its parent is complete. The Related Order property is used for from/to and multiline order processing, revisions, and cancellations.

• Rollback properties – ASAP can be configured to roll back ASDLs upon ASDL failure. This field is used to override the default rollback behavior defined in the SARM translation tables.

Batch Orders

Provisioning activities can be batched in the following ways:

• Single batch orders – Large orders that contain many instances. Such orders are processed serially within ASAP and are most efficient when all instances in the batch are destined to the same network element. You can specify an error threshold associated with a single batch order that, if exceeded, results in the entire batch being stopped.

• Multiple orders in a batch – The SRP provides the capability to aggregate a set of otherwise independent orders into a logical batch group and then activate these orders in parallel. This technique is best suited to a batch consisting of several instances that span many network elements. You can specify an error threshold associated with such batch groups that, if exceeded, results in the entire batch being stopped.

Once the SRP has completed the translation process, it transmits the SRP version of the work order with the specified properties to the SARM for provisioning. The SARM can either accept or reject the work order.

When the SARM receives the SRP version of the work order, it stores details such as work order properties, CSDLs, and parameters in the SARM database.

SRP Notification Reception

The SRP receives notification events from the SARM while a work order is being provisioned. Specifically, whenever the state of the work order changes (wether the work order is part of a batch or individual), the SARM notifies the SRP. The SRP can then notify the originating system of the change in work order status.

SRP notification events include:

• Work order timeout – If the SARM is configured to calculate the work order timeout, it sends a timeout notification to the SRP when the ASDL processing time exceeds the configured time limit. One of the following situations can occur:

  • Timeout and executing – The first ASDL timeout that occurs during the provisioning of the work order. The timeout notification is sent to the SRP, and the SARM sets the timer again to provide a grace period for the ASDL and continues provisioning of the ASDL. It does not fail the work order.

  • Timeout and fail – Work order timeout or an ASDL timeout for the grace period on a work order. A timeout notification is sent to the SRP and the work order is failed in the SARM.

• Work order rollback – This notification type informs the SRP that rollback is being invoked on the work order. In general, Work Order Rollback is produced whenever a work order fails and rollback is configured on one or more ASDLs.

• Work order failure – The Work Order Failure notification is triggered by the SARM whenever a work order fails there. The notification includes details on the CSDL that failed.

• Work order accept – Transmitted to the SRP when the SARM accepts the work order.

• Work order estimate – Transmitted when the SARM receives a work order from the SRP. If the SARM is configured to perform a work order estimated time calculation, it calculates the average time, in seconds, for this work order to be provisioned.

• Work order completion – Transmitted to the SRP when the work order completes in the SARM. This notification can report Normal Completion (no errors) or Completion with Exceptions (such as soft errors).

• Work order start up – Informs the SRP that the work order has started provisioning in the SARM. When possible, this information is passed back to the originating system to provide feedback on the progress of the work order.

• Work order soft error – Generated whenever an ASDL response on the work order is labelled Fail But Continue. If the work order fails or completes, this notification is followed with a Failure or Completion notification.

• NE unknown – Identifies a Remote NE on the work order that could not be routed to an appropriate Host NE, causing a SARM Remote NE routing error to occur.

When the SRP receives work order event notifications, it can query the SARM for additional details. Queries are generally made when the order is in a final state such as Failed or Completed, but can be made at any point in the provisioning process.

SRP Information Retrieval

When the SRP receives work order event notifications, it can query the SARM for additional details. Queries are generally made when the order is in a final state such as Failed or Completed, but they can be called at any point in the order provisioning process.

The SRP can query the SARM for the following information.

• Work order parameters – Work order parameters are created by the State Tables in the NEP or by the JInterpreter provisioning method used by the NEP, while the ASDL commands are being processed on the ASAP work order. Query results from the NEP such as formatted NE configuration information are transmitted back to the SRP, which can then pass them on to the originating system in their native format.

• Work order log – The work order log is the SARM log of all events that took place on a particular ASAP work order. Although you can query any event type, failure is the primary event to be queried. The work order log retrieves the history of all NE commands and responses transmitted to, and received from, all NEs during the processing of a failed work order. This information is useful for analysis.

• Work order CSDL log – This function returns SARM CSDL log information for a particular CSDL command on the ASAP work order.

• Work order CSDL list – This function returns a list of CSDLs on a particular ASAP work order with a time estimate for each CSDL.

• Work order revisions – The Work Order Revisions function records changes made to failed work orders in the SARM so that they can be completed at the NE. This facility provides a “before and after” picture of any modified CSDLs or parameters on the work order, which is an important feature if you update failed work orders from the OCA. This allows the originating system to be notified of all changes to the original work order.