5 Creating and Configuring Atomic Actions and Action Processors

This chapter describes how to create and configure Oracle Communications ASAP atomic actions and action processors.

About Creating and Configuring Atomic Actions

An Atomic Service Activation Layer (ASDL) or atomic action command is an ASAP command that is associated with a particular Common Service Description Layer (CSDL) or service action command. A service action describes the service action to be performed, and can contain one or more one atomic action. The atomic actions associated with the service action performs the operations on one or more Network Elements (NEs) in order to fulfil the services action.

The naming convention for a network cartridge atomic action is as follows:

A_vendor-technology_softwareload_action_entity

where

• A_: This prefix indicates an atomic action.

• vender: see "Selecting the Vendor Token"

• technology: see "Selecting the Technology Token"

• softwareload: see "Selecting the Software Load Token"

• action: see "Selecting the Action Tokens"

• entity: see "Selecting Entity Tokens"

Atomic action command names include A_ (for atomic action) and attributes including the cartridge identification elements (tokens), verbs, and entities that have been selected for the cartridge in "Mapping Network Element Commands to Actions, Entities, and Parameters". The tokens are separated by underscores, and compound tokens include a dash as a separator. If the software load token includes a "." it is replaced by a dash. All characters in the name must be in upper case.

If entities are used, entity should include the service package in its name. For example an atomic action belonging to the GSM service package would be named as follows:

A_CSCO-IOS_12-2-X_ADD_GSM-MAX-PREFIX

Service cartridge atomic actions do not have to follow this naming convention.

Oracle Communications Design Studio for ASAP automatically enforces this naming convention when you create an atomic action with the Atomic Action Wizard.

Creating and Configuring an Atomic Action

You can create an atomic action using Design Studio with the Atomic Action Wizard.

Each atomic action within the SARM has a configuration record that you can set up. This record contains the following attributes:

• Atomic action timeout and retry properties:

• Atomic action used for rollback: Determines which rollback atomic action command the SARM must use if a rollback is required.

• Routing support: You can choose the routing method you want to use to send the atomic action to the Network Element Processor (NEP).

tbl_asdl_config is a user-populated static table that defines the atomic action configuration information required to handle routing and rollback at the atomic action level. It is used by the SARM to determine whether rollback is required for this atomic action, and if so, the rollback atomic action to use.

To configure an atomic action using Design Studio:

1. Select Studio, then New, then Activation, then Atomic Action.

2. From the Atomic Action Wizard, do the following:

   • Enter an action name that corresponds to an network element (NE) command.

   • Enter an entity name that corresponds to an NE service name or service package you want to configure.

3. Click Finish.

   The Atomic Action editor appears.

4. In the Details tab, select a routing method for the atomic action from the Routing Support list:

   • None: Indicates that no routing method has been selected.

   • DN Routing: Indicates that DN routing has been selected. For more information about DN routing, see "Configuring Atomic Action Routings by Using a Directory Number"

   • NE Routing: Indicates that NE routing has been selected. For more information about NE routing, see "Configuring Atomic Action Routings by Using a Network Element"

   • ID Routing: Indicates that ID routing has been selected. For more information about ID routing, see "Configuring Atomic Action Routings by Using ID_ROUTING"

   • User Defined Routing: Indicates that user-defined routing has been selected. For more information about user-defined routing, see "Configuring Atomic Action Routings by Using USER_ROUTING"

   • Dynamic Routing: Indicates that dynamic routing has been selected. For more information about user-defined routing, see "Configuring Dynamic Routing"

   
   

   Note: Selecting a routing methods populates parameters specific to the routing method you selected in the Atomic Action editor Parameters tab.

   
   

5. In the Details tab, select atomic action routing configuration information from the Details Information section:

   • Provide Parameter Count: Select to indicate that the NEP should send the current index value for the atomic action.

   • Index Count: Specify the name of the parameter for obtaining the index value in Java provisioning classes.

   • Timeout (Second): Specify the number of seconds before the ASAP server considers an atomic action in-progress as failed. The default value is 0, which means ASAP server will not consider the atomic action in-progress as failed. For more information, see "About Retry Properties".

   • Rollback Atomic Service: Specify an atomic action that rolls back the changes of the current atomic action in a failure scenario.

     For example, atomic action A is mapped to service action B. The rollback is configured on the service action. On the Atomic Action editor, in the Details tab, for the atomic action entity A, you select an atomic action Y. In case of a failure scenario, the service action B is rolled back and atomic action Y is called to rollback the action of atomic action A. For more information, see "About Configuring a Rollback Atomic Action"

   • Retry: Enables the Retry Count and the Retry Interval fields. For more information, see "About Retry Properties".

   • Retry Count: Specifies the number of times the atomic action can be tried at the NE. For more information, see "About Retry Properties".

   • Retry Interval (Second): Specifies the time interval, in seconds, between each retry attempt by ASAP. For more information, see "About Retry Properties".

