Database Reference
In-Depth Information
plug-in tag must be four characters or fewer. For example, Oracle's sample plug-in ID is
oracle.sysman.xsh1
, and for
my demo MySQL plug-in, I use the ID
pythian.mysql.demo
.
The plug-in version is indicated by five numbers: a.b.c.d.e. The first two numbers (a.b) should be the same as
the EM12c version that you are developing on. The third number (c) should always be 0. The fourth number is what
you will be incrementing every time you're publishing the plug-in. Oracle reserves the fifth number (e) for future use
and instructs that you always set it to 0. However, I have been using it to identify minor plug-in releases. For example,
12.1.0.1.2 is the current release of the Pythian MySQL plug-in at the time of this writing.
You need to increment versions as you deploy the next versions in your development environment. You could
use that last number for development release increments or you can just modify the plug-in ID during development.
For example, I use
pythian.mysql.prod
for publicly released versions and
pythian.mysql.test
for development
and testing.
The
PluginOMSOSAruId
element defines on which OS the OMS should be running to support this plug-in. A value
of 2000 indicates a generic platform, and you will often find that your plug-ins have pretty much no dependency on
the OMS server platform but often have a dependency on the agent OS. I won't go into the details of compatibility
here (see the documentation referenced earlier) but
plugin.xml
is the place that you can define the compatibility of
the plug-in and other EM12c components.
The
ShortDescription
and
Readme
tags are self-explanatory. The
PluginAttributes
element hosts a few basic
properties. You can set a few predefined categories for the
Category
attribute, such as Databases, Middleware, and so
forth. The
DisplayName
attribute is how your plug-in will be shown in the EM12c user interface.
Finally, there is the
TargetTypeList
element listing all the target types a plug-in contains. A simple plug-in
usually contains just one target type, so there is only one
TargetType
child element. The target type name is an
internal ID of the target type included in the plug-in. More on ID selection for target types is shown later in this
chapter, when I actually define one.
There are also provisions to define plug-in dependencies, version support and compatibility, and a multitude
of other attributes such as a “What's New” section. You don't need to get into that now and can always make plug-in
metadata more complex later. I generally recommend starting simple and slowly adding features into your plug-in.
While
plugin.xml
contains OMS-side metadata,
plugin_registry.xml
defines the metadata required by
the agents where the plug-in is deployed—usually just the list of target type metadata files and default collection
metadata files. For a single target type plug-in, there is just one of each. They are defined by using the
TargetTypes
and
TargetCollections
elements, simple containers for one or more
FileLocation
elements. The path in
FileLocation
is relative to the agent directory in the staging area. Listing 10-6 is the simplified
plugin_registry.xml
file from the example.
Listing 10-6.
Agent-Side Plug-in Metadata
plugin_registry.xml
for Sample Host Plugin 1
<?xml version="1.0"?>
<PlugIn ID="oracle.samples.xsh1" Description="Sample Host Plugin 1" Version="12.1.0.0.0"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance
"
xsi:schemaLocation="
http://www.oracle.com/EnterpriseGridControl/plugin
plugin.xsd" >
<TargetTypes>
<FileLocation>metadata/sample_host1.xml</FileLocation>
</TargetTypes>
<TargetCollections>
<FileLocation>default_collection/sample_host1.xml</FileLocation>
</TargetCollections>
</PlugIn>
You can see that the attributes
ID
,
Description
, and
Version
are replicated from the OMS-side
plugin.xml
file.
Note that the
ID
is a dot-notation version of
PluginId
. More-advanced options are available, but they are still quite
poorly documented and not provided in the examples. For example, you can register your own metric collection
method by defining a custom fetchlet (you will learn about fetchlets soon) but you won't do that until you become
very proficient in plug-in development.
