Working with User-Defined Exit Types
User-defined exit types are values that describe the manner in which ASAP atomic actions complete. You can create your own values to describe exit scenarios specific to your own cartridge solutions.
When implementing user-defined exit types, see the following topics:
About User-Defined Exit Types
User defined exit types may be configured based on the base exit types explained in the table in "Extending User-Defined Exit Types" and other attributes like the following:
-
Service action
-
Action action
-
Vendor
-
Technology
-
Software load
-
Pattern
Creating New User-Defined Exit Types
Use the User-Defined Exit Type Wizard to create a user-defined exit type.
To create a new user-defined exit type:
-
Select Studio, then select Show Design Perspective.
-
Select Studio, select New, select Activation, then select User Defined Exit Type.
-
Select the project for this element and enter a name for the entity.
-
(Optional) Select a location for the entity.
By default, Design Studio saves the entity to your default workspace location. You can enter a folder name in the Folder field or select a location different from the system-provided default. To select a different location:
-
Click the Folder field Browse button.
-
Navigate to the directory in which to save the entity.
-
Click OK.
-
-
Click Finish to create the user-defined exit type.
Configuring User-Defined Exit Types
You can configure user-defined exit types using the User Defined Exit Type editor.
To configure a user-defined exit type:
-
In the Studio Projects view, double-click a User-Defined Exit Type entity to open the User Defined Exit Type editor.
-
In the User Defined Exit Types area, click Add.
This enables the fields in the User Defined Exit Types Detail area of the editor and populates those fields with default values.
-
In the Pattern field, enter a value.
For example, enter SUCCESS, DENIED, RESOURCE BUSY, and so on.
-
Select the corresponding base exit type.
-
Enter the User Defined Exit Type for this pattern.
For example, you might enter AA1_SUCCESS.
-
Select File, then Save.
Note:
Use the Service Action and Atomic Action fields when creating Service Cartridges.Working with User-Defined Exit Types
Working with Custom Action Processors
Extending User-Defined Exit Types
In ASAP, cartridge error messages are categorized and generally assigned one of the following base exit types:
| Atomic Action Exit Type | Description |
|---|---|
| SUCCEED | The atomic action executed successfully. The NEP successfully completes the atomic action command and the SARM provisions the next atomic action on the work order. |
| FAIL | Hard error. The atomic action failed. ASAP fails the entire work order and notifies the SRP of the WO Failure Event. If rollback is configured on the work order, the SARM rolls back any previously completed atomic actions. |
| RETRY | The atomic action will be retried later. While the atomic action is waiting to be retried, the connection to the network element can be used to provision other atomic actions destined to that network element (during Maintenance Mode, however, no other atomic actions are transmitted to the network element). If the atomic action command does not complete after the final retry, it is failed. The number and frequency of retry attempts is governed by work order properties. If these properties are not defined on the work order, the retry attempts is governed by ASAP.cfg configuration properties. |
| RETRY_DIS | A base exit type. The atomic action is not failed, but will be retired at a later time. ASAP disables the port that was originally used for the connection and forwards any future atomic action commands to other connections associated with the network element. This base exit type should be used when a connection is found to be in abnormal state and must be manually reset. |
| SOFT_FAIL | The atomic action has encountered a minor error, but the provisioning of the order completed successfully. For example, this exit type may occur when attempting to add a feature to a line that already has that option. |
| MAINTENANCE | The atomic action command failed because the network element is currently unavailable to receive provisioning requests. On receiving this atomic action response, ASAP moves the atomic action from the In Progress Atomic Action queue, and then marks the status of the network element as Maintenance. |
| DELAYED_FAIL | The atomic action failed during provisioning. The SARM skips any subsequent atomic actions associated with the service action and continues provisioning at the next service action. It then fails the order after all subsequent service actions have finished processing. Rollback and delayed failure are incompatible because the intent of this base type is to continue to provision subsequent service actions; rollback would reverse successfully provisioned service actions. Delayed failure should be used only when there are no dependencies on subsequent service actions. If dependencies exist, the subsequent provisioning actions will fail. |
| STOP | The atomic action has stopped processing. While the work order is in a stopped state, ASAP only accepts requests to resume or cancel this work order. |
For specific solutions, designers working with delivered cartridges will likely be required to customize the user-defined exit types provided in the cartridges for the following reasons:
-
Unusual connection behavior in which connections may be dropped in the middle of activations and need to be reset.
-
Various service actions and atomic actions must influence the base exit types that are assigned.
-
Network elements have specific preassigned static maintenance windows in which they are not available to receive activation commands.
Examples: User-Defined Exit Types
When working with user-defined exit types, see the following examples:
Example: Unstable Network Element Connections
Problem: On an Ericsson network element during activation (after a successful connection and login to the network element has already occurred) the login to the network element is randomly terminated. As an atomic action may be in progress against the network element at the time the connection was dropped it must be placed back in the queue for later activation and the connection must be re-established.
Solution: Configure a user- defined exit type with the RETRY_DIS base type that is triggered when the login prompt is detected during normal activation. This will allow for the atomic action to be retried at a later time after instructing ASAP to disable the current connection. If there is only one connection to the network element then ASAP will eventually re-enable the connection and re-login.
Examples: User-Defined Exit Types
Example: Configuration of Context Sensitive Exit Types
Problem: The customer has a network in which each HLR (referred to as a primary HLR) has a backup HLR (referred to as a secondary HLR). Services must be activated on both HLRs but if activations fail on primary HLRs the work order must be failed; if activations fail on secondary HLRs they must be soft failed.
Solution: Create different atomic actions that map to the same implementation. Configure two user-defined exit types that include the atomic action names in the configuration. Configure the base type for the primary atomic action with FAIL. Configure the base type for the secondary atomic action with SOFT_FAIL. The service model for this configuration is shown in the following diagram:
The user-defined exit type configuration is shown as follows:
In this example, whenever the response from the network element contains the strings SUB and EXISTS and the atomic action is A_HLR_ADD_SUB-PRIMARY, then a failure is triggered. Whenever the response from the network element contains the strings SUB and EXISTS and the atomic action is A_HLR_ADD_SUB-SECONDARY then a soft failure is triggered.
Examples: User-Defined Exit Types
Example: Exit Type Rationalization
Problem: There are too many exit type entries with similar attributes present in the configuration, resulting in potentially high maintenance costs.
Solution: Where possible, collapse multiple exit type rows. For example, collapsing rows that have identical attributes other than the software load may be possible when the network element responses remain the same across software loads. A prime example of when exit type rationalization should occur is when multiple delivered cartridges are employed in the solution for the same network element. Because the user-defined exit types in delivered cartridges always contain the vendor, technology, and software load attributes to ensure uniqueness, exit type rationalization is generally possible.
Examples: User-Defined Exit Types