2 Setting Up Your Development Environment

This chapter describes the process of setting up the Oracle Audit Vault Server development environment.

This chapter contains:

2.1 Before You Set Up the Development Environment

To develop Audit Collection Plug-ins, you must first set up the development environment. This setup provides a consistent environment for developing and testing the collection plug-ins.

Before you set up a developer environment, do the following:

  • Obtain and install Oracle Audit Vault and Database Firewall 12.1.2. You must have this version so that you can test the collection plug-in execution and determine whether it captures the correct audit records from the secured target and makes them available in the server. Also, doing early end-to-end integration tests helps to eliminate any connectivity problems and other bugs in your code. See Oracle Audit Vault and Database Firewall Installation Guide for more information.

  • To help you decide which type of collection plug-in to use, see "Determining Which Audit Collection Plug-in Type to Create".

2.2 Setting Up the Development Environment

Before setting up the development environment, download the Oracle AVDF SDK from the Audit Vault Server console in Oracle Audit Vault and Database Firewall:

To download the SDK, do the following:

  1. Log in to the Audit Vault Server console as an administrator.

  2. Click the Settings tab, and then click Plug-ins (under the System subsection).

  3. Click Download SDK.

  4. Unzip the SDK into an empty directory.

To set up an environment for developing collection plug-ins, follow these steps:

  1. Set the AV_SDK_HOME variable to the directory you extracted the SDK to.

    For example:

    $ export AV_SDK_HOME=/home/username/avsdk
  2. Set the PATH environment variable to bin directory of the Audit Vault Server.

    For example:

    $ export PATH=$AV_SDK_HOME/bin:$PATH

    This setting enables you to use existing scripts during the development cycle.

  3. Set the CLASSPATH environment variable to include the relevant jars for your collection plug-in project.

    For example:

    $ export CLASSPATH=$AV_SDK_HOME/av/jlib
  4. Create directories as necessary.

    See "Audit Collection Plug-in Directory Structure" for the directory structure that you should use.

2.3 Audit Collection Plug-in Directory Structure

This section contains these topics:

2.3.1 General Directory Structure

Example 2-1 shows a general directory structure.

Example 2-1 General Directory Structure


In Example 2-1, the STAGE_DIR_ROOT directory is the root directory where you stage your collection plug-in files. Place the plugin-manifest.xml directly in this directory. Under the STAGE_DIR_ROOT directory, create the following directories:

  • jars: Holds all the binaries generated through the Java build process.

    Place your collector binaries for a Java-based plug-in in the jars directory. You should package the various collector Java classes into a jar file for easier access on the file system. For collection plug-ins, you do not need to package the Collector.jar in to this directory because it is part of the core agent and is automatically available for all collectors that are managed by an agent.

  • config: Holds any configuration files that the collection plug-in requires to function. These configuration files can be resource bundles, property files, and so on.

  • bin: Holds any native non-Java binary executables. For example, if your collector code invokes any native non-Java binaries, place them in the bin directory.

    Because the agent is supported on multiple platforms, you should build the non-Java binaries on all platforms that the agent supports. In addition, the collector process locates and loads the appropriate binary based on the execution platform, so use a naming convention similar to that described in the "Description of Plug-in Manifest File".

  • patches: Holds any OPatch patches for secured target-specified event attributes that the collector needs to function. If your collector adds new event attributes that are needed during run-time, then contact Oracle Support. Oracle Support will provide you with a patch that adds these events into the Audit Vault Server repository. This approval process is necessary to avoid collisions with other event attribute names across multiple plug-ins. After you have obtained these patches, place them in the patches directory. Then they will automatically be applied to the server during collection plug-in deployment.

2.3.2 Audit Collection Plug-in Directory Structure

Example 2-2 shows the structure of a stage directory for a collection plug-in.

Example 2-2 Directory Structure for collection plug-in


See "Description of Plug-in Manifest File".

For a collection plug-in, place all mapper files in the templates directory, as shown in Example 2-2. This placement directs the collection plug-in to load the relevant template file based on the information that the file contains.

2.3.3 Staging a plugin-manifest.xml File

The plugin-manifest.xml file is a core XML file that describes the collection plug-in and defines its attributes. You must stage the plugin-manifest.xml file directly under the STAGE_DIR_ROOT directory, as follows:

  • On UNIX systems: If your stage directory is /opt/final-plugin-stage/, then stage the plugin-manifest.xml file at /opt/final-plugin-stage/plugin-manifest.xml.

  • On Microsoft Windows systems: If your stage directory is c:\myplugin\final-stage-dir, then stage the plugin-manifest.xml file at c:\myplugin\final-stage-dir\plugin-manifest.xml.

See Also: