Cross-system data processing method and device, equipment and medium

Abstract

The invention discloses a cross-system data processing method and device, equipment and a medium, and relates to the field of computer data processing. The method comprises the following steps: receiving a data calling request, wherein the data calling request comprises data extraction information and a requester system identifier; determining a requester data format based on the requester system identifier; obtaining source data from a provider system according to the data extraction information, wherein the source data is in a provider data format; converting the source data from a provider data format to a requester data format, and generating target data adapted to a requester system; and transmitting the target data to the requester system according to the requester system identifier. Through the method, the technical problems of inaccurate data processing and low efficiency among the systems caused by inconsistent data formats of multiple service systems in a power grid scene in the prior art are solved, and the technical effect of improving the accuracy and efficiency of data processing among the service systems of a power grid is achieved.

Description

Technical Field

[0001] This application relates to the field of computer data processing, and particularly to a cross-system data processing method, device, equipment and medium. Background Art

[0002] With the continuous deepening of the informatization construction of the power grid, the number of business systems involved in power grid operation and management has increased day by day, including multiple business systems such as production management systems, equipment management systems, operation and maintenance management systems, and dispatching systems. In the long-term development process of these business systems, due to factors such as different construction periods, different development manufacturers, and different technical standards, they have formed their own independent data formats and interface standards.

[0003] In actual grass-roots power grid work, it is often necessary to exchange and share data between different business systems. However, due to the inconsistent data formats adopted by each business system, for example, there are differences in data structure, field definition, encoding method, data type, etc., data interaction cannot be directly carried out between business systems. Currently, manual processing or relying on the original factory to develop special interface programs is mainly used to achieve data conversion. Manual processing not only has a cumbersome processing process, is prone to data conversion errors, affects the accuracy of data processing, but also requires a large amount of manpower input and a long processing time, seriously affecting the efficiency of data processing between systems; while relying on the original factory to develop special interface programs has problems such as a long development cycle, high cost, and difficult maintenance, and the coordination and cooperation between different manufacturers are complex, making it difficult to form a unified data interaction standard. Summary of the Invention

[0004] The main purpose of this application is to provide a cross-system data processing method, device, equipment and medium, aiming to solve the technical problems in the prior art that the data formats of multiple business systems in the power grid scenario are inconsistent, resulting in inaccurate and inefficient data processing between systems.

[0005] To achieve the above object, in the first aspect, an embodiment of this application provides a cross-system data processing method, the method includes: receiving a data call request, the data call request includes data extraction information and a requester system identifier; determining the requester data format based on the requester system identifier; obtaining source data from a provider system according to the data extraction information, the source data is in the provider data format; converting the source data from the provider data format to the requester data format to generate target data adapted to the requester system; and transmitting the target data to the requester system according to the requester system identifier. In some embodiments, the data extraction information includes a data type identifier, a data range parameter, and a query condition.

[0006] In some embodiments, determining the requestor data format based on the requestor system identifier includes: retrieving a system data format mapping library, where the system data format mapping library includes multiple system identifiers and multiple system data formats, and the multiple system identifiers and multiple system data formats are in one-to-one correspondence; inputting the requestor system identifier into the system data format mapping library to obtain the system data format corresponding to the requestor system identifier, and obtaining the requestor data format.

[0007] In some embodiments, obtaining source data from the provider system according to the data extraction information includes: determining the provider system according to the data type identifier; constructing a data screening condition according to the data range parameter and the query condition; converting the data screening condition into a query request format supported by the provider system to generate a target query request; sending the target query request to the provider system and receiving the returned source data.

[0008] In some embodiments, converting the source data from the provider data format to the requestor data format to generate target data adapted to the requestor system includes: parsing the data structure of the source data to identify the fields and data types of the source data; obtaining a target data format mapping rule between the provider data format and the requestor data format; performing field mapping, data type conversion, and encoding standardization processing on the source data according to the target data format mapping rule to obtain conversion data; performing format verification on the conversion data, and using the conversion data that passes the verification as the target data.

[0009] In some embodiments, obtaining a target data format mapping rule between the provider data format and the requestor data format includes: querying a preset format conversion rule library, where the format conversion rule library stores data format mapping rules between multiple systems, and the data format mapping rules between multiple systems include directional data format conversion mappings between system pairs; retrieving the corresponding data format mapping rule from the format conversion rule library according to the provider system and the requestor system to obtain the target data format mapping rule.

[0010] In some embodiments, retrieving the corresponding data format mapping rule from the format conversion rule library according to the provider system and the requestor system to obtain the target data format mapping rule includes: constructing a system pair mapping retrieval expression, where the system pair mapping retrieval expression specifies the mapping direction from the provider system to the requestor system; using the system pair mapping retrieval expression to perform a query in the format conversion rule library to obtain a data format mapping rule that matches the system pair mapping retrieval expression as the target data format mapping rule.