About Retry Properties

Retry properties instruct the SARM to retry an atomic action command according to the Retry Count and Retry Interval parameter that you have configured. If the atomic action command does not complete after the final retry, the SARM fails it.

Timeout and retry attributes are configurable at:

• The atomic action level using the Timeout (second), Retry Count, and Retry Interval (second) attributes. These attributes are defined in the Design Studio Atomic Action editor Details tab

• At the NE level using the Drop Time Out (minutes), Retry Count and Retry Interval attributes. These attributes are defined in the Design Studio Network Element editor General tab

• At the work-order level

• At the system level

If an atomic action needs to be retried, the atomic action timeout and retry attributes are applied first. If no atomic action timeout and retry attributes are configured, the attributes configured for the NE apply. If no timeout and retry attributes are configured for the NE, the work order attributes are applied. If no work order timeout and retry attributes are configured, system-wide attributes are used.

If ASDL_TIMEOUTS is disabled in the ASAP.cfg file, all atomic action timeouts are disabled, regardless of whether timeout and retry data is configured for the atomic action.

These properties are specified on the work order. Default retry properties are also specified in ASAP.cfg.

Table 5-1 Retry Properties

Property	Description
NUM_TIMES_RETRY	Specifies the number of atomic action retries to be applied to an atomic action command if the atomic action fails with a “Fail But Retry” condition.
RETRY_TIME_INTERVAL	Defines the time interval between atomic action retries if an atomic action fails with a “Fail but Retry” condition.

When defining hard error thresholds, you must consider the following points:

• The host NE, atomic action command, and atomic action command user exit code must already be defined.

• The same host NE, atomic action command, and atomic action command user exit code combination can only be used once.

For more information about configuring user exit types, see "Configuring Base Exit and User Exit Types".

Because different NEs often have different retry requirements, it is necessary to provide a flexible retry mechanism that enables retry properties to be specified at the NE 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 NEs 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 the Retry Interval, which will be used whenever a retry occurs, on any NE 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, these values will override those defined elsewhere in the system (including the ASAP.cfg: file, atomic action level, or NE instance level).

• Atomic Action: If you specify the Number of Retries and Retry Interval at the atomic action level, and 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 NE 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 NE 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 NE 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 NE instances dynamically created using the template will inherit the retry values you specify. These values will override those defined at the ASAP.cfg: level.

Figure 5-1 Retry Properties Locations

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

A specific vendor's NE 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 NE 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 NE instance level. The work order will fail only if the configured Number of Retries is exceeded.

To configure retry properties at the NE 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 NE instances of that type.

   To do this, update the retry values in the NE editor for each NE 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 NE 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 NE templates, NEs, and dynamic NE templates that were changed have been saved.

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

Example 2: Configuring Retry Properties at the Atomic Action Level

When trying to change the LEN on a specific vendor's NE, the NE 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 NE'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 NE instances that are created), for each NE 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 NE 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.

About Delayed Failure Properties

Delayed Failure properties instruct the SARM to continue provisioning an order until the Order Delayed Failure Threshold is reached and the order is failed. These properties are work order properties.

Table 5-2 Delayed Failure Properties

Property	Description
Delayed Failure Property	Requests the SARM to treat all hard errors on atomic actions as Delayed Failures. The SARM skips any subsequent atomic action in the service action, continues provisioning at the next service action, and then fails the order. You can use the Delayed Failure property to override the ASDL_EXIT configuration in the State Table program or Java method. This property should only be set when there are no dependencies on subsequent service actions on the work order. Upon hard failure of an atomic action, the associated service action is failed by ASAP, even if the Delayed Failure property is set.
Order Delayed Fail Threshold	Specifies the number of delayed failures that a particular order can have before the order is explicitly failed. This property is intended for batch orders.

Rollback must be turned off for delayed failure to work.

About Composite Priorities

The composite priority mechanism ensures a balance between maximizing throughput and the need to provision higher priority atomic actions over those with lower priority. This mechanism does not guarantee the explicit sequential execution of work orders. Rather, it is designed to ensure that high priority orders are not impeded by lower priority orders that are in progress at the same time. ASAP will use any available processing power to activate orders, and does so by activating many orders in parallel across many network devices.

