B Plug-in Technical Checklist

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:

Checking your Plug-in
Checking Targets
Checking Customized UIs
Checking Job Types
Checking Reports
Testing your Plug-in

B.1 Checking your Plug-in

Table B-1 provides a list to check the plug-in data.

For more information about defining plug-in metadata, see Chapter 2, "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, "Key Elements Within the plugin.xml File"
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, "Key Elements Within the plugin.xml File"
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, "Key Elements Within the plugin.xml File"
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. Applications Databases Middleware Engineered Systems Cloud Servers, Storage and Network For more information, see Table 2-1, "Key Elements Within the plugin.xml File"
Generic Plug-in	The default is Generic, so Oracle recommends removing the `<PluginOMSOSAruId>` tag or define as follows: <PluginOMSOSAruId value="2000"/> For more information, see Table 2-1, "Key Elements Within the plugin.xml File"
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 Section 14.4, "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 Section 14.3, "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.

B.2 Checking Targets

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 Chapter 3, "Creating Target Metadata Files" and Chapter 7, "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: is_system is_end_user_system Note: This property is for end-user systems. Most plug-ins do not require this so check with the Oracle Extensibility reviewers before setting the property. is_service is_install_home is_group Note: This property should be set the target_type=composite group only. is_existence_only Note: This property should be set for new targets that are not fully managed or monitored. For more information, see Table 3-2, "Type Properties".
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 Section 3.4.2, "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 12.01 to start with for 12.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 Section 3.3.3, "Defining the Target Type Metadata".
Target Type Metadata Minor Version	Ensure that the minor version number uses a 2 digit format, such as 12.01 instead of 12.1. Note: Minor versions are compared right-padded to 20 digits, so 12.9 > 12.10 in meta version semantics, since 12=12 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 12.NNYYWWW. If you are providing a metadata patch on top of 12.01, then the patch version is 12.0113005 (for 5th week of 2013). 12.0113005 is greater than 12.01 but less than 12.02 in target type metadata version semantics For more information, see Section 3.3.3, "Defining the Target Type Metadata".
Associations	Ensure that no abstract association types are used (`select assoc_type from mgmt_assoc_types where is_abstract=1`).
Associations	Ensure that only core association types are used (`select assoc_type from mgmt_assoc_types where category=1`)
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 Chapter 16, "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 Section 3.4.2, "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, "Key Elements Within the Default Collection Metadata File"
Metric Definitions	Ensure that the display names for metrics and metric columns are user-friendly and have proper NLSID. For more information, see Section 3.4.1, "Metric Definition Files".
Metric Definitions	Ensure that configuration metric definitions use type RAW (not TABLE). For more information, see Table 3-4, "Key Elements Used to Define Metrics"
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 Section 3.6.1, "Defining Target Metadata"
Metric Definitions	Ensure that you categorized your metrics within the Default metric class. For more information, see Section 3.4.5, "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 Section 7.3.2, "Key Elements of a Configuration Metadata XML File"
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 Section 11.3.1, "Using Association Derivation Rules Syntax and Semantics"
Derived Associations	Ensure that your triggers satisfy all trigger patterns in the guide. For more information, see Section 11.3.5, "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)

B.3 Checking Customized UIs

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 Chapter 9, "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 Section 9.32, "Accessibility Guidelines".
Performance	Run performance tests on all new pages to ensure they load under a reasonable time limit.

B.4 Checking Job Types

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 Chapter 8, "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. By using the plugin_tag as the prefix, you ensure the job type does not conflict with similar named job types from other plug-ins An appropriate verb-noun combination ensures that the objective of the job type is clear to the customer. 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"

B.5 Checking Reports

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 Chapter 5, "Adding Information Publisher Reports" and Chapter 6, "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.

B.6 Testing your Plug-in

Table B-6 provides a checklist for self-testing your plug-in.

For more information, see Chapter 14, "Validating, Packaging, and Deploying the Plug-in".

Table B-6 Plug-in Self-Test Checklist