Method and device for docking digital map based on topology fusion topology architecture

Abstract

The invention discloses a digital map docking method and device based on topology fusion topology architecture, and the method comprises the steps: defining different types of original topological graphs, defining a customized graph list for each type of original topological graph, defining a rule tree for each customized graph, and storing the customized graphs in a topology database; when the Newcastle digital map is docked, acquiring the digital map, loading the corresponding customized graph list from the topology database according to the type of the digital map, and loading the corresponding rule tree according to the selected customized graph; calculating points and lines corresponding to the selected customized graph according to the digital map and the rule tree, forming the customized graph by the calculated points and lines and the point-line relationship, and storing the customized graph in a topology cache library; and the front-end page loads the customized graph from the topology cache library for presentation. The method and the device not only have basic function characteristics of topology, but also have high performance, maintainability, reliability, safety and usability.

Description

Technical Field

[0001] This invention relates to the field of new urban metropolitan area networks, and in particular to a method and apparatus for connecting digital maps based on a topology fusion topology architecture. Background Technology

[0002] Business-driven:

[0003] (1) There are currently multiple different topologies, including metropolitan area network IP topology, IPRAN topology and visual routing topology. The three topologies are completely different in terms of implementation mechanism and presentation effect, which leads to differences in user experience. Users often question why one topology is missing a certain function, and raise different requirements for the differences between topologies on different topology diagrams. They also strongly demand that the style be consistent, the usage habits be consistent, and that the topologies be merged into one set.

[0004] (2) Currently, the requirements for sliced ​​topology and CT cloud monitoring topology in new metropolitan area networks cannot be quickly integrated, whether implemented on visualized routing topology or metropolitan area network IP topology. Metropolitan area network IP topology cannot flexibly customize topology design; visualized routing topology does not define methods for extending services; IPRAN topology is a highly specialized topology that cannot be extended.

[0005] (3) There are many current network management network topologies. At present, no topology can achieve rapid business expansion and reduce the development workload.

[0006] Technology-driven:

[0007] (1) Different topologies use different frameworks, which creates technical barriers to maintenance. They are maintained by different teams, and it is difficult to implement the functions of other topologies on the existing framework. Visualized routing topology data is stored in Java memory, which has a single point of failure, and there is a performance bottleneck if there is a lot of topology data. Metropolitan area network IP topology cannot flexibly define network topology, and only supports simple device attributes and node definitions. The calculation part uses SQL statistics in Python, which is difficult to maintain. IPRAN topology can be used as a reference for services, but IPRAN topology is a topology defined purely according to services and cannot be customized.

[0008] (2) The current topologies all have varying degrees of performance problems, real-time problems, and issues with the aesthetics of the layout and presentation. They urgently need to be optimized and reconstructed.

[0009] Based on the above issues, a more complete, compatible, and scalable new topology framework is urgently needed for the connection of the new city's metropolitan area network. Summary of the Invention

[0010] To address the aforementioned technical problems, this invention provides a method and apparatus for connecting digital maps based on a topology fusion topology architecture. This method not only possesses the basic functional characteristics of topology but also features high performance, maintainability, reliability, security, and ease of use.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] In one embodiment of the present invention, a method for connecting digital maps based on a topology fusion topology architecture is proposed, the method comprising:

[0013] Define different types of original topology graphs, define a list of custom graphs for each type of original topology graph, define a rule tree for each custom graph, and store them in the topology database;

[0014] When connecting to the new city's digital map, the digital map is obtained and the corresponding list of customized maps is loaded from the topology database according to the type of the digital map. The corresponding rule tree is loaded according to the selected customized map.

[0015] Based on the digital map and rule tree, calculate the points and lines corresponding to the selected customized map. The calculated points and lines, as well as the relationships between them, constitute the customized map and are stored in the topology cache library.

[0016] The front-end page loads a custom graph from the topology cache library for presentation.

[0017] Furthermore, based on the rule tree, each customized graph defines the expanded and collapsed states of the rule tree nodes; each customized graph also defines multiple alarm rules.

[0018] Furthermore, the processing logic for calculating the customized graph based on the original graph is as follows:

[0019] Load the original graph object based on the original graph topology;

[0020] Load the rule tree object based on the rule tree ID;

[0021] Based on the original graph and rule tree, the point data that should be included under the rule is calculated according to the rule tree, and a customized graph object is generated. At the same time, the point data, line data, point-line relationship and parent-child relationship data are recorded.

[0022] Store custom graph objects in the topology cache library.

[0023] Furthermore, according to the rule tree, calculate the point data that should be included under the rule, including:

[0024] Obtain a list of rules sorted by rule priority based on the rule tree;

[0025] A list of double-loop rules and a set of points;

[0026] Call the `isRight` method to determine if each point conforms to the rule, pass in the points, calculate the relationship between the rule and the points, and store it as a MAP.

[0027] Furthermore, the calculation generates a custom graph object, including:

[0028] Starting from the top-level ROOT layer, each node and its corresponding points are generated recursively.

[0029] Get the list of subrules of the current rule;

[0030] Loop through the list of subrules and check if the list is empty;

[0031] If the value is empty, the current rule recursion ends and the previous loop rule is returned. If the value is not empty, the current rule is created as a node in the topology and added to the topology.

[0032] Add the data of all points under the current rule to the topology and record the parent-child relationships;

[0033] Recursively apply the current rule as a parent rule;

[0034] The loop ends, generating all parent-child relationships for nodes and lines;

[0035] Get all the points in the customized graph, add the links between two points in the original graph to the set of all lines, and record them in the customized graph.

[0036] In one embodiment of the present invention, a device for connecting digital maps based on a topology fusion topology architecture is also proposed, the device comprising:

[0037] The topology calculation service module is used to define different types of original topology maps. Each type of original topology map defines a list of custom maps, and each custom map defines a rule tree, which are stored in the topology database. When connecting to the new city digital map, the module obtains the digital map and loads the corresponding list of custom maps from the topology database according to the type of the digital map. It also loads the corresponding rule tree according to the selected custom map. Based on the digital map and the rule tree, the module calculates the points and lines corresponding to the selected custom map. The calculated points and lines, as well as the point-line relationships, constitute the custom map and are stored in the topology cache library.

[0038] The topology runtime service module is used by the front-end page to load a customized graph from the topology cache library for presentation.

[0039] In one embodiment of the present invention, a computer device is also proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it realizes the aforementioned docking of digital maps based on topology fusion topology architecture.

[0040] In one embodiment of the present invention, a computer-readable storage medium is also provided, which stores a computer program that executes a digital map based on a topology fusion topology architecture.

[0041] Beneficial effects:

[0042] 1. The present invention provides a unified architecture for topology services, clearly defining the functional divisions of topology computing services, topology runtime services, etc.

[0043] 2. This invention stores the customized graph in Redis, separating computation and presentation, which facilitates service expansion.

[0044] 3. The present invention provides a unified basic model for topology computation. The topology computation service module can flexibly compute customized graphs based on the original graph and rule tree and store them in Redis, laying a solid foundation for flexible business definition of topology.

[0045] 4. This invention clearly defines the interface specifications for obtaining the original graph and provides implementation examples; business users can flexibly define the original graph according to their own business needs, which facilitates business expansion.

[0046] 5. This invention clearly defines the definition specifications of the rule tree and provides implementation examples; business users can flexibly define the rule tree and the unfolded / folded state of the rules based on the original graph according to their own business needs.

[0047] 6. The topology runtime service module of the present invention covers the basic functions of the topology, including alarms, performance, resources and permissions. The basic topology functions can be reused, avoiding the repeated implementation of the same functions and improving R&D efficiency.

[0048] 7. This invention is based on a converged topology architecture, which allows for flexible definition of business functions. Based on the topology development specifications, it can reuse existing stable functions and quickly customize development according to individual business needs. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the method for connecting digital maps based on topology fusion topology architecture according to the present invention;

[0050] Figure 2 This is a schematic diagram of the topology computing service of the present invention;

[0051] Figure 3 This is a schematic diagram defining the original drawing of this invention;

[0052] Figure 4 This is a schematic diagram of the rule tree definition of the present invention;

[0053] Figure 5 This is a schematic diagram defining the custom drawing of this invention;

[0054] Figure 6This is a schematic diagram of the processing logic of calculating a customized graph based on the original graph in this invention;

[0055] Figure 7 This is a schematic diagram of the device structure for connecting digital maps based on a topology fusion topology architecture according to the present invention;

[0056] Figure 8 This is a schematic diagram of the computer device structure of the present invention. Detailed Implementation

[0057] The principles and spirit of the present invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are provided merely to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0058] Those skilled in the art will recognize that embodiments of the present invention can be implemented as an apparatus, device, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0059] According to an embodiment of the present invention, a method for connecting digital maps based on a topology fusion topology architecture is proposed, which has the basic functional characteristics of topology and possesses high performance, maintainability, reliability, security and ease of use.

[0060] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0061] Figure 1 This is a schematic diagram of the method for connecting digital maps based on a topology fusion topology architecture according to the present invention. Figure 1 As shown, the method includes:

[0062] 1. Topology Computing Service:

[0063] (1) Interface:

[0064] Topology data acquisition service interface (original graph loading);

[0065] Topology rule management service interface (rule definition);

[0066] Topology computing service interface (custom computing);

[0067] Topology data update service interface (real-time refresh, timed refresh);

[0068] Topology data storage service interface (customized storage model);

[0069] (2) Define different types of original topology graphs, define a list of custom graphs for each type of original topology graph, define a rule tree for each custom graph, and store it in the topology database;

[0070] When connecting to the new city's digital map, the digital map is obtained and the corresponding list of customized maps is loaded from the topology database according to the type of the digital map. The corresponding rule tree is loaded according to the selected customized map.

[0071] Based on the digital map and rule tree, calculate the points and lines corresponding to the selected customized map. The calculated points and lines, as well as the relationships between them, constitute the customized map and are stored in the topology cache library.

[0072] like Figure 6 As shown, the processing logic for calculating the customized graph based on the original graph is as follows:

[0073] Load the original graph object based on the original graph topology;

[0074] Load the rule tree object based on the rule tree ID;

[0075] Based on the original graph and rule tree, the point data that should be included under the rule is calculated according to the rule tree, and a customized graph object is generated. At the same time, the point data, line data, point-line relationship and parent-child relationship data are recorded.

[0076] Store custom graph objects in the topology cache library;

[0077] According to the rule tree, calculate the point data that should be included under each rule, including:

[0078] Obtain a list of rules sorted by rule priority based on the rule tree;

[0079] A list of double-loop rules and a set of points;

[0080] Call the `isRight` method to determine if each point conforms to the rule, pass in the points, calculate the relationship between the rule and the points, and store it as a MAP.

[0081] Calculate and generate custom graph objects, including:

[0082] Starting from the top-level ROOT layer, each node and its corresponding points are generated recursively.

[0083] Get the list of subrules of the current rule;

[0084] Loop through the list of subrules and check if the list is empty;

[0085] If the value is empty, the current rule recursion ends and the previous loop rule is returned. If the value is not empty, the current rule is created as a node in the topology and added to the topology.

[0086] Add the data of all points under the current rule to the topology and record the parent-child relationships;

[0087] Recursively apply the current rule as a parent rule;

[0088] The loop ends, generating all parent-child relationships for nodes and lines;

[0089] Get all the points in the customized graph, get the links between two points in the original graph and add them to the set of all lines, and record them in the customized graph;

[0090] 2. Topology runtime services

[0091] (1) Interface:

[0092] Topology map retrieval interface (converting customized map data into front-end presentation data);

[0093] Topology graph operation service interface (expand and merge, drill down);

[0094] Alarm performance data association service interface;

[0095] (2) The front-end page loads a custom graph from the topology cache library for presentation.

[0096] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0097] To provide a clearer explanation of the above-mentioned topology fusion architecture for connecting to digital maps, a specific embodiment will be used for illustration below. However, it is worth noting that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation of the present invention.

[0098] Example:

[0099] 1. Topology Computing Service

[0100] like Figure 2As shown, the topology computing service defines the original graph resource service interface, which is actually implemented by the resource service. The acquisition of original graph data differs for different topology types. Each original graph topology loads devices with limited device attributes and circuits with limited circuit attributes according to its respective business. For device resources, additional device information is loaded according to the needs of the original graph presentation, such as cloud resource pools, CP groups, UP groups, POD groups, warm standby groups, data centers, and slice types for new cities; for sliced ​​devices, virtual points and lines need to be constructed according to the business; the finally calculated points and lines constitute the original graph data, which is then returned.

[0101] The topology database stores original graph definitions, rule tree definitions, and alarm rule definitions. For each topology type, multiple customized graphs can be defined according to dimensions such as province, city, and cloud resource pool. Each customized graph can define a rule tree. A rule tree consists of several tree-structured rules, each defining several dimensions of rule constraints, such as node, device attributes, cloud resource pool, CP group, UP group, POD group, temperature standby group, data center, and slice type, etc. Based on the rule tree, the expansion and collapse states of the rule tree nodes can be customized for each customized graph. Furthermore, each customized graph can define alarm rules, limiting the filtering conditions for alarms on the customized graph. Each alarm rule defines several dimensions of alarm rule constraints, such as node, device attributes, cloud resource pool, alarm type, and alarm level, etc.

[0102] The primary function of the topology computing service is to store customized graph data. The topology computing service retrieves the original graph from the original graph resource service interface and loads a list of customized graphs corresponding to the original graph type. It then iterates through the list of customized graphs, loading the corresponding rule tree based on the customized graph identifier. Finally, based on the original graph and the rule tree, it calculates the points and lines corresponding to the customized graph. These calculated points, lines, and their relationships constitute the customized graph, and each customized graph is ultimately stored in Redis.

[0103] (1) Definition of the abstract base class object for topology computing services, such as Figure 3 As shown:

[0104] MapObject object, the abstract parent class of dots and lines

[0105] @Getter

[0106] @Setter

[0107] @ApiModel

[0108] public class MapObject implements Serializable {

[0109] private static final long serialVersionUID = 78880893313419381L;

[0110] @ApiModelProperty(value = "Parent ID")

[0111] @JsonProperty("pId")

[0112] private String pId;

[0113] @ApiModelProperty(value = "ID")

[0114] private String id;

[0115] @ApiModelProperty(value = "name")

[0116] private String name;

[0117] @ApiModelProperty(value = "alias, short name")

[0118] private String alias;

[0119] @ApiModelProperty(value = "whether to collapse")

[0120] private boolean fold = true;

[0121] @ApiModelProperty(value = "object type")

[0122] private String type;

[0123] @ApiModelProperty(value = "Change type")

[0124] private String changeType;

[0125] @ApiModelProperty(value = "Change Time")

[0126] private String changeTime;

[0127] @ApiModelProperty(value = "Total number")

[0128] private int size;

[0129] @ApiModelProperty(value = "Style")

[0130] private MapObjectStyle style;

[0131] private String nodeServType;

[0132] MapObject() {}

[0133] }

[0134] Point top-level base class Point object

[0135] @Getter

[0136] @Setter

[0137] @ApiModel(value = "Point")

[0138] public class Point extends MapObject {

[0139] private static final long serialVersionUID = -8986833452805423099L;

[0140] @ApiModelProperty(value = "Coordinates")

[0141] PointCoordinate position;

[0142] public Point() {

[0143] this.setType(BaseConstant.PTYPE_POINT);

[0144] }

[0145] public boolean isNode(){

[0146] return BaseConstant.PTYPE_NODE.equals(this.getType());

[0147] }

[0148] }

[0149] Link top-level base class object

[0150] @Getter

[0151] @Setter

[0152] @ApiModel(value = "line")