[0011] Second aspect, embodiments of the present application provide a cross-system data processing apparatus, including: A data request module, configured to receive a data call request, where the data call request includes data extraction information and a requester system identifier; A format determination module, configured to determine a requester data format based on the requester system identifier; A data acquisition module, configured to obtain source data from a provider system according to the data extraction information, where the source data is in a provider data format; A format conversion module, configured to convert the source data from the provider data format to the requester data format to generate target data adapted to the requester system; A data transfer module, configured to transfer the target data to the requester system according to the requester system identifier.

[0012] Third aspect, embodiments of the present application provide an electronic device, which includes: a memory and a processor, where the memory is used to store a computer software program; the processor is configured to, when executing the computer software program, enable the electronic device to implement the cross-system data processing method according to any one of the above first aspects.

[0013] A memory, configured to store a computer software program; a processor, configured to read and execute the computer software program, thereby implementing a cross-system data processing method provided by the present application.

[0014] Fourth aspect, embodiments of the present application provide a computer-readable storage medium, in which a computer software program is stored, and when the computer software program is executed by a processor, the cross-system data processing method according to any one of the above first aspects is implemented.

[0015] The cross-system data processing method provided by the embodiments of the present application receives a data call request, which includes data extraction information and the identifier of the requesting party's system, and unifies the data call methods of different systems through a standardized request interface; determines the data format of the requesting party based on the identifier of the requesting party's system to provide an accurate conversion target for subsequent data format conversion; obtains source data from the provider system according to the data extraction information, and the source data is in the provider data format, so as to extract the required original data from the corresponding business system; converts the source data from the provider data format to the requesting party's data format to generate target data adapted to the requesting party's system, and eliminates the data format differences between different systems through the format conversion mechanism to ensure the accuracy and compatibility of the data; and delivers the target data to the requesting party's system according to the identifier of the requesting party's system to ensure that the data can be accurately delivered to the corresponding business system. Through the above technical solutions, automatic conversion and seamless transfer of data formats between various business systems of the power grid are realized, effectively solving the problems of inaccurate data processing and low efficiency caused by inconsistent data formats. At the same time, there is no need to rely on the original factory to develop special interface programs, reducing the development cost and maintenance difficulty, and providing a convenient and efficient cross-system data processing solution for data processing between various business systems of the power grid. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0018] Figure 1 It is a schematic flowchart of an embodiment of the cross-system data processing method provided by the present application; Figure 2 It is a schematic structural diagram of the cross-system data processing device provided by the embodiments of the present application; Figure 3 It is a schematic structural diagram of the electronic device provided by the embodiments of the present application; Figure 4 It is a schematic structural diagram of the computer-readable storage medium provided by the embodiments of the present application.

[0019] In the accompanying drawings, the list of components represented by each reference numeral is as follows: 11. Data request module, 12. Format determination module, 13. Data acquisition module, 14. Format conversion module, 15. Data transfer module, 200. Electronic device, 210. Memory, 220. Processor, 211. Computer software program, 300. Computer-readable storage medium.

[0020] The realization of the purpose of this application, functional features and advantages will be further described in conjunction with the embodiments and with reference to the accompanying drawings. Detailed implementation manners

[0021] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0022] In the following description, specific details such as specific system structures, interfaces, technologies, etc. are presented for the purpose of illustration rather than limitation, so as to thoroughly understand this application.

[0023] The terms "first", "second", and "third" in this application are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first", "second", and "third" may explicitly or implicitly include at least one of the said features. In the description of this application, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise specifically and clearly defined. In the embodiments of this application, all directional indications (such as up, down, left, right, front, back...) are only used to explain the relative positional relationship and movement conditions between components in a specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indications will also change accordingly. The terms "including" and "having" in the embodiments of this application and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or components inherent to these processes, methods, products, or devices.

[0024] Referring to "embodiments" herein means that the specific features, structures, or characteristics described in conjunction with the embodiments can be included in at least one embodiment of this application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0025] The present application will be described in detail below with reference to the accompanying drawings and embodiments.

[0026] An embodiment of the cross-system data processing method is provided in the present application. Referring to Figure 1 as shown, the cross-system data processing method provided by the embodiment of the present application includes the following steps: S1. Receive a data call request, where the data call request includes data extraction information and a requestor system identifier; S2. Determine the requestor data format based on the requestor system identifier; S3. Obtain source data from the provider system according to the data extraction information, where the source data is in the provider data format; S4. Convert the source data from the provider data format to the requestor data format to generate target data adapted to the requestor system; S5. Transmit the target data to the requestor system according to the requestor system identifier.

[0027] Specifically, in the power grid business scenario, different business systems (such as power dispatching systems, power consumption information collection systems, distribution systems, marketing business application systems, production management systems, etc.) need to obtain data from other systems to support their business processes. However, due to the large number of business systems in the power grid, complex business processes, and inconsistent interfaces of each business system, the processing of business data in the power grid is inaccurate and inefficient. The cross-system data processing method provided by the embodiment of the present application can realize data exchange between different business systems in the power grid business scenario, can shield the interface differences between systems, and realize unified data format conversion and data transmission services, so as to efficiently complete cross-system data penetration and improve the data interaction efficiency and data processing accuracy between power grid business systems.

