Data processing method based on multi-service system and computing device

Abstract

The application relates to the field of computing, and in particular provides a data processing method based on a multi-service system and a computing device. The method comprises the following steps: collecting a plurality of system pages in a plurality of service systems and specified attribute data corresponding to each system page, wherein the specified attribute data comprises service data corresponding to at least one element in the system page, and the at least one element comprises at least one page element and a plurality of sub-elements corresponding to each page element; constructing a target knowledge graph by taking each page element and each sub-element in the specified attribute data of each system page as a node and taking a nesting relationship between each page element and the corresponding plurality of sub-elements as an edge; querying a target node having an association relationship with to-be-queried content according to the target knowledge graph; generating a query result according to a page element or a sub-element corresponding to the target node and outputting the query result, wherein the query result comprises service data of the page element or service data of the sub-element corresponding to the target node.

Description

[0001] This application claims priority to Chinese Patent Application No. 202511235748.4, filed on August 29, 2025, entitled "Data Processing Method and Computing Device Based on Multi-Business System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computing, and in particular to a data processing method and computing device based on a multi-service system. Background Technology

[0003] Business systems can refer to data processing systems for enterprises or organizations, such as PDM (Product Data Management) systems, ERP (Enterprise Resource Planning) systems, IMM (Inventory & Material Management) systems, and any other type of system.

[0004] Currently, various business systems contain a large amount of data, and these systems operate independently with no data correlation between them. However, if two or more business systems contain the same data, querying that data requires searching each system individually, which is cumbersome and results in low data retrieval efficiency. Summary of the Invention

[0005] This application provides a data processing method and computing device based on multiple business systems, which establishes knowledge connectivity between data from multiple business systems, forms a knowledge graph, facilitates content querying, automatically realizes cross-system data tracking, and improves data query efficiency and accuracy.

[0006] According to a first aspect of the embodiments of this application, a data processing method based on a multi-service system is provided, including: Collect multiple system pages from multiple business systems and the specified attribute data corresponding to each system page. The specified attribute data includes business data corresponding to at least one element in the system page. At least one element includes: at least one page element and multi-level sub-elements corresponding to each page element. Using the specified attribute data of each system page as nodes and the nesting relationship between each page element and its corresponding multi-level child elements as edges, construct the target knowledge graph. Based on the target knowledge graph, query the target nodes that are related to the content to be queried; Generate and output query results based on the page element or sub-element corresponding to the target node. The query results include: business data of the page element corresponding to the target node or business data of the sub-element corresponding to the target node.

[0007] In this embodiment, multiple system pages from multiple business systems are collected to achieve page integration across multiple business systems. Furthermore, specified attribute data corresponding to each system page is collected. This specified attribute data includes business data corresponding to at least one element within the system page. Each element includes at least one page element and its corresponding multi-level sub-elements, converting unstructured data from system pages into structured specified attribute data to ensure consistent data representation across different system pages. Additionally, a target knowledge graph is constructed using page elements and sub-elements as nodes, and the nesting relationships between page elements and their multi-level sub-elements as edges. This displays the page distribution structure in the form of a knowledge graph, reflecting the dependencies between one or more elements within a page. Based on this target knowledge graph, target nodes related to the queried content can be queried, and the page elements or sub-elements corresponding to the target nodes can be used as the source of the query results. This enables cross-page and cross-system business data queries, breaking down query barriers between systems, obtaining more flexible and comprehensive content queries, and improving the accuracy and comprehensiveness of the queries.

[0008] In conjunction with the first aspect, in certain implementations of the first aspect, a target knowledge graph is constructed using page elements and child elements of each system page as nodes, and the nesting relationships between each page element and its corresponding multi-level child elements as edges, including: Using each page element and its child element as nodes, and the nesting relationship between each page element's child element as edges, a business call relationship graph of the system page is generated. Connect the business call relationship graphs corresponding to system pages with page association relationships to obtain an initial knowledge graph; The nodes of the initial knowledge graph are normalized to obtain the target knowledge graph.

[0009] In this embodiment, after collecting multiple system pages and their specified attribute data, a corresponding business call relationship graph is generated on a per-system-page basis. Then, by connecting the business call relationship graphs of system pages with page associations, an initial knowledge graph is constructed, transforming the static page structure into a dynamic flow association. This achieves automatic integration of knowledge from the page level to the system level. Furthermore, the nodes in the initial knowledge graph are normalized to avoid ambiguity and duplicate nodes, enhancing the consistency of knowledge representation. Moreover, after obtaining the target knowledge graph, content queries based on the constructed target knowledge graph can discover cross-page queries, uncover implicit relationships between different pages, and obtain deeper, more relevant query results, improving the accuracy and comprehensiveness of the query.

[0010] In conjunction with the first aspect, in certain implementations of the first aspect, a business call relationship graph of the system page is generated, using each page element and its child element corresponding to the system page as nodes and the nesting relationship between the child elements of each page element as edges. This graph includes: Based on the preset graph structure, each page element and its sub-elements corresponding to the system page are used as nodes, and the nesting relationships between the sub-elements of each page element are used as edges to generate a business call relationship graph of the system page.

[0011] In this embodiment of the application, the preset graph structure can be a structure or template for graph establishment. Using the preset graph structure to establish the business call relationship graph of the system page can make the graph construction consistent and standardized.

[0012] In conjunction with the first aspect, in certain implementations of the first aspect, the business call relationship graphs corresponding to system pages with page association relationships are connected to obtain one or more initial knowledge graphs, including: If the same element exists on multiple first system pages, then it is determined that the multiple first system pages have a page association relationship; By connecting the business call relationship graphs corresponding to multiple first system pages with page association relationships, an initial knowledge graph corresponding to multiple first system pages is obtained.

[0013] In this embodiment of the application, when connecting page-level business call relationship graphs to form a system-level knowledge graph, page association relationships are used as the connection conditions for business call relationship graphs. This enables the integration of cross-page business call relationship graphs, forming a complete knowledge graph. This makes the knowledge conversion process more unified and standardized, eliminates redundant knowledge, improves the simplicity and accuracy of the knowledge graph, and provides a higher quality knowledge graph, thereby further improving the efficiency and accuracy of knowledge retrieval.

[0014] In conjunction with the first aspect, in certain implementations of the first aspect, data is collected from multiple system pages across multiple business systems, as well as specified attribute data corresponding to each system page, including: Simulate the operation of each business system and obtain the access address corresponding to at least one system page in each business system. Based on the access address of the system page, retrieve the specified attribute data from the system page to obtain the specified attribute data corresponding to multiple system pages in multiple business systems.

[0015] In this embodiment, by simulating the use of various business systems, the access addresses of each system page are obtained, and the specified attribute data in the system page is captured through the access addresses of each system page, thereby realizing the automated collection of specified attribute data. Data collection can be completed without modifying the business system or embedding code. While ensuring system security, intelligent data collection of various elements in the system page is achieved, improving collection efficiency.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, based on the access address of the system page, specific attribute data in the system page is retrieved, including: Parse the access address of the system page and locate at least one element in the system page. The element is either a page element or a child element corresponding to a page element. Extract the business data corresponding to at least one element; Determine the specified attribute data of the system page based on the business data corresponding to at least one element.

[0017] In this embodiment, the system page can be parsed using its access address to obtain at least one element, thus confirming the element-level analysis object. After extracting the business data corresponding to each of the at least one element, the specified attribute data of the system page can be determined based on the business data corresponding to each of the at least one element. This element-based data extraction makes the entire system page data collection process more accurate, structured, and scalable, enabling efficient extraction of business data from the system page.

[0018] In conjunction with the first aspect, in certain implementations of the first aspect, at least one element's corresponding business data is extracted, including: Identify at least one subtask corresponding to each element. A subtask is a task that performs a corresponding data collection operation on an element in the system page. Execute at least one subtask corresponding to each element to obtain business data corresponding to at least one element.

[0019] In this embodiment of the application, during the process of extracting business data corresponding to at least one element, at least one sub-task corresponding to each element can be determined first. For each element, a corresponding sub-task can be constructed. Then, by executing the sub-tasks of each element, the business data of each element can be obtained. This makes the data collection process of each element more refined, avoids data collection on the basis of the entire system page, and ensures that the data collection sub-tasks of each element do not affect each other. This allows for more accurate and faster collection of specified attribute data.

[0020] In conjunction with the first aspect, in certain implementations of the first aspect, at least one subtask corresponding to each element is determined, including: Based on a pre-defined large language model, the system identifies the user's processing intent corresponding to at least one element when using the system page. Based on the processing intent corresponding to at least one element, determine at least one subtask, and associate each subtask with the target tool to be used.

[0021] In this embodiment, when constructing subtasks for each element, a large language model can be used to understand the processing intent of each element. By utilizing the processing intent of each element, at least one subtask can be determined. Each subtask is associated with the target tool to be used, and the target tool of each element can be used to execute the corresponding subtask. This achieves a link-based analysis from intent recognition, tool matching, and task execution, ensuring that the subtask matches the processing intent of the corresponding element. Through subtasks with higher matching degree, data collection of elements can be completed more accurately and efficiently, effectively improving operation and maintenance efficiency.

[0022] In conjunction with the first aspect, in certain implementations of the first aspect, at least one subtask corresponding to each element is executed to obtain business data corresponding to at least one element, including: Call the target tools required by each subtask from the tool library, execute the corresponding subtasks according to the target tools called by each subtask, and obtain the execution results of each subtask; Based on the execution results of each subtask, determine the business data corresponding to at least one element.

[0023] In this embodiment, the target tools required for each subtask are called from the tool library, enabling automated tool invocation. By executing the corresponding subtasks according to the target tools invoked for each subtask and obtaining the execution results, the tooling, modularization, and automation of subtask processing can be achieved, improving processing efficiency. Based on the execution results of each subtask, at least one element's corresponding business data is determined. The execution results of different subtasks can be used to determine the business data of each element, enhancing the flexibility and scalability of the business data acquisition process.

[0024] In conjunction with the first aspect, in some implementations of the first aspect, the tool library includes at least one of the following tools: Page layout analysis tool; dynamic element positioning tool; button click tool; character conversion tool; component area recognition tool; source code conversion tool; page parsing tool.