[0153] public class Link extends MapObject {

[0154] private static final long serialVersionUID = -5208604828604154009L;

[0155] / / fromId

[0156] @ApiModelProperty(value = "starting ID")

[0157] @JsonProperty("fId")

[0158] private String fId;

[0159] / / toId

[0160] @ApiModelProperty(value = "Termination ID")

[0161] @JsonProperty("tId")

[0162] private String tId;

[0163] / / from end name

[0164] @ApiModelProperty(value = "starting name")

[0165] @JsonProperty("fName")

[0166] private String fName;

[0167] / / to end name

[0168] @ApiModelProperty(value = "Termination Name")

[0169] @JsonProperty("tName")

[0170] private String tName;

[0171] private List <link> diffLinks = new ArrayList<>();

[0172] private List <link> sameLinks = new ArrayList<>();

[0173] / / Total number of link groups

[0174] private int total = 1;

[0175] }

[0176] (2) Rule base class objects, such as Figure 4 As shown:

[0177] public abstract class Rule implements Serializable {

[0178] private static final long serialVersionUID = -8133415295641339232L;

[0179] / / Topology map ID

[0180] private String topoId;

[0181] / / RuleId

[0182] private String id;

[0183] / / Rule Parent ID

[0184] @JsonProperty("pId")

[0185] private String pId;

[0186] / / Rule Name

[0187] private String name;

[0188] / / Rule Priority

[0189] private int priority;

[0190] / / Rule creation time

[0191] private Date createTime;

[0192] / / Rule modification time

[0193] private Date modifyTime;

[0194] / / Associate Topology ID

[0195] private String relaTopo;

[0196] private String nodeServType;

[0197] public abstract boolean isRight(Point point);

[0198] }

[0199] (3) The top-level class of the topology graph is the BasicTopo object (topology base class), such as Figure 5 As shown:

[0200] Description of the topology base class functionality:

[0201] Define a graph object (original graph, abstract class for custom graph, wrapper class);

[0202] It supports various processing methods to implement the creation, deletion, modification, and query of graph objects, and to calculate various relational data.

[0203] Define the top-level base class Point;

[0204] Define the top-level base class for the line: Link;

[0205] Define the parent-child relationship of points.

[0206] The attributes are shown in Table 1 below:

[0207]

[0208] Table 1

[0209] The methods are shown in Table 2 below:

[0210]

[0211] Table 2

[0212] Once a base class for a topology graph is available, how do we represent and initialize a topology object?

[0213] A Point object that converts a device into a topology-identifiable point;

[0214] The Link object converts a circuit into a topology-identifiable line.

[0215] Calling Topo.addPoints() adds all Points to Topo;

[0216] Calling Topo.addLinks() adds all the links to the Topo.

[0217] The above steps will generate a topology object.

[0218] (4) Custom graph abstract class AbstractCustomTopo topology (inherited from BasicTopo)

[0219] Function Description:

[0220] The original graph object inherits from the topology base class;

[0221] The original point inherits from the base class of topology lines;

[0222] The primitive line inherits from the base class of topological lines;

[0223] It also inherits the methods of all topology base classes.

[0224] The attributes are shown in Table 3 below:

[0225]

[0226] Table 3

[0227] The methods are shown in Table 4 below:

[0228]

[0229] Table 4

[0230] All methods in the abstract class are implemented by lower-level implementation classes.

[0231] (5) BasicRuleTree object

[0232] Function Description:

[0233] Define a rule tree object corresponding to a graph;

[0234] Rule object definition;

[0235] Supports the maintenance, management, addition, deletion, and modification of the rule tree through a tree-like interface;

[0236] Generate a rule tree memory object based on database data;

[0237] Defined as the top-level parent class of the rule object;

[0238] Define the `isRight` method to determine whether a point meets the condition (indicating whether the calculated point belongs to this rule).

[0239] The attributes are shown in Table 5 below:

[0240]

[0241] Table 5

[0242] The methods are shown in Table 6 below:

[0243]

[0244] Table 6

[0245] 2. Calculate a customized graph based on the original graph.

[0246] The input parameters are shown in Table 7 below:

[0247]

[0248] Table 7

[0249] The output parameters are shown in Table 8 below:

[0250]

[0251] Table 8

[0252] Processing logic, such as Figure 6 As shown:

[0253] S1. Load the original graph object based on the original graph topology (graph initialization).

[0254] Load point: stored as a CPoint object;

[0255] Load lines: stored as CLink objects;

[0256] Call the topology addition and line addition methods to complete the graph initialization;

[0257] S2. Load the rule tree object based on the rule tree ID (rule initialization)

[0258] Load rule objects based on CRule objects;

[0259] Load the rule tree object based on CustomRuleTree;

[0260] S3. Generate a custom graph object based on the original graph and rule tree (by calling the loadCustomTopoByRuleTree method of the custom graph to calculate the custom graph), and record point data, line data, point-line relationships, and parent-child relationship data.

[0261] S3.1, loadCustomTopoByRuleTree

[0262] Calculate all points within the rules, calculate parent-child relationships, calculate all lines, calculate point-line relationships, and store the results in Redis.

[0263] S4. Store the custom graph object in Redis.

[0264] Store the key properties of the object, allPoints, allLinks, parentChildRelation, pointLinkRelation, and rulePointRelation, in a user-friendly manner.

[0265] If storing in Redis, increase the aging time to 30 days; the time must be updated every time the data is stored.

[0266] Specific stored content:

[0267] allPoints: Stores point information in Redis in hash format [topoid, point ID, point information JSON];

[0268] allLinks: Stores line information in reids [topoid, line ID, line information JSON] in hash format;

[0269] parentChildRelation: Stores the parent-child relationship in Redis in hash form [topoid, parent ID, child ID set josn];

[0270] pointLinkRelation: Stores the point-line relationship in Redis in hash form [topoid, point ID, and set of associated line IDs josn];

[0271] rulePointRelation: Stores the relationship between rules (nodes) and points in Redis in hash form [topoid, rule id, set of point ids contained in the rule].

[0272] 3. Integration with the new city's digital map

[0273] The new city digital map integration utilizes topology computing and topology rendering services. Based on the type of digital map, an original map is defined, such as a combat map, a CT cloud map, and a pod map. The original map contains the devices and links that need to be rendered for topology rendering. According to their respective business requirements, the original map defines the range of device attributes, the range of link attributes, and the corresponding new city attributes for the devices, such as up groups, pods, CP groups, and warm standby groups. After the original map is defined, a custom map is defined. The custom map presents the desired effect based on the original map. Custom maps primarily use a custom rule tree, defining the desired device attributes at each level and defining the expandable / collapseable states of the rule tree. In runtime, the actual devices and lines of the custom map are loaded based on the rule tree. Topology elements are flexibly presented through the expandable / collapseable states of points and lines. Double-clicking a collapsed device allows for flexible drilling down of the topology layer according to the rule tree.

[0274] (1) Obtaining the original image

[0275] The input parameters are shown in Table 9 below:

[0276]

[0277] Table 9

[0278] The output parameters are shown in Table 10 below:

[0279]

[0280] Table 10

[0281] The original graph, `originalTopo`, is shown in Table 11 below:

[0282]

[0283] Table 11

[0284] The point structure flexePoint is shown in Table 12 below:

[0285]

[0286] Table 12

[0287] The corresponding device structure topoDevice is shown in Table 13 below:

[0288]

[0289] Table 13

[0290] The connection structure flexeLink is shown in Table 14 below:

[0291]

[0292] Table 14

[0293] The corresponding circuits for the lines are shown in Table 15 below:

[0294]

[0295] Table 15

[0296] Processing logic: The following is the processing logic for BNC maps. Other digital maps can refer to the implementation method and implement it flexibly according to their respective business needs.

[0297] When topoType=bnc, the following logic is executed:

[0298] Obtain device attributes and tile data for the new city's digital map operational map;

[0299] select topotype,scope,uiid,cfgitemcode,cfgitemname,cfgitemdesc,cfgitemvalue from cm_res_mcndmap_config where topotype='mcndmap_bnc' andscope='net' and uiid in='devprop'

[0300] Retrieve uiid, cfgitemcode, cfgitemname, cfgitemvalue

