Metadata can be provided for a number of declarations, describing the purpose of the declarations. Metadata attributes can be defined for the pattern module as a whole, and for individual patterns and identify tables in the module. Metadata declarations take the form:
When pattern modules are loaded into BMC Discovery, the metadata attributes are stored along with the pattern modules in the data store, allowing them to be searched for and used in reports. There is not a fixed set of metadata attributes - any attributes can be set as appropriate for the pattern. However, the following attributes are recommended for all patterns and pattern modules:
The software categories the product is in
Versions of the product(s) that are known to exist
Any publishers that OEM the product(s)
Publishers previously related to the product(s), in case the product or publisher has been bought
If the product is available in different editions, which ones the pattern covers
Publisher specific product families the product(s) belong to
Other names for the product(s)
The names of the product(s) identified by the pattern
Other names the publishers are known by
The publisher(s) or the product(s) at the time of pattern creation
Suppress the display of communication and observed communication relationships from the SI. See suppress_comms for more information.
For patterns from the Technology Knowledge Network, the identity in the TKN database
Position of the pattern module within the tree on the Knowledge management page
Web URLs of relevance
All of the attributes are lists of strings or numbers since it is possible for one single pattern or pattern module to be relevant to a number of different products.
Attributes are tagged as "expected" if well-written patterns would be expected to have them. All patterns available through TKN will have all of the expected attributes.
In many monitoring and management applications there are a large number of relationships between the server and agents. In most cases these are not particularly interesting in visualizations. The
suppress_comms declaration enables you to tailor the communication that you want to display. Permitted values are described in this table:
Prevent the display of all ObservedCommunication and Communication relationships for the SI.
Prevent the display of just ObservedCommunication relationships, but keep and model Communication relationships.
Do not follow relationships where the SI is the client end of a modeled Communication relationship.
Do not follow relationships where the SI is the server end of a modeled Communication relationship.
Do not follow relationships where the SI is the connecting (that is, client) end of an ObservedCommunication relationship.
Do not follow relationships where the SI is the listening (that is, server) end of an ObservedCommunication relationship.
Do not follow relationships where the SI is a Peer in a directionless Communication or ObservedCommunication relationship.