[0028] First, a data call request sent by the requesting system is received. The data call request, as the starting signal of cross-system data interaction, carries the information necessary to complete data acquisition. The data call request contains data extraction information and the requesting system identifier. By receiving the data call request, the data requirements of the requesting party can be accurately understood, and the necessary parameters for the subsequent cross-system data processing process can be provided. Among them, the requesting system can be various business systems in the power grid, such as power dispatching system, power consumption information collection system, distribution system, marketing business application system, production management system, etc. Among them, the data extraction information describes the specific characteristics and scope of the data required by the requesting system, including but not limited to the type, time range, geographical range, equipment range and other attributes of the data, which provides a clear guidance basis for subsequent data screening and acquisition operations, ensuring that the target data that meets the requirements of the requesting system can be accurately identified and extracted. The requesting system identifier is used to uniquely identify the system identity that initiates the data call request. Through the requesting system identifier, the source system of the data request can be accurately determined, and the corresponding data format requirements and transmission specifications can be determined based on the requesting system identifier, laying the foundation for subsequent data format adaptation and data transmission operations.

[0029] Since different business systems in the power grid use different data format standards, for example, the power dispatching system may use the IEC 61970 standard, the distribution system may use the IEC 61968 standard, and the marketing business application system may use a custom data structure. Therefore, accurately identifying the data format required by the requesting system is a prerequisite for ensuring the correct transmission of data. Specifically, the requesting system identifier is used as the index key to query and obtain the corresponding data format specification from the pre-established system data format mapping library to obtain the requesting data format. The requesting data format defines in detail the technical parameters such as the data structure, field definition, data type, encoding method, transmission protocol, etc. that the requesting system can recognize and process. By establishing a one-to-one correspondence between the system identifier and the data format, the requesting data format of any requesting system can be automatically determined without manual intervention or additional format negotiation process. This identifier-based format determination mechanism not only improves processing efficiency, but also reduces maintenance complexity, and provides an accurate target format reference for subsequent data format conversion operations. Once the requester data format is successfully determined, the requester data format will be used as the target standard for data conversion to guide the format conversion processing of the source data in subsequent steps, ensuring that the target data finally generated can be correctly identified and used by the requester system.

[0030] In the power grid business scenario, the provider system refers to the business system that stores data, such as the production management system that stores equipment operation parameters, the power consumption information collection system that stores power consumption data, and the distribution system that stores power grid topology information. Since different provider systems use their own data formats and access interfaces, it is necessary to build targeted data acquisition strategies to adapt to the characteristics of each system. Specifically, first, parse the data extraction information and identify the parameters contained therein, such as data type identifier, data range parameter, and query condition. Based on the data type identifier, the specific source system of the data, that is, the provider system, can be determined. Subsequently, accurate data filtering conditions are constructed based on the data range parameter and query condition, which clearly define the time boundary, spatial range, device range, and other limiting conditions of the data to be extracted. In order to ensure compatibility with the provider system, the constructed data filtering conditions are converted into a specific query request format supported by the provider system. Different provider systems may support different query languages, such as SQL queries, RESTful API calls, WebService requests, etc. Through format conversion, a target query request that conforms to the provider system interface specification is generated. After that, the target query request is sent to the provider system, and the source data returned by the provider system is received. The acquired source data maintains the original data format of the provider system, i.e., the provider data format, including the provider system’s unique data structure, field naming rules, data type definition, encoding standards and other format features. These source data provide the original material for the subsequent format conversion steps, ensuring the integrity and accuracy of the data and providing a data foundation for achieving cross-system data connectivity.

[0031] Due to the large number of power grid business systems and their diverse technical architectures, there are often significant differences in the data formats adopted by different systems. For example, the provider system may store data using the table structure of a relational database, while the requester system may require data in XML format or JSON format; or the provider system uses a certain specific coding standard, while the requester system adopts a different coding specification. If these format differences are not addressed, the data cannot be correctly recognized and used. Therefore, after obtaining the source data, the source data is first deeply parsed to identify the complete data structure of the source data, including attributes such as the names of data fields, hierarchical relationships, data types, value ranges, etc., and comprehensively understand the organization form and semantic meaning of the source data. Subsequently, the target data format mapping rules between the provider data format and the requester data format are obtained from the preset format conversion rule library. The target data format mapping rules define in detail the conversion parameters such as the corresponding relationship between the fields of the provider system and the requester system, the conversion method of data types, and the conversion specification of coding standards, providing precise operation guidance for data format conversion. Based on the obtained target data format mapping rules, a comprehensive format conversion process is performed on the source data, including field mapping, data type conversion, and coding standardization processing, so as to obtain the target data that meets the requirements of the requester system. This target data not only maintains the business semantics and data integrity of the source data but also has the data format characteristics that the requester system can directly recognize and process, laying the foundation for the final data transmission. Among them, field mapping ensures that each data field in the source data can be correctly mapped to the field structure of the requester system; data type conversion ensures that the type definition of the data meets the requirements of the requester system; coding standardization processing unifies the coding format of the data and eliminates compatibility problems caused by coding differences.

[0032] After obtaining the target data, the detailed configuration information of the requesting party's system is retrieved from a preset system configuration library based on the system identifier of the requesting party. The technical parameters include the network address, port number, communication protocol type, security authentication parameters, data receiving interface specifications, etc. of the requesting party's system. These configuration information provide complete routing and protocol guidance for data transmission. According to the detailed configuration information of the requesting party's system obtained, a data transmission method compatible with the requesting party's system is selected, and the target data is transmitted to the requesting party's system, thereby realizing cross-system processing of data between different systems in the power grid. Different requesting party systems may support different data receiving mechanisms, such as RESTful API calls using the HTTP / HTTPS protocol, SOAP message passing of Web Service, asynchronous push of message queues, FTP file transfer, direct writing to databases, etc. Preferably, during the data transmission process, necessary security control measures can also be executed, including security operations such as data encryption, identity authentication, access permission verification, etc., to ensure the security and compliance of the data transmission process; at the same time, it supports transmission status monitoring and exception handling mechanisms, which can track the data transmission status in real time and execute retry or alarm operations when transmission fails. Through the above transmission process, the target data is accurately and securely delivered to the requesting party's system, and the requesting party's system can directly use the received data to support its business processes without additional format conversion or data processing. Thus, a complete cross-system data processing process is realized, effectively solving the technical problem of data connection between different systems in the power grid business scenario, and significantly improving the efficiency and reliability of data interaction between systems.

[0033] Further, the data extraction information includes a data type identifier, a data range parameter, and a query condition.

[0034] In a feasible implementation manner, the data extraction information includes three components: a data type identifier, a data range parameter, and a query condition, which can comprehensively and accurately express the specific requirements for data acquisition, providing guidance for subsequent data location and extraction operations.

[0035] Among them, the data type identifier is used to clearly specify the business type and technical category of the required data. In the power grid business scenario, the data type identifier may include, but is not limited to: equipment operation data, power measurement data, power grid topology data, fault alarm data, load prediction data, power quality data, etc. Through the data type identifier, the source system and storage location of the data can be quickly determined, providing a direct path guidance for data location. For example, when the data type identifier is "equipment operation data", the production management system or SCADA system can be directly located to obtain data.

[0036] Data range parameters are used to define boundary conditions such as the spatial range, time range, and device range of the required data. Specifically, the spatial range can specify spatial limitations such as specific geographical regions, substations, line segments, etc.; the time range can set time constraints such as the start time, end time, and sampling frequency of the data; the device range can clarify specific device types, device numbers, device groups, etc. Through these range parameters, the range of data extraction can be precisely controlled, avoiding the acquisition of irrelevant data and improving the efficiency and accuracy of data acquisition.

[0037] Query conditions are used to set more fine-grained data screening criteria, including business logic constraints such as data value conditions, status conditions, and quality conditions. For example, query conditions can set specific screening conditions such as "voltage level greater than 110 kV", "device status is running", and "data quality flag is valid". These query conditions can determine the data extraction range and ensure that the acquired data fully meets the business requirements of the requester system.

[0038] Through the combination of information in the above three dimensions, the data extraction information can construct a complete and accurate description of the data acquisition requirements, laying an information foundation for the realization of efficient and accurate cross-system data extraction.

[0039] Furthermore, based on the requester system identifier, the requester data format is determined, including: S21. Retrieve the system data format mapping library, which includes multiple system identifiers and multiple system data formats, and the multiple system identifiers and multiple system data formats are in one-to-one correspondence; S22. Input the requester system identifier into the system data format mapping library to obtain the system data format corresponding to the requester system identifier, and obtain the requester data format.

[0040] In some embodiments, first, retrieve the pre-established system data format mapping library. This system data format mapping library centrally stores the format configuration information of each system in the power grid business scenario. Specifically, the system data format mapping library includes multiple system identifiers and multiple system data formats, and a strict one-to-one correspondence is established between the multiple system identifiers and the multiple system data formats. Among them, the system identifier serves as the index key of the system data format mapping library and usually adopts a unique system code, system name, or identifier to distinguish different business systems in the power grid. For example, "SCADA_SYS_001" represents the dispatching system, "DMS_SYS_002" represents the distribution system, etc. The system data format, as the data value of the system data format mapping library, details the data format specifications adopted by the corresponding system, including complete format description information such as data structure definition, field naming rules, data type standards, encoding methods, and transmission protocols. By establishing this one-to-one mapping relationship, the system data format mapping library can provide accurate format configuration information for each business system in the power grid, ensuring the uniqueness and accuracy of format recognition. This system data format mapping library supports dynamic maintenance and expansion. When a new business system is added to the power grid or the format of an existing system changes, the mapping relationship can be updated in a timely manner to maintain the timeliness and integrity of the mapping library.