[0301] Get the list of cities and regions where the up devices are located;

[0302] select distinct n.areaname from cm_res_device d,cm_res_node n whered.nodeid=n.nodeid and d.devprop=$pupDevProp

[0303] Obtain all equipment in the city-level combat map;

[0304] select

[0305] d.devId,

[0306] d.devName,

[0307] d.devAlias

[0308] d.mgmtIp,

[0309] d.mgmtIpv6,

[0310] d.nodeid,

[0311] n.nodeCode,

[0312] n.areaname as city,

[0313] d.devProp,

[0314] v.vendor,

[0315] v.vendorName,

[0316] d.cpgroupname_code,

[0317] d. podname_code,

[0318] d. upgroupname_code,

[0319] d. cloud_pool

[0320] from cm_res_device d

[0321] inner join cm_res_node n on d.nodeid = n.nodeid

[0322] left join dc_res_devset s on d.devset = s.devset

[0323] left join dc_res_vendor v on s.vendor = v.vendor

[0324] where d.flag = 1 and d.devprop in (devprop list in Step 1)

[0325] and n.areaname in (up city list)

[0326] Get the short name of the device:

[0327] Select topotype,scope,uiid,cfgitemcode,cfgitemname,cfgitemdesc,cfgitemvalue from cm_res_mcndmap_config where topotype=’ all’ and scope=’all’and uiid in (‘devShortName’)

[0328] If cfgitemcode can be associated with devprop, then the regular expression corresponding to the current device property is taken. If cfgitemcode = d.devProp, then the cfgitemvalue corresponding to cfgitemcode is the regular expression of the corresponding device property.

[0329] If cfgitemcode cannot be associated with devprop, then directly use the cfgitemvalue corresponding to cfgitemcode=reg as the device's regular expression.

[0330] Retrieve cfgitemvalue. If this configuration exists, the device name needs to be processed according to a regular expression. The processed value is the device abbreviation.

[0331] `devShortName=devName` uses regular expression to match `$cfgitemvalue` and then removes `$devProp` (gets device attributes. Matches the last string, case-insensitive).

[0332] The associated device extended attribute table yields the data center code and data center name. Then, dext.itemcode and dext.itemvalue are retrieved.

[0333] left join cm_res_devext dext on d. devid=dext. devid and dext.Itemcode in ('DClocation', 'DClocationName')

[0334] Obtaining a common circuit:

[0335] SELECT

[0336] c.circuitId,

[0337] c.cirName as circuitName,

[0338] c.aDevId,

[0339] c.bDevId,

[0340] a.devname as aDevName,

[0341] b.devname as bDevName,

[0342] a.mgmtip as aMgmtIp,

[0343] a.mgmtipv6 as aMgmtIpv6,

[0344] b.mgmtip as bMgmtIp,

[0345] b.mgmtipv6 as bMgmtIpv6,

[0346] c.aIntfDescr,

[0347] c.bIntfDescr,

[0348] c.aIntfIp,

[0349] c.bIntfIp,

[0350] FROM cm_res_circuit c

[0351] inner JOIN cm_res_device a on c.adevid = a.devid and a.flag =1

[0352] inner JOIN cm_res_device b on c.bdevid = b.devid and b.flag =1

[0353] inner join cm_res_node na on a.nodeid = na.nodeid and na.areaname in (up city list)

[0354] inner join cm_res_node nb on b.nodeid = nb.nodeid and nb.areaname in(up_city_list)

[0355] where c.flag = 1 and a.devprop in (comma-separated devprop from step one) and b.devprop in (comma-separated devprop from step one)

[0356] Build point:

[0357] Point id = $device id;

[0358] The device information of a point = the device information structure corresponding to the current point;

[0359] Construction line:

[0360] Line ID: Circuit ID;

[0361] Circuit name: The name of the circuit;

[0362] Line start ID: Device ID (A);

[0363] Line termination ID: Device B ID;

[0364] Circuit information: Current circuit information.

[0365] (2) Custom initialization rules

[0366] The rules tree is defined at the provincial and municipal levels, and the custom topology is automatically generated by the program.

[0367] Get the list of cities:

[0368] Call the ` / api / mcnres / dmap / bncProv / getCityList` interface to retrieve the list of cities. <cityinfo>The cityInfo property contains city and nodeId.

[0369] Relationship between device attributes and data center:

[0370] Call api / mcnres / dmap / ctcloud / getDclocationAreaMap, cfgitemcode=pupDevProp,swDevProp to get the dcloctaion and dcloctaionname corresponding to devpropcode.

[0371] Given devpropcode='pupDevProp', obtain the list of computer rooms corresponding to devpropcode='pupDevProp'.

[0372] Given devpropcode='swDevProp', obtain the list of computer rooms corresponding to devpropcode='swDevProp'.

[0373] Get the list of CP devices under the city / prefecture level:

[0374] Calling / api / mcnres / dmap / bncProv / getCPList retrieves a List. <cpinfo>cpInfo contains cpDevId, cpDevName, cpDevIp, cpCity, upCity, and cloudPool.

[0375] List of CP devices under a city: List of CP devices under cpCity.

[0376] List of CP devices under upCity: List of CP devices under upCity.

[0377] ① Provincial topology

[0378] Initialize topo_base_topo_def

[0379] topoid: mcndmap_bnc_prov

[0380] toponame: bnc provincial view

[0381] topolevel: 1

[0382] topotype: bnc

[0383] link_colortype: alarm

[0384] topocode:prov

[0385] flexetype:

[0386] nodeid:

[0387] cloud_pool:

[0388] podcode:

[0389] Constructing a rule tree:

[0390] Provincial nodes

[0391] ruleid= $topotype_$topcode, rulename=province, rulecode=prov, topoid=$topoid, priority=1, devnodeid=list of cities, multiple cities separated by |;

[0392] Loop through the list of cities and construct a rule tree for each city:

[0393] ruleid=$topotype_$topcode_$nodeid,rulename=$city,rulecode= $nodeId,rulepid = $topotype_$topcode, topoid=$topoid, priority=2, devnodeid=$nodeId

[0394] CR under the prefecture-level city:

[0395] ruleid=$topotype_$topcode_$nodeid_CR,rulename=CR,rulecode= CR,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($crDevProp), devnodeid=$nodeid

[0396] MCR under the prefecture-level city:

[0397] ruleid=$topotype_$topcode_$nodeid_MCR,rulename=MCR,rulecode=MCR,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($mcrDevProp), devnodeid=$nodeid

[0398] MER under the prefecture-level city:

[0399] ruleid=$topotype_$topcode_$nodeid_MER,rulename=MER,rulecode=MCR,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($merDevProp), devnodeid=$nodeid

[0400] UP computer room under the prefecture-level city:

[0401] ruleid=$topotype_$topcode_$nodeid_$upRoomCode,rulename=$upRoomName,rulecode=$upRoomCode,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($pupDevProp|$umerDevProp), devnodeid=$nodeid,dclocation=$up computer room code

[0402] umer under the computer room:

[0403] ruleid=$topotype_$topcode_$nodeid_$upRoomCode_umer,rulename=UMER,rulecode=umer,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$upRoomCode, devprop=($umerDevProp), devnodeid=$nodeid, dclocation=$up computer room code

[0404] up under the computer room

[0405] ruleid=$topotype_$topcode_$nodeid_$upRoomCode_up,rulename=UP,rulecode=up,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$upRoomCode, devprop=($pupDevProp), devnodeid=$nodeid, dclocation=$up computer room code

[0406] SW computer room under the prefecture-level city:

[0407] ruleid=$topotype_$topcode_$nodeid_$swRoomCode,rulename=$swRoomCode,rulecode=$swRoomCode,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($swDevProp|$oltDevProp) , devnodeid=$nodeid,dclocation=$SW computer room code

[0408] SW under the computer room:

[0409] ruleid=$topotype_$topcode_$nodeid_$swRoomCode_sw,rulename=SW,rulecode=SW,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$swRoomCode, devprop=($swDevProp) , devnodeid=$nodeid, dclocation=$SW computer room code

[0410] olt under the computer room:

[0411] ruleid=$topotype_$topcode_$nodeid_$swRoomCode_olt,rulename=OLT,rulecode=OLT,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$swRoomCode, devprop=($oltDevProp) , devnodeid=$nodeid, dclocation=$SW computer room code

[0412] CP devices under the prefecture-level city:

[0413] ruleid=$cpDevId,rulename=$cpDevName,rulecode=$cpDevId,topoid=$topoid,priority=3, rulepid = $topotype_$topcode_$nodeid,cloudpool=$cloudPool

[0414] DCGW under CP:

[0415] ruleid=$topotype_$topcode_$nodeid_$cpDevId_dcgw,rulename=DCGW,rulecode=dcgw,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($dcgwDevProp), cloudpool=$cloudPool

[0416] FW under CP:

[0417] ruleid=$topotype_$topcode_$nodeid_$cpDevId_fw,rulename=FW,rulecode=FW,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudFWDevProp), cloudpool=$cloudPool

[0418] EOR under CP:

[0419] ruleid=$topotype_$topcode_$nodeid_$cpDevId_eor,rulename=EOR,rulecode=EOR,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*eor).*$

[0420] Business TOR under CP:

[0421] ruleid=$topotype_$topcode_$nodeid_$cpDevId_bussTor,rulename=Business TOR,rulecode= bussTor,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*serv)(?=.*tor).*$

[0422] CP Hard Tube TOR:

[0423] ruleid=$topotype_$topcode_$nodeid_$cpDevId_pMgmtTor, rulename=hard tube TOR, rulecode= pMgmtTor, topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*tor)(?=.*-pservTOR).*$

[0424] Managing TOR under CP:

[0425] ruleid=$topotype_$topcode_$nodeid_$cpDevId_mgmtTor, rulename= manage TOR, rulecode= mgmtTor, topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*tor)(?=.*mgmt).*$

[0426] Managing servers under CP:

[0427] ruleid=$topotype_$topcode_$nodeid_$cpDevId_mgmtServ, rulename= management server, rulecode= mgmtServ, topoid=$topoid, priority=200, rulepid = $cpDevId,devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*mgmt).*$

[0428] CP-managed server:

[0429] ruleid=$topotype_$topcode_$nodeid_$cpDevId_wgServ, rulename= network management server, rulecode= wgServ, topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*wg).*$

[0430] Service servers under CP:

[0431] ruleid=$topotype_$topcode_$nodeid_$cpDevId_bussServ, rulename= business server, rulecode= bussServ, topoid=$topoid, priority=200, rulepid =$cpDevId,devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*bussServer).*$

[0432] Service-aware server under CP:

[0433] ruleid=$topotype_$topcode_$nodeid_$cpDevId_bussSense, rulename= business awareness server, rulecode= bussSense, topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*busssenseServer).*$

[0434] Initial rule state:

[0435] The whole province:

[0436] A tote, except for the CP, CP child nodes, and OLT, is expanded.

[0437] vgid: $topotype_$topcode

[0438] netuserid: default

[0439] topoid: mcndmap_$topotype_$topcode

[0440] eleclass:p

[0441] status: 1

[0442] eleid: Multiple rule IDs, batch insertion into the database according to rule ID.

[0443] Except for CP, CP's child nodes, and OLT, all other nodes are expanded.

[0444] CP:

[0445] vgid: $cpDevId;

[0446] netuserid: default;

[0447] topoid: mcndmap_$topotype_$topcode;

[0448] eleclass: p;

[0449] status: 1;

[0450] eleid: Multiple rule IDs, batch input into the database according to rule ID;

[0451] Expand all child nodes of the cp command.

[0452] ②City-level topology

[0453] Initialize topo_base_topo_def, one topo for each city.

[0454] topoid: mcndmap_bnc_city_$nodeId

[0455] toponame:bnc$city view

[0456] topolevel: 1

[0457] topotype: bnc

[0458] link_colortype: alarm

[0459] topocode: city

[0460] flexetype:

[0461] nodeid: $nodeId

[0462] cloud_pool:

[0463] podcode:

[0464] Loop through each topoid and build a rule tree for each topology.

[0465] Provincial nodes:

[0466] ruleid= $topotype_$topcode_$nodeid_prov, rulename=province, rulecode=prov, topoid=$topoid, priority=1

[0467] Constructing the rule tree for prefecture-level cities:

[0468] ruleid=$topotype_$topcode_$nodeid, rulename=$city, rulecode= $nodeId, topoid=$topoid, priority=2, devnodeid=$nodeId, rulepid= $topotype_$topcode_$nodeid_prov

[0469] CR at the prefecture-level city level:

[0470] ruleid=$topotype_$topcode_$nodeid_CR, rulename=CR, rulecode= CR,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($crDevProp) , devnodeid=$nodeid

[0471] MCR at the prefecture-level city level:

[0472] ruleid=$topotype_$topcode_$nodeid_MCR, rulename=MCR, rulecode=MCR,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($mcrDevProp) , devnodeid=$nodeid

[0473] MER under the prefecture-level city:

[0474] ruleid=$topotype_$topcode_$nodeid_MER,rulename=MER,rulecode=MCR,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($merDevProp), devnodeid=$nodeid

[0475] UP computer room under the prefecture-level city:

[0476] ruleid=$topotype_$topcode_$nodeid_$upRoomCode,rulename=$upRoomName,rulecode=$upRoomCode,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($pupDevProp|$umerDevProp), devnodeid=$nodeid,dclocation=$up computer room code

[0477] umer under the computer room:

[0478] ruleid=$topotype_$topcode_$nodeid_$upRoomCode_umer,rulename=UMER,rulecode=umer,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$upRoomCode, devprop=($umerDevProp), devnodeid=$nodeid, dclocation=$up computer room code

[0479] up under the computer room:

[0480] ruleid=$topotype_$topcode_$nodeid_$upRoomCode_up,rulename=UP,rulecode=up,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$upRoomCode, devprop=($pupDevProp), devnodeid=$nodeid, dclocation=$up computer room code

[0481] SW computer room under the prefecture-level city:

[0482] ruleid=$topotype_$topcode_$nodeid_$swRoomCode,rulename=$swRoomCode,rulecode=$swRoomCode,topoid=$topoid, priority=100, rulepid = $topotype_$topcode_$nodeid, devprop=($swDevProp|$oltDevProp), devnodeid=$nodeid,dclocation=$sw computer room code

[0483] SW under the computer room:

[0484] ruleid=$topotype_$topcode_$nodeid_$swRoomCode_sw,rulename=SW,rulecode=SW,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$swRoomCode, devprop=($swDevProp), devnodeid=$nodeid, dclocation=$sw computer room code

[0485] olt under the computer room:

[0486] ruleid=$topotype_$topcode_$nodeid_$swRoomCode_olt,rulename=OLT,rulecode=OLT,topoid=$topoid, priority=200, rulepid = $topotype_$topcode_$nodeid_$swRoomCode, devprop=($oltDevProp), devnodeid=$nodeid, dclocation=$sw room code

[0487] Current city and CP devices in the corresponding UP city under the current city:

[0488] ruleid=$cpDevId,rulename=$cpDevName,rulecode=$cpDevId,topoid=$topoid,priority=3, rulepid = $topotype_$topcode_$nodeid,cloudpool=$cloudPool

[0489] DCGW under CP:

[0490] ruleid=$topotype_$topcode_$nodeid_$cpDevId_dcgw,rulename=DCGW,rulecode=dcgw,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($dcgwDevProp), cloudpool=$cloudPool

[0491] FW under CP:

[0492] ruleid=$topotype_$topcode_$nodeid_$cpDevId_fw,rulename=FW,rulecode=FW,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudFWDevProp), cloudpool=$cloudPool

[0493] EOR under CP:

[0494] ruleid=$topotype_$topcode_$nodeid_$cpDevId_eor,rulename=EOR,rulecode=EOR,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*eor).*$

[0495] Business TOR under CP:

[0496] ruleid=$topotype_$topcode_$nodeid_$cpDevId_bussTor,rulename=Business TOR,rulecode= bussTor,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg= (?i)^(?=.*serv)(?=.*tor).*$

[0497] Hard pipe TOR under CP:

[0498] ruleid=$topotype_$topcode_$nodeid_$cpDevId_pMgmtTor,rulename=Hard pipe TOR,rulecode= pMgmtTor,topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*tor)(?=.*-pservTOR).*$

[0499] Management TOR under CP:

[0500] ruleid=$topotype_$topcode_$nodeid_$cpDevId_mgmtTor, rulename= manage TOR, rulecode= mgmtTor, topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($cloudSWDevProp), cloudpool=$cloudPool,devname_reg=(?i)^(?=.*tor)(?=.*mgmt).*$

[0501] Managing servers under CP:

[0502] ruleid=$topotype_$topcode_$nodeid_$cpDevId_mgmtServ, rulename= management server, rulecode= mgmtServ, topoid=$topoid, priority=200, rulepid = $cpDevId,devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*mgmt).*$

[0503] CP-managed server:

[0504] ruleid=$topotype_$topcode_$nodeid_$cpDevId_wgServ, rulename= network management server, rulecode= wgServ, topoid=$topoid, priority=200, rulepid =$cpDevId, devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*wg).*$

[0505] Service servers under CP:

[0506] ruleid=$topotype_$topcode_$nodeid_$cpDevId_bussServ, rulename= business server, rulecode= bussServ, topoid=$topoid, priority=200, rulepid = $cpDevId,devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*bussServer).*$

[0507] Service-aware server under CP:

[0508] ruleid=$topotype_$topcode_$nodeid_$cpDevId_bussSense, rulename= business awareness server, rulecode= bussSense, topoid=$topoid, priority=200, rulepid = $cpDevId, devprop=($servDevProp), cloudpool=$cloudPool, devname_reg=(?i)^(?=.*busssenseServer).*$

[0509] Initialize rule status:

[0510] Prefecture-level cities:

[0511] Each city has its own topology, and all nodes under the topoid of each city, except for cp, cp's child nodes, and OLT, are expanded.

[0512] vgid: $topotype_$topcode_$nodeid_prov;

[0513] netuserid: default;

[0514] topoid: mcndmap_$topotype_$topcode_$nodeId;

[0515] eleclass: p;

[0516] status: 1;

[0517] eleid: Multiple rule IDs, batch input into the database according to rule ID;

[0518] Except for CP, CP's child nodes, and OLT, all other nodes are expanded.

[0519] CP:

[0520] Expand all CP child nodes.

[0521] vgid: $cpDevId;

[0522] netuserid: default;

[0523] topoid: mcndmap_$topotype_$topcode_$nodeId;

[0524] eleclass: p;

[0525] status: 1;

[0526] eleid: Multiple rule IDs, batch input into the database according to rule ID;

[0527] Expand all child nodes of cp.

[0528] 3. Topology presentation

[0529] (1) Obtain topology data

[0530] The input parameters are shown in Table 16 below:

[0531]

[0532] Table 16

[0533] The output parameters are shown in Table 17 below:

[0534]

[0535] Table 17

[0536] The return result structure topoResult is shown in Table 18 below:

[0537]

[0538] Table 18

[0539] The statInfo structure for statistical information is shown in Table 19 below:

[0540]

[0541] Table 19

[0542] The point structure is shown in Table 20 below:

[0543]

[0544] Table 20

[0545] The corresponding device structure topoDevice is shown in Table 21 below:

[0546]

[0547] Table 21

[0548] The link structure is shown in Table 22 below:

[0549]

[0550] Table 22

[0551] The circuit structure topoCircuit corresponding to the line is shown in Table 23 below:

[0552]

[0553] Table 23

[0554] Processing logic:

[0555] Load current topology base resources:

[0556] The rule tree is loaded based on the topoId (retrieved from the database). The rule tree retrieves the folding status of points and lines (vgid, topoid, netuserid) from the database. netuserid includes the current netuserid and the default. Data for netuserid is loaded first, followed by data for default. If vgid or eleid is duplicated, it is discarded.

[0557] The custom graph object is obtained by loading the SDK's `load` method based on the `topoId`. If the `load` method of the SDK does not retrieve the graph, the topology graph data is obtained through the HTTP method of the computation service.

[0558] Calculate the current topology line based on topoId:

[0559] The custom graph object calls the SDK method getResultLinks(all points from the previous step, custom graph, rule tree).

[0560] Filter irrelevant nodes:

[0561] When the input parameter filterIndependencePoint=Y, delete points that are not on the line and whose pointType is not equal to np.

[0562] Get all device points based on topoId and vgId.

[0563] If vgId is not filled in, then vgId is equal to the id corresponding to the root node of the rule tree.

[0564] Get all points under the custom graph object vgId of topoId, and call the SDK's getAllPointsInParentLoopNotRule(<input parameter vgId>) based on the custom graph object.

[0565] Count the number of all equipment points.

[0566] Get the connections between the expanded nodes.

[0567] Based on the filtered rule tree above, the parent-child relationships of the rule tree are obtained.

[0568] Get the expanded nodes, which are nodes that satisfy the condition that the number of sub-rules of a node is equal to 0 and pointType=np.

[0569] The SDK method `getResultLinks(list of rule IDs from the previous step, custom graph, rule tree)` is called. The resulting links are the connections between rules. If the connection circuit is empty or either end of the connection is an NP (non-pointing) node, the outer `fid` and `tid` are used. Otherwise, the inner `fid` and `tid` are used. These are then placed in `linknodes`.

[0570] The construction result is returned as follows:

[0571] points: all points.

[0572] nodes: All expanded nodes.

[0573] links: All links.

[0574] linknodes: all linknodes.

[0575] (3) Topology node expansion and merging

[0576] The input parameters are shown in Table 24 below:

[0577]

[0578] Table 24

[0579] The output parameters are shown in Table 25 below:

[0580]

[0581] Table 25

[0582] Processing logic:

[0583] Query point folding status:

[0584] If the status query based on netUserId or pointId does not find the result or is collapsed, the status will be changed to expanded; otherwise, the status will remain collapsed.

[0585] select eleid,status from topo_bussiness_fold_status where topoid=<input parameter topoId> and eleid=$pointId and netuserid=<input parameter netUserid> and eleclass='p'

[0586] Delete records related to topo_bussiness_fold_status based on pointId and netUserId.

[0587] delete from topo_bussiness_fold_status where topoid=<input parameter topoId> andeleid=<input parameter pointId> and netuserid=<input parameter netUserid> and eleclass='p'

[0588] If the status is expanded, it needs to be entered into the topo_bussiness_fold_status table.

[0589] eleclass='p'

[0590] (4) Topology connection expansion and merging

[0591] The input parameters are shown in Table 26 below:

[0592]

[0593] Table 26

[0594] The output parameters are shown in Table 27 below:

[0595]

[0596] Table 27

[0597] Processing logic:

[0598] Get the current line status:

[0599] key = fId + "#" + tId;

[0600] String otherKey = tId + "#" + fId;

[0601] If you want to query the status of topo_bussiness_fold_status based on key or otherKey.

[0602] select eleid,status from topo_bussiness_fold_status where topoid=<input parameter topoId> and (eleid= $key or eleid= $otherKey) and netuserid=<input parameter netUserid>and eleclass='l'

[0603] If none are found, or if the found item is folded, the status is changed to unfolded; otherwise, the status remains folded.

[0604] Delete records related to topo_bussiness_fold_status based on the retrieved eleid and netUserId.

[0605] The `delete` statement is defined from `topo_bussiness_fold_status` where `topoid=<input parameter topoId>` and `eleid=<final key value>` and `netuserid=<input parameter netUserid>` and `eleclass='l'`.

[0606] If the status is expanded, it needs to be entered into the topo_bussiness_fold_status table.

[0607] eleclass='l'

[0608] (5) Refresh topology alarm information

[0609] The input parameters are shown in Table 28 below:

[0610]

[0611] Table 28

[0612] The output parameters are shown in Table 29 below:

[0613]

[0614] Table 29

[0615] The alarm data structure, alarmData, is shown in Table 30 below:

[0616]

[0617] Table 30

[0618] The alarm event structure, alarmEvent, is shown in Table 31 below:

[0619]

[0620] Table 31

[0621] The node alarm structure nodeAlarm is shown in Table 32 below:

[0622]

[0623] Table 32

[0624] The linkAlarm structure is shown in Table 33 below:

[0625]

[0626] Table 33

[0627] The topology alarm summary structure, topoAlarmsum, is shown in Table 34 below:

[0628]

[0629] Table 34

[0630] Processing logic:

[0631] Based on topoId, vgId, netUserId, and filterIndependencePoint, the topology data calculation interface 3.5.6.1 is called, with topoId=<input parameter topoId>, vgId=<input parameter vgId>, and netUserId=<input parameter netUserId>, to obtain the topology point set, line set, and expanded node set.

[0632] The device list is obtained by calling the query topology device resource interface / api / dttopo / res / point / queryTopoResDevice based on the input parameters topoId, vgId, and netUserId.

[0633] Based on the line set, obtain the sameLinks and diffLinks for linkType=l and linkType=lg, and get the list of all circuits.

[0634] Alarm Inquiry:

[0635] resIdList: Assembles a list from the circuit list and the device list.

[0636] Based on the topoId, query topo_alarm_alarm_def to obtain alarmtypeid and alarmlevel.

[0637] alarmType: alarmtypeid is a list separated by commas.

[0638] alarmLevel: The alarmlevel list is obtained by separating alarm levels with commas.

[0639] netUserId: Enter parameter netUserId.

[0640] alarmStatus: 1.

[0641] Call the ` / api / ala / alarm / getAlarmRpc` interface to obtain the alarm list for this topology: `k_sumalarmid`, `l_alarmlevel`, `k_alarmtypeid`, and `k_resid`.

[0642] Summary of node alarm information:

[0643] The custom graph object is obtained by loading the SDK's `load` method based on the `topoId`. If the `load` method of the SDK does not retrieve the graph, the topology graph data is obtained through the HTTP method of the computation service.

[0644] Statistical topology point alert:

[0645] Circular topology point set `points`. Query the alarm resource `k_RESID` based on the `devId` of the device corresponding to the `pointId` of the point set.

[0646] If found, record that there is an alarm under the topology point pointId. If not found, obtain a list of all child nodes under the topology point pointId (by calling the SDK's getAllPointsInParentLoopNotRule(pointId) to get the list of child nodes based on the custom graph object), and aggregate the alarms of all child nodes into an alarm for that topology point.

[0647] Aggregation topology point alarm:

[0648] Determine whether the device's devId corresponding to the pointId in the child node list is within the range of the alarm resource k_RESID. If found, record the alarm under the topology pointId.

[0649] Based on the alarm list corresponding to the topology point, calculate the maximum alarm level max(l_ALARMLEVEL) corresponding to the topology point.

[0650] Count the number of topological points after deduplication according to the k_RESID corresponding to l_ALARMLEVEL.

[0651] Summary of line alarm information:

[0652] Based on the circuit's circuit ID corresponding to the link ID under lineData, query the alarm resource k_RESID. If found, record that there is an alarm under the topology link ID. If not found, loop through all sameLinks and diffLinks under the rule link, and check if the circuit ID corresponding to the link ID in the same-direction and reverse-direction circuit lists is equal to the alarm's k_RESID. If found, record the alarm on the topology link ID, and calculate the maximum alarm level for each link ID corresponding to the circuit ID.

[0653] Based on the circuit's circuit ID corresponding to the link ID under the linknodes, query the alarm resource k_RESID. If found, record that there is an alarm under the topology link ID. If not found, loop through all sameLinks and diffLinks under the rule link, and check if the circuit ID corresponding to the link ID in the same-direction and reverse-direction circuit lists is equal to the alarm's k_RESID. If found, record the alarm on the topology link ID, and calculate the maximum alarm level for each link ID corresponding to the circuit ID.

[0654] Based on the alarm list corresponding to the topology line, calculate the maximum alarm level of the circuit corresponding to the topology line.

[0655] Count the alarm list corresponding to the topology line, and count the number of duplicates after deduplication according to the k_RESID corresponding to l_ALARMLEVEL.

[0656] Summary of alarm resource information:

[0657] Step 5 yields the number of alarm devices at different levels.

[0658] Step 6 yields the number of alarm links corresponding to different levels.

[0659] Based on the alarm level, the number of alarm devices and alarm links corresponding to different levels are obtained.

[0660] The alarm level value is the alarm level corresponding to topo_alarm_alarmlevel. If there are no alarms at this alarm level, the corresponding quantity is 0.

[0661] (6) Obtain connection traffic

[0662] The input parameters are shown in Table 35 below:

[0663]

[0664] Table 35

[0665] The output parameters are shown in Table 36 below:

[0666]

[0667] Table 36

[0668] The linkFlux structure is shown in Table 37 below:

[0669]

[0670] Table 37

[0671] Processing logic:

[0672] Call the topology data calculation interface 3.5.6.1 based on topoId, vgId, and netUserId, with topoId=<input parameter topoId>, vgId=<vgId>, and netUserId=<input parameter netUserId>, to obtain the topology point set, line set, expanded node set, and node line set.

[0673] Based on the line set, obtain the sameLinks and diffLinks for linkType=l and linkType=lg, and get the list of all circuits.

[0674] Based on the circuit list, obtain the latest inflow bandwidth utilization rate, outflow bandwidth utilization rate, and circuit bandwidth for the current day. The inflow bandwidth utilization rate and outflow bandwidth utilization rate are taken as their maximum values. According to the `topo_perf_flux_threshold` table, the maximum level and color corresponding to the circuit are obtained.

[0675] A set of cyclic lines, and the flow levels corresponding to the statistical lines.

[0676] Determine the linkType corresponding to the line:

[0677] If linkType=l, then the inflow bandwidth utilization, outflow bandwidth utilization, circuit bandwidth, inflow rate, and outflow rate of the circuit are obtained based on circuitId and used as the maxInRatio, maxOutRatio, bandwidth, influx, and outflux of the line. The corresponding level and color of the circuit are obtained based on circuitId. fluxunit is adaptive for influx and outflux units.

[0678] If `linkType=lg`, then loop through `sameLinks` and `diffLinks` to obtain the inflow bandwidth utilization, outflow bandwidth utilization, and circuit bandwidth for each circuit. These are used as the `maxInRatio`, `maxOutRatio`, and `bandwidth` for that line. The circuit's level and color are obtained based on its `circuitId`. The `maxInRatio` and `maxOutRatio` for each connection are the maximum `maxInRatio` of all circuits. The level and color for each connection are the maximum levels and colors corresponding to the maximum levels of all circuits. The bandwidth is the sum of all circuits' bandwidth. `influx` and `outflux` are the maximum values ​​for all circuits, and `fluxunit` is the adaptive unit for the total inflow and outflow flow.

[0679] Assembly results are returned.

[0680] Based on the same inventive concept, this invention also proposes a device for interfacing with digital maps based on a topology fusion topology architecture. The implementation of this device can refer to the implementation of the method described above, and repeated details will not be repeated. The term "module" as used below can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0681] Figure 7 This is a schematic diagram of the device structure for connecting digital maps based on a topology fusion topology architecture, as per the present invention. Figure 7 As shown, the device includes:

[0682] The topology calculation service module 101 is used to define different types of original topology maps. Each type of original topology map defines a list of custom maps, and each custom map defines a rule tree, which is stored in the topology database. When connecting to the new city digital map, the digital map is obtained and the corresponding list of custom maps is loaded from the topology database according to the type of the digital map. The corresponding rule tree is loaded according to the selected custom map. Based on the digital map and the rule tree, the points and lines corresponding to the selected custom map are calculated. The calculated points and lines and the point-line relationships constitute the custom map and are stored in the topology cache library.