[0025] In this embodiment of the application, by defining at least one of the following tools in the tool library: layout parsing tool, dynamic element positioning tool, button clicking tool, character conversion tool, component area recognition tool, source code conversion tool, or page parsing tool, the tool library can provide a richer set of tools, support the unified and standardized design of tools, improve the richness and executability of matching target tools for each element, and form a more adaptable automated task creation scheme.

[0026] In conjunction with the first aspect, in some implementations of the first aspect, query results are generated based on the page element or child element corresponding to the target node, including: Generate a target graph based on the page element or child element corresponding to the target node. A target graph is a graph formed by the flow relationship between one or more target nodes. The target map is selected as the query result; Alternatively, a table can be generated based on the page element or child element corresponding to the target node. The columns of the table refer to the component objects in the page objects of each business system, and the rows of the table refer to the values ​​of the target node in the corresponding business system. The table is then used as the query result.

[0027] The flow relationship can include: the order in which nodes flow, the data transmission path, the interaction logic of components, and other relationships.

[0028] In this embodiment, after obtaining the target nodes, the flow relationships between them are transformed into a graph, connecting the independently existing nodes to visualize the flow relationships. This makes the flow process clearer and improves the comparability and operability of the data. Alternatively, a table can be generated based on the page elements or sub-elements corresponding to the target nodes, allowing the target nodes to be displayed intuitively through the component objects and values ​​of the table, reducing the cost of reading the relevant data of the target nodes. Therefore, both graph-based relational data and table-based structured data can achieve intuitive data display, making data query results more intuitive and reducing the information understanding cost of complex query results.

[0029] In conjunction with the first aspect, in some implementations of the first aspect, when the query result is a table, the table is generated based on the page element or child element corresponding to the target node, including: Retrieve one or more target business systems containing the target node; Retrieve the target page objects that contain the target nodes in each target business system; Based on the multi-level component objects in the target page object where the target node is located, a table header is created, and the field values ​​of the target node in the corresponding business system are written into the table as row data to obtain the table after writing is completed.

[0030] In this embodiment, by first locating the target business system and target page object containing the target node, and then automatically constructing the table header based on the multi-level component object where the target node is located, and filling the table with the business field values ​​corresponding to the target node in the form of row data, the target data can be automatically and accurately extracted and structured from cross-system and multi-level business pages. There is no need to manually sort the table header or manually enter information, which significantly reduces the operational cost and complexity of multi-source business data integration. At the same time, the table structure is generated based on the standardization of multi-level component objects and written into the corresponding table header, which can ensure that the generated table has a unified format, clear structure, and accurate data, realize the visualization and tabular output of query results, and improve the convenience and efficiency of cross-system business data integration, presentation and use.

[0031] In conjunction with the first aspect, some implementations of the first aspect also include: Display the relevant information of the target node in the table in a different color than the values ​​of other fields in the table.

[0032] In this embodiment, the relevant information of the target node in the table is displayed with different colors from the values ​​of other fields in the table. This can highlight the relevant information of the target node at the visualization level, enabling users to quickly locate the relevant information of the target node when viewing the table, improving the efficiency of reading and recognizing effective information. At the same time, the differentiated color display can make the table content more distinguishable, avoid data confusion, reduce the risk of misreading, and enhance the intuitiveness, readability and ease of use of the table display.

[0033] According to a second aspect of the embodiments of this application, a data processing apparatus based on a multi-service system is provided, comprising: The data acquisition unit is used to collect multiple system pages in multiple business systems and the specified attribute data corresponding to each system page. The specified attribute data includes business data corresponding to at least one element in the system page. The at least one element includes: at least one page element and multi-level sub-elements corresponding to each page element. The graph construction unit is used to construct the target knowledge graph by taking each page element and each sub-element in the specified attribute data of each system page as nodes and the nesting relationship between each page element and its corresponding multi-level sub-element as edges. The content query unit is used to query target nodes that are related to the content to be queried, based on the target knowledge graph. The result output unit is used to generate and output query results based on the page element or sub-element corresponding to the target node. The query results include: business data of the page element corresponding to the target node or business data of the sub-element corresponding to the target node.

[0034] In this embodiment, multiple system pages from multiple business systems are collected to achieve page integration across multiple business systems. Furthermore, specified attribute data corresponding to each system page is collected. This specified attribute data includes business data corresponding to at least one element within the system page. Each element includes at least one page element and its corresponding multi-level sub-elements, converting unstructured data from system pages into structured specified attribute data to ensure consistent data representation across different system pages. Additionally, a target knowledge graph is constructed using page elements and sub-elements as nodes, and the nesting relationships between page elements and their multi-level sub-elements as edges. This displays the page distribution structure in the form of a knowledge graph, reflecting the dependencies between one or more elements within a page. Based on this target knowledge graph, target nodes related to the queried content can be queried, and the page elements or sub-elements corresponding to the target nodes can be used as the source of the query results. This enables cross-page and cross-system business data queries, breaking down query barriers between systems, obtaining more flexible and comprehensive content queries, and improving the accuracy and comprehensiveness of the queries.

[0035] According to a third aspect of the embodiments of this application, a computing device is provided, including: a memory and a processor; The memory is used to store computer programs; the processor is used to execute computer programs to implement any of the above-mentioned data processing methods based on a multi-service system.

[0036] According to a fourth aspect of the embodiments of this application, a communication device is provided, including a transceiver unit and a processing unit. The transceiver unit is used to receive or send data, and the processing unit is used to execute any of the data processing methods based on a multi-service system according to the embodiments of this application.

[0037] According to a fifth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, and when executed by a controller, the computer program implements any data processing method based on a multi-service system.

[0038] According to a sixth aspect of the embodiments of this application, a computer product is provided, comprising: a computer program that, when executed by a controller, implements the steps of any data processing method based on a multi-service system.

[0039] As will be described in detail below, the data processing method based on multiple business systems provided in this application can collect multiple system pages from multiple business systems, realizing page integration between multiple business systems. Furthermore, it also collects specified attribute data corresponding to each system page. This specified attribute data includes business data corresponding to at least one element in the system page. Each element includes at least one page element and its corresponding multi-level sub-elements, thus converting unstructured data in the system pages into structured specified attribute data, ensuring consistency in the data expression of different system pages. In addition, a target knowledge graph is constructed using page elements and sub-elements of each system page as nodes, and the nesting relationships between page elements and their multi-level sub-elements as edges. This displays the page's distribution structure in the form of a knowledge graph, reflecting the dependencies between one or more elements on the page. Based on the target knowledge graph, target nodes related to the content to be queried can be queried, and the page elements or sub-elements corresponding to the target nodes can be used as the source of the query results. This enables cross-page and cross-system business data queries for the content to be queried, breaking down query barriers between systems, obtaining more flexible and comprehensive content queries, and improving the accuracy and comprehensiveness of the queries.

[0040] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0041] The above and other objects, features, and advantages of the embodiments of this application will become more apparent from the more detailed description of the embodiments in conjunction with the accompanying drawings. The accompanying drawings are used to provide a further understanding of the embodiments of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the embodiments of this application and do not constitute a limitation thereof. In the accompanying drawings, the same reference numerals generally represent the same components or steps.

[0042] Figure 1 The figure shows a schematic diagram of a data processing system based on a multi-service system according to an embodiment of this application; Figure 2 The figure shows a flowchart of a data processing method based on a multi-service system according to an embodiment of this application; Figure 3 The figure shows an example of a system page according to an embodiment of this application; Figure 4 The figure shows an example diagram of the element structure of a first business system according to an embodiment of this application; Figure 5 The figure shows an example diagram of a knowledge graph construction according to an embodiment of this application; Figure 6 The figure shows an example of a target map according to an embodiment of this application; Figure 7 The illustration shows an example of a table according to an embodiment of this application; Figure 8 The figure shows another flowchart of a data processing method based on a multi-service system according to an embodiment of this application; Figure 9 The figure shows an example diagram of a map construction according to an embodiment of this application; Figure 10 The illustration shows an example of a target knowledge graph of a first business system according to an embodiment of this application. Figure 11 The figure shows another flowchart of a data processing method based on a multi-service system according to an embodiment of this application; Figure 12 The figure shows a schematic diagram of a data processing device based on a multi-service system according to an embodiment of this application; Figure 13 The figure shows a hardware block diagram of a computing device according to an embodiment of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent, exemplary embodiments according to the embodiments of this application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the embodiments of this application, and not all embodiments of the embodiments of this application. It should be understood that the embodiments of this application are not limited to the exemplary embodiments described herein.

[0044] The technical solutions of the embodiments of this application can be applied to the field of computing technology.

[0045] In related technologies, a business system can refer to a data processing system for an enterprise or organization, such as any type of system like a PDM system, ERP system, or IMM system. A user's terminal can have one or more business systems installed. After logging into one or more of these systems, the user can access the services provided. The services provided by the business system are based on the system's interface; users obtain these services through the operating system's interface. Taking an ERP system as an example, the business system might include a main interface, an order management interface, and an inventory management interface. The main interface provides query functions for key indicators such as order status, timely inventory management, and sales volume. The order management interface provides services such as order query and order details. The inventory management interface provides services such as inbound management, outbound management, and inventory reports.

[0046] A company, especially a manufacturing company, often has a large number of business systems. In practice, these systems operate independently, and their data is not interconnected. If two or more systems contain the same data, querying that data requires searching each system individually, a cumbersome process that leads to low data retrieval efficiency.

[0047] To address the aforementioned issues, this embodiment extracts business data from each business system separately and associates the business data from each system to establish a business graph. The business graph is a knowledge graph built around individual data items and the relationships between them as edges. By establishing the business graph, data connectivity between multiple business systems can be achieved. When a query is needed, the target data and its path related to the query content are retrieved through the knowledge graph and output. By establishing knowledge connectivity between data from multiple business systems to form a knowledge graph, content querying is facilitated, cross-system data tracking is automatically achieved, and data query efficiency and accuracy are improved.

[0048] The technical solution of this application will be described in detail below with reference to the accompanying drawings.

[0049] like Figure 1 The diagram shown is a structural schematic of a data processing system based on a multi-service system provided in an embodiment of this application. The data processing system may include: a server 10, a database 20, and a user terminal 30.