After orders are placed in the in-progress queue, each atomic action on the order inherits the work order properties including the due date and time, order priority and action. These attributes are used to determine where the atomic action should be placed in the pending queue but do not guarantee that it will be provisioned in advance of any other atomic action. The following diagram shows the importance of the attributes (from left to right) in the prioritization of the atomic action. Details of the algorithm are explained in the main flow of the use case.

Figure 5-2 Composite Priorities

ASAP maintains one pending queue for each NE. Many orders are processed at the same time but only a single atomic action is active for each order at any given time due to the serial nature of atomic action processing within an order. In other words, if there are 100 orders in progress, there are 100 active atomic actions. While ASAP is processing a high priority atomic action for one work order, atomic actions from lower priority orders will also be processed against different NEs. ASAP retrieves future-dated orders from the database based on their due date/time, and subjects these orders to composite prioritization at the atomic action level. When a work order is submitted to ASAP, it is subject to BATCH_SLEEP_INTERVAL, which is the time period between SARM database queries for orders that have become due.

Composite priorities operate as follows:

1. A work order is submitted into ASAP with the following attributes:

   1. Due date and time

   2. Priority

   3. Action (query, remove, change or add)

2. When the order arrives at its due date and time and BATCH_SLEEP_INTERVAL expires, its first atomic action, referred to as the active atomic action for the purposes of this example, is inserted into the pending queue according to the following algorithm:

   1. Search through the pending queue comparing the priority of the active atomic action (as inherited from the work order) to those already in the queue. If there are no atomic actions with identical priorities insert the atomic action into the queue according to its priority (in other words, an active atomic action with a priority of 4 is inserted behind an atomic action with a priority of 3 but ahead of an atomic action with a priority of 6 – the lower the number, the higher the priority and hence the closer to the front of the pending queue) and proceed to step 3.

   2. For the subset of atomic actions in the pending queue whose priorities match the active atomic actions priority, ASAP examines the due dates and times of each and inserts the active atomic action into the queue according to its due date and time. In other words, the active atomic action is inserted behind atomic actions with older due dates and times but ahead of atomic actions with newer due dates and times. atomic actions with older due dates and times are closer to the front of the pending queue. Go to step 3.

   3. For the subset of atomic actions in the pending queue whose priorities and due dates and times match the priority and due date and time of the active atomic action, insert the atomic action into the pending queue according to its action. An active atomic action with an action of “Query” is inserted ahead of atomic actions with other actions. The priority of the action from highest to lowest is Query, Remove, Change, Add.

3. Eventually the atomic action is moved to the in-progress queue where it provisions and completes. While the SARM is being notified that the atomic action has completed an idle connection is detected and another atomic action may be scheduled.

   If the active atomic action is placed in the retry queue, the retry timer starts. During the time the active atomic action remains in the retry queue other atomic actions may be scheduled.

   When the retry time interval expires and the atomic action is placed back in the pending queue, step 2 is repeated.

The following diagram shows multiple pending queues (one for NE A and one for NE B). NE A has many high priority atomic actions (for example: priority 1, 2) in its pending queue while NE B has many lower priority atomic actions (for example priority 7, 8, 9) in its pending queue. Because there only low priority atomic actions in NE Bs pending queue, these will be provisioned at the same time as the high priority atomic actions on NE As pending queue.

The following diagram shows a single queue containing low priority atomic actions when a high priority atomic action arrives. The high priority atomic action is inserted ahead of all lower priority atomic actions in the pending queue and as a result will be placed in-progress before any of the others. When the high priority atomic action has completed, the SARM must be notified and an idle connection will be detected. At this time another atomic action (possibly of greater, equal or lower priority) may be scheduled (for example: in this example the atomic action with priority 7).

Figure 5-3 Pending Queues

About Configuring a Rollback Atomic Action

You can configure atomic actions in the system to perform rollback on a failed provisioning activity by setting its rollback flag and specifying a rollback atomic action command. For example, if you have an atomic action for creating a service, you can select a rollback atomic action from deleting a service. See "Creating and Configuring an Atomic Action" for instructions about enabling the rollback feature and assigning a rollback atomic action to a standard atomic action. You must also enable the rollback functionality at the service action level to enable atomic action rollback. To enable rollback at the service action level, see "Enabling the CSDL Rollback Functionality".

Note: The SARM will only roll back atomic actions that you have configured with these settings.

Atomic actions can perform the following types of rollback:

