|
|
Runtime Administration may be required for the configuration files that are already present, or any newly added configuration files. You may require to add some configurations specific to the deployed environment and want to modify the configuration file at runtime. Runtime Administration APIs are available for the purpose of allowing user-specific files to be managed. The following section describes how the runtime administration works and the APIs that can be used for customizing runtime administration.
How Runtime Administration Works?
Whenever a DMS registers with the Central Server, a new directory with the DMS name is created under the <Central Home>/conf/probe/ directory.
The configuration files present under the <Central Home>/conf/probe/ defaultToNewProbes directory of the Central Server are copied to the <DMS Home>/conf/probe/ <DMS Name> directory.
When a DMS-specific update is made to the configuration files at runtime, the changes are first effected in the DMS-specific directory in the Central server and then copied to the DMS and the DMS database is updated if necessary.
This ensures that for any Distributed Mediation Server, the configuration files are always up-to-date in the Central server. This helps in faster access to the configuration data and also in re-configuring the Distributed Mediation Server which is temporarily down, so that the next time it reconnects, the configuration changes take effect.
Adding User-Specific Runtime Administration
When runtime administration needs to be performed for a user-specific file, implementations need to be provided at the Client, Central Server and the Distributed Mediation Server.
For the User Interface, the implementation should take care of displaying and manipulating the configuration details contained in the user-specific file. This includes
a new user interface
representing the data contained in the user-specific file in the new user interface
taking care of transferring the modified data to the Server.
For the Central Server and the Distributed Mediation Server, the user implementation should take care of the actual file updates with the data received from the Client. In the Distributed Mediation Server, in addition to the file, the database may also need to be updated.
Details of implementations are provided as follows:
The Client implementation
must be specified in the RuntimeConfig.xml
file present in <Central Home>/conf
directory
(in the case of standalone Client, the RuntimeConfig.xml will be present
in the <Standalone Client Home>/conf
directory).
The Central Server implementation must be specified in the ConfUpdnListeners.xml file present in the <Central Home>/conf directory.
The Distributed Mediation Server implementation needs to be specified in the ConfUpdnListeners.xml file present in the
<DMS Home>/conf directory.
If runtime configuration support is required for a user-specific file the following implementations need to be provided at the Client:
Runtime Administration Data representation ->Takes care of representing the configuration data.
Runtime Administration Data Model -> Takes care of how the Distributed Mediation Server is represented in the Client UI.
User-specific Interface -> Takes care of UI specifications for the data that need to be modified at runtime.
Details of DMS List and Data Display Area
The Distributed Mediation Server list and the data display area are contained in a JPanel and this container panel implements the ProbePanelListener interface.
This implementation registers to receive notifications for runtime changes in the Client tree node.
Each Client tree node for which runtime configuration is enabled is identified by a unique identifier called Module ID.
This id is used during the notification process and for user-specific service, the Module ID needs to be set to 1000 or above.
When a node corresponding to a service like discovery or performance is selected, the names of the Distributed Mediation Servers that have registered to receive notifications for that service are loaded in the Distributed Mediation Server list.
The data corresponding to the file is represented as an implementation of RTAData interface.
When a node is selected from this list, the corresponding data is fetched from memory and loaded in the data display area.
The implementation that performs the fetching and manipulation should be either Single Object Model or Multi Object Model which extend AbstractRTADataModel.
At startup, the RunTimeConfig.xml file present in the conf directory is read to initialize the Client UI.
This file contains the entries for the modules and the respective module implementations for runtime administration.
The user-specific interface implementation for the module needs to be mentioned in this configuration file.
Runtime Administration Data representation
The data corresponding to the options present
in the middle tree should be of the type RTAData
. The RTAData interface provides methods to manipulate the
data during navigation of nodes in the middle tree. The methods of the
interface are explained below:
The getKey() method is used to uniquely identify the sub-nodes
present under the Distributed Mediation Server node in the middle tree.
This method returns a String value corresponding to the name of the sub-node.
The
setKey()
method is used to set the key value for the sub-nodes under the Distributed
Mediation Server node in the middle tree. This method takes the key value
as input in the form of String.
|
public String getKey(); public void setKey(String key); |
The clone() method is used to create a new sub-node based on an
existing node. This method is invoked when copy followed by paste option
is used in the UI. This method returns an Object that has the same values
as the original node but different name identifying it.
|
public Object clone(); |
The
equals() method is used
to check if any modifications have been effected for the currently selected
module data. This method is invoked when the user navigates from one node
to another and the data need to be updated. This method takes the data
that needs to be updated in memory as input. If the data have been modified
and the changes have not been applied to the server, a mark is placed
near the Distributed Mediation Server node to indicate that the values
for this node have been changed but not applied.
|
public boolean equals(Object obj); |
The validate() method is used to check if the values entered in the data
display area are in the required format.
|
public void validate(); |
Runtime Administration Data Models
Data Models
The Distributed Mediation Server list is based on a Data Model which can be based on either Single Object Model or Multi Object Model. The Single Object Model is used when the configuration data do not contain any sub-nodes in the XML form and can be associated directly to the Distributed Mediation Server name for example, data associated with network discovery. The Multi Object Model is used when the configuration values need to be listed as sub-nodes under the Distributed Mediation Server node, for example, data associated with polling, event parsers and trap parsers. The left tree is an example of Single Object Model and the right tree is an example of Multi Object Model.
Each node in this list is represented as RTAData. When the panel is loaded, only the names of the Distributed Mediation Servers are loaded. In a Single Object Model, the Distributed Mediation Server is represented as RTAData; and in Multi Object Model, the leaf nodes are represented as RTAData.
When a node is selected, the XML data corresponding to that Distributed Mediation Server name are fetched from the Central Server and displayed in the data display area. If another node is selected, the current node's data is saved in memory and the new data is fetched from memory.
To indicate that the
node has been modified but the changes have not been applied, the modified
icon 
is displayed alongside the Distributed Mediation
Server node. If a new Distributed Mediation Server node is selected, the
modifications need to be applied before moving to the new node and this
is prompted through a dialog.
Implementation
Extend the class
DefaultMultiObjectModel or DefaultSingleObjectModel to create the data model to be displayed in the Client UI.
If the configuration values are directly associated with the Distributed
Mediation Server name, Single Object Model can be used and if the module
contains more than one category of information that needs a separate representation
in the Client UI, the Multi Object Model needs to be used. The methods
in the abstract class are described below :
The loadData() method is used to load the configuration-related data and form the middle tree component. Based on the Data Model implemented, the middle tree will contain only the Distributed Mediation Server names; and in the case of Multi Object model, sub-nodes under the Distributed Mediation Server nodes. This method takes as input a hash table which contains the key corresponding to the module and the data that need to be displayed.
|
public abstract boolean loadData(Hashtable xmlHash); |
The costructXML() method is used to convert the modified data that is to be updated into an XML node. This method returns a hash table containing the required data in XML form.
|
public abstract Hashtable constructXML(); |
The getConfProperties() method is used to fetch the configuration file properties, such as moduleName, downloadFile, etc. This method returns a Properties object containing the configuration properties.
|
public abstract Properties getConfProperties(); |
The getDefaultUserObject() method is used to create a new object on screen when the Add option is used in the Client UI. This method returns an Object containing the default properties for the new object.
|
public abstract Object getDefaultUserObject(); |
Implement the ProbePanelListener to register to listen for notifications.
To register as a
listener to the Probe Panel, use the addProbePanelListener()
method of ProbePanel component.
To set the data model, use the setProbeDataModel() method; and to initialize, use the initialize() method.
The methods in the ProbePanelListener interface that need to be implemented are described below:
The setUserObject() method is invoked whenever the user selects a node in the middle tree. This method is used to display the data corresponding to the node selected in the data display area. The input to this method is the data that need to be displayed in the Client UI.
|
public void setUserObject(Object uo) {} |
The getUserObject() method is invoked when the user navigates from one node to another. This method is used to collect the data that is currently displayed in the data display area, which contains the latest modifications. The output is the modified values in the form of Object data type.
|
public Object getUserObject(){} |
The updateUserObject() method is invoked when modify option is used. This method is used to update the data based on the latest modifications in memory. The input to this method is the data that need to be updated obtained through the getUserObject() method.
|
public void updateUserObject(Object uo); |
The getModuleID() method is used to get the ID that uniquely identifies the module. This method returns an integer value that corresponds to the module invoked.
|
public int getModuleID(); |
The getRequiredXMLFileNames() method is used to obtain the name of the files associated with the module. If the runtime configuration update will be effected in more than one configuration file, the multiple file names can be mentioned in this method. This method returns a Vector containing the XML data read from the file.
|
public Vector getRequiredXMLFileNames(); |
The getModuleDisplayName() method is used to get the module name that needs to be displayed in the status bar of the Client UI. This method returns a String value corresponding to the module.
|
public String getModuleDisplayName(); |
In the implementation for the Apply button in the Client UI, the applyToServer() method of the ProbePanel interface needs to be invoked. This takes care of updating the modifications present in the memory to the respective configuration files.
Implementation at Central Server and Distributed Mediation Server
On startup, the Central Server reads the
ConfUpdnListeners.xml present
in the <Central Home>/conf
directory to get the implementation for runtime configuration changes.
This implementation should implement the ConfUpdnListener interface
and takes care of registering to receive notifications for the required
services. The fireConfUpdate()
method performs the required update to the configuration file when modified
data is received from the framework.
The ConfUpdnListeners.xml file present in the <Central Home>/conf directory, should contain the name of the implementation that will act as the listener for updating the configuration file changes. A sample entry is shown below:
|
<CONF_UPDATION_LISTENERS> <LISTENER key="FAULT_PARSERS" className="com.adventnet.nms.extranet.remote.rta.server.noc.NOCRuntimeParserUpdater" /> </CONF_UPDATION_LISTENERS> |
The fireConfUpdate() method of ConfUpdnListener
interface is used to make the necessary changes to the configuration files.
This method takes the configuration properties as input and the XML data
that is to be updated. This method should be present in the implementation
specified in the ConfUpdnListeners.xml file present in the <Central
Home>/conf directory.
|
public void fireConfUpdate(Properties confProps, XMLNode xmlElem); |
Implementation at Distributed Mediation Server
On startup, the Distributed Mediation Server reads the ConfUpdnListeners.xml present in the <DMS Home>/conf directory to get the implementation for runtime configuration changes. This implementation should implement the ConfUpdnListener interface and takes care of registering to receive notifications for the required services. The fireConfUpdate() method performs the required update to the configuration file when modified data is received from the framework and also performs database updation if required.
The ConfUpdnListeners.xml file present in the <DMS Home>/conf directory should contain the name of the implementation that will act as the listener for updating the configuration file changes. A sample entry is shown below:
|
<CONF_UPDATION_LISTENERS> <LISTENER key="FAULT_PARSERS" className="com.adventnet.nms.extranet.remote.rta.server.probe.RuntimeParserUpdater" /> </CONF_UPDATION_LISTENERS> |
The fireConfUpdate() method of ConfUpdnListener interface is used to make the necessary changes to the configuration files. This method takes the configuration properties as input and the XML data that is to be updated. This method should be present in the implementation specified in the ConfUpdnListeners.xml file present in the <DMS Home>/conf directory.
|
public void fireConfUpdate(Properties confProps, XMLNode xmlElem); |
|
|