[0050] Server 10 can simulate user operations on business systems using a large model, and perform A1 data collection: acquiring multiple system pages from multiple business systems. It acquires specified attribute data corresponding to each system page, including at least one page element and its corresponding multi-level child elements. These multi-level child elements belong to multiple nested levels, with each level of child element associated with its next-level child element.

[0051] Server 10 can execute step A2 to construct the graph: using each page element and its child element corresponding to the system page as nodes, and the nesting relationship between each page element and its child element as edges, to construct the target knowledge graph. Server 10 can also execute A21: storing the target knowledge graph in database 20.

[0052] Next, server 10 executes step A3, data query: A31, any user terminal 30 can detect the user's input query content, which is carried in the query request; A32, user terminal 30 sends the query request to server 10; A33, server 10 queries the target node that matches the query content based on the target knowledge graph stored in database 20, and generates and outputs the query results based on the page element or sub-element corresponding to the target node. For example, A34, server 10 sends the query results to user terminal 30.

[0053] like Figure 2 The diagram shown is a flowchart of a data processing method based on a multi-service system provided in an embodiment of this application. The method may include the following steps: S201. Collect multiple system pages from multiple business systems, as well as the specified attribute data corresponding to each system page.

[0054] The specified attribute data can include business data corresponding to at least one element on the system page. Each element includes at least one page element and its corresponding multi-level child elements. The page element and its corresponding multi-level child elements can be specified; for example, a table element can be specified as the element for which data needs to be collected.

[0055] The technical solutions provided in this application can be applied to computing devices, such as computers, servers, digital computing platforms, and any other type of device.

[0056] A business system can refer to a system that provides data processing services to an enterprise or organization. Examples include IMM systems and PDM systems. A system page can refer to the page on which the business system provides services to users. Elements within a system page can refer to objects that can be analyzed on the page; these elements can be any objects such as components, controls, tables, fields, interactive buttons, dialog boxes, images, or titles.

[0057] The business data corresponding to at least one element may include: business data of each page element, and business data of each level of child elements of each page element.

[0058] Business data can be represented as data nodes using the Neo4j format. Neo4j data nodes can include nodes, relationships, and paths. Of course, business data can also be stored using other data formats, such as key-value pairs; however, we will not impose too many restrictions on the specific form of business data here.

[0059] In this context, nodes represent entities and can include page element attributes (stored as key-value pairs), tags, and other information. It should be understood that when page element attributes are stored as key-value pairs, each key-value pair specifically refers to a data field and the value of the node within that data field. For example, if the node is table t and the data field is "Product Identifier," then the value of table t in that data field is "1". 8”, then the node can use [tablet t, product identifier, 1 8] indicates.

[0060] A relationship indicates a nested relationship between two nodes. For example, if node A and node B are nested, then node B is a relation of node A. Relationships can include one or more of the following: direction (e.g., unidirectional or bidirectional), type (e.g., connection, jump, response), and attributes (e.g., time attribute).

[0061] A path is a sequence of nodes and relationships that represents indirect connections between multiple entities (e.g., "Page A → Button B → Page C → Table D" can form a path). Neo4j has native support for path queries and can efficiently find multi-hop relationships.

[0062] like Figure 3 The image shown is an example diagram of a system page in a business system. Figure 3 The system page 300 of the first business system shown may include a functional area 301, which may include multiple components such as: homepage, first business, second business, third business, fourth business, and fifth business. Users can switch to the corresponding system page by clicking on any component.

[0063] If you click on the first service, the corresponding first system page 302 will be displayed.

[0064] The first system page 302 may include page elements such as table 3021 and multiple search controls 3022. The multiple search controls 3022 may be search controls created based on the field content of each field in table 3021. Corresponding search controls can be created for each of the fields in table 3021, including "Product Line," "Product Identifier," "Product Type," "Product Attribute," "Product Description," "Product Name," "Product Address," and "Product Manager," and each search control can be used to perform product searches based on the input content.

[0065] The page element table 3021 can include multiple first-level child elements. For example, fields such as "Product Line", "Product Identifier", "Product Type", "Product Attribute", "Product Description", "Available Quantity", "Reserved Quantity", "Total Quantity", "Product Name", "Product Address", and "Product Manager" in table 3021 can all be first-level child elements of table 3021.

[0066] The specified attribute data in the first system page includes: 1. Business data of page elements, namely, business data of table 3021 and business data of each search control 3022 in the first system page.

[0067] 2. Page data of each level of child elements of a page element, such as business data of a field in Table 3021.

[0068] In one possible design, such as when Table 3021 is used as a page element, the business data in the table can be one or more rows of data. For example, the first row of Table 3021 could be "[Department 1, 0... 8. Production raw materials, consumables, 0 8, 2, 0, 2, ABC, Warehouse 1-2-3 Shelves, Management Name 1] can be considered as a single business data entry. For example, the second row of Table 3021 contains "[Department 2, 2 9. Finished products, products for sale, 5 The string "9, 3, 2, 3, 123, warehouse 2-5-2 shelf, management name 2" can also be used as a business data item.

[0069] The business data of the first-level sub-elements in Table 3021 can refer to the value of any field in any row. Taking the product identifier as the first-level sub-element as an example, the value of the product identifier in the first row can be used as a piece of business data. For example, the value of the product identifier in Table 3021 is "0". "8" can be used as a business data entry for "product identification".

[0070] Of course, the above-mentioned composition of business data is merely exemplary, and the specific composition or scope of business data is not limited in this application embodiment.

[0071] Optionally, the specified attribute data corresponding to the system page can be stored in a system document, which can be one or more of the following: XML (Extensible Markup Language) document, CSV (Comma-Separated Values) document, or JSON (JavaScript Object Notation) document.

[0072] It should be understood that a system page may include one or more elements, which may include, for example, a root element, at least one page element, and multi-level child elements corresponding to each page element. Figure 3 For example, the root element of system page 300 is the first business in the first business system. At least one page element in system page 300 is table 3021 and multiple search controls 3022. Table 3021 includes first-level child elements, such as the various fields in table 3021, including "Product Line," "Product Identifier," "Product Type," "Product Attribute," "Product Description," "Available Quantity," "Reserved Quantity," "Total Quantity," "Product Name," "Product Address," and "Product Manager." Of course, when the table is a nested table, any nested field within a table can be a next-level or multi-level child element.

[0073] Optionally, multi-level child elements belong to multiple nested levels, and each child element is associated with its corresponding next-level child element.

[0074] In this context, the root element is the outermost element of the page, or the container for all other elements on the page. Taking a system page as an HTML5 page as an example, the root element can be a unique `<head>` tag. At least one page element can be a sub-element of the root element, and page elements can also contain multi-level child elements.

[0075] For example, page element A can include three levels of child elements. Let's assume these three levels of child elements include first-level, second-level, and third-level child elements. For instance, the first-level child elements are A1, A2, and A3; the two second-level child elements of the first-level child element A1 are A11 and A12; and the two third-level child elements of the second-level child element A11 are A111 and A112. Of course, the above elements are merely examples and do not constitute a specific limitation. In practical applications, the number of levels of child elements and the number of child elements contained in each level are not overly restricted in the multi-level child elements corresponding to any page element.

[0076] by Figure 3 Taking the first system page shown as an example, combined with Figure 4 The element structure of the first business system is illustrated by example.

[0077] The first business system 401 may include multiple system pages, such as the first system page of the first business 402, the second system page of the second business 403, and system pages of other businesses not shown in the figure.

[0078] The first system page of the first business 402 includes a table. The multi-level sub-elements associated with the table may include: product line 4021, product identifier 4022, product type 4023, product attribute 4024, product description 4025, available quantity 4026, reserved quantity 4027, total quantity 4028, product name 4029, product address 40210, product manager 40211, etc.

[0079] The multi-level sub-elements of the second business 403 can include first-level sub-elements such as product line 4031, product identifier 4032, product type 4033, and product attribute 4034. Of course, Figure 4 The specified attribute data shown is merely illustrative and does not constitute a specific limitation.

[0080] Of course, each first-level child element can be associated with one or more second-level child elements, and a second-level child element can be associated with one or more third-level child elements, and so on. For example, the second-level child elements corresponding to product identifier 4022 may include: product identifier type 40221, product identifier source 40222, etc.

[0081] In this embodiment, there are no excessive restrictions on the maximum nesting level of each level of child elements, or the number of child elements contained in each level.

[0082] Specified attribute data can refer to data related to page elements read from the system page. For example, when a table is used as a page element, a row of data in the table can be a piece of business data.

[0083] Optionally, page elements or child elements can be associated with business data, which may include at least one of the following: title / field name, link / address, sample data, action, or path.

[0084] To facilitate the differentiation of different types of business data, in the specified attribute data, the title is... <name>Identifiers, links <address>Identification, sample data <sampledata>Marking, action <action>Identifier, path <path>Logo.

[0085] In one possible design, after obtaining the business data of each element, a field-level mapping engine can be established, that is, a dynamic association between page entities and the database can be established. For example, if the table data in page A is stored in database 1, then a dynamic association between page A and database 1 is established. Of course, the dynamic association between page entities and the database can be one-to-one, one-to-many, many-to-one, and / or many-to-many, and this application does not impose too many limitations on this aspect in the embodiments.

[0086] S202. Using the specified attribute data of each system page as nodes and the nesting relationship between each page element and its corresponding multi-level child element as edges, construct the target knowledge graph.

[0087] Nesting relationships between elements can refer to the inclusion and being included relationship between elements at different levels. For example, a page element having three first-level child elements constitutes a nesting relationship. That is, a page element can be connected to three first-level child elements, and the line segment formed by the page element and each first-level child element is an edge in the knowledge graph.

[0088] A knowledge graph can refer to a network structure formed by connecting one or more elements, such as page elements or child elements of page elements.

[0089] For ease of understanding, such as Figure 5 The image shown is an example diagram of a knowledge graph construction.

[0090] refer to Figure 5 Suppose that the specified attribute data 501 of a certain system page in the second business system may include, but is not limited to, the following: <xml> <system> <name> Second Business System< / name> <address>http: / / dizhi1 <sampledata> 0 1< / sampledata> <path> Component 1.csv< / path> <link> <name> A system page< / name> <action> click< / action> <address>http: / / dizhi2 <tabs> <tab> <name> Component properties< / name> <path> component attribute keyval.json< / path> < / tab> <tab> <name> BOM List< / name> ... Suppose that after extracting elements from the specified attribute data 501, at least one element is obtained as the root element 5021 shown in 502: the system page corresponding to the second business system. The page elements of this system page specifically include component attributes 5022, BOM (Bill of Materials) list 5023, product data 5024, process records 5025, substitution information 5026, and ERP attributes 5027, etc. The first-level sub-elements corresponding to component attributes 5022 include, for example, basic attributes 50221, product name 50222, product identifier 50223, and product line 50224, etc.

[0091] Of course, the specified attribute data of the above system pages includes multiple data. Therefore, based on the multiple specified attribute data, the target knowledge graph can be constructed by taking the page elements and child elements of each system page as nodes and the nesting relationship between each page element and its corresponding multi-level child elements as edges.

[0092] like Figure 5 As shown in Figure 503, an example diagram of the target knowledge graph for a system page of the second business system is presented. In Figure 503, a system page (such as the main page) of the second business system can navigate to a specific system page. A specific system page may include page elements such as component attributes, BOM (Bill of Materials) lists, and product data. Component attributes may include first-level sub-elements such as basic attributes, product name, product identifier, and product line. BOM lists may include first-level sub-elements such as name, quantity, serial number, unit, and serial number. Product data may include first-level sub-elements such as version, code, view, name, English description, and lifecycle.

[0093] certainly, Figure 5 The target knowledge graph can be constructed based on the business call relationship graph of each system page. For the specific implementation of constructing the target knowledge graph through the business call relationship graph of each system page, please refer to the relevant description of the following embodiments, which will not be repeated here.

[0094] S203. Based on the target knowledge graph, query the target nodes that are related to the content to be queried.

[0095] Optionally, before S204, the process may further include: receiving a query request, which may include the content to be queried.

[0096] It should be understood that query requests can be sent from the user terminal to the computing device. The computing device can execute SQL (Structured Query Language) queries to obtain the corresponding query results.

[0097] It should be understood that the output of query results by the computing device may include: the computing device sending the query results to the user terminal. After receiving the query results sent by the computing device, the user terminal can display the query results.

[0098] For example, query results can be displayed in the form of emails, web pages, graphs, etc.

[0099] In one possible design, the content to be queried can be, for example, the value of a node's data field. For instance, the content to be queried could be the product identifier "0". 8".

[0100] During the query process, the dynamic connection between the page and the database can be used to perform security checks on the field-level content to be queried, so as to ensure the validity and security of the query.

[0101] Specifically, we can first identify one or more databases corresponding to each business system, parse the database structure, analyze the schema (pattern or architecture) contained in the database, the data tables contained in each schema, and what fields each table has.

[0102] First, determine if the data field type matches the type of the value to be retrieved. If they match, execute the SQL query. To avoid retrieving conflicting values ​​for the same field, use multiple values ​​to compare the same field. When multiple values ​​from the same business data field match the same database field, the database field is considered identical to the business field, and a relationship is established.

[0103] The above product identification "0" For example, "8" can be used to search for "0" in the knowledge graph. The data field corresponding to "8" is the product identifier. Then, the database checks whether the "product identifier" includes "0". Verify with "8". If included, search for the product identifier "0". The node associated with "8".

[0104] The validation ensures robustness in complex environments and enables self-evolution when dealing with interface changes, element offsets, and dynamic interference. Ultimately, it achieves a new paradigm of enterprise-level data governance that is ready to use and continuously optimized through a fully closed-loop autonomous mode.

[0105] Furthermore, one can query the target knowledge graph and the product identifier "0". 8” indicates nodes with flow or nesting relationships, and will be associated with the product identifier "0". Nodes with flow or nesting relationships are identified as target nodes. Since the target knowledge graph already includes the connection relationships between nodes in multiple business systems, querying the target node of the content to be queried from the target knowledge graph reflects the connectivity of target nodes related to the content to be queried in different business systems. This breaks the limitation of a single analysis path in a single system, realizes full-link gaps between multiple systems, and obtains more comprehensive target nodes. It automatically resolves semantic conflicts in heterogeneous systems and improves cross-platform compatibility.

[0106] S204. Generate and output the query results based on the page element or child element corresponding to the target node.

[0107] Optionally, the query results may include: business data of the page element corresponding to the target node or business data of the child element corresponding to the target node.

[0108] Understandably, when the query result is a graph, the graph can include one or more target nodes. The business data of the page element or sub-element corresponding to the target node can be node information. The node information of each node may not be directly displayed in the graph. Instead, the node information is displayed when the user triggers a query operation on any node (such as clicking a node in the graph or right-clicking a selected node and triggering a display operation from a drop-down menu).

[0109] Furthermore, pop-up windows containing node information can be displayed at the node's location or adjacent locations. Alternatively, an information display area can be associated with the graph to display the node's information.

[0110] When the query results can be presented as a table, the table can be created based on the business data of the page element corresponding to the target node or the business data of its child elements. In other words, the table can display the business data of the page element corresponding to the target node or the business data of its child elements.

[0111] In this embodiment, multiple system pages from multiple business systems are collected to achieve page integration across multiple business systems. Furthermore, specified attribute data corresponding to each system page is collected. This specified attribute data includes business data corresponding to at least one element within the system page. Each element includes at least one page element and its corresponding multi-level sub-elements, converting unstructured data from system pages into structured specified attribute data to ensure consistent data representation across different system pages. Additionally, a target knowledge graph is constructed using page elements and sub-elements as nodes, and the nesting relationships between page elements and their multi-level sub-elements as edges. This displays the page distribution structure in the form of a knowledge graph, reflecting the dependencies between one or more elements within a page. Based on this target knowledge graph, target nodes related to the query content can be queried, and the page elements or sub-elements corresponding to the target nodes can be used as the source of query results. This enables cross-page and cross-system queries of the query content, breaking down query barriers between systems, obtaining more flexible and comprehensive content queries, and improving the accuracy and comprehensiveness of the query.

[0112] Furthermore, based on any of the above embodiments, query results are generated according to the page element or sub-element corresponding to the target node, including: Generate a target graph based on the page element or child element corresponding to the target node. A target graph is a graph formed by the flow relationship between one or more target nodes. The target map is selected as the query result; Alternatively, a table can be generated based on the page element or child element corresponding to the target node. The columns of the table include the component objects in the page objects of each business system, and the rows of the table include the values ​​of the target node in the corresponding business system. The table is then used as the query result.

[0113] For example, Figure 6 An example diagram of a target map is shown. For example... Figure 6 The target graph shown may include multiple target nodes with flow relationships, such as target node 0 and target nodes 1-9 associated with target node 0, which are all nodes associated with the content to be queried.

[0114] The flow relationship can include: the order in which nodes flow, the data transmission path, the interaction logic of components, and other relationships.

[0115] The target node can be a node in one or more business systems. The product identifier "0" is used as the query content. For example, "8" is different from the product label "0". 8” Nodes with flow or nesting relationships are considered target nodes. For example, the target nodes found in the query could include those with "Product Identifier" set to "0". The target node can be, for example, an 8” node. Figure 3 The nodes shown in the business system can also be nodes in other business systems.

[0116] For example, the page elements or sub-elements corresponding to the target node may include the first-level sub-elements in Table 3021, such as "Product Line", "Product Identifier", "Product Type", "Product Attribute", "Product Description", "Available Quantity", "Reserved Quantity", "Total Quantity", "Product Name", "Product Address", "Product Manager", etc.

[0117] It's understandable that a Page Object can refer to a wrapper class for page elements within a webpage, app page, or mini-program page, representing the corresponding page element. A Component Object can be a subclass of a Page Object, specifically referring to a component within a Page Object that possesses independent functionality; one object can correspond to a child element of a page element. Of course, Component Objects can also be multi-level. For example, a first-level Component Object can be the system name, second-level Component Objects can be the names of page elements within the system, and third-level Component Objects can be the names of each child element of the page element. Taking the IMM system as an example, the first-level Component Object can be the IMM system itself; second-level Component Objects can include the sample market and the material market; and third-level Component Objects can include: sub-elements of the sample market, such as sample type, sample manufacturer, accountant, product line, sample code, and sample loss; and sub-elements of the material market, such as material type, product identifier, and material description.

[0118] The value of the target node in the corresponding business system can include the business data corresponding to the target node. For example, the target node is defined as "product identifier" and is represented by "0". Taking the node "8" as an example, the business data corresponding to the first row in Table 3021 is "[Department 1, 0 8. Production raw materials, consumables, 0 8, 2, 0, 2, ABC, warehouse 1-2-3 shelves in a certain location, management name] can be the value of a target node in the corresponding business system.

[0119] Optionally, generating a table based on the page element or child element corresponding to the target node may include: obtaining one or more target business systems containing the target node, obtaining the target page object containing the target node in each target business system, establishing a table header based on the multi-level component object in the target page object where the target node is located, and writing the field values ​​of the queried target node in the corresponding business system as row data into the table to obtain the completed table.

[0120] In this embodiment, by first locating the target business system and target page object containing the target node, and then automatically constructing the table header based on the multi-level component object where the target node is located, and filling the table with the business field values ​​corresponding to the target node in the form of row data, the target data can be automatically and accurately extracted and structured from cross-system and multi-level business pages. There is no need to manually sort the table header or manually enter information, which significantly reduces the operational cost and complexity of multi-source business data integration. At the same time, the table structure is generated based on the standardization of multi-level component objects and written into the corresponding table header, which can ensure that the generated table has a unified format, clear structure, and accurate data, realize the visualization and tabular output of query results, and improve the convenience and efficiency of cross-system business data integration, presentation and use.

[0121] Optionally, the table name and field names of the data tables containing each target node can be added to the table. The table includes two components: the data table and the fields. These two components can be placed on the same row as the second-level or third-level component objects for easy viewing.

[0122] Optionally, after generating the table, the relevant information of the target node in the table (such as the content to be queried and the name of the queried data table, field names, etc.) will be displayed in different colors compared with the values ​​of other fields in the table.

[0123] Specifically, you can set the background or font color of the target node's page element or child element in the table to the first color, and set the background or font color of the non-target node's page element or child element in the table to the second color. The first color and the second color are different.

[0124] In this embodiment, the relevant information of the target node in the table is displayed with different colors from the values ​​of other fields in the table. This can highlight the relevant information of the target node at the visualization level, enabling users to quickly locate the relevant information of the target node when viewing the table, improving the efficiency of reading and recognizing effective information. At the same time, the differentiated color display can make the table content more distinguishable, avoid data confusion, reduce the risk of misreading, and enhance the intuitiveness, readability and ease of use of the table display.

[0125] like Figure 7 As shown, taking the first business system as IMM system 701 and the second business system as PDM system 702 as examples, this demonstrates how to generate a table based on the page element or sub-element corresponding to the target node. The table header can be a multi-level component object of the page object of the business system where the target node is located.

[0126] Specifically, IMM system 701, as a first-level component object in the table, can include second-level component objects such as sample market 7011 and material market 7012. Sample market 7011 can include third-level component objects such as sample type 701a, product line 701b, and sample code 701c. Material market 7012 can include third-level component objects such as material category 701d, material code 701e, and material description 701f.

[0127] PDM system 702, as a first-level component object in the table, can include second-level component objects such as component attribute class 7021. Component attribute class 7021 can include third-level component objects such as: sub-category name 702a, category 702b, external model 702c, default unit 702d, code 702e, and sub-category code 702f.

[0128] like Figure 7 The table shown may include the following headers: the Table (data table) containing each node, and the column (field) of each node within the Table. The table rows may also include: the table name of the data table containing each target node, and the field names corresponding to the fields.

[0129] For example, using material codes "030568758" and "06182999" as the query content, the corresponding target nodes are queried from the IMM system 701 and PDM system 702. In IMM system 701, the material code name remains unchanged, while in PDM system 702, the material code is replaced with an encoding. After eliminating the ambiguity of the encoding, the target node for material code "030568758" can be queried in IMM system 701, specifically target nodes 710, 711, and 712. In PDM system 702, target nodes 713 and 714 for encoding "06182999" are queried.

[0130] The background color of the row and column values ​​of the target node, as well as the table name and field names of the target node, can be different from the colors of other fields in the table. For example... Figure 7 In the table shown, the background color of the table name, field names, and field values ​​for the target node with material code "030568758" retrieved in IMM system 701 can all be the first color. The background color of the table name, field names, and field values ​​for the data retrieved in PDM system 702 can also be the first color, such as orange. Other fields in the table can also be the second color, such as white. By setting two different colors, the relevant information for the queried target node can be quickly distinguished from the table.

[0131] In this embodiment, after obtaining the target nodes, the flow relationships between them are transformed into a graph, connecting the independently existing nodes to visualize the flow relationships. This makes the flow process clearer and improves the comparability and operability of the data. Alternatively, a table can be generated based on the page elements or sub-elements corresponding to the target nodes, allowing the target nodes to be displayed intuitively through the component objects and values ​​of the table, reducing the cost of reading the relevant data of the target nodes. Therefore, both graph-based relational data and table-based structured data can achieve intuitive data display, making data query results more intuitive and reducing the information understanding cost of complex query results.

[0132] like Figure 8 The diagram shown is another flowchart of a data processing method based on a multi-service system provided in this application embodiment. The method may include the following steps: S801: Collect data from multiple system pages in multiple business systems, as well as the specified attribute data corresponding to each system page.

[0133] Optionally, determining multiple system pages in multiple business systems may include: performing usage simulations on each business system to obtain at least one system page for each business system, and determining the at least one system page corresponding to each of the multiple business systems as multiple system pages.

[0134] Specifically, the usage simulation of each business system is performed to obtain at least one system page of each business system. This may include: using a large model obtained through training to simulate the usage of each business system and obtain at least one system page of each business system.

[0135] It should be understood that each system page in the business system can be accessed through its URL (Uniform Resource Locator) address.

[0136] For any business system, the business system may include one or more system pages, and the page flow path may refer to multiple system pages and / or page elements and / or page sub-elements that have jump / flow associations in the same business system.

[0137] Optionally, determining the page flow path between multiple system pages may include recording the page flow path between each system page during the simulation of each business system. For example, clicking button B on page A displays page C. Clicking button D on page C displays page E, thus forming a page flow path from page A to page C to page E.

[0138] S802. Using each page element and its child element corresponding to the system page as nodes, and the nesting relationship between the child elements corresponding to each page element as edges, generate a business call relationship graph of the system page.

[0139] A business call relationship graph can refer to a graph formed by the call relationships between different elements. For example, if clicking button B on page A displays page C, then there is a call relationship between page A and button B, and there is also a call relationship between button B and page C.

[0140] like Figure 9 The example diagram showing the business call relationship is 901 for a system page. For example, it could include business call relationship diagrams 9011-9014 for four system pages. In business call relationship diagram 9011, the page element is Product Identifier 1. The first-level sub-elements of Product Identifier 1 can include: associated files, related history, associated documents, comments, manufacturer 1, changes, associated baselines, documents, related projects, and related processes. The second-level sub-element of the first-level sub-element, associated documents, includes codes. In business call relationship diagram 9012, the page element is Product Identifier 2, and the page elements include: process records, ERP attributes, alternative information, associated files, related manufacturers, BOM list, and component attributes. When alternative information is a first-level sub-element, it includes three second-level sub-elements: component, alternative component, and detailed information. When the BOM list is a first-level sub-element, it includes the second-level sub-element corresponding to the code. In business call relationship diagram 9013, the page element is Product Identifier 2, and the first-level sub-element of Product Identifier 2 is product data. In the business call relationship graph 9014, the page element is product identifier 3, and the first-level sub-element of product identifier 3 is process record.

[0141] S803. Connect the business call relationship graphs corresponding to system pages with page association relationships to obtain the initial knowledge graph.

[0142] like Figure 9 As shown, both business call relationship graphs 9011 and 9012 contain associated files; therefore, business call relationship graphs 9011 and 9012 can be connected via associated files. Both business call relationship graphs 9012 and 9013 contain product identifier 2; therefore, business call relationship graphs 9012 and 9013 can be connected via product identifier 2. Furthermore, both business call relationship graphs 9012 and 9014 contain process records; therefore, business call relationship graphs 9012 and 9014 can be connected via process records.

[0143] Therefore, the business call relationship graphs corresponding to system pages with page association relationships are connected to obtain the initial knowledge graph 902. The initial knowledge graph 902 can be composed of the business call relationship graphs 901 of multiple system pages with page association relationships. The connecting node is the same element in the two business call relationship graphs.

[0144] S804. Normalize the nodes of the initial knowledge graph to obtain the target knowledge graph.

[0145] Optionally, normalizing the nodes of the initial knowledge graph to obtain the target knowledge graph can include: disambiguation and merging the nodes of the initial knowledge graph to obtain the target knowledge graph. Specifically, for nodes in the initial knowledge graph, nodes with the same name or the same meaning can be merged into one node to obtain the target knowledge graph.

[0146] For example, if the initial knowledge graph 1 includes S nodes and the initial knowledge graph 2 also includes S nodes, then there is an edge between the S nodes of the initial knowledge graph 1 and the S nodes of the initial knowledge graph 2. However, since both nodes on the edge are S nodes, the two S nodes and the edge can be merged into one S node.

[0147] For example, if initial knowledge graph 1 contains node S1 and initial knowledge graph 2 contains node S2, then there is an edge between node S1 in initial knowledge graph 1 and node S2 in initial knowledge graph 2. However, since the two nodes S1 and S2 have the same meaning, they can be merged into one node. The merged node can be called either node S1 or node S2. Of course, the node information of the retained node can also include the node information of the merged node. For example, if node S1 is retained, its node information can include the node information of node S2.

[0148] like Figure 9 As shown, the target knowledge graph 903 is obtained by normalizing the nodes in the initial knowledge graph 902. The following example illustrates the node normalization process.

[0149] For example, although product identifier 1 and product identifier 2 in the initial knowledge graph 901 have different field names, their field values ​​are the same, such as "4123". Therefore, product identifier 1 and product identifier 2 can be merged into one product identifier, such as using product identifier 1 to represent them.

[0150] For example, if Manufacturer 1 and Manufacturer 2 have the same manufacturer name, address, and other information, then the two nodes, Manufacturer 1 and Manufacturer 2, can be merged into a single related manufacturer 9031.

[0151] For example, product evaluation 9021 and comment 9022 are both evaluations of the same product. Therefore, product evaluation 9021 and comment 9022 can be normalized to obtain related comment 9032.

[0152] For ease of understanding, such as Figure 10 As shown, Figure 3 and Figure 4 The example shown is of the target knowledge graph of the first business system. Specifically, it may include three system pages: page element 1001 corresponding to the system page of the first business system, page element 1002 corresponding to the first system page of the first business, and page element 1003 corresponding to the second system page of the second business.

[0153] The page element 1002 of the first system page includes: product line 10021, total quantity 10022, available quantity 10023, product identifier 10024, product type 10025, product description 10026, product attributes 10027, reserved quantity 10028, product manager 10029, product address 1002a, and product name 1002b, etc. The product identifier may include: product identifier type 1002c and product identifier source 1002d, etc., as second-level sub-elements.

[0154] The page element 1003 of the second system page includes: source order number 10031, product identifier 10032, finance 10033, account setup method 10034 and other first-level sub-elements.

[0155] S805. Based on the target knowledge graph, query the target nodes that are related to the content to be queried.

[0156] S806. Generate and output the query results based on the page element or child element corresponding to the target node.

[0157] In this embodiment, after collecting multiple system pages and their specified attribute data, a corresponding business call relationship graph is generated on a per-system-page basis. Then, by connecting the business call relationship graphs of system pages with page associations, an initial knowledge graph is constructed, transforming the static page structure into a dynamic flow association. This achieves automatic integration of knowledge from the page level to the system level. Furthermore, the nodes in the initial knowledge graph are normalized to enhance the consistency of knowledge representation. Moreover, after obtaining the target knowledge graph, content queries based on the constructed target knowledge graph can discover cross-page queries, uncover implicit relationships between different pages, and obtain deeper, more relevant query results, improving the accuracy and comprehensiveness of the query.

[0158] In the process of building a knowledge graph, a page-level graph can be built first. The following will introduce the construction of a page-level graph. As an example, using each page element and its child elements corresponding to a system page as nodes, and the nesting relationships between the child elements of each page element as edges, a business call relationship graph of the system page is generated, including: Based on the preset graph structure, each page element and its sub-elements corresponding to the system page are used as nodes, and the nesting relationships between the sub-elements of each page element are used as edges to generate a business call relationship graph of the system page.

[0159] In this embodiment of the application, the preset graph structure can be a structure or template for graph establishment. Using the preset graph structure to establish the business call relationship graph of the system page can make the graph construction consistent and standardized.

[0160] Connect the business call relationship graphs corresponding to system pages with page association relationships to obtain the target knowledge graph, including: If the same element exists on multiple first system pages, then it is determined that the multiple first system pages have a page association relationship; By connecting the business call relationship graphs corresponding to multiple first system pages with page association relationships, an initial knowledge graph corresponding to multiple first system pages is obtained.

[0161] Optionally, having page association can mean that the same page element exists in pages on different systems.

[0162] It should be understood that if the same page element appears on one or more system pages, then the one or more system pages containing the same page element are considered page elements with a page relationship. Alternatively, if different page elements have different names but the same meaning, then the respective system pages of those different page elements are considered page elements with a page relationship.

[0163] For example, if system page A contains the S element and system page B contains the S element, then system page A and system page B are system pages with a page relationship.

[0164] For example, if clicking the S element in system page A redirects to system page B, and the redirection to system page B is related to the S element, then it is determined that the S element appears in system page B. Therefore, it can be determined that system page A and system page B are system pages with a page relationship.

[0165] For example, if system page A contains element S1 and system page B contains element B2, and elements B1 and B2 have different names but the same meaning, then system page A and system page B are determined to be system pages with a page relationship.

[0166] Optionally, the business call relationship graphs corresponding to system pages with page association relationships are connected to obtain one or more initial knowledge graphs. This may include: identifying multiple first system pages with page association relationships, and flow page elements representing the page association relationships between the multiple first system pages, and connecting the nodes corresponding to the flow page elements in the business call relationship graphs of different first system pages to obtain the initial knowledge graph.

[0167] Optionally, if the same element exists in multiple system pages, then these multiple system pages are determined to have a page association relationship. The page element used to indicate the page association relationship among multiple system pages is a transition page element. A system page with a page association relationship can also be called the first system page.

[0168] It should be understood that multiple first system pages containing the same page element can comprise one or more groups, and each group of multiple first system pages can construct a corresponding initial knowledge graph. Therefore, an initial knowledge graph can include one or more, and duplicate nodes in each initial knowledge graph can be eliminated and merged to obtain the target knowledge graph corresponding to each initial knowledge graph.

[0169] For ease of understanding, if both the business call relationship graph corresponding to system page A and the business call relationship graph corresponding to system page B contain an "encoding" element, then the "encoding" elements of the business call relationship graphs can be connected to form an initial knowledge graph.

[0170] Of course, if a business call relationship graph does not have a page association relationship with other business call relationship graphs, then the business call relationship graph that does not have a page association relationship with other business call relationship graphs can be directly used as an initial knowledge graph.

[0171] In this embodiment of the application, when connecting page-level business call relationship graphs to form a system-level knowledge graph, page association relationships are used as the connection conditions for business call relationship graphs. This enables the integration of cross-page business call relationship graphs, forming a complete knowledge graph. This makes the knowledge conversion process more unified and standardized, eliminates redundant knowledge, improves the simplicity and accuracy of the knowledge graph, and provides a higher quality knowledge graph, thereby further improving the efficiency and accuracy of knowledge retrieval.

[0172] It should be understood that the embodiments of this application may correspond to multiple business systems, and each business system may include one or more system pages to interact with the user. The specified attribute data can be data in the system page.

[0173] In order to obtain system pages and specified attribute data within system pages from a business system, in one possible design, Figure 11 This illustration shows another flowchart of a data processing method based on a multi-service system provided in an embodiment of this application. The difference from the previous embodiments lies in that the method involves collecting multiple system pages from multiple service systems and the specified attribute data corresponding to each system page, which may include: S1101. Simulate the operation of each business system and obtain the access address corresponding to at least one system page in each business system.

[0174] S1102. Based on the access address of the system page, retrieve the specified attribute data in the system page to obtain the specified attribute data corresponding to multiple system pages in multiple business systems.

[0175] In this embodiment, by simulating the use of various business systems, the access addresses of each system page are obtained, and the specified attribute data in the system page is captured through the access addresses of each system page, thereby realizing the automated collection of specified attribute data. Data collection can be completed without modifying the business system or embedding code. While ensuring system security, intelligent data collection of various elements in the system page is achieved, improving collection efficiency.

[0176] Furthermore, based on the access address of the system page, retrieving specified attribute data from the system page can include: Parse the access address of the system page to locate at least one element in the system page, where the element is a page element or a child element corresponding to a page element; Extract the business data corresponding to at least one element; Determine the specified attribute data of the system page based on the business data corresponding to at least one element.

[0177] Optionally, a page parsing tool can be queried from the tool library, and the access address of the system page can be entered into the page parsing tool. The page parsing tool can then parse the system page to obtain at least one element of the system page.

[0178] At least one element in the system page may include: visual elements in the visual layer of the system page, structural elements in the structural layer, and interactive elements in the interaction layer.

[0179] Optionally, the system page can be parsed based on the access address of the system page to obtain the visual elements in the visual layer, the structural elements in the structural layer, and the interactive elements in the interaction layer of the system page.

[0180] For example, visual elements can be tables, structural elements can be data corresponding to label areas, and interactive elements can be interactive data after a button is clicked.

[0181] It should be understood that the business data corresponding to at least one element may include at least one of the following: text data corresponding to visual elements, structural data corresponding to structural elements, and visual data corresponding to interactive elements.

[0182] In this embodiment of the application, by extracting business data of different elements from the visual layer, structural layer and interaction layer, the specified attribute data can be integrated with data from multiple modalities, making the data content of the specified attribute data more comprehensive and able to represent the attribute data contained in the page from diverse dimensions.

[0183] Optionally, determining the specified attribute data of the system page based on the business data corresponding to at least one element may include: determining the business data of each crawled element as the specified attribute data of the system page. Alternatively, data fusion may be performed on the specified attribute data corresponding to at least one element to obtain the specified attribute data corresponding to the system page.

[0184] In this embodiment, the system page can be parsed using its access address to obtain at least one element, thus confirming the element-level analysis object. After extracting the business data corresponding to each of the at least one element, the specified attribute data of the system page can be determined based on the business data corresponding to each of the at least one element. This element-based data extraction makes the entire system page data collection process more accurate, structured, and scalable, enabling efficient extraction of business data from the system page.

[0185] Furthermore, based on any of the above embodiments, at least one element's corresponding business data is extracted, including: Identify at least one subtask corresponding to each element. A subtask is a task that performs a corresponding data collection operation on an element in the system page. Execute at least one subtask corresponding to each element to obtain business data corresponding to at least one element.

[0186] In one possible design, for any element, one or more candidate subtasks can be created, each candidate subtask being associated with a corresponding target tool. The computational complexity of the target tools for different candidate subtasks differs. One of these candidate subtasks can be selected as the element's subtask.

[0187] It should be understood that if any element's subtask fails to execute, a new subtask can be selected and executed from the remaining candidate subtasks of that element. By establishing a strategy of one or more candidate subtasks for each element, automatic switching between multiple strategies can be achieved, ensuring the success rate of subtask execution for each element and improving the robustness of the entire data processing method.

[0188] In this embodiment of the application, during the process of extracting business data corresponding to at least one element, at least one sub-task corresponding to each element can be determined first. For each element, a corresponding sub-task can be constructed. Then, by executing the sub-tasks of each element, the business data of each element can be obtained. This makes the data collection process of each element more refined, avoids data collection on the basis of the entire system page, and ensures that the data collection sub-tasks of each element do not affect each other. This allows for more accurate and faster collection of specified attribute data.

[0189] Furthermore, based on any of the above embodiments, determining the sub-task corresponding to at least one element may include: Based on a pre-defined large language model, the system identifies the processing intent corresponding to at least one element when a user interacts with a system page.

[0190] Based on the processing intent corresponding to at least one element, determine at least one subtask, and associate each subtask with the target tool to be used.

[0191] Among them, Large Language Model (LLM) refers to an artificial intelligence model that is trained on large-scale training data and has the ability to understand and generate human language, perform logical reasoning, and answer questions.

[0192] It should be understood that any subtask can be established for one or more elements. After obtaining the processing intent corresponding to at least one element, at least one subtask can be determined.

[0193] Furthermore, based on the processing intent corresponding to at least one element, at least one sub-task is determined. This can include: establishing and orchestrating one or more sub-tasks based on the trained large model and the processing intent corresponding to at least one element, thereby obtaining at least one sub-task. Each sub-task is associated with a corresponding execution order and the target tool to be used. For example, sub-tasks may include: triggering snapshots, OCR (Optical Character Recognition) recognition, simulating scrolling, etc. The target tool can be at least one of the following: screenshot statistics, layout parsing tool, DOM (Document Object Model) mapper, simulated scroller, dynamic loading detection module, pop-up focuser, form extraction tool, etc.

[0194] For ease of understanding, Table 1 below shows an example of dynamic task decomposition.

[0195] Table 1

[0196] Referring to Table 1, the table page can be broken down into three sub-tasks: triggering snapshot, OCR recognition, and coordinate mapping. The target tool for the triggering snapshot sub-task is the screenshot tool, the target tool for the OCR recognition sub-task is the layout parsing tool, and the target tool for the coordinate mapping sub-task is the DOM mapper.

[0197] The list page with unlimited scrolling can be broken down into three sub-tasks: simulated scrolling, incremental DOM, and deduplication and merging. The target tool for the simulated scrolling sub-task is the scroll simulator, and the target tool for the incremental DOM and deduplication and merging sub-tasks is the dynamic loading detection module.

[0198] The multi-step pop-up form page can be broken down into three sub-tasks: locating the trigger button, pop-up parsing, and data backfilling. The target tool for the location trigger and pop-up parsing sub-tasks is the pop-up focuser, and the target tool for the data backfilling sub-task is the form extraction tool.

[0199] In this embodiment, when constructing subtasks for each element, a large language model can be used to understand the processing intent of each element. By utilizing the processing intent of each element, at least one subtask can be determined. Each subtask is associated with the target tool to be used, and the target tool of each element can be used to execute the corresponding subtask. This achieves a link-based analysis from intent recognition, tool matching, and task execution, ensuring that the subtask matches the processing intent of the corresponding element. Through subtasks with higher matching degree, data collection of elements can be completed more accurately and efficiently, effectively improving operation and maintenance efficiency.

[0200] To execute each subtask, the target tool required for the subtask execution can be called from the tool library, thereby executing the corresponding subtask and obtaining the execution result of the subtask.

[0201] Furthermore, based on any of the above embodiments, at least one subtask corresponding to each element is executed to obtain business data corresponding to at least one element, including: The tool library is used to call the target tools required for each subtask, and the corresponding subtasks are executed according to the target tools called by each subtask to obtain the execution results of each subtask. Based on the execution results of each subtask, the business data corresponding to at least one element is determined.

[0202] As mentioned above, each subtask is associated with a corresponding execution order. Further, calling the target tools required by each subtask from the tool library, and executing the corresponding subtasks according to the target tools called by each subtask, to obtain the execution results of each subtask can include: sequentially calling the target tools required by each subtask from the tool library according to the execution order of each subtask, and executing the corresponding subtasks according to the target tools called by each subtask, to obtain the execution results of each subtask.

[0203] The execution results of each subtask may include business data corresponding to one or more elements related to that subtask. If one or more elements have the same execution purpose, then the business data of one or more elements will be the same.

[0204] It should be understood that the target tool can be one or more tools found in the tool library that match the processing intent of the element.

[0205] As described above, at least one element in a system page can include: visual elements in the visual layer, structural elements in the structural layer, and interactive elements in the interaction layer.

[0206] Based on the processing intent corresponding to at least one element, at least one subtask is determined, which may include: based on the processing intent corresponding to the visual element, structural element, and interactive element, establishing a first subtask for the visual element, a second subtask for the structural element, and a third subtask for the interactive element.

[0207] The first subtask requires the use of a layout parsing tool, a character conversion tool, and a dynamic element positioning tool; the second subtask requires the use of a layout parsing tool and a dynamic element positioning tool; and the third subtask requires the use of a button clicking tool. The execution order of the subtasks is as follows: first the first subtask, then the second subtask, and finally the third subtask.

[0208] For example, you can call layout analysis tools, character conversion tools, and dynamic element positioning tools that match visual elements from the tool library to perform the first subtask and obtain the execution result of the first subtask; you can query component area recognition tools and source code conversion tools that match structural elements from the tool library to perform the second subtask and obtain the execution result of the second subtask; you can query button clicking tools that match interactive elements (such as buttons or input boxes) from the tool library to perform the third subtask and obtain the execution result of the third subtask.

[0209] For example, the execution result of the first subtask may include text data corresponding to the visual element. For instance, the visual element could be a table element; that is, a layout parsing tool and a dynamic element positioning tool can be used to parse the system page, obtain the table element on the system page, locate the table, and then use a character conversion tool to identify the data in the table based on its position.

[0210] For example, the execution result of the second subtask may include the structural data corresponding to the structural elements. If the component region identification tool and source code conversion tool required by the second subtask are used, the component region identification tool can identify the tag regions (i.e., structural elements) that carry the core content in the system page, and then the source code conversion tool can extract the structural data corresponding to the tag regions.

[0211] For example, the execution result of the third subtask may include visual data corresponding to the interactive element. If the interactive element is a button, and the target tool of the third subtask is a button clicking tool, the visual tracking result after the button click can be obtained by performing a click operation on the button on the system page and tracking the interactive element under the click operation, thereby determining the visual tracking result as the visual data corresponding to the button.

[0212] In this embodiment, the target tools required for each subtask are called from the tool library, enabling automated tool invocation. By executing the corresponding subtasks according to the target tools invoked for each subtask and obtaining the execution results, the tooling, modularization, and automation of subtask processing can be achieved, improving processing efficiency. Based on the execution results of each subtask, at least one element's corresponding business data is determined. The execution results of different subtasks can be used to determine the business data of each element, enhancing the flexibility and scalability of the business data acquisition process.

[0213] In another possible design, after generating and outputting the query results based on the page elements or sub-elements corresponding to the target node, the query results can be fed back to the large language model. Starting from the recognition of the processing intent based on the preset large language model, the results are fed back to the entire data processing method based on the multi-business system, realizing continuous optimization of the self-learning feedback loop and getting rid of the dependence on manual rule configuration.

[0214] Optionally, the tool library includes at least one of the following tools: Page layout analysis tool; dynamic element positioning tool; button click tool; character conversion tool; component area recognition tool; source code conversion tool; page parsing tool.

[0215] Optionally, a layout analysis tool can refer to a tool that uses OCR technology to perform structural analysis on different layout areas of a page. A layout analysis tool can also be called an OCR layout analysis tool.

[0216] As we can understand, OCR technology is a technique that converts images (such as scanned documents, photos, and text in screenshots) into editable and searchable digital text. The principle is to capture the shapes of characters in an image using optical means, and then use algorithms to match and recognize them as text.

[0217] For example, layout analysis tools can automatically identify different areas on a page, such as title areas, body text areas, table areas, image areas, and formula areas. Then, they can tag each area with attributes, assigning labels (e.g., "title", "content", "table") and recording information such as the area's coordinates and hierarchical relationship (e.g., "title above body text"). Furthermore, they can extract text from each area, organizing it according to the area structure while preserving the layout logic.

[0218] Alternatively, a dynamic element positioning tool can refer to a tool for positioning elements whose attributes / positions change dynamically over time, through operations, or during rendering.

[0219] The button click tool can be used for dynamic tracking of React components. It can accurately locate and parse the boundaries, types, dependencies, and structural characteristics of React components in code or applications through technical means (static analysis, runtime detection, etc.). React components are the core building blocks of the React framework, encapsulating independent code blocks with specific UI (User Interface) structures, styles, and logic, such as button components, list components, and navigation components.

[0220] Character conversion tools can refer to OCR conversion tools, specifically tools that use OCR technology to recognize and convert characters. For example, first capture an image of a page, then use OCR technology to recognize the characters in the image. If further character conversion is needed, character type conversion or encoding can be performed.

[0221] Optionally, the component area recognition tool can be, for example, a body area recognition tool. Body area recognition can accurately locate the effective information in the tag area of ​​a page / webpage that carries the core content in order to support subsequent conversion.

[0222] Body region recognition is used to filter and locate the "effective content area" within tags in the complete DOM tree (excluding non-core modules such as navigation bars, advertisements, and footers), so as to optimize the structure only for the core content and avoid interference from irrelevant elements.

[0223] Optionally, source code conversion tools can refer to web source code conversion tools, which can be used to perform intelligent DOM structure conversion. DOM (Document Object Model) is the structured representation of a webpage, and "intelligent DOM structure conversion" essentially optimizes / reconstructs the DOM tree through technical means. Intelligent DOM structure conversion is used to automatically adjust the webpage DOM tree based on rules or AI algorithms, thereby achieving functions such as simplifying hierarchy, unifying tag specifications, adapting to multiple platforms (such as PC to mobile), and improving rendering performance.

[0224] Optionally, a page parsing tool can be used to parse the page and obtain the elements within it.

[0225] Of course, the tools mentioned above are merely examples and do not constitute a limitation on the types and number of tools. The tool library may also include: screenshot tools, DOM mappers, scroll simulators, dynamic loading detection modules, pop-up focusers, and form extraction tools, among others.

[0226] In this embodiment of the application, by defining at least one of the following tools in the tool library: layout parsing tool, dynamic element positioning tool, button clicking tool, character conversion tool, component area recognition tool, source code conversion tool, or page parsing tool, the tool library can provide a richer set of tools, support the unified and standardized design of tools, improve the richness and executability of matching target tools for each element, and form a more adaptable automated task creation scheme.

[0227] like Figure 12 As shown, a schematic diagram of a data processing device based on a multi-service system is provided. The data processing device 1200 based on a multi-service system may include: The data acquisition unit 1201 is used to collect multiple system pages in multiple business systems and the specified attribute data corresponding to each system page. The specified attribute data includes business data corresponding to at least one element in the system page. The at least one element includes: at least one page element and multi-level sub-elements corresponding to each page element. The graph construction unit 1202 is used to construct a target knowledge graph by taking each page element and each sub-element in the specified attribute data of each system page as nodes and the nesting relationship between each page element and the corresponding multi-level sub-element as edges. The content query unit 1203 is used to query target nodes that are related to the content to be queried, based on the target knowledge graph. The result output unit 1204 is used to generate and output query results based on the page element or sub-element corresponding to the target node; the query results include the business data of the page element or sub-element corresponding to the target node.

[0228] In this embodiment, multiple system pages from multiple business systems are collected to achieve page integration across multiple business systems. Furthermore, specified attribute data corresponding to each system page is collected. This specified attribute data includes business data corresponding to at least one element within the system page. Each element includes at least one page element and its corresponding multi-level sub-elements, converting unstructured data from system pages into structured specified attribute data to ensure consistent data representation across different system pages. Additionally, a target knowledge graph is constructed using page elements and sub-elements as nodes, and the nesting relationships between page elements and their multi-level sub-elements as edges. This displays the page distribution structure in the form of a knowledge graph, reflecting the dependencies between one or more elements within a page. Based on this target knowledge graph, target nodes related to the query content can be queried, and the page elements or sub-elements corresponding to the target nodes can be used as the source of query results. This enables cross-page and cross-system queries of the query content, breaking down query barriers between systems, obtaining more flexible and comprehensive content queries, and improving the accuracy and comprehensiveness of the query.

[0229] As one embodiment, the map construction unit 1202 may include: The graph construction module is used to generate a business call relationship graph of the system page, with each page element and its child element as nodes and the nesting relationship between the child elements as edges. The graph connection module is used to connect the business call relationship graphs corresponding to system pages with page association relationships to obtain an initial knowledge graph. The graph disambiguation module is used to normalize the nodes of the initial knowledge graph to obtain the target knowledge graph.

[0230] As another example, the map construction module can be specifically used for: Based on the preset graph structure, each page element and its sub-elements corresponding to the system page are used as nodes, and the nesting relationships between the sub-elements of each page element are used as edges to generate a business call relationship graph of the system page.

[0231] The map connection module can be specifically used for: If the same element exists on multiple first system pages, it is determined that there is a page association relationship among the multiple first system pages; the business call relationship graphs corresponding to the multiple first system pages with page association relationships are connected to obtain the initial knowledge graph corresponding to the multiple first system pages.

[0232] As another embodiment, the data acquisition unit 1201 may include: The simulation acquisition module is used to simulate the operation of various business systems and obtain the access address corresponding to at least one system page in each business system.

[0233] The data capture module is used to capture specified attribute data from system pages based on their access addresses, in order to obtain the specified attribute data corresponding to multiple system pages in multiple business systems.

[0234] As another embodiment, the data capture module may include: The element locator submodule is used to parse the access address of the system page and locate at least one element in the system page. The element is either a page element or a child element corresponding to a page element. The data extraction submodule is used to extract business data corresponding to at least one element. The data fusion submodule is used to determine the specified attribute data of the system page based on the business data corresponding to at least one element.

[0235] As another example, the data extraction submodule is specifically used for: Identify at least one subtask corresponding to each element. A subtask is a task that performs a corresponding data collection operation on an element in the system page. Execute at least one subtask corresponding to each element to obtain business data corresponding to at least one element.

[0236] As another embodiment, the data extraction submodule determines at least one subtask corresponding to each element, which may specifically include: Based on a pre-defined large language model, the system identifies the processing intent corresponding to at least one element on the page; it queries the tool library for target tools that match the processing intent of each element; and it determines the sub-tasks corresponding to each element based on the target tools, thus obtaining at least one sub-task corresponding to each element.

[0237] As yet another example, the tool library includes at least one of the following tools: Page layout analysis tool; dynamic element positioning tool; button click tool; character conversion tool; component area recognition tool; source code conversion tool; page parsing tool.

[0238] As another embodiment, the result output unit 1204 may specifically include: The first output module is used to generate a target graph based on the page elements or sub-elements corresponding to the target node. The target graph refers to the graph formed by the flow relationship between one or more target nodes; the target graph is then used as the query result. Alternatively, the second output module is used to generate a table based on the page element or sub-element corresponding to the target node. The columns of the table include component objects in the page objects of each business system, and the rows of the table include the values ​​of the target node in the corresponding business system; the table is then used as the query result.

[0239] As another embodiment, when the query result is a table, the second output module is specifically used to: obtain one or more target business systems containing the target node; obtain the target page object containing the target node in each target business system; establish a table header based on the multi-level component object in the target page object where the target node is located, and write the field values ​​of the queried target node in the corresponding business system as row data into the table to obtain the table after writing.

[0240] As another embodiment, the second output module is specifically used to: display the relevant information of the target node in the table and the values ​​of other fields in the table in different colors.

[0241] It should be understood that the communication device described here is embodied in the form of a functional unit. The term "unit" here may refer to application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memories for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0242] In an optional example, those skilled in the art will understand that the communication device may specifically be the first processing unit or the second processing unit in the above embodiments. The communication device may be used to execute the various processes and / or steps corresponding to the first processing unit or the second processing unit in the above method embodiments. To avoid repetition, it will not be described again here.