Table 5-3 Atomic Action Rollback Types

Rollback	Description
Provisioning Rollback	Used when a work order fails while provisioning.
Cancellation Rollback	Used when a cancellation request is applied to an existing order in the SARM.
Correction Rollback	Used when a correction request is applied to an existing order in the SARM.

About Rollback Atomic Action Parameters

The parameters that are sent to the rollback atomic action are automatically pre-determined, consequently, you do not need to define or configure the atomic action parameters for a rollback atomic action command in tbl_asdl_parm. Rollback parameters are created in the atomic action State Table using the SEND_PARAM action function with an option of R (or ReturnRollbackParam) in the JInterpreter.

If a rollback parameter is created for an atomic action using SEND_PARAM, the value of this parameter remains the same for the rollback atomic action. For example, if a rollback parameter is created in another atomic action using the same name as the initial rollback atomic action parameter, the value of this new rollback parameter will not overwrite the value provided to the initial rollback atomic action. If you send a rollback atomic action parameter that has the same name as the forward atomic action, the rollback atomic action parameter takes precedence. When the rollback atomic action is executed, it receives the value of the rollback atomic action parameter.

The rollback parameters created by a particular atomic action are provided exclusively to its rollback atomic action command, and are not shared with other atomic actions. You cannot use rollback parameters to share information between rollback atomic actions.

About Atomic Action Rollback Functionality

The following sections describe additional considerations for rollback functionality.

Rollback Order

Atomic actions are rolled back in reverse order of completion. When the rollback process begins, the last completed atomic action is rolled back first, followed by the second-to-last completed atomic action, etc.

Rollback Failure

The rollback of an atomic action can either complete or fail. During rollback processing, the status of every rollback atomic action is recorded as either Completed or Failed.

If the configuration variable is set to 0, the service action status will be set to "rollback successful" even if one or more rollback atomic actions fail to complete. The failure of a rollback atomic action is ignored and the rollback of previous atomic actions continues.

If the configuration variable is set to 1, the service action status will be set to "rollback failed" if a rollback atomic action fails for any reason.

Order Timeout

The order timeout parameter is ignored on rollback.

Rollback Completion

Rollback processing ends when the final rollback atomic action has either completed or failed. If the rollback was initiated as a result of a cancellation, a work order Completion Notification is sent to the SRP. In all other cases, the SRP receives a work order Failure Notification.

Rollback Upon Failure

When a work order fails, the SARM performs the following rollback steps:

1. As the SARM loads a work order for provisioning, it scans all of the service actions in the work order to determine if one or more has been configured for rollback in the event of failure.

2. If none of the service actions have been configured for rollback in the event of failure, rollback is not performed if the work order fails.

3. If rollback has been configured on one or more service actions and the work order property specifies rollback, the SARM sets a global flag on the work order to indicate that rollback is required.

4. If the work order fails, the SARM notifies the SRP that rollback is to be performed and starts the procedure.

5. When rollback is complete, the SARM sends an Order Failure notification to the SRP.

   
   

   Note: During normal provisioning, when atomic action failure occurs, the SARM immediately fails the work order and rolls back all successfully completed atomic actions.

   
   

Rollback Upon Cancellation of an Order

When processing a work order cancellation, the SARM does not reference the service action rollback configuration, but invokes rollback at the atomic action level.

Note: The ASAP work order cancellation functionality is intended to provide the ability to cancel a work order in the short period of time between the submission of an order to ASAP and the reception of an event indicating the order is in a final state (such as completed, failed). Oracle recommends that orders are not canceled outside this window as this can lead to additional un-needed performance overhead and fallout risk in ASAP. For example, terminating the service of a subscriber that has been successfully created means rolling back all of the original atomic actions rather than simply deleting the subscriber (a single atomic action). In addition, because data in ASAP should be maintained only for a limited period of time (see data purging and archival strategies section), use of cancellation functionality is subject to purging constraints.

The SARM performs the following rollback steps when a work order is cancelled:

1. When the SARM receives the cancellation request, it halts the work order when the current atomic action completes.

2. Before the rollback operation begins, the SARM notifies the SRP that the work order rollback is to be performed.

3. The SARM references the atomic action log to determine which atomic actions have been completed on the order.

4. The SARM rolls back completed atomic actions for which rollback is configured and rollback atomic actions are defined.

5. Upon completion, the SARM sends the SRP a Completion Notification.

Depending on the status of the work order when it is cancelled, a different rollback procedure is performed. The different work order status values and their corresponding rollback procedures are described in Table 5-4:

