Every metadata plug-in is assessed for quality and best practices using the Self Validation checklists included in this appendix.
Oracle recommends that you self-validate your plug-in against these checklists before submitting your plug-in for a formal review. Alternatively contact the Enterprise Manager Release Management team for the latest version of this checklist.
It includes the following sections:
Table B-1 provides a list to check the plug-in data.
For more information about defining plug-in metadata, see Defining the Plug-in.
Table B-1 Plug-in Metadata Checklist
Category | Checklist Item |
---|---|
Readme Tag |
Include a Readme tag in the plugin.xml file that provides a description of your plug-in. Ensure that it is at least 80 characters in length. For more information, see Table 2-1 |
Display Name Attribute |
Include a DisplayName attribute in the plugin.xml file such as: <PluginAttributes DisplayName="Oracle Sun ZFS Storage Appliance" Type="MP"/> For more information, see Table 2-1 |
TargetTypeList Tag |
Include a TargetTypeList tag in the plugin.xml file such as: <TargetTypeList> <TargetType isIncluded="TRUE" name="sun_storage_7000" /> |
Version Support Information |
If you are supporting a specific version or specific range of versions for these targets, ensure you define these versions. If you do not specify versions, then Enterprise Manager assumes that this plug-in can monitor and manage all versions of the target type. Note: It is not a mandatory requirement to specify supported versions, but check whether you need it. The following example is from a database plug-in: <TargetType name="oracle_database"> <VersionSupport> <SupportedVersion supportLevel="Comprehensive" minVersion="9.2.0.8.0" maxVersion="9.2.0.8.0"/> <SupportedVersion supportLevel="Comprehensive" minVersion="10.1.0.5.0" maxVersion="10.1.0.5.0"/> <SupportedVersion supportLevel="Comprehensive" minVersion="10.2.0.4.0" maxVersion="10.2.0.5.0"/> <SupportedVersion supportLevel="Comprehensive" minVersion="11.1.0.7.0" maxVersion="11.1.0.7.0"/> <SupportedVersion supportLevel="Comprehensive" minVersion="11.2.0.1.0" maxVersion="11.2.0.3.0"/> </VersionSupport> For more information, see Table 2-1 |
Specific Plug-in Category |
Choose a specific category other than “Others". Contact the Oracle Extensibility reviewers if your plug-in does not fit into the following predefined categories.
For more information, see Table 2-1 |
Generic Plug-in |
The default is Generic, so Oracle recommends removing the <PluginOMSOSAruId value="2000"/> For more information, see Table 2-1 |
Size of the OPAR less than 2 MB |
Ensure that your Oracle Plug-in Archive (OPAR) file is less than 2 MB. For more information about the OPAR file, see Creating the Plug-in Archive. |
Plug-in Validation Report |
Ensure that no violations are reported in the plug-in validation report. For more information, see Validating the Plug-in. |
Repository Connection Details |
Ensure that the plug-in validation report does not show any skipped validations because of missing repository connection details. |
Table B-2 provides a checklist which applies to defined targets for your plug-in. This checklist is only applicable if you have files in the plugin_stage/oms/metadata/targetTypes directory.
For more information about targets, see Creating Target Metadata Files and Collecting Target Configuration Data.
Table B-2 Targets Checklist
Category | Checklist Item |
---|---|
Target Type Name |
Ensure that the target type name follows the pattern company_plugin_tag_type _name, such as oracle_vt_zone or oracle_emas_forms_server |
Target is an Entity |
Ensure that the target is a monitorable and manageable entity and it makes business sense to model it. |
Identifiable Presence |
Ensure that the target being modelled has a identifiable presence even if Enterprise Manager is not installed. |
Manageable Entity Class |
Identify the manageable entity class to which the target type belongs and set the property accordingly:
For more information, see Table 3-2. |
Monitoring Mode |
This check applies to repository-side targets only. Ensure that MonitoringMode is set to Repository for Repository target types. |
Monitoring Mode |
This check applies to MultiAgent-side targets only. Set MonitoringMode set to OMSMediated for multi-agent target types. |
Response Metric |
All target types must have a response metric defined. For more information, see Defining the Basic Response Metric Group. |
Target Type Metadata Version |
The Target Type metadata version consists of 2 numbers, MM.NN where MM is the major version number and NN is the minor version number. Set the major version number to the main plug-in release, such as 12 if the plug-in release is 12.1.N.N.N and 13 if the plug-in version is 13.N.N.N.N. Set the minor version number to 2 digits starting with 01, such as 13.01 to start with for 13.x plug-ins Note: You do not have to update the metadata version if you are changing query or execution descriptor or the agent-side script. For more information, see Defining the Target Type Metadata. |
Target Type Metadata Minor Version |
Ensure that the minor version number uses a 2 digit format, such as 13.01 instead of 13.1. Note: Minor versions are compared right-padded to 20 digits, so 13.9 > 13.10 in meta version semantics, since 13=13 and 9 right padded to 20 digits is greater than 10 right padded to 20 digits (900000... > 100000..). The number of digits in the minor version must be consistent when you move from one version to another. Having 2 digits in the minor version allows you to bump up until 99. DDR patches supplied on top of previous releases use the format 13.NNYYWWW. If you are providing a metadata patch on top of 13.01, then the patch version is 13.0113005 (for 5th week of 2013). 13.0113005 is greater than 13.01 but less than 13.02 in target type metadata version semantics For more information, see Defining the Target Type Metadata. |
Associations |
Ensure that no abstract association types are used ( |
Associations |
Ensure that only core association types are used ( |
Associations |
Ensure that the Provided_by/relies_on_key_component allowed pair is not defined between the service and any other target type. |
Valid Target Properties |
Ensure that the Target properties include only properties that are used for monitoring the target, such as collecting a metric. Do not use target properties as a name value pair to dump data against the target. If it is not actively used by the Management Agent, then it is not a target property. |
Target Version Property |
Ensure that the Target version property is added. The Target version property captures the target version. By default, Enterprise Manager uses the "version" property to represent the target version. Target version is required for managing the target so that you can indicate that a particular version of the target is deprecated with a new release of plug-in. It helps administrators to determine the versions of the products they are using also. |
Credential Sets |
Ensure that credentials are defined as Credential Sets. For more information, see Defining Credentials. |
Storing Credentials |
Do not store credentials (user name or password) in target properties. They must be modelled as credentials. |
Response Metric |
Ensure that the Response metric category has only one numeric metric called Status. For more information, see Defining the Basic Response Metric Group. |
Metric Definitions |
Check that there are no hardcoded paths to Perl in your metric definitions. |
Metric Definitions |
Ensure that no defined key column stores Timestamp or Date or has key parts that are variable such as Date, Timestamp, Line Number, or Session Id. |
Metric Definitions |
Ensure that no credential values are passed as command-line arguments to scripts in the metric definitions |
Metric Definitions |
Ensure that user names and passwords are passed by stdin to scripts and not by environment variables. |
Metric Collection Item |
Do not use the UPLOAD_ON_FETCH attribute when defining a collection item. For more information, see Table 3-5 |
Metric Definitions |
Ensure that the display names for metrics and metric columns are user-friendly and have proper NLSID. For more information, see Metric Definition Files. |
Metric Definitions |
Ensure that configuration metric definitions use type RAW (not TABLE). For more information, see Table 3-4 |
Metric Definitions |
Ensure that any count or number type metric column is not defined as type STRING. |
Metric Definitions |
Ensure that metric keys do not have high cardinality, that is, a metric does not collect thousands of keys. For more information, see Defining Target Metadata |
Metric Definitions |
Ensure that you categorized your metrics within the Default metric class. For more information, see Categorizing Metrics. |
Metric Definitions |
Ensure that configuration metrics only collect data that is explicitly changed due to administrator actions. |
Target Configuration Data |
Ensure that the integer VER attribute is specified in the Configuration Metadata XML file. For more information, see Table 7-1 |
Target Configuration Data |
Ensure that table names begin with the plug-in tag followed by an underscore and can be a maximum size of 25 characters. |
Target Configuration Data |
Ensure that table and column names are in uppercase. |
Target Configuration Data |
Ensure that the size of columns is reasonable. |
Target Configuration Data |
Ensure that User Interface (UI) names for tables and columns are reasonable and user-friendly because these appear in the UI and can be seen by end users. |
Target Configuration Data |
Ensure that key columns are correctly identified for each table (for non-single row tables) |
Target Configuration Data |
Ensure that flags with default settings are not repeated. Do not repeat flags in every table or column that have default settings. Use flags for non-default setting overrides only. List all flags (including default setting) at METADATA level if you want to list them in one place. |
Target Configuration Data |
Ensure that the META_VER attribute in the target collection files matches the corresponding META_VER attribute defined for the target type. |
Metric Collection Items |
Ensure that the Response CollectionItem defined for the Response metric has a frequent schedule. Oracle recommends a collection interval between 1 and 5 minutes. |
Metric Collection Items |
Ensure that conditions are not defined on key columns |
Metric Collection Items |
Ensure that values used with MetricColl elements are valid metric values in the target type metadata XML. |
Metric Collection Items |
Ensure that messages defined for conditions use substitution variables for threshold values instead of hardcoding values. |
Metric Collection Items |
Ensure that Alert messages include metric display names, metric values and the thresholds that caused the alerts. Ensure that the main alert is conveyed in first 80 chars of the message. |
Upgrading Targets |
When upgrading a target type from an earlier release, ensure that data column types are not modified |
Upgrading Targets |
When upgrading a target type from an earlier release, ensure that the key columns, order, data type, or number are not modified |
Upgrading Targets |
When upgrading a target type from an earlier release, ensure that the metric type is not modified (such as TABLE to RAW) |
Upgrading Targets |
When upgrading a target type from an earlier release, ensure that for RAW metrics, STORAGE_TABLE_NAME or STORAGE_COLUMN_NAME are not modified |
Upgrading Targets |
When upgrading a target type from an earlier release, ensure that the USAGE_TYPE of a metric is not modified. |
Derived Associations |
Ensure that your derived association rules start with proper prefix. For more information, see Using Association Derivation Rules Syntax and Semantics |
Derived Associations |
Ensure that your triggers satisfy all trigger patterns in the guide. For more information, see About Regular Query and Trigger Patterns. |
Derived Associations |
Ensure that your rule query only contains simple joins and one FROM clause. (If it is more complex, then explain how performance will be ensured) |
Derived Associations |
Test performance for each perspective on which your rule might get triggered |
Derived Associations |
Check that you have necessary indexes defined for joined columns (especially for larger data tables) |
Table B-3 provides a checklist which applies to the customized UI for your plug-in. This checklist is only applicable if you have a customized UI.
For more information about customized UIs, see Defining a Management User Interface.
Table B-3 Customized User Interface Checklist
Category | Checklist Item |
---|---|
Adobe Flash Player |
Check that your custom UI works with the supported version of Adobe Flash Player. See the Enterprise Manager certification matrix available on My Oracle Support for supported versions. https://support.oracle.com/ |
Browser Version Compatibility |
Check that your custom UI works with the supported versions of Web browsers. See the Enterprise Manager certification matrix available on My Oracle Support for supported versions. https://support.oracle.com/ |
Accessibility |
Ensure that the UI complies with the Oracle Global HTML Accessibility Guidelines (OGHAG). For more information, see Accessibility Guidelines. |
Performance |
Run performance tests on all new pages to ensure they load under a reasonable time limit. |
Table B-4 provides a checklist which applies to job types defined for your plug-in. This checklist is only applicable if you have files in the plugin_stage/oms/metadata/jobTypes directory.
For more information about Job Types, see Adding Job Types.
Table B-4 Job Types Checklist
Category | Checklist Item |
---|---|
Job Type Name |
Ensure the job type name is of the form plugin_tag_VerbNoun.
Oracle recommends names such as oracle_as_RunHostProcess, oracle_db_BackupDB, oracle_as_RotateLogs |
Display Names |
Ensure the job type's NLS information clearly conveys the intention of the job type. Keep in mind that there might be similar named job types from other plug-ins. Oracle recommends names such as dbBackupDB - "Backup Oracle Database", or asRotateLogs - "Rotate Weblogic Logs" |
Table B-5 provides a checklist which applies to reports defined for your plug-in. This checklist is only applicable if you have files in the plugin_stage/oms/metadata/reports directory.
For more information about reports, see Adding Information Publisher Reports and Developing BI Publisher Reports.
Table B-5 Reports Checklist
Category | Checklist Item |
---|---|
SQL Usage Information Publisher Reports only |
Ensure that NamedSQL is used rather than a raw SQL statement parameter in a report. Oracle recommends using Named SQL because it makes patching and changing your SQL more robust. If a user does a CREATE LIKE on your report, then they get an actual copy of the SQL statement unless you use Named SQL, in which case they get a pointer to the Named SQL. If you subsequently change the SQL, then the user gets the new copy from the Named SQL pointer. |
BI Publisher Reports only |
Ensure that the report includes proper header and footer subtemplates. |
Table B-6 provides a checklist for self-testing your plug-in.
For more information, see Validating, Packaging, and Deploying the Plug-in.
Table B-6 Plug-in Self-Test Checklist
Category | Checklist Item |
---|---|
Deployment Scenarios |
Confirm that you tested in the following deployment sequence:
For more information, see Importing and Deploying the Plug-in Archive into Enterprise Manager. |
Upgrade |
If this is not the first version of your plug-in, ensure that you have tested your plug-in upgrade on the same Enterprise Manager installations as the earlier supported versions of your plug-in. |