Introduction

OAT for IDS is the new GUI administration tool for IDS 11 and IDS 11.5. A PHP-based Web browser administration tool, OAT for IDS provides the ability to administer multiple database server instances from a single location. OAT makes IDS administration easy by allowing you to drill down on resource usage and events, view performance statistics, remotely perform administrative actions, and much more. Part of OAT's uniqueness stems from its ability to provide IDS administration through a purely SQL interface. But one of the best advantages is that, since the tool is written in PHP and available freely as open source, you can customize it with your own business logic and installation requirements.

The ability to customize OAT has recently become much easier with the new Plug-in Manager feature in OAT, Version 2.21. The Plug-in Manager defines a standard by which OAT will be able to recognize modules as plug-ins and install them automatically. The power of the Plug-in Manager feature rests in its transformation of OAT from an administration tool to an administration platform upon which Informix developers can build, expand, and share. Since open source software is only as strong as its community of developers and users, this new feature becomes the vehicle for users and developers to transform OAT into a product entirely suited and adapted to their IDS administrative needs.

This article provides a guide to plug-in development for OAT by taking you through the process of creating an example plug-in. In this process, this article explains the structure of OAT modules and how they are executed, defines the extra requirements for turning a module into a plug-in, and shows how the Plug-in Manager is used to install and manage plug-ins.

OAT modules

Understand the URL and how modules are invoked

OAT functionality is divided into a set of modules, with each module residing in its own PHP file. Modules are invoked by OAT's main bootstrap file, index.php, whenever OAT is executed in a user's Web browser. The main bootstrap file determines which module to execute based on parameters passed as part of the URL. The standard for OAT is that each URL has an act and a do parameter. The act parameter specifies which module to invoke, which index.php does by looking for a file called act.php in the modules source directory. The do parameter is passed to the module and is used to tell the module what functionality it should execute. As an example, look at the URL of OAT's Health Center > Alerts page, shown in Figure 1. In this URL, act=health indicates that health.php is the module to invoke and do=showAlerts tells the health module to display the database server's alerts.

Module requirements

There are three requirements that each module must adhere to:

• First, the module must be written in PHP and must be named module_name.php.
• Second, the module must have an $idsadmin class variable. The $idsadmin object (lib/idsadmin.php) greatly simplifies module code by providing a library of the basic functions that all modules will need for things such as the creation of database connections, the loading of the correct language file, and the rendering of the module output in HTML. The $idsadmin object is passed to each module as a parameter to the module’s constructor. An example constructor is shown in Listing 1. Notice that this constructor takes the $idsadmin object as a parameter and stores it in its own $idsadmin class variable. This example constructor also shows some typical actions that the $idsadmin object can be used to perform, namely loading the "example" language file and then using $idsadmin functionality to both return a localized title and set this as the browser’s page title. More information on using OAT's built-in language localization functionality is provided in the Use lang files for language globalization section.
  
  Listing 1. Sample constructor for an OAT module
  

  public $idsadmin; function __construct(&$idsadmin) { $this->idsadmin = $idsadmin; $this->idsadmin->load_lang("example"); $this->idsadmin->html->set_pagetitle( $this->idsadmin->lang("mainTitle")); }

  
  