Table 5-4 Cancellation Order Status Rollback Procedures

Order Status	Rollback Procedure
Initial order	The order is cancelled and no provisioning is needed or occurs.
In Progress order	The SARM accepts the cancellation request and begins to roll back the order when the current atomic action on the work order completes. It reloads all completed atomic action commands from the database, determines which ones require rollback by referencing their rollback flags, and then executes the rollback atomic action commands. When the rollback procedure is complete, the SARM transmits a work order Completion Notification to the SRP. No reference is made to the work order rollback flag or to the rollback status of the service actions.
Completed order	The rollback procedure is identical to the procedure used for In-Progress orders, except there is no delay at the start, such as waiting for the last atomic action to complete before starting to roll back the order.
Failed order	The rollback procedure is identical to the procedure used for Completed orders.

Rollback Upon Revision to an Order

For the failed order to be rolled back explicitly, one or more service actions must be configured for rollback. The SARM automatically rolls back the work order before receiving and processing a new copy of it.

The rollback procedure for a revision or correction request depends on the state of the work order as described in Table 5-5:

Table 5-5 Revision Order Status Rollback Procedures

Order Status	Rollback Procedure
Initial order	The order is overwritten and no rollback occurs.
In Progress order	The SARM rejects the request for an order revision or correction from the SRP and no rollback occurs.
Completed order	The SARM rejects the order revision or correction request and no rollback occurs.
Failed order	If all service actions on the work order are aborted, then no explicit rollback is performed.

If explicit rollback is not performed upon receipt of an order failure and revision request, the activation of a new copy of the work order may cause a fallout at the NE because parts of the original work order may have been activated. Intelligent NE State Tables in the ASAP NEP manage such potential conflicts. After concluding that a provisioning request has failed, the State Table queries the switch and determines if the provisioning activity represented by this command has already been applied to the NE. If so, ASAP issues a soft error and continues processing the new order.

Note: If rollback is not performed explicitly, the SRP can be designed to transmit a cancellation request on the original order, and then send a correction order that is dependent on the cancellation. In this way, the failed order is rolled back and the revision is only applied when the cancellation is complete.

Table 5-6 shows database variables and tables that you must configure to implement rollback of completed atomic actions:

Table 5-6 Rollback of Completed Atomic Actions Parameters

Variable	In Table
ignore_rollback	tbl_asdl_config
rollback_req	tbl_csdl_config

For information on these database tables, refer to ASAP Developer Reference.

Configuring ignore_rollback

This configuration variable is located in the tbl_asdl_config table in the SARM database:

• If it is set to Y, rollback is ignored for the specified atomic action even if the rollback flag on the work order is set to Y.

• If it is set to N, rollback is required for the specified atomic action.

  
  

  Note: If employing the delayed_failure property (see "About Delayed Failure Properties"), rollback must be turned off. Service action-level rollback must be set to N, and ignore rollback must be set to Y.

  
  

The following example employs a configuration that requires:

• Setting the work order wo_timeout parameter to the required value.

• Configuring the rollback parameters in tbl_asdl_config.

In this example, the work order has one service action with three atomic actions. The expected result is that the work order fails after exceeding the time specified in the wo_timeout parameter on the work order and all completed atomic actions are rolled back.

Figure 5-4 Rollback Sequence of Operations

1. SRP submits work order to the SARM for provisioning.

2. The SARM starts provisioning the work order and sets the timer for work order timeout based on the timeout value. The SARM sends a WO_STARTUP event notification to the SRP.

3. The SARM starts provisioning the first atomic action in the work order.

4. The first atomic action is successfully provisioned.

5. The SARM starts provisioning the second atomic action in the work order.

6. While provisioning the second atomic action, a work order timeout occurs.

7. The SARM sends a WO_TIMEOUT (Fail) event notification to the SRP. The SARM resets the timer to zero and waits until the second atomic action completes.

8. When the second atomic action completes (with a Success or Fail status) all successfully completed atomic actions are rolled back.

9. The SARM sends a WO_ROLLBACK event notification to the SRP.

10. Rollback completes and the work order is failed. The SARM sends a WO_TIMEOUT (Fail) event notification to the SRP. The SARM may also send a WO_FAILURE event notification to the SRP.

About Atomic Action to Java Method or State Table Mappings

State Tables and Java classes (collectively referred to as programs) are resident programs invoked by the State Table Interpreter or JInterpreter, respectively, during the provisioning of a work order. State Tables and Java classes are the interface between specific NEs and atomic action command execution.

