Service Tree
In CMDB, a service tree is a hierarchical structure for organizing and presenting the relationships between IT services, applications, and related components. Service trees help organizations to better manage and maintain IT services by providing a clear understanding of the dependencies and hierarchies between different services. With a service tree, users can quickly view and understand the associations between individual services, helping to improve the efficiency and visualization of IT service management.
Common CI relationships include containing, employment, installation, connive.
can be added to Admin Relation Type if additional relationships are required.
Definition of business relations
Through the backend management business relationship definition , users can add relationship view definitions. Users will be able to see the page displaying the relationships between various models in a tree diagram format, as shown in the following figure:
The model relationship in the graph in Configuration Module via association creating and corresponding CIType, eg:server contains web cards and hard drives.
Add Business Relationship(service tree)
For example, we would like to know the distribution of physics and virtual machines on the link chain -> Product -> Apply can be used to define the relationship view： as follows.
When defining the relationship view, please note that the tree node must have a lower node, that is, the resource node in the above graph and that the next node will be shown as table data in the relationship view
1. Selecting tree catalog nodes
First click the Add Service Tree button, and then check the tree catalog node，For example, Business Division -> Product -> Project
2. Fill out the service tree configuration
Click the Save button in the upper-left corner of the page to open the New Service Tree pop-up window, fill in the name of the service tree, check the box to make it public, display the child nodes of the tree as a Table, display the information of the tree nodes, etc., and click the OK button.
- Name：Service tree name.
- Public：When checked, the current service tree is visible to all users.Only the Service Tree menu is publicly available, and Service Tree data permissions need to be authorized separately on the Service Tree page.
- Show Leaf Node：Required, the details of the Service Tree resource nodes will be displayed as a Table.
- Show Tree Node：When checked, the tree node information will also be displayed as a Table.
- Sort：Configure the order in which Show Leaf Node and Show Tree Node are displayed in the Table
3. View Service Tree
After adding a new business relationship, in the menu bar view module, you find a new menu Service Tree(The name of the service tree you entered in the Add Service Tree pop-up window).
The values displayed in the directory on the left side of the service tree default to the model's unique identification attribute values, or you can go to Setting Display Properties for Models to customize the display attributes of the service tree nodes.
If you need to customize multiple service trees, just follow the above steps again to add new business relationships.
On the Service Tree page, you can do the following:
- Adding subordinate nodes.
- Remove current node.
- Grant, Revoke permissions and Viewing permissions.
- Modify the current node name.
- Batch operation: supports batch authorization, recycling and removal of peer nodes.
Service Tree Authority Control
Permission control of the veops CMDB service tree ensures that only authorized users can access and manipulate service tree related information. This protects sensitive data and configuration information and prevents unauthorized users from modifying or viewing the service tree, thus improving system security and data protection. At the same time, privilege control can also assign different privilege levels according to the roles and responsibilities of users to ensure that users can only access the information they need, improving the controllability and management efficiency of the system.
Service Tree node permissions have a downward override, so that when a user is granted node permissions, he or she is automatically granted view permissions for child nodes.
Non-administrative users can only access the data of authorized nodes. The node permissions of the service tree are governed by the service tree permissions and are independent of the instance permission configuration in the model configuration. The underlying table data of the service tree is subject to the intersection of the service tree permission control and the model instance permissions because the underlying table data of the service tree is displayed in detail.
many-to-many relationships
CMDB supports one-to-one, multi-pairs and multi-to-multiple relationships in service trees. This This chapter will demonstrate the application of many-to-many relationships in the service tree through an example.
Instance Demo
Please first follow the steps above to configure a service tree containing many-to-many relationships.
Next, let's demonstrate the application of many-to-many relationships in the Veops CMDB service tree through a practical scenario. The model relationships and service tree definitions are illustrated in the following diagram:
As shown in the diagram above, the entire chain is: Environment -> Region -> Cluster -> Namespace -> Node. Among them, the relationships between Region and Cluster, and between Namespace and Node are one-to-many relationships, while the relationships between the rest of the models are many-to-many relationships.
If there are many-to-many relationships in the service tree, please do not modify the definition of the service tree, which will lead to the confusion of the data in the existing service tree. Before defining the service tree, please design your usage scenario in advance and then plan the service tree business relationship.
With the custom service tree mentioned above, we can achieve the following scenarios:
As shown in the above diagram, both the Stage and Test environments include multiple regions, and the number of nodes in the Shanghai region differs between these two environments. It's evident that there is a many-to-many relationship between environments and regions. Each region has its own clusters, and a cluster does not exist in multiple regions; therefore, the relationship between regions and clusters is one-to-many. Similarly, the relationship between clusters and namespaces is many-to-many, while the relationship between namespaces and nodes is one-to-many.
Through the service tree, we can clearly see the distribution of resource nodes (Node) in the hierarchical directory nodes (environment -> region -> cluster -> namespace), achieving clarity and improving operational efficiency.