[0041] Then, use the requester system identifier obtained from the data call request as the query key and input it into the system data format mapping library for an exact match query. Through an efficient indexing mechanism, it is possible to quickly locate the mapping record that exactly matches the requester system identifier and obtain the corresponding system data format information in this record. The obtained system data format information is the requester data format, which completely describes the data specifications that the requester system can recognize and process. By means of the format determination mechanism based on the mapping library, the complex format negotiation process is avoided, and the automation and standardization of format determination are realized, significantly improving the efficiency and reliability of cross-system data processing.

[0042] Through the above steps, it is possible to accurately and quickly determine the data format requirements of any requester system, provide an accurate target format reference for subsequent data format conversion operations, and ensure that the generated target data fully complies with the format specifications of the requester system.

[0043] Furthermore, obtaining the source data from the provider system according to the data extraction information includes: S31. Determine the provider system according to the data type identifier; S32. Construct a data screening condition according to the data range parameter and the query condition; S33. Convert the data screening condition into the query request format supported by the provider system to generate a target query request; S34. Send the target query request to the provider system and receive the returned source data.

[0044] In a feasible implementation, first, determine the provider system according to the data type identifier in the data extraction information. For example, a pre-established mapping relationship library between data type identifiers and system sources is established, which details the specific storage locations and management systems of different types of data. Using the data type identifier as an index key, the provider system storing the target data can be quickly and accurately located. For example, when the data type identifier is "real-time power consumption data", the provider system can be determined as the power consumption information acquisition system; when the data type identifier is "equipment operation parameters", the provider system can be determined as the production management system or the SCADA system; when the data type identifier is "power grid topology information", the provider system can be determined as the distribution system. This system positioning mechanism based on data types avoids blind searches and significantly improves the efficiency of data acquisition.

[0045] Then, construct precise data screening conditions based on the data range parameters and query conditions in the data extraction information. Integrate the boundary constraints such as the time range, space range, and equipment range in the data range parameters with the business logic constraints in the query conditions to form a complete data screening criterion. For example, the construction process of the data screening conditions includes: converting the time range parameter into a time screening condition, such as "data collection time >= 2024-01-01 00:00:00 AND data collection time <= 2024-01-31 23:59:59"; converting the space range parameter into a geographical screening condition, such as "substation number IN ('110kV_Station_001', '110kV_Station_002')"; converting the equipment range parameter into an equipment screening condition, such as "equipment type = 'transformer' AND equipment status = 'running'"; and at the same time integrating the business constraints in the query conditions, such as "voltage value > 100 AND data quality = 'valid'". Through multi-dimensional condition construction, ensure that the screening conditions can comprehensively and accurately reflect the data acquisition requirements.

[0046] Subsequently, the constructed data screening conditions are converted into a specific query request format supported by the provider system to generate a target query request. Since different provider systems adopt different data access interfaces and query languages, format conversion needs to be carried out specifically to ensure compatibility. For example, for a relational database system that supports SQL queries, the data screening conditions are converted into standard SQL statements; for a system that supports RESTful APIs, the screening conditions are converted into HTTP request parameters; for a system that supports Web Services, the screening conditions are encapsulated into a SOAP message format; for a real-time data system that supports a specific protocol, the screening conditions are converted into the corresponding protocol message format. Through an adaptive format conversion mechanism, seamless docking with various types of provider systems can be achieved.

[0047] After that, the generated target query request is sent to the determined provider system, and the source data returned by the provider system is received. During the data transmission process, necessary security control measures can be implemented, including security guarantee mechanisms such as identity authentication, access permission verification, and encrypted data transmission, to ensure the security and compliance of the data acquisition process. At the same time, an exception handling and retry mechanism is supported. When a query fails due to a network exception or system failure, a retry operation can be automatically executed or an alarm message can be sent to the administrator. The received source data maintains the original format characteristics of the provider system, including its unique data structure, field definitions, data types, encoding standards, and other format attributes. These source data provide complete and accurate original materials for the subsequent format conversion steps, ensuring data integrity and business continuity in cross-system data transfer.

[0048] Through the above steps, the function of accurately and efficiently obtaining the required source data from any provider system is realized, laying a data foundation for the entire cross-system data processing process.

[0049] Furthermore, converting the source data from the provider data format to the requester data format to generate target data adapted to the requester system includes: S41. Analyze the data structure of the source data to identify the fields and data types of the source data; S42. Obtain the target data format mapping rules between the provider data format and the requester data format; S43. Perform field mapping, data type conversion, and encoding standardization processing on the source data according to the target data format mapping rules to obtain converted data; S44. Perform format verification on the converted data, and use the converted data that passes the verification as the target data.

[0050] In some embodiments, first, the source data obtained from the provider system is subjected to structural analysis to identify the organizational form and technical characteristics of the source data. For example, through existing data parsing techniques, key attribute information such as each data field in the source data, the hierarchical relationship between fields, the data type, data length, value range, etc. of each field are automatically identified. Specifically, the data structure analysis process includes: for structured data (such as XML, JSON, database table structures), by parsing the data schema definition or data structure description, metadata information such as field names, data types, and constraint conditions are accurately identified; for semi-structured data, through pattern recognition and data mining techniques, the internal structural rules of the data are automatically inferred; for unstructured data, through text parsing and semantic analysis techniques, useful structured information is extracted. Through comprehensive structural analysis, the technical characteristics and business semantics of the source data can be fully understood, providing an accurate data basis for subsequent format conversion.

