| Oracle® Communications ASAP Concepts Release 7.2 E18880-01 |
|
 Previous |
 Next |
The Service Activation Request Manager (SARM) provides much of the functionality for Oracle Communications ASAP. The SARM performs the following functions:
Maintains connections to all Service Request Processors (SRPs) and Network Element Processors (NEPs) within ASAP
Controls all ASAP operations in both directions
Manages host feedback
Manages connection load balancing
During the provisioning process, the SRP transmits the Common Service Description Layer (CSDL) commands and parameters for a work order to the SARM and receives event notifications from the SARM. The SARM translates these CSDLs into Atomic Service Description Layer (ASDL) commands and then sends the ASDL commands and their associated parameters to the appropriate NEP. The NEP returns the resulting ASDL responses to the SARM, where they are processed.
Figure 4-1 illustrates the various ASAP data components and APIs relating to the SARM process.
The following sections describe the main order management and connection management features for the SARM.
Order management within the SARM refers to the process of scheduling and coordinating the provisioning activities associated with work orders. These activities include releasing immediate orders, managing and releasing future-dated orders, and managing order dependencies (parent/child relationships).
The SARM contains most of the high-level intelligence for network element management, including the following:
Rollback Management – You can configure rollback at the CSDL level or the ASDL level. Should an order be cancelled or encounter an error during provisioning, rollback returns the network element to its original state.
For more information on rollback, refer to ASAP System Administrator's Guide.
Managing Dependencies – When one work order is dependent on another (a parent/child relationship), the SARM manages the dependency and starts provisioning the child order once the parent order is complete.
After receiving a work order, the SARM either accepts or rejects the work order based on the following:
Order security
Order collisions
As part of the SRP-to-SARM protocol, the SARM performs a security check on all work orders transmitted for provisioning. The SRP passes a user ID and password to the SARM using the protocol. The SARM checks these values with a list of valid users in a static user-populated database table. If the user ID and password combination is not valid, the SARM rejects the work order. If the combination is valid, the SARM accepts the work order.
The order security logic is centralized in the SARM to avoid having each SRP conduct its own security check. As new SRPs are added to the system, centralization becomes a critical advantage.
The SARM rejects a work order sent by the SRP for provisioning if a version of this work order already exists in the SARM in one of the following states.
In-Progress WO – An existing copy of the work order is currently in progress in the SARM.
Completed WO – An existing copy of the work order has already been completed in the SARM.
Timeout WO – An existing copy of the work order has timed out in the SARM.
Configuration error – The work order has been rejected due to a configuration error, such as an unknown CSDL command, and a copy of the rejected order was saved in the Translation Error state in the SARM database.
The SARM processes a work order by performing one of the following operations.
The Update operation provisions the work order at its due date and time. Once the provisioning begins, the status of the work order is updated to In-Progress.
The activation date and time is not necessarily the same as the due date and time. The SRP can request the SARM to activate the work order at a date and time other than the due date and time, dependent upon business rules in the SRP.
The SARM manages a work order according to its status:
New order – If the order does not already exist in the SARM, the SARM accepts the order.
Initial, Held, Reviewed, or Translation Error states – The SARM overwrites the existing copy of the order.
In-Progress, Cancelled, or Completed states – The SARM rejects the order.
Failed state – The SARM aborts all CSDLs on the work order and updates the existing copy of the order, using a newly generated work order with the same work order ID and a different service request ID (SRQ_ID).
The Cancel operation cancels an existing order in ASAP. The SARM manages a work order according to its status:
Non-Existent orders – If the order does not already exist in the SARM, the SARM accepts the cancellation request and maintains a cancelled record.
Initial, Held, Reviewed, or Translation Error states – The status of the work order changes to Cancelled.
In-Progress state – The order is stopped at the end of the next ASDL command. The ASDL rollback mechanism is used to roll back the provisioning activities performed by completed ASDLs. The status of the work order changes to Cancelled.
Completed or Failed states – The ASDL rollback mechanism is used to roll back all completed ASDLs. The status of the work order changes to Cancelled.
Stopped state – If the work order is stopped without rollback, the completed ASDLs are rolled back and the order is moved into a Cancelled state. If the work order is stopped with rollback, the order is moved directly into a Cancelled state.
The Translation Error operation applies when the SRP transmits a work order that contains translation errors to the SARM. The SARM does not activate the work order; instead, it maintains it in a Translation Error state. The following qualifications apply when the states listed below are updated with a Translation Error order:
Non-Existent orders – The SARM accepts the work order.
Initial, Held, Reviewed, or Translation Error states – The SARM accepts the work order and overwrites the existing copy of the work order with the order update.
In Progress, Cancelled, or Completed states – The SARM rejects the translation error work order.
Failed states – the SARM aborts all CSDLs on the work order and updates the existing copy of the order using a newly generated work order, with the same work order ID and a different service request ID.
During a Hold operation, a work order is given the Held status, and the SARM retains the work order and activates it only after receiving a release request or an order update. The following qualifications apply when the states listed below are updated with a Hold order:
Non-Existent orders – The SARM accepts the work order.
Initial, Held, Reviewed, or Translation Error states – The SARM accepts the work order and overwrites the existing copy of the work order with the order update.
In Progress, Cancelled, or Completed states – The SARM rejects the Hold order.
Failed states – The SARM aborts all CSDLs on the work order and updates the existing copy of the order using a newly generated work order with the same work order ID and a different service request ID.
The Stop operation halts a work order that is in In-Progress state. It contains an option to specify whether the completed ASDLs must be rolled back. Once the work order is stopped, you can restart it by changing its status to the Initial or Cancelled state.
The Stop operation can only be used on a work order that is in the In-Progress state. This operation is rejected on all orders that are in other states.
The SARM accepts the following order types:
Immediate
Future
Batch
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 NE. 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 with each other. This is best suited to large numbers of instances in the batch that span many NEs for better performance. The user can specify an error threshold associated with such batch groups that, if exceeded, results in the entire batch being stopped.
The SARM contains many features that enable you to efficiently manage connections to network elements.
Managing Connect/Disconnect Requests – When the SARM establishes that a particular ASDL must be routed to a network element, it determines the NEP that manages the network element and the current status of that network element. When a connection to the network element has been established, the SARM transmits the highest priority ASDL for that network element to the NEP.
Primary/Auxiliary Connection Requests – The first connection opened to a network element is called the primary connection. If the SARM determines that additional connections to a network element are required, it opens auxiliary connections.
Spawn and Kill Thresholds – ASAP enables you to configure the SARM to control the number of connections to a particular network element according to the number of ASDL commands awaiting processing on that network element. If the number of ASDL commands exceeds a configurable limit (the spawn threshold), the SARM automatically transmits a request to spawn another connection to the network element.
The SARM sends a network element Disconnect request via the NEP according to the number of ASDL commands awaiting processing on the network element.
Work Order Priority – Orders that have higher work order priorities assigned to them are given processing preference at the ASDL level. The work order priority dictates the sequence in which ASDLs are queued for the same network element. This queueing ensures that if there are multiple ASDLs from different work orders in a particular network element pending queue, the higher priority ASDLs are sent to the network element first. The priority of the ASDLs is dictated by the priority of the work order from which they are spawned.
For more information, refer to ASAP System Administrator's Guide.
Recent Change Retransmission – The Recent Change Retransmission (RCR) functionality in the SARM lets you retransmit all provisioning commands in their original provisioning sequence to a particular network element, within a specified time period.
This functionality is required for some older network elements that may lose their recent change commands due to an unexpected outage, and therefore require retransmission of these commands.
The SARM performs the following order scheduling activities:
Releases immediate orders – Batch or individual orders are released immediately upon receipt and are processed by composite priority. CSDLs (and attached ASDLs) within work orders are processed in the order in which they were configured in the work order.
Releases future-dated orders – Batch or individual orders are released at their respective due dates and times. To determine which orders are past due and must be released for provisioning, the SARM polls the database for such orders every user-configured interval. These work orders are processed by composite priority. CSDL (and attached ASDLs) within work orders are processed in the following way:
The SARM checks an OSSJ work order for a provisioningSequenceNumber for each CSDL within the work order.
If no such number is found, ASAP checks for originalSequenceNumber
If the value is found, then ASAP applies this value to the ServiceSequenceNumber. If all other CSDLs within the work order also use the provisioningSequenceNumber, then ASAP processes each CSDL based on this value.
The SARM checks an OSSJ work order for a originalSequenceNumber for each CSDL within the work order.
If no such number is found, then ASAP processes the CSDLs in the order in which they were received, and gives them a sequence number that start at 5 and increments by 5 for each new CSDL.
If the value is found, then ASAP applies this value to the ServiceSequenceNumber. If all other CSDLs within the work order also use the originalSequenceNumber, then ASAP processes each CSDL based on this value.
Manages explicit order dependencies – If the SRP notifies the SARM that a particular work order depends on the completion of another work order, the SARM manages the dependency and starts provisioning the child order once the parent order is complete. This is useful for from-and-to orders, multiline orders, etc.
The following dependency conflicts can arise:
A child work order is not released for processing until the parent work order is processed.
A separate cancellation request is required for each child and parent work order.
The parent work order is not cancelled until all of its child work orders have been cancelled.
Manages implicit order dependencies – If the SRP does not specify explicit dependencies for future-dated work orders, the SARM manages the dependencies for orders with the same due date and time.
This feature lets you schedule large numbers of orders of equal work order priority for the same due date and time. The SARM prioritizes these orders using the order action, potentially avoiding the Interfering Station or Blocking Service conditions that have implicit ordering of one or more orders. For example, from-and-to orders whose relationship has not been explicitly specified by the SRP.
For each NE, the SARM releases delete action orders first, change action orders next, and add action orders last. It uses the composite work order priority to determine this ordering.
When one work order is dependent on another (a parent/child relationship), the SARM manages the dependency and starts provisioning the child order once the parent order is complete. This feature is useful for from and to and multiline orders.
The following are possible parent/child relationships:
Multiple child orders with a parent – A parent work order can have more than one child.
Parent work order transmitted first – If a parent work order is transmitted before any child work orders, the parent work order is processed first. Child work orders start provisioning once the parent order is complete.
Child work order transmitted first – If a child work order is transmitted before its parent, it is saved in the database in an Initial state until the parent order is complete. Once the parent work order is complete, the Batch Handler picks up the child order for provisioning. When there are multiple child orders, they are picked up for provisioning in a sequence determined by their composite order priority.
The Batch Handler is a SARM thread that periodically fetches all pending provisioning and cancellation requests for the system (territory in HA mode) and processes them based on the composite priority mechanism.
Child order without a parent – If a child work order is transmitted without a parent, it is saved in the database in Initial state.
Child order with in-progress parent – The child work order is saved in the database in Initial state until the parent work order is complete. The child work order is picked up for provisioning after the parent completes.
Child order with completed parent – If the child work order is an immediate order, it is released at once for provisioning. If the child work order is not an immediate order, it is saved in the database in Initial state, and the Batch Handler picks it up and releases it for provisioning at the scheduled due date and time.
Child order with failed parent – The child work order is saved in the database in Initial state.
Routing information is defined either in the SARM database tables (static routing) or in the work order itself (dynamic routing).
The static routing feature reads network element information, such as network element technology and software load, from static, user-controlled configuration tables in the SARM database.
ASAP also provides extended dynamic routing functionality. Using dynamic routing, ASAP routes work orders according to routing information that is already contained in the work order (such as IP addresses and user IDs), rather than information configured in the SARM database tables. Based on specific information contained in the work order, ASAP routes the translated ASDLs to the appropriate network element.
Dynamic routing provisioning supports the many smaller network elements that can be found in IP-based networks, but the feature can be used by all of the downstream communication protocols supported by the NEP.
ASAP contains the facilities to analyze work orders and to provision them accordingly. For example, when ASAP recognizes that dependencies exist between service actions, it determines what actions can be performed in parallel. The SARM processes work orders in one of two ways:
Serial processing is performed when the SARM processes ASDLs on a particular work order as there are often dependencies between ASDL commands. The SARM processes ASDLs serially when there are dependencies between different ASDL commands. For example, in a POTS activation, an option can be added only after a line is created. At any given time, there is a maximum of one ASDL being provisioned on a particular work order.
Parallel processing occurs when the SARM processes the ASDLs from different work orders at the same time and can interleave them with each other at the network element interface. In addition, ASDLs on different work orders can use different connections to the same network element, if multiple connections are available for that network element.
In addition to transmitting ASDL commands to the NEP, the SARM is also responsible for interpreting the resulting ASDL responses.
ASDL responses include ASDL success, failure, retry and so forth.
In ASAP, you can define variables that apply to ASDL responses. For example, you can configure a retry threshold should the ASDL command fail to be completed in a prescribed time period. The retry threshold defines the number of times that an ASDL command is retried before being failed by the SARM.
The SARM performs error threshold management to control the release of ASDL commands to a network element and prevent an excessive number of errors from occurring.
The error threshold specifies the number of delayed failures that can occur before the SARM stops the order. This error threshold can be set on the individual work order or, if not specified, assumes a default specified by a SARM configuration variable. This functionality can accommodate batch orders containing many instances of the same provisioning activity within one SARM work order. If a specified number of such instances fail, the SARM stops the work order.
In addition to managing responses from the network element, the SARM generates notification events and sends them to the SRP while provisioning a work order.
ASAP system events can be configured to trigger system alarms. For example, if a routing error occurs, or if the provisioning of a work order exceeds a configurable period of time, SARM can generate an event that triggers an alarm in an upstream system.
You can configure system events for each CSDL completion and failure. For example, you can configure the CSDL commands associated with cellular work order provisioning to issue a particular system event, which triggers a system alarm to page a user about the cellular work order failure.
In addition to notifying the SRP of events, the SARM server maintains statistical data on work order provisioning, including the number of orders processed, successfully completed, and requiring user intervention.
This information is available to real-time performance monitoring tools. ASAP provides the ability to audit all transactions involved in work order provisioning. All work order auditing messages are stored in an audit table in the SARM database. The user can query work order audit trail records through an ASAP client or third-party monitoring tools.
|
 Copyright © 2005, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
