| Oracle® Communications ASAP Server Configuration Guide Release 7.2 E24629-01 |
|
 Previous |
 Next |
This chapter provides information about configuring network element processors (NEPs), resource pools, and devices.
The NEP is the ASAP component that manages all interaction with network elements (NEs) and Element Management Systems (EMSs). The NEP receives Atomic Service Description Layer (ASDL) requests from the Service Activation Request Manager (SARM) and determines the State Table scripts or Java scripts that are required to execute a dialog with the NE. It returns responses and the provisioning status from the NE to the SARM.
To manage a large number of NEs, multiple NEPs can be deployed.
A single NEP communicates with NEs through two types of interpreters: C-based and Java-based. C-based interpreter uses a set of State Tables that act as an interface between specific NEs and ASDL command execution. The Java interpreter executes Java provisioning classes. These Java provisioning classes support next-generation protocols such as CORBA, HTTP, and XML.
When you start ASAP or the NEP, both NEP interpreters are created (the Java Interpreter must be configured to start). The status command shows two processes for an NEP: a C process and a Java process. The name of the Java process appears as J$NEP ($NEP refers to the UNIX environment variable representing the NEP server name). The J prefix indicates a Java process.
Host and Remote NEs
A host NE is a network element that has an interface through which remote NEs can be provisioned. Several remote NEs covering a given area can be associated with a host NE, which increases the effective coverage of the NE group. Host NEs are not required to have remote NEs assigned to them. An EMS can be considered a host NE if it is configured to manage multiple physical NEs.
Figure 7-2 shows service requests in the form of ASDL commands that are routed through the host NE to the appropriate remote NE.
Every ASDL references a target NE and a software load and version. This information can be configure statically in ASAP or can be provided dynamically as parameters on a work order. The software load and version is used by ASAP to identify a specific interpreter type (C or Java) and program (State Table or Java class.method) to execute.
This section describes the session manager, command processor, State Table Interpreter, and JInterpreter in more detail.
A session manager is a thread that manages all high-level interaction with an NE regardless of how many connections are established to that NE. There is a one-to-one relationship between NEs and session managers within the NEP. Each NE has one session manager that manages at least one resource pool.
A resource pool is a set of dedicated or shared communication devices that use specific communication protocols and parameters. For example, if NEs are serial asynchronous lines, these devices correspond to physical serial ports.
There are different types of resource pools in the NEP:
Primary Pool – A pool dedicated to a particular NE. It is only used to communicate with that NE. It is not necessary that all devices in the primary pool are used.
Auxiliary Pool – A pool used to connect to any of the NEs that the NEP manages. A session manager can acquire these devices to communicate with its NE. When the session manager no longer requires the devices, it returns them to the auxiliary pool for other session managers to use. For example, a serial modem device could be part of an auxiliary pool.
For example, consider an NEP that is managing two NEs. The first NE has a primary pool of two devices, the second has a primary pool of one device, and the NEP has an auxiliary pool. Figure 7-3 represents the NEP configuration.
A command processor is a thread that is spawned for each device, in either the primary or auxiliary pool, that manages all interaction with the NEs on a particular connection by using State Table programs or Java methods.
When a session manager receives the first connect request from the SARM, the session manager binds to a command processor in its primary pool. It requests the command processor to connect to and log in to the NE. This connection is termed the primary connection. There is only one designated primary connection to each NE. All other connections to this NE are auxiliary connections, even if they use devices from the primary pool.
The SARM uses a configurable threshold to determine when auxiliary connections to a particular NE are created and destroyed. If auxiliary connections are required, the SARM sends an NE Connect request to the session manager. The session manager then uses an available command processor in its primary pool to open another connection to the NE. If there are no other available devices in the primary pool, the session manager attempts to bind to a command processor from the secondary pool. By doing this, the session manager can manage many concurrent connections to a given NE. For instance, an NEP with five concurrent connections to an NE maintains one session manager and five command processors to manage that NE.
Each command processor can invoke either a State Table Interpreter or JInterpreter. There are still two physical processes within the NEP: a C/C++ process and Java process. The C/C++ process houses the core NEP functionality including the State Table Interpreter. The Java process hosts the JInterpreter.
The layers of functionality of the command processor are:
Application Layer – Handles the communication to the session manager and uses the Interpreter functionality to provision ASDLs through either State Table or Java execution.
Communication Layer – Employs the Multiple Protocol Manager (MPM) functionality to connect to host NEs through various communication protocol drivers. The MPM connects devices to host NEs with various communication protocols. MPM functionality provides a transparent interface between the user-created scripts and the protocol-specific communication details. Protocol-specific communication parameters such as asynchronous serial (wired or dialup), TCP/IP (Telnet, FTP, socket), LDAP, and SNMP interfaces are maintained in the SARM database. The NEP loads these parameters from the SARM after determining the communication protocol to use and prior to connecting to the NE. Every device interface driver provides the functionality to connect to the NE, disconnect from the NE, and transfer data using the specified protocol.
The communication layer functionality is transparent to ASAP users. Once a connection is established to the NE, the application layer handles the execution of the ASDL. The communication layer takes over when problems occur with the connection to the NE. If an ASDL was being executed when the problem occurred, the SARM is notified.
ASAP's interpreters execute custom code (State Table or Java) to handle device-specific communication with NEs. The custom code is designed to allow for easy, flexible and modular changes to the communication interfaces between ASAP and network elements. State Tables or Java provisioning classes are developed and maintained by a solutions developer (systems integrator, cartridge developer or professional service) independent of the core ASAP product.
Figure 7-4 shows the logical NEP command processor structure.
Interpreter code is commonly used for:
NE Integration – The interpreters provide the basic facilities to communicate to, integrate with, and provision an NE. Different versions of State Tables or Java provisioning classes can be applied to the same NE technology but use a different software load. ASDL commands are mapped to the appropriate program using the technology and software version of the NE.
Virtual Screen Emulation – Interpreters provide the ability to communicate with an NE using VT100 terminal emulation.
NE Response Parsing – The interpreter framework provides the ability to parse NE responses. For example, NE reports can be analyzed to determine the status of the provisioning request.
Once ASAP is in production, modifications to interpreter programs are normally required only when new services are added.
NEP interpreters can load provisioning programs from either the database or the CLASSPATH. Once loaded, they are maintained in a cache for faster access. This cache can be flushed during runtime so that the NEP can dynamically reload State Tables for execution. This allows developers to dynamically load and execute new or modified provisioning programs without having to restart the server.
Cache flushing is accessed via asap_utils options "103. Flush State Table Cache".
|
Note: Only State tables can be flushed. |
With the JInterpreter, you can use Java to provision NEs. The JInterpreter is a Java server process that receives requests from the NEP and executes particular methods in Java classes. Downstream protocol support is provided by the core product (telnet) or by third-party libraries (CORBA, LDAP, and socket).
A Java process is paired with each C/C++ NEP process. Each Java process maintains the set of JInterpreters that execute Java provisioning classes assigned to that NEP. When the NEP starts, both State Table and JInterpreter processes are created.
|
Note: You can optionally disable the Java-based component of the NEP. See "Device Enabling/Disabling" for more information. |
Programming with the JInterpreter requires custom connect methods to handle the logic of both connecting and logging in to the target element. This is the equivalent to LOGIN State Tables. Protocol libraries can be supplied either by third-party vendors (e.g. HTTP, JMS, LDAP, CORBA, SOAP, SFTP) or Oracle Communications (for example, telnet). The device type flag in JInterpreter only associates communication parameters with a specific protocol type (configured in tbl_comm_param). This means that communication parameters are made available to devices based on their association to the same device type. For information the internal mapping and management of protocols, see ASAP Cartridge Development Guide.
As with State Tables, new device types can be defined by modifying the constraints on tbl_comm_param and tbl_resource_pool to permit new device type definitions.
|
Note: Do not assign device types that are already used by the NEP. |
To provide application-specific functionality for the NE connection/disconnection, and provisioning, you must extend the following base classes:
com.mslv.activation.jinterpreter. NEConnection – A Java class that manages the connection and disconnection procedures to and from NEs. Developers need to implement the methods NEConnection.connect() and NEConnection.disconnect to perform the connection and disconnection from the NE. Oracle Communications provides default connection class implementations for telnet, socket, and LDAP. The socket and LDAP classes are wrappers around third-party libraries. Implementations for other protocols can be developed by a customer or integrator.
com.mslv.activation.jinterpreter.JProcessor – A Java class that contains one or more provisioning methods. The provisioning methods are the JInterpreter equivalent of State Tables. Provisioning classes must derive from the com.mslv.activation.jinterpreter.JProcessor Java class.
For information on JInterpreter Java classes, refer to the ASAP Java Online Reference.
Provisioning classes contain one or more provisioning methods. Provisioning methods are the JInterpreter equivalent of traditional State Tables. Provisioning classes must derive from the abstract class, mslv.activation.jinterpreter.JProcessor. Provisioning methods must be public methods of the provisioning class with the following signature:
public void aProvisioningMethod()
The mslv.activation.jinterpreter.JProcessor class provides details on obtaining ASDL parameter values, setting the ASDL exit type, and returning parameters to SARM. For example, the SocketProcessor custom class implements a method to access to socket for messages, and set ASDL exit state to SUCCESS.
A sample demonstration class showing the implementation of a JProcessor using a connection to a socket is located in
ASAP_Home/samples/JeNEP/jenep_demo/Socket/SocketProcessor.java
You can organize the methods into classes as required. The Java-enabled NEP, which maps ASDLs to provisioning methods, assumes a class name of technology_software load when no class is specified in the mapping; that is, when no dot ('.') is found in the program column of table tbl_nep_asdl_prog for the requested ASDL.
JInterpreter provisioning classes differ from State Table action functions. With State Tables, the logic used for State Table action functions is procedural while the JInterpreter is object oriented.
Each JProcessor instance (whether it is a manifestation of the JProcessor class or a subclass) is a separate object with its own attributes. If there are two JProcessor instances, each time a method such as returnInfoParm is called from an instance, the parameters are stored in an internal structure of each instance. If this method is invoked from two different class instances that implement the same parent class, the behavior of the two methods may not be the same.
If you call returnXXXParam in instance 1, the parameters are stored in instance 1's attributes. Calling returnXXXParam in instance 2 stores the parameters in instance 2's attributes. The attributes are not shared across instances. With the JInterpreter, the JProcessor instance that is mapped to the ASDL and loaded and executed by the JInterpreter is the instance whose parameters are retrieved and returned to SARM. Each JProcessor instance operates and maintains its own state. The advantage is that the JInterpreter allows concurrent ASDLs to be processed without affecting the specific parameters of each ASDL.
Oracle recommends that you separate the protocol logic (that is, the connection logic) from the provisioning logic. This facilitates the relationship between the communication protocols and provisioning logic resulting in easier maintenance.
For more information on the tbl_nep_asdl_prog table, refer to the ASAP Developer's Guide.
You can only reload provisioning classes that inherit from mslv.activation.jinterpreter.JProcessor. The lookup of classes is based on a delegation model. The following conditions apply when dynamically reloading provisioning classes:
If the class exists in the CLASSPATH, it is loaded by the primordial class loader. These classes cannot be unloaded.
If the configuration variable LOAD_JCLASS_FROM_DB in ASAP.cfg is set to 1, the class loader tries to find the class in the database. If it is not found in the database, then lookup proceeds to step 3.
If the class exists in the JINTERP_CLASSPATH environment variable, it is loaded by a URL class loader.
Use the JInterpreter utility script, jedd_utils to load the provisioning class to the database and to unload the provisioning class from the database. The jedd_utils options are:
[1] Add provisioning class [2] Delete provisioning class [3] List provisioning classes [Q] Quit
To add a provisioning class:
In the command line, type jedd_utils -c Control Server Name (the name you designated). The jedd_utils menu appears.
In the Enter an option field, type 1.
In the Program name field, type the name of the JInterpreter program using Package.class name format.
In the Class file name field, type the JInterpreter class path.
To delete a provisioning class:
In the command line, type jedd_utils -c $CONTROL (the name you designated). The jedd_utils menu appears.
In the Enter an option field, type 2.
In the Program name field, type the name of the JInterpreter program that you want to delete. The provisioning class is deleted using the Package.class name format.
To list provisioning classes:
In the command line, type jedd_utils -c <$CONTROL> (the name you designated). The jedd_utils menu appears.
In the Enter an option field, type 3. A list of the JInterpreter provisioning classes appears.
State Tables are interpreted database table-resident programs invoked by the State Table Interpreter.
State Tables are used primarily in ASAP NEPs but can also be invoked in other areas within ASAP. For instance, State Tables provide a mechanism for changing the base translation of a Service Request Processor (SRP). This can be useful as the needs of your company change and you require more sophisticated translation.
Programming State Tables is similar to writing macros. Oracle recommends that those who implement State Tables have some programming skills. In addition, they should thoroughly understand the entire provisioning process. Writers of State Table action functions should be skilled UNIX (or Linux) and C programmers.
A State Table can be created and maintained in a flat ASCII file. This allows effective source control and release procedures to be exercised in the development and release of State Tables. State Tables are compiled into SQL insert scripts to be loaded into the SARM database. To translate State Tables to SQL format use the oracomp_npg script.
When using oracomp_npg, keep in mind that the script inserts set_escape_on feature; as a result, backslashes that appear in the State Table are removed when the file is read into the database. Consequently, if you want to maintain control characters in the converted file, you must insert a backslash "\" before control characters.
For example, if the State Table contains the following line…
BCONCAT '%VAR_BIN_MML=%VAR_MML:\n'
…and you want to maintain "\n" as a control character, ensure that this line in the State Table reads as follows:
BCONCAT '%VAR_BIN_MML=%VAR_MML:\\n'
|
Note: It is not necessary to add a backslash to the control character "&". |
Table 7-1 shows the fields used in A line of State Table code.
Table 7-1 State Table Line Contents
| Field Name | Description |
|---|---|
|
Line number |
The four-digit line number for the programming statement. The starting line number must be greater than 0000. Oracle recommends that these line numbers be incremented in units of 10. This makes it easier to add lines later on. |
|
Action |
The name for the action code. This is the action to be performed. The associated action function is invoked. |
|
Action string |
A specific character string that is provided as an input parameter to the action function. |
|
Action integer |
A number that is provided as input to the action function that modifies its behavior. |
ASAP provides a set of State Table actions action functions used to write State Table programs. These actions suffice for most processing required to interact with an NE. However, you can provide additional logic in the State Tables.
|
Note: Writing State Table action functions or modifying existing ones requires a skilled UNIX (or Linux) and C programmer. These customized action functions reside in code that is controlled and maintained by the systems personnel. |
To provide additional logic in the State Tables, you can choose one of the following options:
Creating libraries of State Table functions that provide particular functionality using the existing State Table action functions. You can define libraries of State Table functions that are called from other State Table programs. This lets you create and group together State Table routines that perform related functions.
Writing new State Table actions that can be called from within the State Tables. Newly-created actions generally perform processing actions that either cannot be performed with existing state table actions, or would be too inefficient if implemented using state table logic alone.
Overwriting existing core State Table actions provided as part of the core product.
When the Interpreter executes a State Table, the Interpreter reads the State Table from the database. Subsequent calls for the State Table are returned from this cache.
The Interpreter provides a configuration variable, SWITCH_OPTIMIZATION, that causes the Interpreter to optimize State Tables as it loads them into memory. When executed, these State Tables may appear slightly different because the Interpreter executes the instructions in a different order.
For more information on customizing Interpreter State Table actions, refer to the ASAP Developer's Guide.
It is possible for one State Table to execute another before returning control to the initial State Table. This provides flexibility and modularity in State Table implementation.
The SARM is responsible for tracking the status (up/down) of NEs as well as the number of open and available connections to each NE. If an ASDL request needs to be routed to an NE with no available connections, the SARM coordinates with the NEP to create and initialize a connection. Once the connection is available, the SARM sends the ASDL to the NEP for interpreter execution.
Before ASDLs can be provisioned, ASAP must establish a connection to the NE. If this connection cannot be established, the device associated with the connection is automatically temporarily disabled.
You can use the Automatic Re-enable feature to re-enable the device after a configurable time interval. If the failed connection is the primary connection, the NEP retries connecting to the NE after a defined interval. If the failed connection is an auxiliary connection, the SARM is notified of the auxiliary connection failure.
Many NEs require a session to login before proceeding with provisioning. This logic is implemented in LOGIN state tables or NEConnection.connect() Java methods. A LOGIN/connect implementation can be provided for every software load and version combination. ASAP handles the execution of the login procedure before provisioning an ASDL. If the login fails, ASAP handles the event as a connection failure. Upon login failure, the connection is not disabled, instead, the command processor “sleeps” for a configurable interval and then retries the connection rather than disabling the device.
Similarly, when a particular NE requires logging off, ASAP handles this as part of the disconnection procedure. A LOGOFF State Table or NEConnection.disconnect() method can be defined for an NE to be invoked before disconnection from the NE occurs.
This section describes the connection requests in ASAP.
The first connection that is established successfully to an NE is designated as the primary connection. All subsequent connections are termed auxiliary connections. An end-user does not need to care or know whether their State Table or Java program has been assigned a primary or auxiliary connection.
A primary connection is treated internally by SARM. A primary connection is always the first connection to be established and the last connection to be dropped. Auxiliary connections on the other hand are spawned and killed according to thresholds for efficient connection management to an NE.
In dynamic routing, once the primary connection is dropped, the session manager for that NE is removed from memory.
For more information on dynamic routing, see page 196.
If more than one connection is required to an NE, auxiliary connections are opened. The SARM sends a connect request to the session manager which uses the next available command processor in its primary pool to open an auxiliary connection to the NE.
If there are no available entries in the primary pool, the session manager attempts to bind to a command processor from the secondary pool.
Dynamic routing never uses connections from the auxiliary pool, only from the dynamically-generated primary pool.
If the initial connection attempt fails or the port is configured to be disabled upon login failure and the login attempt fails, an auxiliary failure message is sent to SARM instead of retrying the connection.
ASAP supports dial-up connections to an NE via State Tables. A dialup connection is designated by specifying a serial port dialup device type. The NEP automatically performs login, logoff and retries as necessary to manage the dialup connection.
For more information, refer to ASAP Cartridge Development Guide.
The SARM controls connection disconnects by requesting that a session manager disconnect a device from an NE. The SARM issues disconnect requests based on kill thresholds or drop timer triggers.
The disconnect request types are:
Primary Disconnect – A primary connection is disconnected when there is only a primary connection to the NE and the drop timer has expired.
Auxiliary Disconnect – The SARM requests that one of the auxiliary connections be terminated. The session manager finds the appropriate command processor and requests it to disconnect from the NE. If the command processor is from the auxiliary pool, it returns to the auxiliary pool for all session managers within the NEP to use.
The SARM sends a request to the NEP to disconnect the primary connection to a particular NE after a period of provisioning inactivity, called Drop Timeout. If you set the drop timeout for a busy NE to a high value, such as 24 hours, the connection should never time out and is considered a dedicated connection. If you set the drop timeout to a lower value for an NE that is not very busy, the connection may time out depending on the load to the NE. In general, you should configure NEs that are busy to not time out, and NEs that are not busy to time out.
The DROP_TIMEOUT parameter is configured in tbl_ne_config in ASAP Developer's Guide.
As discussed above, primary connections are disconnected based on the drop timeout interval, while auxiliary connections are disconnected as the number of pending ASDLs drops below the kill threshold.
You can configure the NEP, using communication parameters in tbl_comm_param, to check the integrity of an idle connection by generating an idle ASDL after a period of inactivity on the connection. The period of inactivity is defined in the parameter IDLE_TIMER_INTERVAL in seconds. The idle ASDL is defined in the parameter IDLE_TIMER_ASDL. IDLE_TIMER_ASDL is mapped to a State Table which can then perform any user-defined functions.
You can configure any device that connects to an NE to trigger IDLE_TIMER_ASDL when the connection has been idle for a specified period of time. The NEP does not send a message to the SARM that is related to processing this special ASDL since the activity is entirely within the communication layer. You can associate any State Table program or Java method with this idle ASDL, and any return status generated by the program has no effect on previous or future ASDLs from the SARM.
The execution of the IDLE_TIMER_ASDL State Table or Java program generates a message warning that an idle connection is still alive.
The communication parameter IDLE_TIMER_INTERVAL defines the idle timer. If this parameter is not defined or is set to zero, the IDLE_TIMER_ASDL is not triggered regardless of how long a connection remains idle.
The idle ASDL Interval is set as follows:
IDLE_TIMER_ASDL = <ASDL NAME> IDLE_TIMER_INTERVAL = 60
When an NE becomes unavailable because of a Maintenance Mode condition returned from a State Table, the session manager notifies the SARM about the status of the NE and automatically performs periodic retries to re-establish the NE connection. The session manager also issues a MAINTNCE system event that can be used to notify ASAP users that the NE is in Maintenance Mode.
This section describes the connection thresholds in ASAP.
The SARM triggers the creation and login of new NE connections when the number of ASDLs in the pending queue exceeds the spawn threshold. Connections created in this manner are always auxiliary connections. Once an auxiliary connection has been established, it is used concurrently with other connections to provision ASDLs to a target NE.
By default, the NEP only opens a primary connection to an NE. However, auxiliary connections can be configured to act like dedicated connections by setting a very low spawn threshold.
If the spawn threshold is exceeded by more than one ASDL request, the SARM requests that the NEP establish another auxiliary connection. This process continues as long as:
The number of ASDL requests exceeds the spawn threshold.
Connections to the NE are available.
The maximum number of connections configured by the user is not exceeded.
|
Note: The spawn threshold must always be greater than the kill threshold if multiple connections are required to a particular NE. |
SARM triggers the logoff and destruction of NE connections when the number of ASDLs in the pending queue drops below the kill threshold. Connections dropped in this manner are always auxiliary connections.
When the kill threshold is exceeded, the SARM requests that one of the auxiliary connections be terminated. The session manager determines the appropriate command processor and requests that it disconnect from the NE. If the command processor was assigned from the auxiliary pool, it is returned to the auxiliary pool and is made available for all session managers within the NEP to use.
After each ASDL completion, the SARM determines if the current number of ASDLs in the Pending queue is less than the kill threshold. If it is and the ASDL was completed by an Auxiliary NE connection, the SARM sends an NE Disconnect request to the NEP. The NEP disconnects the appropriate Auxiliary port and the SARM decrements its count of available connections to that NE. This process continues as long as the ASDL Pending queue contains fewer ASDL requests than specified by the kill threshold, or until all Auxiliary connections are disconnected.
If the ASDL was completed on the Primary connection, the SARM does not send a disconnect request for the primary connection. Primary connections are dropped according to the drop timeout interval.
You must configure the maximum number of connections (MAX_CONNECTIONS) that can be established to each NE. The spawn threshold allows additional connections to be opened as required until the number of connections to the NE equals the maximum number of connections.
If the NE is configured within ASAP to allow more connections than is actually available in the primary and auxiliary resource pools, and the SARM sends a request to open the unavailable connection, the NEP sends an Auxiliary connection Failure Notification. When configuring the NE, you must ensure that the maximum number of allowed connections configured is not greater than the total number of connections available.
|
Note: All stored procedures that are accessed through ASAP APIs must return 0 to indicate if there is an open database cursor inside the stored procedure that needs to be closed by the ASAP C code later. If a stored procedure opens a database cursor and sends it back to the ASAP API, then the ASAP API needs to handle the closing of the connection, otherwise the connection stays open indefinitely. This may cause the ASAP system to crash when the maximum available connections are exceeded. |
Using the NE instance throughput control you can manage the number of ASDLs/transactions sent to the network element over time by specifying the minimum number of milliseconds each transaction should take. (A value of 0 disables NE instance throughput control.) Setting an appropriate value for throughput allows you to maximize the number of transactions processed while avoiding performance degradation due to flooding the NE with more requests than it can handle.
The throughput value is stored in tbl_ne_config in the column throughput. For more details, refer to ASAP Developer's Guide.
The NE throughput value can be configured when the NE is designed. In addition, the throughput value can be added to existing NEs or modified on existing NEs using asap_utils.
You can query the NE to confirm the throughput value and whether throughput on the NE is throttled by this value through asap_utils. See "7. ASDL/NE Queue Summary".
The System Administrator may want to deactivate an NE if, for example, the NE is down for maintenance or is in the process of upgrading. In this case, the System Administrator would:
Deactivate and subsequently reactivate the NE through an Administrative RPC Interface, available through asap_utils. When the NE is disabled, any ASDLs currently being provisioning are allowed to finish. All other ASDLs for that NE are sent to the Pending queue until the NE is reactivated.
For more information on asap_utils, see Appendix A, "asap_utils.".
Set up error thresholds for the NE to deactivate itself whenever it receives too many hard failures on commands. The Enhanced Error Management functionality provides a detailed tracking scheme for hard failures related to provisioning by an NEP.
Error thresholds control the release of specific ASDL commands to an NE to prevent an excessive number of errors from occurring. The SARM disables the NE if the actual number of consecutive errors exceeds the configured threshold in the specified time period. ASDLs for the NE are sent to the Pending queue until the NE is reactivated.
|
Note: The dynamic activation or deactivation of an entire NE is not persistent across SARM restarts. To permanently activate or deactivate an NE, you must update the NE definitions in the database. |
A device can be disabled as the result of a connection failure. If this device is the only connection to the NE, all provisioning to the NE stops until the device is re-enabled. A device can be re-enabled either manually or automatically. A device can be re-enabled manually by using the asap_utils utility. Or the device will be automatically re-enabled by the command processor after a period of time has elapsed.
An audit trail of all raw data transmitted to and from an NE can be used for diagnostic purposes. The ASAP System Administrator can enable or disable the dumping of such data to a file by choosing the Enable or Disable Line Diagnostics entry through asap_utils.
Communication to an NE through the device interface can be terminal-emulation-based or message-based. For terminal-based communication, the System Administrator can dump the contents of the virtual screen into a file by choosing the Enable or Disable Screen Diagnostics menu through asap_utils.
For more information on asap_utils, see Appendix A, "asap_utils.".
Typically, the purpose of an ASDL command is to provision NEs. The State Table or Java class.method associated with an ASDL sends provisioning commands and processes NE responses. Most NEs require login procedures to control access to the NE. ASAP has a set of ASDLs related to NE connection management procedures including login, logoff, dialup, and hang-up (in the case of modem connections), and connection integrity checking. These ASDLs are not sent from an upstream system or the SARM, but rather are executed by the NEP as part of connection management.
Since the connection management procedure is NE-specific, each connection management ASDL may require the execution of different State Tables or Java programs for different NE hosts.
The following connection management ASDLs are reserved as keywords to be used by ASAP. You must not use them as ASDL command labels. The reserved class.methods in brackets apply to Java programs
LOGIN (NEConnection.connect)
DIALUP
HANGUP
LOGOFF (NEConnection.disconnect)
The Resend Completed ASDLs function (also known as the Recent Change Retransmission (RCR) function enables you to resend successfully completed ASDL commands in their original provisioning sequence to an NE. This feature is intended for use in situations in which a NE has been recovered to a known state and ASAP is requested to re-activate all successful commands to the NE from that known state onwards.
This mechanism assumes that ASAP is the sole system provisioning such NEs. If not, there is no guarantee that the provisioning commands are entered to the NE in the same provisioning sequence because the multiple systems may not be synchronized in their updates.
SARM provides this functionality in the following ways:
SARM maintains a log of all successfully completed ASDL commands to each NE.
Upon your request, the SARM reloads all completed ASDL commands that are successfully completed on the NE within the specified time period.
The SARM then re-provisions these ASDL commands serially, in their original provisioning sequence.
Errors arising from this process are logged for you to view.
To resend completed ASDLs, use option 11. Resend Completed ASDLs of asap_utils. You can invoke asap_utils by typing the following at the $ASAP_base prompt:
asap_utils [-P ctrl_password] [option]
where:
[-P ctrl_password] is the password for the control database
[option] is the asap_utils option you want to invoke. For the Resend Completed ASDLs option, type 11.
|
Note: You can only use asap_utils to resend completed ASDLs; you cannot send RCR requests using the Order Control Application (OCA) client. |
The arguments for this option include the target NE, the start and end dates/times (in 'Mmm dd yyyy hh:mm[AM/PM]' format, for example 'Dec 31 2004 11:59PM').
When the you invoke the Resend Completed ASDLs command from asap_utils, ASAP determines all of the ASDL commands that have successfully completed on the network element and the sequence in which they were originally executed.
Specifically, if rollback is not being used, then RCR functionality retrieves all ASDLs with a state of ASDL_NEP_COMPLETE. These are ASDLs that have successfully executed on the network element, as shown in the following example.
Table 7-2 Inclusion of ASDLs (Rollback not in use) in RCR Order
| CSDL | ASDL | Description | Final ASDL State | Include in RCR Order? |
|---|---|---|---|---|
|
CSDL1 |
ASDL1 |
ASDL completes |
ASDL_NEP_COMPLETE |
Yes |
|
CSDL1 |
ASDL2 |
ASDL completes |
ASDL_NEP_COMPLETE |
Yes |
|
CSDL1 |
ASDL3 |
ASDL completes |
ASDL_NEP_COMPLETE |
Yes |
|
CSDL2 |
ASDL4 |
ASDL completes |
ASDL_NEP_COMPLETE |
Yes |
|
CSDL2 |
ASDL5 |
ASDL completes |
ASDL_NEP_COMPLETE |
Yes |
|
CSDL2 |
ASDL6 |
ASDL fails |
ASDL_NEP_FAIL |
No |
If rollback is configured, then the RCR functionality retrieves all ASDLs with a state of ASDL_NEP_COMPLETE or ASDL_NEP_RBACK_FAIL. ASDLs with a state of ASDL_NEP_RBACK_FAIL are those ASDLs that successfully executed on the switch but whose rollback ASDL has failed (rollback was triggered due to a subsequent ASDL failure on the order). The following example shows which ASDLs falling within the specified time period that would be included in an RCR order:
Table 7-3 Inclusion of ASDLs (Rollback in use) in RCR order
| CSDL | ASDL | Description | Final ASDL State | Include in RCR Order? |
|---|---|---|---|---|
|
CSDL1 |
ASDL1 |
Rollback of ASDL completes |
ASDL_NEP_RBACK_COMP |
No |
|
CSDL1 |
ASDL2 |
Rollback of ASDL fails |
ASDL_NEP_RBACK_FAIL |
Yes |
|
CSDL1 |
ASDL3 |
Rollback of ASDL completes |
ASDL_NEP_RBACK_COMP |
No |
|
CSDL1 |
ASDL4 |
Failure of ASDL triggers rollback |
ASDL_NEP_FAIL |
No |
The final ASDL state is not the state of the rollback ASDL itself, but the final state of the "forward" ASDL that is being rolled back.
ASAP then automatically generates a new RCR work order ID that contains a single CSDL that maps to all of the ASDLs that were successfully executed against the NE.
ASAP automatically submits and performs the RCR work order.
All ASDL commands are executed in the sequence in which they were originally executed until the work order is complete.
If during the execution of the RCR work order an ASDL exits with a hard failure, ASAP will interpret this as a delayed failure, allowing the entire RCR work order to finish executing before generating a work order failure event.
RCR work orders start with an RCR prefix (for example, RCR-031125184951). When executing this option, ASAP displays the new work order name before returning to the UNIX prompt.
NEP configuration information is held in static tables in the ASAP Control server database and the SARM database. To change configuration information, use the Service Activation Configuration Tool, or SQLplus sessions to invoke stored procedures.
This section outlines the procedures for configuring an NEP using stored procedures.
For instructions on using the Service Activation Configuration Tool, see Chapter 2, "Configuring ASAP Servers."
To add an NEP to the system, perform the following steps:
Export the current database using the export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML"). For example:
export_tool.sh -m -p abc -t config
Open the transOut2_config.xml file using a text editor.
gedit transOut2_config.xml
Remove all elements except for the existing NEP
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd"> <nepServer name="NEP_envid" xsi:type="NEPServerType"> <description>NEP Server</description> <system>envid</system> <territory>envid</territory> <diagnosticFilename>NEP_envid.diag</diagnosticFilename> <diagnosticLevel>LOW_LEVEL</diagnosticLevel> <autoStart>true</autoStart> <controlServer>CTRLenvid</controlServer> <interfaceHostname> <hostname>test.can.com</hostname> </interfaceHostname> <interfacePort>40013</interfacePort> <secondaryPool/> <jinterpreterPort>40014</jinterpreterPort> <program>asc_nep</program> <enableJInterpreter>true</enableJInterpreter> </nepServer> </activationConfig>
Where envid is the environment ID for your ASAP instance.
Modify the NEP element with new values where required. For example:
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd"> <nepServer name="NEP_2envid" xsi:type="NEPServerType"> <description>NEP Server</description> <system>envid</system> <territory>envid</territory> <diagnosticFilename>NEP_2envid.diag</diagnosticFilename> <diagnosticLevel>LOW_LEVEL</diagnosticLevel> <autoStart>true</autoStart> <controlServer>CTRLenvid</controlServer> <interfaceHostname> <hostname>test.can.com</hostname> </interfaceHostname> <interfacePort>40023</interfacePort> <secondaryPool/> <jinterpreterPort>40024</jinterpreterPort> <program>asc_nep</program> <enableJInterpreter>true</enableJInterpreter> </nepServer> </activationConfig>
Save the file.
Update the file using sactConfig as described in "Running the SACT Scripts".
To delete an NEP, perform the following steps:
Export the current database using the export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML"). For example:
export_tool.sh -m -p abc -t config
Open the transOut2_config.xml file using a text editor.
gedit transOut2_config.xml
Remove all elements except for the NEP you want to delete.
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd"> <nepServer name="NEP_2envid" xsi:type="NEPServerType"> <description>NEP Server</description> <system>envid</system> <territory>envid</territory> <diagnosticFilename>NEP_2envid.diag</diagnosticFilename> <diagnosticLevel>LOW_LEVEL</diagnosticLevel> <autoStart>true</autoStart> <controlServer>CTRLenvid</controlServer> <interfaceHostname> <hostname>test.can.com</hostname> </interfaceHostname> <interfacePort>40023</interfacePort> <secondaryPool/> <jinterpreterPort>40024</jinterpreterPort> <program>asc_nep</program> <enableJInterpreter>true</enableJInterpreter> </nepServer> </activationConfig>
Where envid is the environment ID for your ASAP instance.
Save the file.
Update the file using sactUnconfig as described in "Running the SACT Scripts".
To add configuration parameters to an NEP, perform the following steps:
Export the current database using the export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML"). For example:
export_tool.sh -m -p abc -t config
Open the transOut2_config.xml file using a text editor.
gedit transOut2_config.xml
Remove all elements except for the NEP you want to add configuration parameters to. For example:
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd"> <nepServer name="NEP_envid" xsi:type="NEPServerType"> <description>NEP Server</description> <system>envid</system> <territory>envid</territory> <diagnosticFilename>NEP_envid.diag</diagnosticFilename> <diagnosticLevel>LOW_LEVEL</diagnosticLevel> <autoStart>true</autoStart> <controlServer>CTRLenvid</controlServer> <interfaceHostname> <hostname>test.can.com</hostname> </interfaceHostname> <interfacePort>40013</interfacePort> <secondaryPool/> <jinterpreterPort>40014</jinterpreterPort> <program>asc_nep</program> <enableJInterpreter>true</enableJInterpreter> </nepServer> </activationConfig>
Where envid is the environment ID for your ASAP instance.
Add the configuration parameters. For example:
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd"> <nepServer name="NEP_envid" xsi:type="NEPServerType"> <description>NEP Server</description> <system>envid</system> <territory>envid</territory> <diagnosticFilename>NEP_envid.diag</diagnosticFilename> <diagnosticLevel>LOW_LEVEL</diagnosticLevel> <configurationParameters> <configurationParameter xsi:type="AUTOMATIC_BLACKOUT_CHECK"> <value>1</value> </configurationParameter> <configurationParameter xsi:type="CACHE_BLACKOUT_TABLE"> <value>1</value> </configurationParameter> <configurationParameter xsi:type="LOAD_JCLASS_FROM_DB"> <value>0</value> </configurationParameter> </configurationParameters> <autoStart>true</autoStart> <controlServer>CTRLenvid</controlServer> <interfaceHostname> <hostname>test.can.com</hostname> </interfaceHostname> <interfacePort>40013</interfacePort> <secondaryPool/> <jinterpreterPort>40014</jinterpreterPort> <program>asc_nep</program> <enableJInterpreter>true</enableJInterpreter> </nepServer> </activationConfig>
Save the file.
Update the file using sactConfigNR as described in "Running the SACT Scripts".
tbl_resource_pool is a static table that defines the collection of command processors (devices) that the NEP uses to establish connections to NEs. Groups of command processors can be contained in a resource pool. Each NE configuration determines a primary resource pool that contains one or more devices the NEP uses to connect to that NE. These devices are not used to connect to other NEs. Each NEP has an auxiliary resource pool that contains devices used by the NEP to establish connections to any NE managed by the NEP. These primary and auxiliary resource pools are defined in this table.
You must create resource pools and add resource pool devices by populating the tbl_rerouce_pool table before you can add command processors to it. You can create Java processors using Design Studio when you create Java cartridges.
This section outlines the procedures for creating, deleting, or editing resource pools and devices using the SACT. For instructions about using the Service Activation Configuration Tool, see Chapter 2, "Configuring ASAP Servers."
To define, delete, and list resource pools and devices using stored procedures, see Appendix B, "Configuring Resource Pools Using Stored Procedures".
To add a resource pool and device to the system, perform the following steps:
Export the current database using the export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML"). For example:
export_tool.sh -m -p abc -t config
Open the transOut2_config.xml file using a text editor.
gedit transOut2_config.xml
Remove all elements except for one of the default connection pools.
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
<connectionPool name="POOL">
<device name="dev1">
<environment>DEVELOPMENT</environment>
<lineType>TELNET_CONNECTION</lineType>
</device>
</connectionPool>
</activationConfig>
Where envid is the environment ID for your ASAP instance.
Modify the NEP element with new values where required. You can also create additional devices by adding device name elements. For example:
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig
M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd">
<connectionPool name="POOL2"> <device name="dev2"> <environment>DEVELOPMENT</environment> <lineType>SOCKET_CONNECTION</lineType> </device>
<device name="dev3"> <environment>DEVELOPMENT</environment> <lineType>SOCKET_CONNECTION</lineType> </device></connectionPool>
</activationConfig>
Save the file.
Update the file using sactConfig as described in "Running the SACT Scripts".
To delete an resource pool, perform the following steps:
Export the current database using the export_tool.sh (see "Transforming ASAP Database Configurations or Service Models into XML"). For example:
export_tool.sh -m -p abc -t config
Open the transOut2_config.xml file using a text editor.
gedit transOut2_config.xml
Remove all elements except for the NEP you want to delete.
<activationConfig xmlns="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2003/ActivationConfig M:\hlam_view\ASAP_base\ASAP\jmx\xsd\ActivationConfig.xsd"> <connectionPool name="POOL2"> <device name="dev2"> <environment>DEVELOPMENT</environment> <lineType>SOCKET_CONNECTION</lineType> </device></connectionPool> </activationConfig>
Save the file.
Update the file using sactUnconfig as described in "Running the SACT Scripts".
If ASAP must share a port to an NE with another system (as illustrated in the figure below) or if regular NE maintenance must be performed, you can define the NE blackout period during which time the NEP will not connect to that NE.
Figure 7-6 shows an NE blackout profile.
The NE Blackout feature automates ASAP NE Access blackout at scheduled times so that the ASAP System Administrator does not have to disable and enable the NE manually before and after the blackout period. When the NEP detects a blackout period during a check of a database table while executing the BLACKOUT State Table action, the NE is put into Maintenance Mode automatically.
You can configure the blackout period in two ways:
Weekly Periodic (Static) – A day of the week, start time, and end time are specified. For example, you can set regular maintenance on the NE to be performed every Sunday between 2:00 a.m. and 4:00 a.m.
Absolute Date and Time (Dynamic) – An absolute date and time for both the start and end periods are specified rather than a day of the week. For example, April 21, 2003 23:59 and April 22, 2003 1:59.
Table 7-4 displays the blackout information you can configure.
Table 7-4 Blackout Configuration
| Field | Explanation |
|---|---|
|
Host NE |
The identifier of the host NE. |
|
Day of Week |
The day of the week the blackout period starts and ends. If NULL, the blackout period is an Absolute Date and Time. |
|
Start Time |
The start of the blackout period. |
|
End Time |
The end of the blackout period. |
|
Description |
An explanation or reason for the blackout period. |
Note that if the dayname entry is present, then the configuration is considered to be Static. The implementation will check for the start time and end time alone, and assume that both fall on the same day. When configuring a blackout period that spans from one day to the next (for example from 22:00 until 01:00 the next day) you must configure two separate lines in tbl_blackout: one for 22:00:00 till 23:59:59 and another from 00:00:00 till 01:00:00.
Use the following stored procedures to define, list, and delete blackout definitions.
SSP_add_blackout – This procedure configures the static and dynamic blackout periods for a specific network element host.
SSP_list_blackout – This procedure lists blackout periods for a specific network element host.
SSP_del_blackout – This procedure removes blackout periods for a specific network element host.
For more information on these stored procedures, refer to ASAP Developer's Guide.
Blackout information is maintained in tbl_blackout. For more information on tbl_blackout, refer to ASAP Developer's Guide.
|
Note: NE blackout periods can be configured with XML using the SACT or the asapConfig utility. |
In previous versions of ASAP, executing the BLACKOUT action function is the only way to determine the NE blackout period. The BLACKOUT action function cannot be executed within certain predefined state table programs such as LOGIN, LOGOUT, DIALUP, and HANGUP. Consequently, the physical connection between ASAP and the NE is required to check NE blackout period.
You can now check the NE blackout period without having a physical connection with the NE.
If the AUTOMATIC_BLACKOUT_CHECK variable in the ASAP.cfg is enabled, the NEP checks the NE blackout period in two places without having a physical connection with NE:
Before connecting with the NE
Before processing an ASDL request
When the NEP detects the NE blackout period, the NEP disconnects every existing connection with the NE and notifies the SARM that the NE is in maintenance mode. Then the NEP checks the NE blackout period at the interval, in seconds, as configured in the ASAP.cfg file.
The BLACKOUT action function can be used to check the NE blackout period when AUTOMATIC_BLACKOUT_CHECK is set to 0. If AUTOMATIC_BLACKOUT_CHECK is set to 1, then the BLACKOUT state table action function will not do any processing. It will always return successfully and continue processing the remainder of the state table.
The stored procedure SSP_check_blackout enables you to check whether or not the specified network element is currently blacked out.
For more information on this stored procedures, refer to ASAP Developer's Guide.
Table 7-5 describes the ASAP configuration parameters that control automatic NE blackout checking functionality.
Table 7-5 NE Blackout Configuration Parameters
| Variable | Default | Description |
|---|---|---|
|
AUTOMATIC_BLACKOUT_CHECK |
0 |
The boolean type variable controlling automatic NE blackout checking.
|
|
CACHE_BLACKOUT_TABLE |
1 |
This variable controls whether the NEP caches the NE blackout table information in the memory or not. This variable works only when the AUTOMATIC_BLACKOUT_CHECK configuration variable is set to 1.
CACHE_BLACKOUT_TABLE =1 should not be used if you want to change blackout configuration on a regular basis. |
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