[0051] Then, the target data format mapping rule between the provider data format and the requester data format is obtained from the preset format conversion rule library. The target data format mapping rule defines in detail the conversion relationship between the two data formats, including conversion parameters such as field correspondence, data type conversion specification, encoding standard conversion method, and data verification rules. Subsequently, based on the obtained target data format mapping rule, a comprehensive format conversion process is performed on the source data to obtain the converted data. This process includes three core links: field mapping, data type conversion, and encoding standardization processing. Among them, the field mapping process accurately maps each field in the source data to the corresponding field in the requester data format, and operations such as field name conversion, field position adjustment, field combination or splitting are processed. The data type conversion process ensures that the data type of each field meets the requirements of the requester system. For example, converting a string type to a numeric type, converting a timestamp format to a standard time format, converting an enumeration value to the corresponding encoded value, etc. The encoding standardization process unifies the encoding format of the data and eliminates encoding differences between different systems. For example, character encoding conversion, numerical precision adjustment, unit system unification, etc. Through processing, converted data that meets the requirements of the requester data format is generated, ensuring the integrity of business semantics and the accuracy of data content during the format conversion process.

[0052] Subsequently, strict format verification is performed on the generated conversion data to ensure the quality and reliability of the conversion results. The format verification process includes validations in multiple dimensions: verification of data structure integrity to verify whether the converted data contains all required fields and data items; verification of data type correctness to verify whether the data type of each field conforms to the specifications of the requesting party's system; verification of data content validity to verify whether the data values are within a reasonable range; verification of data format consistency to verify whether the overall data format conforms to the standards of the requesting party's system. Only the conversion data that passes all verification items is confirmed as qualified target data. For the data that fails the verification, corresponding exception handling mechanisms are executed, including error logging, alarm information sending, data repair attempts and other handling measures to ensure the controllability and traceability of the data conversion process.

[0053] Through the above steps, high-quality cross-system data format conversion is achieved. The generated target data not only fully meets the format requirements of the requesting party's system, but also maintains the business integrity and semantic accuracy of the source data, providing a guarantee for the realization of reliable cross-system data connection.

[0054] Furthermore, obtaining the target data format mapping rule between the provider data format and the requester data format includes: S421. Query the preset format conversion rule library, which stores data format mapping rules between multiple systems. The data format mapping rules between multiple systems include directional data format conversion mappings between system pairs; S422. According to the provider system and the requester system, retrieve the corresponding data format mapping rule from the format conversion rule library to obtain the target data format mapping rule.

[0055] In some embodiments, first, a pre-established format conversion rule library is queried. The format conversion rule library centrally stores the data format mapping rules between various systems in the power grid business scenario. The format conversion rule library adopts a systematic organizational structure and stores the data format mapping rules between multiple systems. These mapping rules cover the format conversion requirements of various business systems in the power grid. Among them, the data format mapping rules between multiple systems include the directional data format conversion mapping between system pairs, that is, each mapping rule clearly defines the data format conversion relationship from a specific provider system to a specific requester system. This directional mapping design fully considers the directionality and particularity of format conversion between different systems, ensuring the accuracy and pertinence of the conversion rules. For example, the format conversion rule library includes conversion mappings for various system pairs such as "real-time data format conversion rules from the SCADA system to the DMS system", "electricity quantity data format conversion rules from the power consumption information collection system to the marketing system", and "equipment status data format conversion rules from the production management system to the dispatching system". Each conversion mapping details the complete conversion parameters such as the field correspondence relationship, data type conversion method, coding standard conversion specification, and data verification requirements between the provider system and the requester system. The format conversion rule library supports dynamic maintenance and expansion. When a new business system is added to the power grid or the format of an existing system changes, new conversion rules can be added or existing rules can be updated in a timely manner to maintain the timeliness and integrity of the rule library. At the same time, the rule library adopts an efficient indexing mechanism to support fast rule retrieval and matching operations.

[0056] Subsequently, according to the determined provider system and requester system, the corresponding data format mapping rule is retrieved from the format conversion rule library to obtain the target data format mapping rule required for this data conversion task. This retrieval process uses an exact matching method, taking the provider system identifier and the requester system identifier as the combined query conditions to locate the uniquely corresponding conversion rule in the rule library. Specifically, the retrieval process first constructs a query key for the system pair, which contains the complete identifier information of the provider system and the complete identifier information of the requester system. Subsequently, an exact matching query is executed in the format conversion rule library using this query key to locate the data format mapping rule record that exactly corresponds to the current system pair. The obtained target data format mapping rule contains all the conversion parameters required to convert the data format of the current provider system to the data format of the current requester system, including but not limited to: a field mapping table that details the correspondence between each source field and the target field; a data type conversion function that specifies the conversion method between various data types; a coding conversion specification that clarifies the conversion rules between different coding standards; a data verification rule that sets the quality verification standard for the conversion result; and an exception handling strategy that defines the handling method for abnormal situations during the conversion process.

[0057] Through the above steps, the complete mapping rules required for the current data conversion task can be obtained quickly and accurately, providing precise technical guidance for subsequent data format conversion operations, ensuring the standardization, automation, and high-quality implementation of the conversion process, improving the efficiency and accuracy of format conversion, and enhancing maintainability and scalability.

[0058] Further, according to the requesting party system and the providing party system, retrieve the corresponding data format mapping rules from the format conversion rule library to obtain the target data format mapping rules, including: S4221. Construct a system-to-system mapping retrieval expression, where the system-to-system mapping retrieval expression specifies the mapping direction from the providing party system to the requesting party system; S4222. Use the system-to-system mapping retrieval expression to perform a query in the format conversion rule library, and obtain the data format mapping rules that match the system-to-system mapping retrieval expression as the target data format mapping rules.

[0059] In some embodiments, first, construct a system-to-system mapping retrieval expression, which clearly specifies the mapping direction from the providing party system to the requesting party system. The system-to-system mapping retrieval expression is described in a structured manner, including the source system identifier (providing party system), the target system identifier (requesting party system), and the mapping direction identifier. For example, the system-to-system mapping retrieval expression can be expressed as "SCADA_SYS_001 To DMS_SYS_002", clearly indicating the data format conversion direction from the dispatching system to the distribution system. Through this directional expression, the correct conversion rules in the correct direction can be ensured to be retrieved.

[0060] Subsequently, use the constructed system-to-system mapping retrieval expression to perform a query operation in the format conversion rule library. The query process performs an exact match based on the source system identifier, the target system identifier, and the mapping direction in the retrieval expression, and obtains the data format mapping rules that exactly match the retrieval expression. After a successful match, the retrieved data format mapping rules are determined as the target data format mapping rules, and the target data format mapping rules contain the complete conversion configuration information from the current providing party system to the requesting party system, providing accurate guidance for subsequent data format conversion operations.

[0061] Based on the same inventive concept, an embodiment of the present application also provides a cross-system data processing device. Please refer to Figure 2 , Figure 2 which is a schematic structural diagram of the cross-system data processing device provided by the embodiment of the present application. The cross-system data processing device includes: A data request module 11, configured to receive a data call request, where the data call request includes data extraction information and a requesting party system identifier; A format determination module 12 for determining the requester data format based on the requester system identifier; A data acquisition module 13 for acquiring source data from a provider system according to the data extraction information, where the source data is in the provider data format; A format conversion module 14 for converting the source data from the provider data format to the requester data format to generate target data adapted to the requester system; A data transfer module 15 for transferring the target data to the requester system according to the requester system identifier.

[0062] Further, the data extraction information includes a data type identifier, a data range parameter, and a query condition.

[0063] Further, the format determination module 12 includes: A mapping library retrieval unit for retrieving a system data format mapping library, where the system data format mapping library includes multiple system identifiers and multiple system data formats, and the multiple system identifiers and multiple system data formats are in one-to-one correspondence; A format matching unit for inputting the requester system identifier into the system data format mapping library to obtain the system data format corresponding to the requester system identifier, and obtaining the requester data format.

[0064] Further, the data acquisition module 13 includes: A provider determination unit for determining the provider system according to the data type identifier; A filtering condition construction unit for constructing a data filtering condition according to the data range parameter and the query condition; A query request conversion unit for converting the data filtering condition into a query request format supported by the provider system to generate a target query request; A data acquisition unit for sending the target query request to the provider system and receiving the returned source data.

[0065] Further, the format conversion module 14 includes: A data structure analysis sub-module for analyzing the data structure of the source data to identify the fields and data types of the source data; A mapping rule acquisition sub-module for obtaining a target data format mapping rule between the provider data format and the requester data format; A format conversion processing sub-module for performing field mapping, data type conversion, and encoding standardization processing on the source data according to the target data format mapping rule to obtain conversion data; A data verification sub-module for performing format verification on the converted data and using the converted data that passes the verification as the target data.

[0066] Further, the mapping rule acquisition sub-module includes: A rule library query unit for querying a preset format conversion rule library, where the format conversion rule library stores data format mapping rules between multiple systems, and the data format mapping rules between multiple systems include one-way data format conversion mappings between system pairs. A mapping rule retrieval unit for retrieving corresponding data format mapping rules from the format conversion rule library according to the provider system and the requester system to obtain target data format mapping rules.

[0067] Further, the mapping rule retrieval unit includes: A retrieval expression construction sub-unit for constructing a system pair mapping retrieval expression that specifies the mapping direction from the provider system to the requester system. A mapping rule query sub-unit for performing a query in the format conversion rule library using the system pair mapping retrieval expression to obtain data format mapping rules that match the system pair mapping retrieval expression as the target data format mapping rules.

