Working with Retry Properties

Retry properties are set to allow retry of commands at the NE instance level and atomic action level.

When working with retry properties, see the following topics:

About Retry Properties

When a response from a network element is received that is mapped to a RETRY user-defined exit type (UDET), the Number of Retries value informs the system how many times the command should be retried before it is failed, and the Retry Time Interval is the amount of time between each retry.

As different network elements often have different retry requirements, it is necessary to provide a flexible retry mechanisms that enables retry properties to be specified at the network element instance level and at the atomic action level (this is in addition to the ability to configure a single set of system-wide retry properties, which apply to all atomic actions and all network elements that trigger a retry).

Flexible retry configuration in ASAP enables specification of retry properties in the following locations:

  • ASAP.cfg: This configuration file contains values for the Number of Retries and Retry Interval which will be used whenever a retry occurs, on any network element or atomic action, if no other values are configured elsewhere.

  • Work Order: If the Number of Retries and Retry Time Interval are specified on a work order, the values will override those defined elsewhere in the system (including the ASAP.cfg file, atomic action level, or network element instance level).

  • Atomic Action: If you specify the Number of Retries and Retry Interval at the atomic action level, if a retry is encountered on any of the action processors mapped to that atomic action, the values you specify will be used. These values will override those defined at the network element instance level and at the ASAP.cfg level.

  • Network Element Instance: If you specify the Number of Retries and Retry Interval on the Network Element editor, any command triggering a retry against this network element instance will use the retry values you specify. These values will override those defined at the ASAP.cfg level.

  • NE Template: If you specify the Number of Retries and Retry Interval on the NE Template editor, any network element created from the template will inherit the retry values you specify.

  • Dynamic NE Template: If you specify the Number of Retries and Retry Interval on the Dynamic NE Template editor, any network element instances dynamically created using the template will inherit the retry values you specify. These values will override those defined at the ASAP.cfg level.

Diagram is described in surrounding text.

Related Topics

Working with Retry Properties

Example 1: Configuring Retry Properties at the Network Element Instance Level

Example 2: Configuring Retry Properties at the Atomic Action Level

Understanding the Java Processor Class

Understanding Java with Code Generation

Understanding Java Libraries in Design Studio

Working with User-Defined Exit Types

Example 1: Configuring Retry Properties at the Network Element Instance Level

A specific vendor's network element often responds with a FUNCTION BUSY message, meaning that it cannot presently process commands and that the command should be retried at a later time (there is not necessarily any problem with the command itself, but the load on the network element is too large at this particular moment). Best practices dictate that a command will eventually succeed if tried 3 times with a 10 second interval between tries. To ensure that the command is properly retried, the service modeler should configure the retry properties at the network element instance level (see the following procedure). The work order will fail only if the configured Number of Retries is exceeded.

To configure retry properties at the network element instance level:

  1. In the User Defined Exit Type editor, update the user-defined exit type configuration entry that corresponds to the FUNCTION BUSY response to specify an exit type of RETRY when this response message is encountered.

  2. Modify the retry properties for any existing network element instances of that type.

    To do this, update the retry values in the Network Element editor for each network element instance as follows:

    • In the Number of Retries field, enter 3.

    • In the Retry Interval field, enter 10. (seconds)

  3. Modify the retry properties for any existing Dynamic NE Template used for network element instances of that type.

    To do this, update the retry values in the Dynamic NE Template editor as follows:

    • In the Number of Retries field, enter 3.

    • In the Retry Interval field, enter 10. (seconds)

  4. Ensure that all network element templates, network elements, and dynamic network element templates that were changed have been saved.

    After saving, you can deploy the configuration to an ASAP environment for testing.

Related Topics

Working with Retry Properties

Modeling Entities

Example 2: Configuring Retry Properties at the Atomic Action Level

When trying to change the LEN on a specific vendor's network element, the network element responds with an INVALID STATE error message if the customer line is in use. In this scenario, best practices dictate that ASAP retry the atomic action 10 times with an interval of 300 seconds between each attempt before a failure is be generated. The following example demonstrates how the service modeler configures the retry properties at the atomic action level to meet this criteria.

  1. In the User Defined Exit Type editor, update the user-defined exit type configuration entry that corresponds to the INVALID STATE response to specify an exit type of RETRY when this response message is encountered.

  2. When examining this network element's retry requirement, there are two options that would support the requirement:

    1. Modify the retry properties for the NE template (so that the configuration is carried over to any new network element instances that are created), for each network element instance of that type, and for each Dynamic NE template of that type.

    2. Modify the retry properties for the specific service action (change LEN). In this example, assuming the change LEN atomic action is specific to the vendor equipment in question (either a common atomic action mapping to only one vendor and technology, or a vendor and technology-specific atomic action mapping to a single action processor), and assuming the retry behavior specified for this requirement is unique to the atomic action (change LEN), then simply update the retry properties for the atomic action.

      Note:

      Option a) requires multiple updates (to the NE Template, each network element instance, and each Dynamic NE Template). Option b) requires a single update.
  3. Modify the retry properties for the change LEN atomic action.

    Update the retry values in the Atomic Action editor as follows:

    1. In the Number of Retries field, enter 10.

    2. In the Retry Interval field, enter 300. (seconds)

    Note:

    To update the retry value in an editor field, activate the field by selecting the corresponding check box. Retry values have no digit limit but must be positive integers. Retry values can be 0 if overriding the ASAP.cfg configured retry values is required.
  4. Save changes to atomic actions.

    You can now deploy the configuration deployed to an ASAP environment for testing.

Related Topics

Working with Retry Properties

Modeling Entities

Configuring Network Element Instance Throughput Control

Configuring User-Defined Exit Types

Working with Network Elements