[0683] The design unit of Topology Computing Service Module 101 defines a list of topology diagrams to be displayed for each specialty based on their business characteristics. For each topology diagram, a rule list is defined. Since the rule list has a tree-like hierarchical structure, the custom diagram rule list is called the custom diagram rule tree. The custom diagram rule tree includes rule-related attributes and resource-related attributes. Rule-related attributes include rule name, rule identifier, rule parent identifier, and rule priority level. Resource-related attributes include device attributes, device nodes, data centers, CP groups, UP groups, POD groups, slice services, resource pools, etc. Because the initial topology diagram displays some collapsed nodes and does not want to be expanded, the expanded / collapsed state of the rule tree is customized according to business needs during the design of the custom diagram rule tree. If the rule tree rules are collapsed, the topology diagram only displays the rule nodes; clicking on a rule node allows further drilling down to the devices and links under that rule. If the rule tree rules are expanded, the devices and links under that rule are directly displayed.

[0684] The computing unit of the topology computing service module 101 provides an interface for standard managed original diagrams. Each discipline provides the equipment and circuits corresponding to the original diagrams according to their own business characteristics. Based on the equipment information, basic point objects are constructed, and based on the circuit information, basic line objects are constructed. Finally, a list of points and lines is returned.

[0685] The topology calculation service module 101 calculates the resource data and circuit data on the rule tree corresponding to the current graph using customized rules and original graph data, and stores the corresponding rule tree resource data and circuit data in Redis. In addition to calculating customized graph cache data, the topology graph calculation module also provides rich SDK capabilities, such as loading customized graph object data, loading customized graph points according to the rule tree, and calculating the connections of customized graphs based on customized graph points.

[0686] The topology runtime service module 102 is used by the front-end page to load a customized graph from the topology cache library for presentation.

[0687] The topology runtime service module 102 loads customized graph data based on the SDK capabilities provided by the topology calculation service module. According to the rule tree and unfolded / folded state of the customized graph, it calculates the points and lines corresponding to this graph. The points include basic information and device information, and the line information includes basic information and the circuit list corresponding to the line. The front end renders the graph data based on the point and line data.

[0688] The topology runtime service module 102 also supports point and line expansion and merging, topology graph drill-down, and alarm performance data presentation. When a point is in a collapsed state, right-clicking and selecting "Expand and Merge" updates the point's expanded / collapsed state to expanded, reloads the customized graph data, and renders the topology to see the expanded point's effect. Similarly, when a line is in a collapsed state, right-clicking and selecting "Expand and Merge" updates the line's expanded / collapsed state to expanded, reloads the customized graph data, and renders the topology to see the expanded line's effect. When a point is in a collapsed state, double-clicking the point will drill down to the topology graph corresponding to the current rule based on the current topology graph identifier and the rule identifier corresponding to the current point. Clicking the topology graph's return list returns to the main view of the topology graph. When a point is in an expanded state, right-clicking "Device Performance" displays the device's basic resources, CPU utilization, and memory utilization. When a connection is expanded, right-clicking on the link performance will display the current inflow utilization, outflow utilization, inflow rate, and outflow utilization. When a connection is collapsed, it will display the maximum inflow utilization and maximum outflow utilization of the corresponding link. The connection level is matched to the current utilization level (the larger of the inflow and outflow utilization) based on the link utilization level. Based on the alarm type, resource attribute list, node definition, and other conditions defined in the custom graph alarm definition, the alarm service interface is called to obtain the alarm list corresponding to the custom graph, identifying the devices or links with alarms in the custom graph, and then summarizing the alarmed devices or links to the dots and lines in the current custom graph. If a dot or line in the custom graph corresponds to an alarm, the dot or line will be rendered in red.

[0689] It should be noted that although several modules of the device for interfacing with digital maps based on a topology fusion topology architecture have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided and embodied by multiple modules.

[0690] Based on the aforementioned inventive concept, such as Figure 8 As shown, the present invention also proposes a computer device 200, including a memory 210, a processor 220, and a computer program 230 stored in the memory 210 and executable on the processor 220. When the processor 220 executes the computer program 230, it realizes the aforementioned docking of digital maps based on topology fusion topology architecture.

[0691] Based on the aforementioned inventive concept, the present invention also proposes a computer-readable storage medium storing a computer program that executes the aforementioned digital map docking based on topology fusion topology architecture.

[0692] The method and apparatus for connecting digital maps based on topology fusion topology architecture proposed in this invention not only possess the basic functional characteristics of topology, but also have high performance, maintainability, reliability, security and ease of use.

[0693] While the spirit and principles of the invention have been described with reference to several specific embodiments, it should be understood that the invention is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for ease of description. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0694] Regarding the limitation of the scope of protection of this invention, those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solution of this invention are still within the scope of protection of this invention.< / cpinfo> < / cityinfo>

Claims

1. A method for connecting digital maps based on a topology fusion topology architecture, characterized in that, The method includes: Define different types of original topology graphs, define a list of custom graphs for each type of original topology graph, define a rule tree for each custom graph, and store them in the topology database; When connecting to the new city's digital map, the digital map is obtained and the corresponding list of customized maps is loaded from the topology database according to the type of the digital map. The corresponding rule tree is loaded according to the selected customized map. Based on the digital map and rule tree, calculate the points and lines corresponding to the selected customized map. The calculated points and lines, as well as the relationships between them, constitute the customized map and are stored in the topology cache library. The front-end page loads a custom graph from the topology cache library for presentation.

2. The method for connecting digital maps based on topology fusion topology architecture according to claim 1, characterized in that, Based on the rule tree, each custom graph defines the expanded and collapsed states of the rule tree nodes; each custom graph also defines multiple alarm rules.

3. The method for connecting digital maps based on topology fusion topology architecture according to claim 1, characterized in that, The processing logic for calculating the customized graph based on the original graph is as follows: Load the original graph object based on the original graph topology; Load the rule tree object based on the rule tree ID; Based on the original graph and rule tree, the point data that should be included under the rule is calculated according to the rule tree, and a customized graph object is generated. At the same time, the point data, line data, point-line relationship and parent-child relationship data are recorded. Store custom graph objects in the topology cache library.

4. The method for connecting digital maps based on topology fusion topology architecture according to claim 3, characterized in that, According to the rule tree, calculate the point data that should be included under each rule, including: Obtain a list of rules sorted by rule priority based on the rule tree; A list of double-loop rules and a set of points; Call the `isRight` method to determine if each point conforms to the rule, pass in the points, calculate the relationship between the rule and the points, and store it as a MAP.

5. The method for connecting digital maps based on topology fusion topology architecture according to claim 3, characterized in that, Calculate and generate custom graph objects, including: Starting from the top-level ROOT layer, each node and its corresponding points are generated recursively. Get the list of subrules of the current rule; Loop through the list of subrules and check if the list is empty; If the value is empty, the current rule recursion ends and the previous loop rule is returned. If the value is not empty, the current rule is created as a node in the topology and added to the topology. Add the data of all points under the current rule to the topology and record the parent-child relationships; Recursively apply the current rule as a parent rule; The loop ends, generating all parent-child relationships for nodes and lines; Get all the points in the customized graph, add the links between two points in the original graph to the set of all lines, and record them in the customized graph.

6. A device for interfacing with digital maps based on a topology fusion topology architecture, characterized in that, The device includes: The topology calculation service module is used to define different types of original topology maps. Each type of original topology map defines a list of custom maps, and each custom map defines a rule tree, which are stored in the topology database. When connecting to the new city digital map, the module obtains the digital map and loads the corresponding list of custom maps from the topology database according to the type of the digital map. It also loads the corresponding rule tree according to the selected custom map. Based on the digital map and the rule tree, the module calculates the points and lines corresponding to the selected custom map. The calculated points and lines, as well as the point-line relationships, constitute the custom map and are stored in the topology cache library. The topology runtime service module is used by the front-end page to load a customized graph from the topology cache library for presentation.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the method according to any one of claims 1-5.

Images