[0243] The communication devices of the above-described schemes have the function of implementing the corresponding steps executed by the first processing unit or the second processing unit in the above methods; the above functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0244] In the embodiments of this application, Figure 12 The data processing device 1200 in the middle can also be a chip or a chip system, such as a system on chip (SoC).

[0245] Figure 13 This application provides a hardware block diagram of a computing device. The computing device 1300 according to this application includes at least a memory 1301 and a processor 1302. The memory 1301 stores a computer program, which may be, for example, firmware or an operating system. The processor 1302 executes the computer program to implement the data processing method based on a multi-service system as described in any of the above embodiments.

[0246] In addition, both memory 1301 and processor 1302 are electrically connected to bus 1303. Computing device 1300 may also include transceiver 1304 connected to bus 1303 for communication with other devices.

[0247] Furthermore, embodiments of this application also provide a computer-readable storage medium for storing a computer program. When executed by a processor, the computer program implements the data processing method based on a multi-service system described in any of the preceding embodiments of this application.

[0248] Computer-readable storage media include, but are not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, optical disk, magnetic disk, etc.

[0249] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the data processing method based on a multi-service system as described in any of the preceding embodiments of this application.

[0250] The basic principles of the embodiments of this application have been described above with reference to specific examples. However, it should be noted that the advantages, benefits, and effects mentioned in the embodiments of this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the embodiments of this application from necessarily employing the aforementioned specific details.

[0251] The block diagrams of devices, apparatuses, devices, and systems involved in the embodiments of this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0252] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0253] It should also be noted that in the systems and methods of this application embodiment, each component or step can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions of the embodiments of this application.

[0254] Various changes, substitutions, and modifications can be made to the technology herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of the embodiments of this application is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0255] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use embodiments of this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of embodiments of this application. Therefore, embodiments of this application are not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0256] The above description has been given for illustrative and descriptive purposes. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.< / tab> < / tabs> < / address> < / address> < / system> < / xml> < / path> < / action> < / sampledata> < / address> < / name>

Claims

1. A data processing method based on a multi-service system, characterized in that, include: Collect multiple system pages from multiple business systems and specified attribute data corresponding to each system page. The specified attribute data includes business data corresponding to at least one element in the system page. The at least one element includes: at least one page element and multi-level sub-elements corresponding to each page element. Using each page element and each sub-element in the specified attribute data of each system page as nodes, and the nesting relationship between each page element and its corresponding multi-level sub-elements as edges, a target knowledge graph is constructed. Based on the target knowledge graph, query the target nodes that are related to the content to be queried; Based on the page element or sub-element corresponding to the target node, generate and output the query results, which include the business data of the page element or sub-element corresponding to the target node.

2. The method according to claim 1, characterized in that, The construction of the target knowledge graph, using page elements and sub-elements of each system page as nodes and the nesting relationships between page elements and their corresponding multi-level sub-elements as edges, includes: Using each page element and each child element corresponding to the system page as nodes, and the nesting relationship between each page element and its corresponding child element as edges, a business call relationship graph of the system page is generated. Connect the business call relationship graphs corresponding to system pages with page association relationships to obtain an initial knowledge graph; The nodes of the initial knowledge graph are normalized to obtain the target knowledge graph.

