9.0 SNMP Table Handling in Generated Code


9.1 Overview
9.2 Storing the Tabular Data

9.3 Initializing Tables at Start-Up

9.4 Index Handling


9.1 Overview


This section describes the code generated for tables using different storage models. Firstly, it is required to know how the data of a table are stored in the agent.


9.2 Storing the Tabular Data


The data given in tables can be stored in two formats, either in Agent Table Model or in Your Own Storage Model.


9.2.1 Agent Table Model


Agent Table Model is the default storage model provided by Agent Toolkit. As per this storage model,

The figure given below illustrates how the data are stored in AgentTableModel. Methods Generated for Agent Table Model


The Request Handler file has the following lines generated for a table.


For Getting an xxxEntry from Agent Table Model


The following method is called. This would return the xxxEntry corresponding to the specified instance.

For Getting the First Entry from Agent Table Model


The following method is called. This would return the xxxEntry corresponding to the first row (instance oid) in the table.

For Getting the Next xxxEntry from Agent Table Model


To get the xxxEntry corresponding to the instance oid immediately after the specified instance oid (inst), the following method is called.

For Creating a New Entry in the Agent Table Model


For creating a new entry in the Agent Table Model,

The 4 steps given above are repeated for all the rows in the Table.


For Adding the Row to the Agent Table Model


A row is added to the Agent Table Model by calling this method.

9.2.2 User Storage Model


Sometimes, you may prefer to have other storage mechanisms than using the default Agent Table Model. Agent Toolkit also provides an option to implement your own storage model. To acheive this, storage model for tables can be selected as "User Storage".


Follow the given steps to select 'User Storage' for tables from the MIB Compiler UI while generating the agent code,

    1. Select Project->Settings from menu bar. The Settings dialog will pop up.

    2. Select Source Generation-> Storage Model node from the tree in the left frame of the Settings dialog.

    3. To select User Storage Model for tables, select 'User Storage' option from the combo box.

    4. To select the option for individual tables, select the corresponding table from the list in right panel and choose 'User Storage' option from the combo-box provided.

    5. Generate the source.

This generates a XXXTableModelListener class for each table selected using the User Storage option. This class implements the com.adventnet.utils.agent.TableModelListenerExt interface. All the methods that you want to instrument will be listed in this generated file. You can plug-in your implementation here.


If 'User Storage' is used for tables, then in the generated agent code (like XXXRequestHandler class), XXXTableModelListener instance will be used instead of the Agent Table Model instance.

9.3 Initializing Tables Before Agent Start-Up


Any Table is initialized with the default values provided on Agent start-up. The default values for a Table do not get generated unless the "Initialize with Default Values" is checked in the MIB Compiler UI. (Project -> Settings menu -> General Category).

Instead of having the default values, if you prefer your Agent to be started with a Table holding the values you require, the following methods can be utilized. But please note when you instrument the code for the Tables to have specific values, the Agent should be restarted for the changes to take effect.


9.3.1 createAndAddEntry Method


To create a row in the Table, the following methods can be used.



Using this method will add an entry to the Table with the Instance. The method takes all the column values and its instances as inputs and creates the row. The method name and the parameters used will differ according to the Tables used.


For example : The code for creating and adding a new entry in the AapplicationTable of AGENT-SAMPLE-MIB is given below.

This code should be included in the initSnmpExtension Nodes generated in the Main file.




This method is used to create a new entry to the table without specifying the instance. It accepts all the column values as inputs. To create an instance the createInstance method is called. When the instance value is created and the values for the columns exist, the createandAddEntry method is called. This creates a new entry in the Table.


For example : The code for creating and adding a new entry in the AapplicationTable of AGENT-SAMPLE-MIB is given below.

This code should be included in the initSnmpExtension Nodes generated in the Main file.




This method is used for creating an instance for a Table by taking the index values as inputs. Once the instance is defined, they are given as inputs along with the columnar values and used for creating an entry.


For example : The code for creating an instance in the AapplicationTable of AGENT-SAMPLE-MIB is given below. This method gets generated by default in the AapplicationTableRequestHandler file.

9.3.2 setTableVector Method


The setTableVector(Vector) method in xxxRequestHandler enables you to set your own Vector to the Agent. But make sure of the following :

These codes have to be added in the initSnmpExtensionNodes method of the Agent Main file.


9.4 Index Handling


Any Table should have an Index column defined in it. Each row of a Table is identified by its index value. There are various types of Indexing and this topic provides the details of the supported syntax types in indexes and the types of Indexing.


9.4.1 Supported Syntax Types in Index


An Index in a Table can have only the following types of Syntax :-

9.4.2 Types of Indexing


An Index of a Table may belong to the category of  : Single Index, Multiple Index, Implied Index or External Index. To know what exactly each index means and how they can be defined in the MIB , please refer to Adding a Table topic in Defining a MB section. Single Index


For a Table having single index column, the code gets generated as given below. Assume that the code is generated for ifTable of RFC1213 MIB in requestProcessing Methods. ifTable maintains a single index column namely, ifIndex whose syntax type is Integer,

For any Table, the resolve Index method is called. All the SET requests for the Table reaches the Resolve Index method wherein the requests from the Manager are first checked whether such an Instance exists. If a matching instance does not exist then an error is thrown or a new entry is created. The code for resolving index resolves the value of the indices from the instance oid given. Multiple Index


When it comes to a Table having Multiple Index, the code is generated in the same manner. The only change in Multiple Index is that while resolving the Index, the instance and its syntax type are verified. External Index


When a Table has an external index column, then the request for that particular Table should first check if such an index column exists in the Base Table. The presence of external index value is checked by the code generated as follows in the respective Table's Request Handler File, (say for a Table having its first index syntax as Integer)

In this code, the agentName is the reference of the SNMP Agent Main file generated for the MIB and the indexVar[1] is the value of the external index from the request Varbind.


The checking for the value present in the External Table is done using the checkExternalXXX method in the Agent Main file as,

When the entry reaches the Agent with the instance oid value, the resolve index method gets called in the XXXRequestHandler file. The method for the same is,

Based on the instance type, the index is resolved.  If the index value is null or if no such instance exists, an error is thrown after resolving the index. Implied Index


A Table having an Implied index column is similar to a Table having Multiple index columns. The code gets generated similar to other Tables. But while resolving the Index, the API call that gets called is,

If isImplied is set to "false", then the Index is resolved taking into consideration the length of the instance. If set to "true", then it is handled in the manner as any Table that has multiple Index columns is handled.




For better understanding of all indexes please go through the example available in <Agent Toolkit Home>/examples/snmp/tablehandling/tables directory. The information in readme.html will help you run the example.


Copyright © 2013, ZOHO Corp. All Rights Reserved.