Node associations are represented by relationships. There are different types of relationships which define hierarchy, hosting, containment, ownership, manufacturer, category, versions, location, dependency, in fact, any kind of relationship required to model an IT infrastructure.
A type of relationship is represented as colon-separated strings. A relationship comprises more than the two node endpoints, it contains the "route" between the two. This is made up in the following way:
For example, the relationship from a Host node to the Cluster node that contains the host is shown as:
The relationship from a Cluster node to a Host node that it contains is shown as:
A relationship is a bidirectional link between two nodes. In this section, the terms "start node" and "target node" are used to describe the way that the relationship is built. However, once the relationship has been built, the terms are redundant.
The general timeline for the creation of a relationship is:
- Create "start node".
- Create "target node".
- Create relationship between 1 and 2.
The individual components of the relationship are described in the following sections.
The node is any kind of node that can have a relationship, such as a Host node. All nodes can have relationships, including relationships.
The relationship kind describes the nature of the relationship. For example, the DeviceSubnet relationship kind describes the link between a device and the subnet that it is on, but without any directionality implied.
This section refers to Relationship Kinds as the colon-separated lists which describe how two nodes are related, the roles that each node plays in the relationship, and the Relationship Link which describes the nature of the Relationship.
A complete list of Relationship Kinds with their descriptions is provided in the table below.
Relates nodes into a hierarchy.
Relates a node to a file attachment.
Relates an element to a category it is in.
Relates an element to its owner.
Relates an employee to their manager.
Relates an element to the location it is in.
Relates a location to the larger location it is in.
Relates software to the host it is running on.
Relates hosts and software instances to contained virtual hosts.
Relates Hosts that appear to have changed identity
|HostedService||Relates a service to the host it is running on|
|Activity||Relates a Model Definition to an activity that has been performed on it|
Relates software instances to communicating software instances.
Used when a pattern can identify configuration within a piece of software that specifies communication with another piece of software. For example, a pattern might be able to read a configuration file for an application server and see the address of a database server.
Relates elements to elements they depend upon.
Relates an item of software to an item contained in it.
Relates an item of software to a service.
|DefinitionClone||Relates a Model Definition to a cloned version of it|
|DefinitionContainment||Relates a Model Definition to items included or excluded by it|
|FunctionalContainment||Relates a Functional Component to an item contained within it|
|MultiFacet||Relates multiple facets of a single process|
Relates observed communicating elements.
Used when communication between two pieces of software has been generically discovered from information like open network connections and listening ports. When BMC Discovery is able to identify both ends of a communication, it tries to then correlate this information with software that it sees running.
For this to work well, often root/administrator access for BMC Discovery is needed, as operating systems only give all the pertinent information to sufficiently privileged users.
|AdapterWithPort||Relates an adapter to a port|
Relates an IP device to the subnet it is on.
Relates an IP device with one of its network interfaces.
|DeviceAddress||Relates an IP device with one of its IP addresses|
Relates a network interface on a host to a port interface on a switch.
Relates a file to its host.
Relates a file to something that uses it.
Relates a World Wide Node Number (WWNN) to an HBA.
Relates a World Wide Port Number (WWPN) to a WWNN.
Relates the mounter and the FileSystem.
|ChosenEndpoint||Relates a device successfully scanned by this endpoint|
|Endpoint||Relates a Discovery Access that successfully scanned a device by this endpoint|
|CloudService||Relates cloud services|
|CouplingFacility||Relates Coupling Facility to its dependents|
|ExportedFileSystem||Relates exported FileSystem to local FileSystem|
|ExposedView||Relates a port to an exposed view (volume)|
|HardwareUse||Relates hardware to the system using it|
|InterfaceAddress||Relates a network interface with its IP addresses|
|NetworkService||A network device service|
Directly Discovered Data
Relates a DiscoveryAccess to one of its results.
Relates a List of Members.
Relates sequential nodes.
Relates an inferred node with its source node.
Relationship to a status node.
Information about a discovery request.
|DiscoveryCondition||Relates an element with a condition to that condition|
|EndpointRange||A range used to control endpoint access|
|ImplicitScan||Implicitly scanned IP address|
Associates a pattern module to its contents.
Associates a pattern module to its dependents.
Pattern that is maintaining an inferred node.
Associates a pattern that will need the products of another.
Associate patterns that are being overridden or are overriding others.
Associated pattern has been deprecated or is deprecating others.
Errors generated by this pattern at runtime.
Associates a PatternExecution to its Pattern.
Associate a PatternTrigger with things it changed.
Associates a PatternExecution to its trigger nodes.
Associates a Pattern to the DDD nodes requested by it.
Relates the implementation of a resource
Relates the usage of a resource
|CodeGeneration||Relates a generated pattern module to a pattern definition|
|UploadContents||Contents of unloaded knowledge|
Generic Modeling Relationships
Relates an element to its container.
Relates an element to details about it.
Relates Host and Software Instance nodes to SupportDetail nodes.
|Collection||Relates an element to the collection in which it is contained|
|Mirror||Represents a mirroring relationship|
|Replacement||A node replaced during update|
|Replication||Represents a replication relationship|
Associates a rule module to its dependents.
Foundation User Relationships
A Favorite item for a User
Relates to the invoking user
Hardware Reference Data Relationships
Relates physical hosts to hardware reference data
|HardwareReferenceData||Relates Host and HostContainer nodes to HardwareReferenceData nodes|
|DeviceStack||Relates a stack member to the stack itself|
|SANStorage||Relates a host consumer of SAN storage to the reference to that host on the storage|
|Storage||Relates Storage to hosts using it|
|StorageContainment||Relates Storage to the Storage Collection containing it|
|StorageUse||Relates storage nodes|
The role describes the part that its node plays in the relationship.
For example, where a Host node represents a host which is running a software process:
- A Software Instance has been created which represents the process running on the host.
- The Host node is acting in the role of Host; the host for some running software.
- The Software Instance is acting in the role of RunningSoftware; software which is running on a host.
Roles are required because a node can play one of many parts in a relationship, and clarification is needed; the role clarifies the part that the nodes are playing in the relationship.
A complete alphabetical list of Role Kinds in the default taxonomy with their descriptions is provided in the table below.
|ActedUpon||An item that is being acted on|
|AggregateSoftware||Aggregate software running on a host|
|AttachmentContainer||Node containing an attachment|
A group automatically generated by BMC Discovery
|BusinessOwner||Business owner of an element|
|Category||Category of elements|
|Child||Child in hierarchy|
|CloneForEdit||A Definition which is a clone of another for editing|
|CloneSource||A Definition which has been cloned|
|ClusteredSoftware||Clustered software running on a host|
|Collection||Element containing a collection of elements|
|Contained||An element contained within another|
|ContainedDrive||Contained disk drive|
|ContainedFunctionality||Component within a FunctionalComponent|
|ContainedHost||Host contained within another host|
|ContainedInstance||Contained load balancer instance|
|ContainedItem||An item within a container|
|ContainedLocation||A location inside another location|
|ContainedMember||Contained load balancer member|
|ContainedPool||Contained storage or load balancer pool|
|ContainedProcessor||Contained storage processor|
|ContainedService||Contained load balancer service|
|ContainedSoftware||Piece of software contained inside other software|
|ContainedStorage||Storage contained in an element|
|ContainedVolume||Contained storage volume|
|Container||An element containing others|
|Copy||Copy of item|
|Dependant||Entity that depends upon another|
|DependedUpon||Entity depended upon by another|
|Detail||A detail belonging to an element|
|DeviceOnSubnet||IP device belonging to a subnet|
|DeviceWithAddress||A device with an IP address|
|DeviceWithInterface||A device with an interface, for example, a network interface|
|DiscoveryCondition||Identifies a discovery condition|
|ElementInCategory||Element belonging to a category|
|ElementInLocation||Element in a location|
|ElementUsingFile||Element using a file|
|ElementWithCondition||Identifies a node to which a discovery condition pertains|
|ElementWithDetail||Element with associated details|
|ElementWithStatus||Element with an associated status|
|EndpointRange||A range used to control endpoint access|
|Error||An ECAError related to a pattern|
|ExcludedItem||An item excluded from a Definition|
|ExplicitEndpoint||User provided endpoint|
|Favorite||A favorite item for a user|
|FibreChannelDeviceWithNode||A Fibre Channel HBA with a WWNN|
|FibreChannelNode||A Fibre Channel WWNN for a HBA|
|FibreChannelNodeWithPort||A Fibre Channel WWNN with a WWPN|
|FibreChannelPort||A Fibre Channel WWPN|
|FoundationUser||A BMC Discovery User|
|FrontEndPort||A Front End Port|
|FunctionalContainer||FunctionalComponent containing components|
|Hardware||Physical host to which hardware reference data will be related|
|HardwareDetail||Support Detail Data is for Hardware|
|HomeLocation||Home location of an element|
|Host||Host for Software Instances|
|HostContainer||Host containing other hosts|
|HostedFile||A File on a Host|
|IPv4Address||An IPv4 address|
|IPv6Address||An IPv6 address|
|ITOwner||IT owner of an element|
|ImplicitEndpoint||System provided endpoint|
|IncludedItem||An item included in a Definition|
|IntegrationPoint||Integration point for a connection or query|
|InterfaceOfDevice||Interface of an IP device|
|InterfaceOfStack||Interface of the Stack|
|InterfaceWithAddress||Interface with an IP address|
|Location||Current location of an element|
|LocationContainer||A location containing other locations|
|ManagedElement||Element being managed|
|Manufacturer||Manufacturer of an item|
|Member||Member of a list or collection|
|MountedFileSystem||Mounted file system|
|Mounter||Mounter of a file system|
|NetworkEndpoint||One end of a network connection|
|NetworkService||Network device providing a service|
|New||A new node|
|Next||Next node in sequence|
|OSDetail||Support Detail Data is for Operating System|
|Old||A replaced node|
|OperatingSystem||Operating system of a host|
|Overridden||A pattern that is overridden by another|
|Overrider||A pattern that is overriding another|
|OwnedItem||Item owned by someone or something|
|Owner||Owner of an item|
|Parent||Parent in hierarchy|
|PatternDefine||Pattern definitions function|
|PatternWithError||A pattern with ECAErrors|
|Previous||Previous node in sequence|
|ReferenceData||Holds hardware reference data|
|Region||Cloud Region in which the related resource resides|
|RequestSource||Source of discovery request|
|Resource||Resource being used|
|ResourceUser||User of resource|
|RunningService||Service running on a host|
|RunningSoftware||Software running on a host|
|Service||Service being provided|
|ServiceHost||Host providing a service|
|ServiceProvider||Provider of a service|
|SoftwareContainer||Piece of software containing other software|
|SoftwareDetail||Support Detail Data is for Software|
|Stack||Stack of Network Devices|
|StackMember||Network Device in Stack|
|Storage||Storage for an element|
|StorageContainer||Element containing storage|
|Subnet||Subnet of an IP device|
|SupportOwner||Person or group responsible for supporting an element|
|UploadItem||Component of uploaded knowledge|
By linking data items and their attributes to the evidence for them, BMC Discovery enables its data to be easily verified; a prerequisite for trusting it. This feature is called Provenance.
Provenance Data is created by the Reasoning Engine and consists of relationships between Directly Discovered Data (DDD) items and entities inferred from them - a relationship back to the source from the inferred entity. For example, there is a provenance relationship between each Software Instance (SI) and the data that caused the SI to be inferred - typically one or more processes, files, or the like.
Provenance information is meta-information describing how the other information came to exist. It is generated as Reasoning builds and maintains the model. Provenance information is stored on relationships in the model.
- Inference Types
- Primary — indicate that the existence of the evidence node is the reason that the inferred node was created.
- Contributor — indicate that the evidence node provided information used in building the inferred node.
- Associate — indicate that BMC Discovery knows there is a relationship between the evidence node and the inferred node.
- Relationship — indicate that BMC Discovery knows that a relationship exists because of the evidence node.
- Deletion — indicate that the removal of the inferred node was due to withdrawal of the evidence node.
- Maintaining Pattern — the pattern maintaining a node.
If you need to access the data in your model you should access the UI functions provided in BMC Discovery that enable this. Apart from specialist purposes, you should not need to understand the provenance implementation details in BMC Discovery. However, an overview is provided below.
For patterns as well as the overall functioning in BMC Discovery, if the system scans the infrastructure and captures some data but in a subsequent scan fails to obtain the same data, it does not immediately remove the old data. For example, a scan in the past may have captured a host and its installed packages. But the latest scan may fail to retrieve the packages. This does not mean that the host now has no installed packages. The system records the failure in DDD and leaves the existing data as the best-known information. In a subsequent scan if the system successfully gets a list of packages, and some packages that were previously present are now absent, then the system updates the data by removing the relationships to non-existing packages.
Provenance implementation details
To represent provenance information, attributes can be stored on the Inference relationships. The keys attribute contains a list of the attribute keys that were set or confirmed on the inferred node as a result of the inference. The rule attribute contains the name of the reasoning rule that decided upon the inference. Provenance information is only created and is not updated.
Inferred nodes are related to DDD nodes using 'Creation Inference' relationships. The Inferred node has the role InferredElement; the DDD node has the role Primary, Contributor or Associate as appropriate. To support the full lifecycle of inferred nodes there are complimentary Removal Inference relationships. Destruction is the complementary role to Primary, and Withdrawal is the complementary role to Contributor.
The method of linking of discovered information to inferred information means that in general, each inferred node will have relationships to many discovery data nodes, representing multiple discoveries of the entity over time.
Relationships between relationships
Relationships are technically a sub-class of nodes and they have the same basic characteristics. Relationships can have attributes stored in them and can have relationships to other nodes in the same way that nodes can.
A relationship connects two nodes between their role, however a relationship can also act in a role in a relationship. Therefore, you can have relationships between nodes and relationships or relationships between relationships.
Relationships between inferred nodes
Using patterns, the reasoning engine can construct a number of relationships between inferred nodes, as follows:
Links an SI to the Host it is running on.
A client-server relationship between SIs. This can be inferred based on the presence of network connections between processes. It can also be based on other evidence such as configuration files or directly querying the endpoints.
Equivalent to the client-server case, but where the endpoints in a communication are peers, rather than client and server.
A dependency between SIs, other than a communication link. Attributes on the relationship can indicate the kind of dependency.
Represents SIs that logically contain other SIs.
Links a virtual host to the Software Instance that implements it.
Links a configuration file to a Software Instance.
Represents the SIs that make up a BAI.
Represents BAIs that logically contain other BAIs.
A dependency between BAIs.
Indicates the Hosts which form a cluster.
Indicates the SIs that provide clustering services for a cluster.
Represents the relationship between logical hosts and their container for Sun E15Ks and similar.
Represents the relationship between network interfaces and the subnets they are connected to.
In addition to these relationships, the reasoning engine also constructs relationships to the Pattern Management nodes, for example, patterns.