[0068] Based on the same inventive concept, an embodiment of the present application also provides an electronic device. Figure 3 The structural schematic diagram of the electronic device provided by the embodiment of the present application is shown in Figure 3 As shown, the electronic device 200 provided in this embodiment includes: a memory 210, a processor 220, and a computer software program 211 stored on the memory 210 and executable on the processor 220. The processor 220 is used to implement the cross-system data processing method provided by the above embodiment when executing the computer software program 211.

[0069] Based on the same inventive concept, an embodiment of the present application also provides a computer-readable storage medium. Please refer to Figure 4 Figure 4 The schematic diagram of the embodiment of the computer-readable storage medium provided by the embodiment of the present application is shown in Figure 4 As shown, on the computer-readable storage medium 300, there is stored a computer software program 211, which, when executed by the processor 220, enables the electronic device 200 to implement the cross-system data processing method provided by the above embodiment.

[0070] Based on the same inventive concept, an embodiment of the present application also provides a computer program product, which, when running on a computer, enables the computing device to implement the cross-system data processing method provided by the above embodiment.​

[0071] It should be noted that in the above embodiments, the descriptions of the various embodiments have their own focuses. For parts not described in detail in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0072] Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.

[0073] The processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0074] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0075] Computer-readable media include both permanent and non-permanent, removable and non-removable storage media. The storage media can implement information storage by any method or technology, and the information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media do not include transitory media such as modulated data signals and carrier waves.

[0076] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A cross-system data processing method, characterized in that, The method includes: Receiving a data call request, which includes data extraction information and a requester system identifier; Determining the requester data format based on the requester system identifier; Obtaining source data from a provider system according to the data extraction information, where the source data is in the provider data format; Converting the source data from the provider data format to the requester data format to generate target data adapted to the requester system; Transmitting the target data to the requester system according to the requester system identifier.

2. The method according to claim 1, wherein The data extraction information includes a data type identifier, a data range parameter, and a query condition.

3. The method according to claim 1, characterized in that Determining the requester data format based on the requester system identifier includes: Retrieving a system data format mapping library, where the system data format mapping library includes multiple system identifiers and multiple system data formats, and the multiple system identifiers and multiple system data formats are in one-to-one correspondence; Inputting the requester system identifier into the system data format mapping library to obtain the system data format corresponding to the requester system identifier, and obtaining the requester data format.

4. The method according to claim 2, wherein Obtaining source data from a provider system according to the data extraction information includes: Determining the provider system according to the data type identifier; Constructing a data screening condition according to the data range parameter and the query condition; Converting the data screening condition into a query request format supported by the provider system to generate a target query request; Sending the target query request to the provider system and receiving the returned source data.

5. The method according to claim 1, wherein Converting the source data from the provider data format to the requester data format to generate target data adapted to the requester system includes: Analyzing the data structure of the source data to identify the fields and data types of the source data; Obtaining a target data format mapping rule between the provider data format and the requester data format; Performing field mapping, data type conversion, and encoding standardization processing on the source data according to the target data format mapping rule to obtain converted data; Performing format verification on the converted data, and using the converted data that passes the verification as the target data.

6. The method according to claim 5, wherein Obtaining a target data format mapping rule between the provider data format and the requester data format includes: Querying a preset format conversion rule library, where the format conversion rule library stores data format mapping rules between multiple systems, and the data format mapping rules between multiple systems include directional data format conversion mappings between system pairs; Retrieving the corresponding data format mapping rule from the format conversion rule library according to the provider system and the requester system to obtain the target data format mapping rule.

7. The method according to claim 6, characterized in that, Retrieving the corresponding data format mapping rule from the format conversion rule library according to the provider system and the requester system to obtain the target data format mapping rule includes: Constructing a system pair mapping retrieval expression, where the system pair mapping retrieval expression specifies the mapping direction from the provider system to the requester system; Execute a query on the mapping retrieval expression in the format conversion rule library using the system to obtain a data format mapping rule that matches the mapping retrieval expression of the system as the target data format mapping rule.

8. A cross-system data processing device, characterized in that, For implementing the method according to any one of claims 1 to 7, the apparatus includes: A data request module, configured to receive a data call request, where the data call request includes data extraction information and a requester system identifier; A format determination module, configured to determine a requester data format based on the requester system identifier; A data acquisition module, configured to obtain source data from a provider system according to the data extraction information, where the source data is in a provider data format; A format conversion module, configured to convert the source data from the provider data format to the requester data format to generate target data adapted to the requester system; A data transfer module, configured to transfer the target data to the requester system according to the requester system identifier.

9. An electronic device, characterized in that, Comprising: A memory, configured to store a computer software program; A processor, configured to cause the electronic device to implement the cross-system data processing method according to any one of claims 1 to 7 when reading and executing the computer software program.

10. A non-transitory computer-readable storage medium, characterized in that, A computer software program is stored in the storage medium, and when the computer software program is executed by a processor, the cross-system data processing method according to any one of claims 1 to 7 is implemented.

Images