Atomic action-to-program translation is the process of defining which State Tables or Java classes are called upon to perform the function specified by the atomic action command.

Programs provide the basic facilities to communicate with and provision an NE. atomic action commands are mapped to the appropriate programs using the technology and software version of the NE.

When the NEP receives an atomic action command and its parameters from the SARM, the NEP uses the NE_ID to determine the technology and software load for the NE with which it is communicating. Using the atomic action command, technology, and software load, the NEP determines whether the program is to be invoked by the State Table Interpreter or JInterpreter. The program then processes the atomic action command. This atomic action-to-program mapping is kept in a configuration record in the SARM database.

Table 5-7 shows how the same atomic action command can map to various technologies (switches) and various software loads.

Table 5-7 Atomic Action-to-Program Mappings

Atomic Action Command	Technology	Software Load
CLEAR_INTERCEPT	DMS	BCS35
CREATE_LINE	DMS	BCS35
SET_OPTION_ON	DMS	BC35
CLEAR_INTERCEPT	INV	1.0
CREATE_LINE	INV	1.0
SET_OPTION_ON	INV	1.0

Atomic action-to-program mapping relationships are defined in tbl_nep_asdl_prog.

About Atomic Action to Java Method Provisioning Command Ratio

Whenever possible, each atomic action should map to a method containing only one provisioning command.

In some less common scenarios, where several actions must be executed on the NE in sequence (for example, to maintain a context on the NE or when overhead would otherwise be incurred in entering and exiting modes on the NE), it may be necessary to map a single atomic action command to more than one action. As a general rule, the fewer commands associated with the atomic action, the easier it is to use the atomic action as a building block in the implementation of higher level services.

Important examples highlighting the scenario where multiple API commands must be encapsulated within a single atomic action are on NEs that require certain modes to be set before a command can be sent to the NE such as the Cisco router cartridge where atomic action commands always encapsulate IOS commands to manage the modes. The reasons this approach was taken for this particular cartridge are:

• Performance – encapsulating the mode commands increased ASAP and router performance substantially.

• Reduce complexity - the service model became less complicated, allowing the service modeler to focus on implementing service offerings rather than having to understand and model mode setting dependencies for every service.

• Averted the need to have complex mutex logic implemented in the cartridge. For example multiple ASAP work orders destined to the same NE result in interleaved atomic actions. In the Cisco scenario without the mutex logic, interleaving means atomic actions will fail because the router is in an indeterminate mode for any given atomic action (different atomic actions need different mode settings).

• Averts the need to implement additional connection handling logic. For example if the connection to the router is lost at any point, there is no need to determine, if any mode setting commands must be re-executed. Because each atomic action sets its own mode, this problem is avoided.

For additional considerations at the service action level, see "About Limiting Independent Network Element Commands to Optimizing the Network Element Interface".

Creating an Action Processor

To create an action processor:

Note: This procedure also includes information about creating a C++ State Table and program. This feature is included for legacy C-based cartridges.

1. From an Activation project, select Studio, then select New, then Activation, and then Action Processor.

2. From the Action Processor Wizard, enter the following:

   • In the Project field, select a cartridge project to associate the action processor to.

   • In the Action field, enter an action name to characterize the purpose of the action processor (see "Selecting the Action Tokens".

   • In the Entity field, enter an entity that the object of the action (see "Selecting Entity Tokens").

3. Click Finish.

   The Atomic Action editor appears.

4. Select one of the following from the Type list:

   • Java Action Processor (with Code Generation): Auto-generates Java classes and methods configured for the protocol and attributes you selected. If you select this option, do the following:

     1. Click New.

        The Studio Activation Java Implementation Wizard appears.

     2. In the Package field, enter a valid package name.

     3. In the Name field, enter a name for the Java method.

     4. Click Finish.

        Design Studio automatically generates an action processor and test case with the same vendor, technology, and software load of the project. For more information about the autogenerated Java code, see "Creating Java Action Processors".

   • Java Action Processor: Allows you to create a Java class and method without any autogenerated content. If you select this option, do the following:

     1. In the Class field, enter a class name.

     2. In the Method field, enter a method name.

     3. Manually create the Java classes and methods to implement your network connection. For more information about the autogenerated Java code, see "Creating Java Action Processors".

   • State Table: Allows you to create a State Table and program. If you select this option, do the following:

     1. In the State Table field, enter a State Table name.

     2. In the Program field, enter a program name.

     3. Click New.

        An empty program file opens. You must manually code this program.