• The third requirement of every module is that it must have a run function. The run function is the function that is called by the main index.php file to execute the module. By convention, the run function of most modules includes a switch statement that uses the URL do parameter (accessed using $this->idsadmin->in[‘do’]) to decide what functionality to execute. A typical run function is shown in Listing 2.
  
  Listing 2. Sample run function for an OAT module
  

  function run() { // OAT modules use a 'do' parameter to determine what should be executed. switch($this->idsadmin->in['do']) { case 'showOnconfig': $this->idsadmin->html->set_pagetitle( $this->idsadmin->lang("onconfigTitle")); $this->showOnconfig(); break; case 'showMemory': $this->idsadmin->html->set_pagetitle( $this->idsadmin->lang("memoryTitle")); $this->showMemory(); break; default: $this->idsadmin->error( $this->idsadmin->lang("sorry")); break; } }

  
  

Back to top

Creation of an example module -- myReports.php

In this article, you are going to create an example module called myReports.php, which you will later turn into an OAT plug-in. This module creates two reports: a Lock Report to display a list of the current active sessions and the number of locks associated with each and a Session Memory Report showing a graph of current memory usage per user and then a table that breaks the memory usage down further on a per-session basis.

Besides the constructor, your myReports.php module consists of three functions:

• run: Required of all OAT modules
• lockReport: Create the Lock Report
• sessionMemory: Create the Session Memory Report

The following sections will walk you through the code for each of these functions.

The myReports run function

The example myReports module generates two custom reports. The first is a Lock Report that is displayed when the URL do parameter is "lockReport" and the second is a Session Memory Report that is displayed when the URL do parameter is "sessionMemReport". The sole purpose of the run method is to determine which report to run by retrieving the do parameter from the $idsadmin object ($this->idsadmin->in['do']) and then invoking the desired report function.

    function run()
    {
         switch($this->idsadmin->in['do'])
         {
            case "lockReport":
                // Run the lock report
                $this->lockReport();
                break;
            case "sessionMemReport":
                // Run the session memory report
                $this->sessionMemoryReport();
                break;
            default:
                // If we don't recognize the 'do', print an error
                $this->idsadmin->error("Sorry, I don't know which report to run.");
        }
    } 

The myReports lockReport function

Now look at the code to create your Lock Report. For your Lock Report, you will display a list of the current active sessions on the database server and the number of locks associated with each session. Here is the code to do this:

			
    /**
     * Our first custom report will be a Lock Report.
     * This method will generate a report showing the number of lock per active session.
     */
    function lockReport()
    {
        /**
         * Set the browser page title
         */
        $this->idsadmin->html->set_pagetitle("Lock Example");

        /**
         * Ensure that OAT highlights the correct entry in the menu for this report.
         */
        $this->idsadmin->setCurrMenuItem("lockReport");

        /**
         * For our lock report, we want to select some information from the sysmaster 
         * syslocks and sysscblst tables. We will display a list sessions and the number 
         * of locks associated with each session.
         */

        /**
         * Now we write our query.
         */
        $qry = " select sid, "
             . " trim(username)||'@'||" 
             . "trim(decode(length(hostname),0,'localhost',hostname)::lvarchar) as user,"
             . " lockcnt from "
             . " (select owner, count(*) as lockcnt from syslocks group by owner) "
             . " join sysscblst on owner=sid "
             . " order by sid";

        /**
         * We also need another query which would be the 'count' of the # of rows  
         * returned from the previous query.  This 'count' query will be used by the 
         * 'gentab' API below to create and format our output.
         */
        $qrycnt = " select count(*) from syslocks group by owner ";

        /**
         * The OAT 'gentab' API is used to automatically create and format the HTML 
         * tables for query results in OAT.
         *
         * So first, let's load the gentab class.
         */
        require_once("lib/gentab.php");

        /**
         * Then let's create a new instance of the gentab class.
         */
        $tab = new gentab($this->idsadmin);

        /**
         * Now we call the display_tab_by_page function of the gentab class and 
         * and pass the required arguments.
         *   arg1:  Title.
         *   arg2:  Array of 'column' headings.  We the idsadmin lang function to 
         *			get our string to use as a heading.
         *   arg3:  The query.
         *   arg4:  The count query.
         *   arg5:  How many rows to display per page.
         */
        $tab->display_tab_by_page("Locks Per Session",
        array(
                  "1" => $this->idsadmin->lang("sessionid"),
                  "2" => $this->idsadmin->lang("username"),
                  "3" => $this->idsadmin->lang("lockcnt"),
        ),
        $qry, $qrycnt, 5);

        /**
         * That is all... the 'gentab' library takes care of the rest.
         * 
         * Once our plug-in is installed, you can test this function in your browser 
         * using the url : 
         * http://HOSTNAME/OATINSTALL/index.php?act=myPlugin/myReports&do=lockReport
         * 
         * The resulting output will be our lock report.
         */        
    }

Use the gentab library to display tabular data in OAT. A key thing to notice in this function is the use of the gentab (generic table) library to generate tables in OAT. Located at lib/gentab.php in your OAT directory, this library provides an organized look and feel to displaying tables in OAT. The gentab library is also built to automatically deal with large amounts of data by paginating the table's data and providing an interface to sort data by column names.

Notice how easy it is for us to create tables in OAT using gentab. You only need to provide five arguments, and then gentab takes care of the rest for you automatically.

By default, gentab runs the query specified in argument 3 on the sysmaster database. See the gentab class in your OAT installation for the many more options that the library provides for displaying data tables, including how to specify other databases besides sysmaster and how to use templates to customize the generic table.

Pretty simple for your first report. Figure 2 is a screenshot of what the Lock Report looks like when run in OAT.

The myReports sessionMemoryReport function

The second report in this example module is the Session Memory Report. For this report, you want to display a graph of total memory usage per user and then, in a table, break that memory usage down on a per-session basis.

Using the Charts library to display graphical data. In OAT, displaying data in pie chart format is just as easy as displaying data in tables. The Charts library (lib/Charts.php) is OAT's interface for displaying graphical data. Check out the code in Listing 5 to see the Charts library in action (and to see another example of the use of gentab to display tabular data).

			
    /**
     * Our second custom report will be a Session Memory Usage Report.
     * In this report, we will have a graph of memory usage per user and then
     * a table that breaks the memory usage down further on a per session basis.
     */
    function sessionMemoryReport()
    {
        /**
         * Set the page title and the menu item that should be highlighted
         */
        $this->idsadmin->html->set_pagetitle("Session Memory Example");
        $this->idsadmin->setCurrMenuItem("sessionMemReport");

        /**
         * For our session memory report, we want to select some information from the  
         * sysmaster sysscblst table. 
         * 
         * Therefore, we first need a 'connection' to the database which we will get 
         * again from the $this->idsadmin object.
         */
        $db = $this->idsadmin->get_database("sysmaster");

        /**
         * We want a summary graph at the top of this report that will show the 
         * total memory usage per user.  So let's create that query and execute 
         * it on the database server.
         */
        $qry = "select username, " 
             . "sum(memtotal) as memtotal from sysscblst "  
             . "where sid != DBINFO('sessionid') "
             . "group by username";
        $stmt = $db->query($qry);
        
        /**
         * Now we are going to transfer the result of the query into an associative
         * array that maps the username to the memory usage.  This will put it in
         * a format that we can use to generate the pie chart graph.
         */
        $userdata = array();
        while ($res = $stmt->fetch(PDO::FETCH_ASSOC))
        {
            $userdata[$res['USERNAME']] = $res['MEMTOTAL'];
        }
        $stmt->closeCursor();
        
        /**
         * Now we'll create the graph using the Charts library class.  We create the
         * Charts object, set the attributes which includes our data array, and then
         * call the chart render function to create the graph. 
         */
        require_once ("lib/Charts.php");
        $this->idsadmin->Charts = new Charts($this->idsadmin);
        
        $this->idsadmin->Charts->setType("PIE");
        $this->idsadmin->Charts->setTitle("Memory Usage Per User");
        $this->idsadmin->Charts->setLegendDir("vertical");
        $this->idsadmin->Charts->setWidth("100%");
        $this->idsadmin->Charts->setData($userdata);
        
        $this->idsadmin->Charts->Render();
        
        /**
         * Underneath our pie graph, we also want to display a table listing the
         * memory usage per session.  So here is the query for this table.
         */
        $qry = "select sid, " 
             . "trim(username)||'@'||"
             . "trim(decode(length(hostname),0,'localhost',hostname)::lvarchar) as user,"
             . "memtotal from sysscblst "  
             . "where sid != DBINFO('sessionid') "
             . "order by sid";

        /**
         * And here is the 'count' query for the # of rows returned from the above query.
         */
        $qrycnt = " select count(*) from sysscblst where sid != DBINFO('sessionid')";


        /**
         * We'll use the 'gentab' API again to create the output for us.
         * So load the gentab class and create a new instance of the gentab class.
         */
        require_once("lib/gentab.php");

        $tab = new gentab($this->idsadmin);

        /**
         * Now we call the display_tab_by_page function of the gentab class and 
         * and pass the required arguments.
         *   arg1:  Title.
         *   arg2:  Array of 'column' headings.  We use the idsadmin lang function 
         *          to get our string to use as a heading.
         *   arg3:  The query.
         *   arg4:  The count query.
         *   arg5:  How many rows to display per page.
         */
        $tab->display_tab_by_page("Memory Usage Per Session",
        array(
                  "1" => $this->idsadmin->lang("sessionid"),
                  "2" => $this->idsadmin->lang("username"),
                  "3" => $this->idsadmin->lang("memtotal"),
        ),
        $qry,$qrycnt,5);

        /**
         * It's just that easy again.  Now we have our second report for Session Memory 
         * which includes both a table and a pie chart.  This report can be accesses 
         * once the plugin is installed at ...
         *     http://HOSTNAME/OATINSTALL/index.php?act=myPlugin/myReports
         *          &do=sessiomMemReport
         */        
    }

As shown above, to create a pie chart, all you basically need to do is to provide the Charts class with an array of data by calling its setData function ($this > idsadmin > Charts > setData($userdata)) and passing it the data that you got from a database query. Then you set some additional attributes to tell the Charts library how you want the chart to look. Finally, call the Render function. The resulting Session Memory Report is shown in Figure 3.

You can download the full code for this example module in the Download section below.

Back to top

Turn your example module into a plug-in

Now that you have your module class myReports.php working, the next step is to turn it into a plug-in.

Plug-in act parameters

Plug-ins are almost exactly the same as regular OAT modules, except that they are stored in a separate plugin directory to keep them separated from the core OAT code. (This separation ensures that upon upgrades of the OAT code, the plug-in files are unaffected). Since plug-in modules are stored in a different directory, their act parameter is slightly different in order to reflect this. Recall from an earlier discussion that the OAT bootstrap index.php loads modules by looking for a file matching act.php in the modules directory. In order to indicate to index.php that the module needs to be found in the plugin directory, you will use more of a path name in the URL for the act parameter.

To make this clear, look at the URL of the Lock Report of the myReports module after it is installed as a plug-in. The module name is myReports, so call your plug-in myPlugin (and make this the directory name for your plug-in files). Therefore, after it is installed, your module file will be located at plugin/myPlugin/myReports.php, inside the main OAT directory. This means that your URL would be as shown in Figure 4.

By specifying act=myPlugin/myReports, index.php sees that it is a path name and therefore recognizes that you are loading a plug-in instead of a regular module. It then looks inside OAT's plugin directory for the file act.php, which in this case is myPlugin/myReports.php.

Use lang files for language globalization

OAT provides a mechanism for language globalization through its lang files, which are XML files that store localized text strings. The $idsadmin object handles the loading of the proper language file and the retrieval of the specified localized text string. The use of lang files in writing modules and plug-ins is optional, but a good recommended practice to follow.

In order to use lang files, you create a lang directory underneath your main plug-in directory. Inside the lang directory, there needs to be a sub-directory for every language you support. Each of these sub-directories need to include a file called lang_module_name.xml.

So to create an English lang file for this example plug-in, you create a myPlugin/lang/en_US directory for your English language file. Inside this directory, create a lang_myReports.xml file that stores all of the English text you want to display on the screen for your reports. The contents of this file are shown in Listing 6.

			
<?xml version="1.0" encoding="UTF-8"?>
<lang module="lang_myReports">
<sessionid><![CDATA[Session ID]]></sessionid>
<username><![CDATA[User Name]]></username>
<lockcnt><![CDATA[Lock Count]]></lockcnt>
<memtotal><![CDATA[Total Memory]]></memtotal>
</lang>

In the myReports.php module, use the lang file to get all the column headers for your table, which you pass to the gentab library to create the table.

$tab->display_tab_by_page("Locks Per Session",
    array(
         "1" => $this->idsadmin->lang("sessionid"),
         "2" => $this->idsadmin->lang("username"),
         "3" => $this->idsadmin->lang("lockcnt"),
    ),
    $qry, $qrycnt, 5);

Assuming that English is set as the default language in OAT's configuration (Admin > OAT Config), the command $this->idsadmin->lang("sessionid") retrieves the data inside the sessionid attribute of the English lang file (myPlugin/lang/en_US/lang_myReports.xml) and use it as the text for your column header.

Define the plug-in in the plugin.xml file

Now that you know what your plug-in's act and do parameters will be, you can turn your attention to defining your plug-in, which is done through a plugin.xml file. Each plug-in is required to have a plugin.xml file, as this is what tells OAT's Plug-in Manager interface that it is a plug-in. The plugin.xml file defines the plug-in and also tells the Plug-in Manager how to install it.

The table lists the XML attributes that you can use to define your plug-in.

The plugin.xml file for the example myPlugin, which includes the myReports module, is shown in Listing 7. You do not have a license file associated with your example plug-in, so the <plugin_license> element is commented out.

<oat_plugin>
    <plugin_info>
        <plugin_name>Example Report Plug-in</plugin_name> 
        <plugin_author>IBM</plugin_author>
        <plugin_desc>Example plug-in - custom reports</plugin_desc>  
        <plugin_version>1.0</plugin_version>
        <plugin_buildtime>6/27/2008 4:00pm</plugin_buildtime>
        <plugin_server_version>11.10</plugin_server_version> 
        <plugin_upgrade_url>none</plugin_upgrade_url> 
        <!--  <plugin_license>{LICENSE FILE}</plugin_license> -->
    </plugin_info>
    <plugin_menu>
    	<menu_pos>SQLToolBox</menu_pos>
        <menu id="myReports" name="My Reports" lang="myReports" >
            <item name="LockReport"  
                link="index.php?act=myPlugin/myReports&amp;do=lockReport"
                title="My Lock Report" lang="lockReport" />
            <item name="SessionMemReport"  
                link="index.php?act=myPlugin/myReports&amp;do=sessionMemReport" 
                title="My Session Memory Report" lang="sessionMemReport" />
        </menu>
    </plugin_menu>
</oat_plugin>

Add links in the menu for plug-ins

Most plug-in developers want links to their plug-in added into the OAT menu after their plug-in is installed through the Plug-in Manager. To this end, the Plug-in Manager supports menu entries in the plugin.xml. All plug-in menu related information goes within <plugin_menu> tags in the plugin.xml.

To place a top-level expandable entry in the menu for your myReports plug-in, you will use the following syntax:

<menu id="myReports" name="My Reports" lang="myReports" >

The lang attribute specifies which element in the menu language file that is used for the actual text to be displayed in the menu. Therefore, to add menu items for a plug-in, a lang_menu.xml is required in each of the plug-in's lang sub-directories.

To add menu links underneath your new "My Reports" menu section, use the following syntax:

<item name="LockReport"  link="index.php?act=myPlugin/myReports&amp;do=lockReport" 
	title="My Lock Report" lang="lockReport" / >

This line adds a Lock Report link in the menu that takes the user to the URL specified, which maps to your Lock Report's act and do parameters. The actual text displayed in the menu is retrieved from the <lockReport> element in the lang_menu.xml file.

Besides specifying which menu items to add when installing a plug-in, the plugin.xml can also specify where in the menu to add the new items. The <menu_pos> tag is used to specify after which menu item you want to add the new link. In this case, you want to add your myReports links after the SQL ToolBox section, so you specify <menu_pos>SQLToolBox</menu_pos>.

To review, the full <plugin_menu> section menu of your plugin.xml file and your lang_menu.xml file are shown in Listings 8 and 9.

			
    <plugin_menu>
        <menu_pos>SQLToolBox</menu_pos>
        <menu id="myReports" name="My Reports" lang="myReports" >
            <item name="LockReport"  
                link="index.php?act=myPlugin/myReports&do=lockReport"
                title="My Lock Report" lang="lockReport" />
            <item name="SessionMemReport"  
                link="index.php?act=myPlugin/myReports&do=sessionMemReport" 
                title="My Session Memory Report" lang="sessionMemReport" />
        </menu>
    </plugin_menu>
			

			
<?xml version="1.0" encoding="UTF-8"?>
<lang module="lang_menu">
<myReports><![CDATA[My Reports Example]]></myReports>
<lockReport><![CDATA[Lock Report]]></lockReport>
<sessionMemReport><![CDATA[Session Memory Report]]></sessionMemReport>
</lang>

Figure 5 shows what the OAT menu looks like after your example plug-in is installed:

Package plug-ins

Plug-ins for OAT are packaged as ZIP files. It is required that the plugin.xml file exist in the top-level directory within the ZIP file. This is the minimum requirement for OAT to even recognize your package as a plug-in. Besides the plugin.xml file, your plug-in ZIP package needs to include your module file(s), placed in the proper directory structure required by your module's act parameter, as well as any other auxiliary files you create as part of your module. When installing a plug-in, the Plug-in Manager preserves the exact directory structure inside the plug-in ZIP file and places it underneath the OAT's plugin directory.

The contents of our myPlugin.zip would be as follows:

plugin.xml
myPlugin/myReports.php
myPlugin/lang/en_US/lang_myReports.php
myPlugin/lang/en_US/lang_menu.php

You can download the plug-in zip file for your myPlugin example in the Download section below.

Back to top

Install plug-ins

The Plug-in Manager

The Plug-in Manager, shown in Figure 6, is located in the Admin menu of OAT (Admin -> Plug-in Manager). The Plug-in Manager is a new feature of OAT, Version 2.21 and is used by OAT users to install, enable, and disable plug-ins.

Note: To use the Plug-in Manager feature in OAT, you need to have the ZIP module enabled in your PHP installations. The automated installer for OAT, Version 2.21 bundles PHP with this module enabled.

Use the Plug-in Manager

To install a plug-in in OAT, you need to place the plug-in ZIP file in the plugin_install directory of their OAT installation and then go to the Plug-in Manager in the Admin section of OAT. Any uninstalled plug-ins that are sitting in the plugin_install directory are automatically displayed under the "Plug-ins not yet installed" section. Once a user clicks install, the plug-in is installed under OAT's plugin directory and the appropriate menu items added into the OAT menu (which is stored in OAT's connections.db). If the plugin.xml for the plug-in specifies a license file, the user is required to accept the license before the plug-in can be installed.

