Certification Worksheets and checklist

KM certification worksheet

Product Name ______________________________________________________

Product Version ____________________________________________________

Product Prefixes ____________________________________________________

Certified Platforms _________________________________________________

___________________________________________________________________

PATROL Agent Versions ___________________________________________

Pass or Fail (circle one)

Comments _________________________________________________________

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

__________________________________________________________________

__________________________________________________________________

By __________________________________ Date ___________

Certification check list

Product Name _____________________________________________________

Product Version ___________________________________________________

Date ______________________________________________________________

Certification check list

Requirements	Pass
Product naming
Select a KM prefix You must select a unique KM prefix.
Use prefix in file and application class names The KM must use its registered prefix to identify all files in the KM package (.psl, .lib, .km, and .bin ) and application class names.
Use prefix in directory names The KM must use its registered prefix to identify directories that are created by the KM and are not standard directories used by PATROL.
State the use of ActiveX controls A KM that uses ActiveX controls must be designated for use on Windows platforms only.
Installation and packaging criteria
Install and uninstall properly The KM must install and uninstall on all supported platforms.
Do not change core product files The KM must not make modifications to ALL_COMPUTERS or any OS-type KM file.
Provide at least one KML file The KM package must include at least one .kml file to load the product.
Include a package MOF file The KM package must include an .mof file for the PATROL Console Server.
Use KM directives in KM files The KM must include the KM directives that identify the KM in all .KM files.
Provide resource files for KM images The KM must include a resource.mk4 file that includes icons and images for the KM.
Provide a list of files and system values The KM must provide BMC Software Customer Support with a list of all files installed and all system values set by the KM.
Start package names with the KM prefix The KM installation package names must start with the KM developed record or KM prefix.
Install shipped RuleSets in standard directory If the KM ships PATROL Configuration Manager RuleSets, the KM must install the RuleSets in the standard KM RuleSet directory.
Operational criteria
Create one application class per KM file A KM file must contain only one application class.
Do not require a Developer Console The KM must not require a Developer Console connection for configuration.
Support multiple application instances The KM must support multiple instances or state in the product documentation that it does not support multiple instances of an application.
Limit the number of discovered instances When it is realistic that the KM will discover more than 50 instances of an application it is monitoring, the KM must provide a method for limiting the number of instance icons that are displayed.
Limit cumulative data If the KM generates more than 20 MB of cumulative data files per week, the KM must either include an automated clean-up mechanism (unless implemented as a circular file) or document this information in the product documentation.
Clean-up and close channels If the KM supports multiple channels, it must clean up and close channels properly.
Store configuration data in the Agent database The KM must store KM configuration settings and information in the PATROL Agent configuration database, usually done with pconfig().
Create unique configuration variables The KM must create its configuration variables in the PATROL Agent configuration database using a unique name.
Notify the user of Agent reinitialization The KM must notify the user if the KM must reinitialized the agent.
Enable KM with metadata The KM must be Section 508 compliant.
Enable KM with metadata The KM must be enabled with metadata.
Supporting the PATROL Configuration Manager and the PATROL KM for Event Management
Store user configurable KM data in pconfig database You must store user configurable KM data in the pconfig database, which allows your KM configuration data to be directly accessed and, when appropriate, managed by the PATROL Configuration Manager.
Do not use the change_state function instead of a threshold on a parameter Do not use the change_state function to alter the initial state of the application instances. Instead, provide a corresponding parameter-level status indicator, which allows the user to create events and adjust thresholds through the PATROL KM for Event Management.
Use a pconfig rule to alter parameter polling intervals Do not alter parameter polling intervals internally or dynamically in the code. When a KM is loaded for the first time and the initial values are set, use a pconfig rule to make any subsequent changes to the parameter intervals (poll times). You must use the same pconfig rule that is accessible to the user through the PATROL Configuration Manager.
Use a pconfig rule to alter the initial value of a parameter's built-in variable Do not alter the status of a parameter's built-in variable programatically or dynamically in the code. When a KM is loaded for the first time and the initial status is set, use a pconfig rule to make any subsequent changes to the parameter status. You must use the same pconfig rule that is accessible to the user through the PATROL Configuration Manager. The pconfig() function call must be used in lieu of the set() function call to memory.
Do not use the event_trigger function for event messages The KM must not use the event_trigger or event_trigger2 functions to generate events that are implicitly generated by PATROL. The KM must rely on the PATROL Agent to generate events when alarm ranges are exceeded.
Use only alphanumeric characters when naming objects The KM should use only alphanumeric characters when naming objects such as application names, instances, and parameters, within the KM. Begin the object name with an alphabetic character. Do not start an object name with a numeric character.
Ship all default KM configuration settings as standard RuleSets You MUST ship all default KM configuration settings as a standard RuleSet for the KM. The RuleSet must include any configuration that is unique to the KM, not just thresholds and alarm ranges.
Handle an incorrect pconfig value Your KM must be able to handle an out-of-range pconfig value by substituting a value that is within range. Your KM must notify the user of the value that was substituted for the out-of-range value.
Do not use sleep periods if annotating data points If annotating data points, do not put in a sleep period between when the parameter is set and when the annotation is made unless absolutely necessary.
User interface
Store user configurable KM data in pconfig database The KM must provide icons for use in all PATROL Consoles.
Identify warnings and alarms The KM icons must clearly identify warning and alarm conditions.
Provide distinguishable error messages The KM error messages must contain a unique tag that identifies the messages.
Provide KM tracing or diagnostics The KM must provide the ability to turn tracing or diagnostics (debugging) on and off.
Display KM version in InfoBoxes The KM must include the KM version number in the top-level InfoBox of each application class.
Documentation
Provide KM Context-Sensitive Online Help The KM must included a context-sensitive online help system for each supported console.
Provide documentation in electronic form The documentation must be available in electronic form using PDF or HTML format.
Provide instructions for installing and deploying The documentation must include step-by-step instructions for installing and deploying the KM.
Provide instructions for uninstalling The documentation must include step-by-step instructions for uninstalling the KM.
Provide configuration steps The documentation must include step-by-step instructions on how to configure the KM.
Document required accounts and privileges on OS The documentation must clearly identify what functionality, if any, is lost when the KM does not have the required user accounts and privileges.
Document loss of functionality due to lack of privileges The documentation must clearly identify what functionality, if any, is lost when the KM does not have the required user accounts and privileges.
List supported operating systems The documentation must list the operating environments supported by the KM, including the monitored application versions and PATROL versions.
Document platform issues The documentation must document any portability issues, inconsistencies, or lack of functionality that occurs across platforms.
Provide reference information The documentation must include reference information for all PATROL KM components.
Document inter-class dependencies The documentation must list and describe inter-class dependencies.
Document Agent to Agent communication If the KM uses agent to agent communication, the documentation must include descriptions and uses of inter-agent communications.
Document how to access the Help system The documentation must include instructions on how to access the KM Help system on all supported PATROL consoles.
Document directory and file use The documentation must describe any directory or file usage, with permissions (read, write, execute), outside of the BMC Software installation directory (BMC_BASE or BMC_ROOT).
Document security level differences The documentation must explain any differences in KM behavior at different PATROL security levels (0 through 4).
Document the KML file The documentation must include the contents and a description of the KMs loaded by the.kml file.
List executables and services The product documentation must provide a list of executable files, binaries, services, and processes that are included with the KM.
[Document KM structure / hierarchy\|Document KM structure / hierarchy#67730] The product documentation must provide a hierarchical map or tree structure that shows the KM hierarchy.
[Provide KM online Help TOC\|Document KM structure / hierarchy#55886] The TOC of each Help system must roll up into one book with the following naming convention: prod_name v V.R.
[Provide KM version in online Help\|Document KM structure / hierarchy#25024] The KM name and version number must appear in the title bar of the TOC and Help windows in the following format: prod_name Help v V.R.
[Document if the KM enables or disables an application class\|Document KM structure / hierarchy#94395] The product documentation must follow the conventions and formats in the Help and hard copy models created by the KM Consistency team.
[Document if the KM enables or disables an application class\|Document KM structure / hierarchy#82187] If the KM programmatically enables or disables an application class, the documentation must describe the conditions when the KM will enable or disable the application class.
[Document if the KM adjusts parameter settings\|Document KM structure / hierarchy#98394] If the KM programmatically adjusts parameter settings, the documentation must describe the conditions when the KM adjusts parameter settings.
[Document if the KM sets the parameter status\|Document KM structure / hierarchy#79467] If the KM programmatically sets the parameter status, the product documentation must describe the conditions when the KM sets the parameter status.
[List files created by the KM\|Document KM structure / hierarchy#97568] The documentation must list all files that are created by the KM.
Provide documentation for other requirements The product documentation must document any of the following issues that are cover by requirements in other sections.
Security
Do not store clear text passwords The KM must not store clear text passwords in external files or in the agent namespace.
Use KM defaultAccount encryption method (PATROL Agent 3.7. and earlier versions) If the KM stores passwords in the agent configuration database, the KM must use configuration variables with the suffix defaultAccount.
Use Secure Key Store to store password (PATROL Agent version 3.8 and later) For PATROL Agent version 3.8, the KM must use the Secure Key Store to store passwords.
Ensure passwords are not exposed If the KM spawns a process that requires a password as a command-line argument, the KM must ensure that the password is not visible.
Use KM protocol security If the KM uses protocols other than the PATROL protocols, the KM must document the use of the protocols so that customers can understand their level of security risk.
Document Windows advanced rights If the KM runs on Windows, the KM must document the need for advanced user rights and what functionality will be disabled (loss of functionality) if each of the advanced rights does not exist.
Document group use The KM must document the need for the agent default account to belong to administrator type groups (Administrators, Domain Admin, etc.) and what functionality will be disabled (loss of functionality) if the agent default account is not a member of the group.
Internationalization
Externalize message IDs and catalogs KM messages (menu command strings, dialog messages, event catalogs, etc.) must be externalized in the form of message catalogs.
Use complete messages in catalog files KM message catalogs must contain complete messages to facilitate translation. Messages must not be broken into segments in the message catalogs.
Use vendor IDs for catalog files The KM must use its assigned vendor ID that uniquely identifies the vendor.
Use tool IDs for catalog files The KM must use its assigned tool ID.
Support system locales The KM must support the system locale and not make any assumptions as to the character size.
Use file paths in localized format The KM must handle file paths, within the context of the monitored application, in the localized format correctly.
Perform codeset conversion When the KM communicates with an external process with a compatible locale but a different codeset, the KM must perform the codeset conversion.
Support locale uniqueness The KM must correctly translate the monetary, time, date, and demographic specific formats for supported locale.
Sort text correctly The KM text sorting must operate based on the alphabetical order defined for supported locale.
Support multi-byte characters The KM must not split multi-byte characters when reading or writing data files.
Provide locale translation If localization is required, the KM menu commands, InfoBox items, window captions, graph titles, and units. must be translated into the supported locale and be displayed correctly.
Support language enablement If language enablement is required, the KM must accept and display the characters of the required languages correctly.