3. The method according to claim 2, characterized in that, The process of generating a business call relationship graph for the system page, using each page element and its child elements as nodes and the nesting relationships between the child elements as edges, includes: Based on the preset graph structure, each page element and each sub-element corresponding to the system page are taken as nodes, and the nesting relationship between the sub-elements of each page element is taken as edges, to generate the business call relationship graph of the system page.

4. The method according to claim 2, characterized in that, The process involves connecting the business call relationship graphs corresponding to system pages with page associations to obtain one or more initial knowledge graphs, including: If the same element exists on multiple first system pages, then it is determined that the multiple first system pages have a page association relationship; By connecting the business call relationship graphs corresponding to multiple first system pages with page association relationships, an initial knowledge graph corresponding to multiple first system pages is obtained.

5. The method according to claim 1, characterized in that, The collection of multiple system pages from multiple business systems and the specified attribute data corresponding to each system page includes: Simulate the operation of each business system and obtain the access address corresponding to at least one system page in each business system. Based on the access address of the system page, specified attribute data in the system page is captured to obtain the specified attribute data corresponding to the multiple system pages in the multiple business systems.

6. The method according to claim 5, characterized in that, The step of retrieving specified attribute data from the system page based on the access address of the system page includes: Parse the access address of the system page and locate at least one element in the system page, wherein the element is a page element or a child element corresponding to a page element; Extract the business data corresponding to each of the at least one element; Based on the business data corresponding to each of the at least one element, determine the specified attribute data of the system page.

7. The method according to claim 6, characterized in that, The extraction of the business data corresponding to each of the at least one element includes: Determine the subtask corresponding to each of the at least one element, wherein the subtask refers to the task of performing corresponding data collection operations on the elements in the system page; Execute the subtasks corresponding to the at least one element to obtain the business data corresponding to the at least one element.

8. The method according to claim 7, characterized in that, The step of determining the subtasks corresponding to the at least one element includes: Based on a preset large language model, identify the processing intent corresponding to at least one element when the user uses the system page; Based on the processing intent corresponding to the at least one element, at least one subtask is determined, and each subtask is associated with the target tool to be used.

9. The method according to claim 7, characterized in that, The step of executing the subtasks corresponding to the at least one element to obtain the business data corresponding to the at least one element includes: Call the target tools required by each subtask from the tool library, execute the corresponding subtasks according to the target tools called by each subtask, and obtain the execution results of each subtask; Based on the execution results of each subtask, determine the business data corresponding to each of the at least one element.

10. The method according to claim 9, characterized in that, The tool library includes at least one of the following tools: Page layout analysis tool; dynamic element positioning tool; button click tool; character conversion tool; component area recognition tool; source code conversion tool; page parsing tool.

11. The method according to claim 1, characterized in that, The step of generating query results based on the page element or sub-element corresponding to the target node includes: Based on the page element or sub-element corresponding to the target node, a target graph is generated, wherein the target graph refers to a graph formed by the flow relationship between one or more target nodes; the target graph is then determined as the query result. Alternatively, a table can be generated based on the page element or sub-element corresponding to the target node. The columns of the table include component objects in the page objects of each business system, and the rows of the table include the values ​​of the target node in the corresponding business system. The table is then determined as the query result.

12. The method according to claim 11, characterized in that, When the query result is the table, generating the table based on the page element or sub-element corresponding to the target node includes: Obtain one or more target business systems that contain the target node; Retrieve the target page objects that contain the target nodes in each target business system; Based on the multi-level component objects in the target page object where the target node is located, a table header is created, and the field values ​​of the queried target node in the corresponding business system are written into the table as row data to obtain a table that has been written.

13. The method according to claim 12, characterized in that, Also includes: The relevant information of the target node in the table is displayed in a different color compared to the values ​​of other fields in the table.

14. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs; The processor is used to execute computer programs to implement the data processing method based on a multi-service system as described in any one of claims 1-13.

Images