After a plug-in is installed, it will show up in the "Installed Plug-ins" section of the Plug-in Manager. Users can enable or disable their installed plug-ins using the check box provided. Disabled plug-ins will no longer be displayed in the OAT menu.

Figure 7 provides a final screenshot of the Plug-in Manager after the example plug-in is installed and enabled.

Back to top

Conclusion

This article covered OAT for IDS's new Plug-in Manager feature and took you through the steps of creating an example plug-in. The complete plug-in ZIP file for this example plug-in can be downloaded from the Download section of this article, which you can install in your OAT instance or use to examine the source code files in more detail.

This article's example plug-in exhibits a very basic set of the functionality that OAT modules can be coded to perform. Luckily, since OAT is open source, you can see many examples of more complex modules by examining some of the files in the modules directory of your OAT installation. With OAT now having a standardized way of handling and supporting plug-ins, the sky is the limit for OAT users to develop their own plug-ins in order to customize OAT to fit their individual IDS administration needs.

Back to top

Download

Information about download methods

Resources

Learn

• OpenAdmin Tool Web site: Find out all about the latest OAT for IDS versions, including new feature details, screenshots, and tutorials.
  
  
• "Manage your Informix database with IDS OpenAdmin Tool" developerWorks series: Find more information regarding OAT:
  • Part 1: "Configuring and using the OpenAdmin Tool with IDS" (developerWorks, July 2008): Learn about some of the most useful features of OAT.
  • Part 2: "Migrate from Informix Server Administrator to the IDS OpenAdmin Tool" (developerWorks, July 2008): Migrate from the Informix Server Administrator (ISA) to the OAT. This article also describes how the basic capabilities of ISA are made available on OAT, along with enhanced functionalities and greater ease-of-use.
  • Part 3: "Performance analysis of Informix Dynamic Server made easy through the OpenAdmin Tool" (developerWorks, July 2008): Easily monitor performance through statistical data and charts that give you a quick way to comprehend the information.
  
  
• developerWorks Informix page: Find articles, tutorials, and other resources to expand your Informix skills.
  
  
• Informix Dynamic Server, V11.50 Information Center: Learn more about IDS.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• developerWorks Information Management zone: Learn more about DB2. Find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• Download OpenAdmin Tool for IDS.
  
  
• Download a free trial version of Informix Dynamic Server.
  
  
• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• Visit OpenAdmin Tool forum
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Erika Von Bargen has been a part of the IBM Informix development organization for five and a half, the last two and a half of which have been spent on the OpenAdmin Tool team. She is based in the IBM Lenexa lab.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• OAT modules
• Creation of an example module -- myReports.php
• Turn your example module into a plug-in
• Install plug-ins
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Informix Ultimate Edition
• Buy: Informix Ultimate Edition

Dig deeper into Information Management on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers