Method and system for verifying oil field GIS (Geographic Information System) modularization application program interface

Abstract

The invention discloses an oil field GIS modularization application program interface verification method and system, and the method comprises the steps: firstly, setting a uniform interface specification, guaranteeing that all modules follow the same standard during the interface development, and reducing the verification problem caused by the interface difference; the access point of each interface is provided with interface metadata used for describing the basic information, the parameter type, the value range and the like of the interface. The interface metadata is the basis of interface verification and provides all information required during interface calling. When the interface is called, the transmitted parameters are dynamically verified according to the interface metadata to ensure that the parameters conform to the definition in the interface metadata. And after the parameter verification succeeds, obtaining a corresponding business logic processing object and a data format according to the interface metadata. This ensures that the system can correctly process the interface request, avoiding problems caused by mismatching of data formats or processing logic errors. Therefore, the method provided by the invention can solve the problems in the prior art.

Description

Technical Field

[0001] This invention belongs to the field of software development technology and relates to a method and system for verifying the interface of a modular application program for oilfield GIS. Background Technology

[0002] Geographic Information Systems (GIS) are widely used in drilling, oil extraction, surface operations, production operations, oil and gas pipeline maintenance, power generation, storage and transportation, flood control and drainage, and other fields. Component-based GIS has emerged as a cutting-edge technology and is gradually becoming the mainstream trend. Commercial component-based GIS platforms include MapObjects, ArcObjects, and GeoMedia.

[0003] Oilfield GIS systems need to process large amounts of geographic data and complex business logic, placing extremely high demands on system stability. With the continuous expansion of oilfield construction and the increasing amount of equipment, GIS systems require constant upgrades and expansions to meet new business needs. Interface verification is a crucial step in ensuring the stable operation of component-based GIS systems. Through interface verification, errors and anomalies in data interaction and function calls between components can be detected and resolved in a timely manner, improving system reliability and stability. The research and application of interface verification methods are of great significance for improving the overall performance and user experience of oilfield GIS systems. However, in oilfield applications, the lack of unified interface standards prevents interface verification, leading to poor GIS system stability. Summary of the Invention

[0004] The purpose of this invention is to solve the problem of poor stability of GIS systems in the prior art due to the inability to perform interface verification caused by inconsistent interface standards, and to provide an interface verification method and system for oilfield GIS componentized application programs.

[0005] To achieve the above objectives, the present invention employs the following technical solution:

[0006] The present invention proposes a method for verifying the interface of a modular application program for oilfield GIS, comprising the following steps:

[0007] The component-based application sets up an access point to receive interface call requests from different modules, and the interface of the access point has corresponding interface metadata.

[0008] Componentized applications initiate API call requests, passing API parameters through the access point;

[0009] Dynamically validate interface parameters based on interface metadata, and then implement interface validation after dynamic validation.

[0010] Preferably, in the dynamic verification of interface parameters based on interface metadata, the interface parameters conform to the definitions in the interface metadata.

[0011] Preferably, when a change is required to the interface, the interface metadata corresponding to the interface in the interface data module is changed, and the business logic processing object and / or parameter validation object corresponding to the interface in the external object encapsulation module is changed; the interface is connected to the interface data module and the external object encapsulation module respectively.

[0012] Preferably, when the verification fails, it means that the requested interface does not exist or the interface call request contains content that violates the interface metadata definition rules.

[0013] Preferably, the interface metadata includes the interface name, interface version, and interface configuration data; based on the interface configuration data, an existing target interface is determined, and new configurations are added to the existing target interface based on its existing configuration to obtain a new interface;

[0014] The interface configuration data specifically includes: determining the interface communication protocol corresponding to each interface, and parsing the interface metadata of each interface according to the data parsing specification corresponding to each interface communication protocol to determine the interface configuration data corresponding to each interface; wherein, the interface communication protocol includes at least one of Hypertext Transfer Protocol and Remote Procedure Call Protocol, and the parsing specification is used to specify the parsing method and configuration data items corresponding to each interface type.

[0015] Preferably, the dynamic verification includes parameter matching, parameter data type verification, parameter range verification, and logical relationship verification between parameters.

[0016] Furthermore, the parameter matching and verification steps are as follows: obtain the list of parameters passed in when calling the interface, and compare it one by one with the list of parameters defined in the interface metadata to check whether the passed parameters are missing or redundant. If they match, continue to the next step of verification.

[0017] The parameter data type validation steps are as follows: Extract the data type of the input parameter and compare it with the type defined in the interface parameter metadata. If the types match, proceed to the next validation step.

[0018] The parameter range verification steps are as follows: obtain the input parameter value, check whether the parameter value is within the range, and if the parameter value is within the range, continue to the next step of verification;

[0019] The steps for verifying the logical relationship between parameters are as follows: obtain all relevant parameter values ​​and verify them according to the logical relationship rules. If the logical relationship is satisfied, the verification passes.

[0020] Preferably, all data transmissions are performed via a communication protocol.

[0021] This invention proposes an oilfield GIS componentized application programming interface verification system, comprising:

[0022] An interface configuration module is used to set up access points for receiving interface call requests from different modules based on a componentized application. The interfaces of the access points have corresponding interface metadata.

[0023] The data acquisition module is used by the componentized application to initiate interface call requests and pass interface parameters through the access point;

[0024] The interface verification module is used to dynamically verify the interface parameters based on the interface metadata, and the interface verification is completed after the dynamic verification is completed.

[0025] A terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of an oilfield GIS componentized application programming interface verification method.

[0026] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of an oilfield GIS componentized application program interface verification method.

[0027] Compared with the prior art, the present invention has the following beneficial effects:

[0028] This invention proposes a method for verifying the interface of a modular application for oilfield GIS. First, it establishes access points to receive interface call requests from different modules, ensuring that all modules adhere to the same standards during interface development, reducing verification issues caused by interface differences. Interface metadata is set at each interface's access point to describe its basic information, parameter types, and value ranges. This interface metadata is the foundation of interface verification, providing all the information required for interface calls. When an interface is called, the incoming parameters are dynamically verified based on the interface metadata to ensure they conform to the definitions in the metadata. After successful parameter verification, the corresponding business logic processing object and data format are obtained from the interface metadata. This ensures the system can correctly process interface requests, avoiding problems caused by data format mismatches or processing logic errors. Therefore, the method proposed in this invention solves the problem of poor GIS system stability caused by the inability to perform interface verification due to inconsistent interface standards in existing technologies.

[0029] Furthermore, considering security factors, all data transmissions are conducted through secure communication protocols to reduce system stability issues caused by security problems.

[0030] Furthermore, parameter matching validation ensures that the names and quantities of parameters passed during the API call match the predefined API requirements; any mismatch in name or quantity will result in validation failure. Parameter data type validation ensures that the type of the passed parameter value matches the type defined in the API; for example, if a parameter should be an integer but a string is passed, validation will fail. Parameter range validation ensures that the passed parameter value is within a predefined valid range; for example, an integer parameter should be between 0 and 100, and a value outside this range will fail. Parameter logical relationship validation ensures that the combination of multiple parameters satisfies a specific logical relationship, such as the start time being earlier than the end time.

[0031] This invention proposes an interface verification system for modularized oilfield GIS applications. The system is divided into an interface configuration module, a data acquisition module, and an interface verification module to achieve interface verification. The modular approach ensures that each module is independent, facilitating unified management of all modules. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 A flowchart of the oilfield GIS component application interface verification method provided in this embodiment of the invention.

[0034] Figure 2 A diagram of an oilfield GIS componentized application program interface verification system provided in an embodiment of the present invention.

[0035] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0037] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0038] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0039] In the description of the embodiments of the present invention, it should be noted that if terms such as "upper," "lower," "horizontal," or "inner" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of the invention is in use, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. Furthermore, terms such as "first" and "second" are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0040] Furthermore, the use of the term "horizontal" does not imply that the component must be absolutely horizontal, but rather that it can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0041] In the description of the embodiments of the present invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention according to the specific circumstances.

[0042] The present invention will now be described in further detail with reference to the accompanying drawings:

[0043] This invention proposes a method for verifying the interface of a modular application program for oilfield GIS, such as... Figure 1 As shown, it includes the following steps:

[0044] S1. Based on the componentized application, an access point is set up to receive interface call requests from different modules. The interface of the access point has corresponding interface metadata.

[0045] When an interface needs to be changed, the corresponding interface metadata in the interface data module is modified, and the corresponding business logic processing object and / or parameter validation object in the external object encapsulation module are also modified, without modifying the logic code in the interface call processing module. The interface is connected to both the interface data module and the external object encapsulation module. This limitation has the following advantages: 1) Flexibility and adaptability: When an interface needs to be changed, the relevant interface metadata, business logic processing objects, and parameter validation objects can be quickly and specifically adjusted. This allows the system to flexibly adapt to constantly changing business needs and technical environments, improving the system's adaptability and scalability. 2) Reduced maintenance costs: Through clear module division and targeted change methods, the workload of large-scale modification and testing of the entire system during interface changes can be reduced, thereby reducing system maintenance costs. 3) Improved system stability: Only the parts directly related to the interface are changed, reducing the risk of introducing new errors due to modifications and helping to maintain the stability and reliability of other parts of the system. It avoids unnecessary impacts on unrelated business logic and functions during interface changes, reducing the possibility of system failures due to chain reactions. 4) Improve development efficiency: When making interface changes, developers can clearly know the specific modules and objects that need to be modified, reducing the time spent searching for and understanding related code, thereby improving development efficiency.

[0046] The interface metadata includes interface name, interface version, and interface configuration data. Based on the interface configuration data, existing target interfaces are determined, and new configurations are added to these existing target interfaces to obtain new interfaces. Specifically, the interface configuration data involves: determining the interface communication protocol for each interface, and parsing the interface metadata for each interface according to the data parsing specification corresponding to each interface communication protocol to determine the interface configuration data for each interface. The interface communication protocol includes at least one of Hypertext Transfer Protocol (HTTP) and Remote Procedure Call (RPC) protocols. The parsing specification defines the parsing method and configuration data items for each interface type. The above content has the following advantages: 1) Standardization of interface management: The specific composition of interface metadata is clarified, including interface name, version, and configuration data, making interface management more standardized and orderly. This helps improve the identifiability and traceability of interfaces, facilitating effective management and maintenance. 2) Convenience of interface expansion: New interfaces can be obtained by adding new configurations to existing target interfaces, greatly facilitating interface expansion and upgrades. There is no need to redesign the entire interface, saving development time and costs. 3) Strong adaptability and compatibility: By defining communication protocols and corresponding data parsing specifications for different interfaces, it can adapt to various common communication protocols, such as Hypertext Transfer Protocol (HTTP) and Remote Procedure Call (RPC). This enhances the system's ability to interact with different types of external systems or components, improving its compatibility and adaptability. 4) Improved accuracy and efficiency of data parsing: With clear data parsing specifications, interface metadata can be accurately parsed according to the prescribed methods and configuration data items, reducing errors and uncertainties in the data parsing process and improving the efficiency and accuracy of data processing. 5) Guaranteed system stability and reliability: Due to the standardization and normalization of interface configuration and data parsing, the risk of system failure caused by interface configuration errors or abnormal data parsing is reduced, ensuring the stable operation of the system.

[0047] S2. The componentized application initiates an interface call request and passes the interface parameters through the access point;

[0048] S3. Perform dynamic validation of interface parameters based on interface metadata, and implement interface validation after dynamic validation is completed.

[0049] The dynamic verification includes parameter matching, parameter data type verification, parameter range verification, and logical relationship verification between parameters.

[0050] The parameter matching and verification steps are as follows: Obtain the list of parameters passed when calling the interface, and compare it with the list of parameters defined in the interface metadata one by one to check whether the passed parameters are missing or redundant. If they match, continue to the next step of verification.

[0051] The parameter data type validation steps are as follows: Extract the data type of the input parameter and compare it with the type defined in the interface parameter metadata. If the types match, proceed to the next validation step.

[0052] The parameter range verification steps are as follows: obtain the input parameter value, check whether the parameter value is within the range, and if the parameter value is within the range, continue to the next step of verification;

[0053] The steps for verifying the logical relationship between parameters are as follows: obtain all relevant parameter values ​​and verify them according to the logical relationship rules. If the logical relationship is satisfied, the verification passes.

[0054] The dynamic validation of interface parameters based on interface metadata ensures that the interface parameters conform to the definitions in the interface metadata. This offers the following advantages: 1) Improved system stability: Ensures that the input of interface calls meets expectations, reducing system crashes or errors caused by abnormal parameters, thereby improving the stability of the entire componentized application. 2) Enhanced data consistency: Guarantees consistency in format, type, and content of data transmitted by different modules through interfaces, facilitating subsequent data processing and analysis. 3) Enhanced system security: Prevents malicious or erroneous parameter input, reducing the risk of system attacks or security vulnerabilities. 4) Facilitated error troubleshooting and debugging: When interface parameters conform to the definitions, problems are easier to locate and resolve, as parameter mismatch, a common cause of errors, can be ruled out. 5) Promoted inter-module collaboration: Enables smoother data interaction and collaboration between different modules, improving the integration and synergy of the entire system.

[0055] If the verification fails, it means that the requested interface does not exist or the interface call request contains content that violates the interface metadata definition rules.

[0056] All data transmissions are performed using communication protocols.

[0057] During the verification process:

[0058] Parameter matching: Check whether the passed interface parameters match the parameters defined in the metadata, including parameter name, type, quantity, etc.

[0059] Parameter range verification: If the parameter has a specific range or value range requirement, the system will further verify whether the input parameter value falls within this range.

[0060] Parameter type validation: For parameters of type string, date, time, etc., the system will verify whether they conform to the format requirements in the metadata.

[0061] Parameter matching verification: This refers to ensuring that the names and quantities of parameters passed during the API call are consistent with the predefined API requirements. Any mismatch in name or quantity will result in verification failure. The specific verification method includes: obtaining the list of parameters passed during the API call and comparing them one by one with the list of parameters defined in the API metadata to check whether the passed parameters are missing or redundant. If they match, the next step of verification is performed; if they do not match, an error message indicating missing or redundant parameters is returned.

[0062] Parameter data type validation: This ensures that the type of the passed parameter value is consistent with the type defined in the interface. For example, if a parameter should be an integer but a string is passed, the validation will fail. The specific validation method includes: extracting the data type of the passed parameter and comparing it with the type defined in the interface parameter metadata. If the types are consistent, the next step of validation is performed. If they are inconsistent, an error message indicating a type mismatch is returned.

[0063] Parameter range validation: This ensures that the passed parameter value is within a predefined valid range. For example, an integer parameter should be between 0 and 100. If the passed value exceeds this range, the validation will fail. Specific methods include: obtaining the passed parameter value and checking whether it is within the valid range. If it is within the range, the validation continues; otherwise, an error message indicating that it is out of range is returned.

[0064] Parameter logical relationship validation: This ensures that the combination of multiple parameters satisfies a specific logical relationship, such as the start time should be earlier than the end time. Specific validation methods include: obtaining all relevant parameter values ​​and validating them according to the logical relationship rules. If the logical relationship is satisfied, the validation passes; otherwise, an error message is returned indicating that the logical relationship is incorrect.

[0065] For calls to the deployed interfaces, the corresponding interface call requests are received through a unified access point. When changes are needed to the API interfaces provided by the API service provider, only the interface metadata corresponding to the API interface in the API interface data module needs to be changed, and the business logic processing object and / or parameter validation object corresponding to the API interface in the external object encapsulation module needs to be changed. There is no need to modify the unified logic code in the API interface call processing module. Even if API interfaces are frequently added and modified in the system, it will not affect the unified logic code in the API interface call processing module, and will not affect the stability of the entire system corresponding to the API service provider.

[0066] After the API call parameters are passed, if the validation is successful, the complete data format of the component and a success code will be returned. If the parameter validation fails, it may indicate that the requested API interface does not exist in the API service; or, if the validation of the interface parameters fails based on the API parameter definition information in the interface metadata, it may indicate that the interface call request contains content that violates the interface metadata definition rules. Once any of the aforementioned failure scenarios occurs, the processing of the interface call request will be terminated, and the corresponding error information will be returned to the caller.

[0067] The use of components and APIs in this invention can be divided into two types: one type does not require parameters, and the other type requires parameters.

[0068] 1) For types that don't require parameters, first install the API library via npm, then import the API library into your code, and finally configure it via parameters. npm is Node.js's official package manager. Taking a Vue project as an example:

[0069] To install the core functionality specifically designed for Geographic Information Systems (GIS), execute `npm install @TlmGis / core` in the terminal using the npm package manager. It provides basic geospatial data manipulation, map projection, coordinate transformation, spatial analysis, and other functions. Configure the parameters, and then import the `init` method in your code to initialize the map.

[0070] 2) For parameter types, first install the API library via npm, then import the API library into your code, and then import the component as needed. The call is implemented by configuring the component parameters. Taking the coordinate transformation component imported into a Vue project as an example:

[0071] The `npm install @TlmGis / core` module is the core module under the `@TlmGis` namespace, providing basic functions and core algorithms related to Geographic Information Systems (GIS). This type of module includes geospatial data manipulation, coordinate transformation, map projection, and other functions. The `@TlmGis / Comps` module is the component module under the `@TlmGis` namespace, providing GIS-related components or UI components for building visualizations or interactive interfaces for geospatial data in applications. To implement the interface, import `PosTransform` from `@TlmGis / Comps / PosTransform`; add the component `components:{PosTransform}` to the component; this imports the `PosTransform` component from the `@TlmGis / Comps` module. Using `Vue.component('PosTransform', PosTransform)` registers the `PosTransform` component in the Vue instance; this enables interface rendering, while the background displays the verification results.

[0072] Example 2

[0073] This invention proposes an oilfield GIS componentized application programming interface verification system, such as... Figure 2 As shown, it includes an interface configuration module, a data acquisition module, and an interface verification module;

[0074] The interface configuration module is used to set up access points for receiving interface call requests from different modules based on the componentized application. The interfaces of the access points have corresponding interface metadata.

[0075] When an interface needs to be changed, the interface metadata corresponding to the interface in the interface data module is changed, and the business logic processing object and / or parameter validation object corresponding to the interface in the external object encapsulation module is changed, without modifying the logic code in the interface call processing module; the interface is connected to the interface data module and the external object encapsulation module respectively.

[0076] The interface metadata includes the interface name, interface version, and interface configuration data; based on the interface configuration data, the existing target interface is determined, and new configurations are added to the existing target interface to obtain the new interface;

[0077] The interface configuration data specifically includes: determining the interface communication protocol corresponding to each interface, and parsing the interface metadata of each interface according to the data parsing specification corresponding to each interface communication protocol to determine the interface configuration data corresponding to each interface; wherein, the interface communication protocol includes at least one of Hypertext Transfer Protocol and Remote Procedure Call Protocol, and the parsing specification is used to specify the parsing method and configuration data items corresponding to each interface type.

[0078] The data acquisition module is used by the componentized application to initiate interface call requests and pass interface parameters through the access point;

[0079] The interface verification module is used to dynamically verify the interface parameters based on the interface metadata, and the interface verification is completed after the dynamic verification is completed.

[0080] The dynamic verification includes parameter matching, parameter data type verification, parameter range verification, and logical relationship verification between parameters.

[0081] The parameter matching and verification steps are as follows: Obtain the list of parameters passed when calling the interface, and compare it with the list of parameters defined in the interface metadata one by one to check whether the passed parameters are missing or redundant. If they match, continue to the next step of verification.

[0082] The parameter data type validation steps are as follows: Extract the data type of the input parameter and compare it with the type defined in the interface parameter metadata. If the types match, proceed to the next validation step.

[0083] The parameter range verification steps are as follows: obtain the input parameter value, check whether the parameter value is within the range, and if the parameter value is within the range, continue to the next step of verification;

[0084] The steps for verifying the logical relationship between parameters are as follows: obtain all relevant parameter values ​​and verify them according to the logical relationship rules. If the logical relationship is satisfied, the verification passes.

[0085] In the dynamic validation of interface parameters based on interface metadata, the interface parameters conform to the definitions in the interface metadata.

[0086] If the verification fails, it means that the requested interface does not exist or the interface call request contains content that violates the interface metadata definition rules.

[0087] All data transmissions are performed using communication protocols.

[0088] Example 3

[0089] Please see Figure 3As shown, the present invention also provides an electronic device 100 for verifying the application programming interface of an oilfield GIS component; the electronic device 100 includes a memory 101, at least one processor 102, a computer program 103 stored in the memory 101 and executable on the at least one processor 102, and at least one communication bus 104.

[0090] The memory 101 can be used to store the computer program 103. The processor 102 implements the steps of the oilfield GIS component application interface verification method described in Embodiment 1 by running or executing the computer program stored in the memory 101 and calling the data stored in the memory 101. The memory 101 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device 100 (such as audio data), etc. In addition, the memory 101 may include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0091] The at least one processor 102 may be a Central Processing Unit (CPU), or 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 processor 102 may be a microprocessor or any conventional processor. The processor 102 is the control center of the electronic device 100, connecting various parts of the electronic device 100 via various interfaces and lines.

[0092] The memory 101 in the electronic device 100 stores multiple instructions to implement an oilfield GIS component application programming interface verification method, and the processor 102 can execute the multiple instructions to achieve the following:

[0093] The component-based application sets up an access point to receive interface call requests from different modules, and the interface of the access point has corresponding interface metadata.

[0094] Componentized applications initiate API call requests, passing API parameters through the access point;

[0095] Dynamically validate interface parameters based on interface metadata, and then implement interface validation after dynamic validation.

[0096] Example 4

[0097] If the modules / units integrated in the electronic device 100 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, and a read-only memory (ROM).

[0098] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0099] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0100] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0101] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0102] Therefore, the component-based GIS application interface verification method proposed in this invention has the following advantages: 1) Improved production efficiency: Through API interfaces, fast and accurate data exchange is achieved, allowing enterprises to use different systems, platforms, and services for interaction, thereby improving production and management efficiency. 2) Reduced costs: Through API interfaces, enterprises can achieve real-time data exchange and information sharing, avoiding human errors in data input and output, thus reducing costs. 3) Increased service quality: Through API interfaces, enterprises can quickly respond to customer needs and provide the required services in a timely manner, thereby improving service quality and customer satisfaction. 4) Improved data security: API interfaces can achieve secure data transmission and management, preventing data leakage and information loss. 5) API interfaces can adapt to the development needs of HTML5 and front-end / back-end separation frameworks, meet the needs of all Web systems, and solve the problem of application scope and application platform uniformity; the interface calling method can prevent code library pollution, and various original requests and responses are implemented through clear protocol standards. Therefore, the component API interface verification method can greatly solve the problem of poor GIS system stability in oilfield applications due to inconsistent interface standards and the inability to perform interface verification.

[0103] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An oilfield GIS componentized application program interface verification method, characterized in that, The method comprises the following steps: An access point for receiving interface call requests from different modules is set based on the componentized application, and corresponding interface metadata is arranged at the interface of the access point; The componentized application initiates an interface call request and transmits interface parameters through the access point; Dynamic checking of the interface parameters is performed according to the interface metadata, and interface checking is realized after the dynamic checking.

2. The oilfield GIS componentized application program interface verification method of claim 1, wherein, In the dynamic checking of the interface parameters according to the interface metadata, the interface parameters meet the definition in the interface metadata.

3. The oilfield GIS componentized application program interface verification method of claim 1, wherein, When the interface needs to be changed, the interface metadata corresponding to the interface in the interface data module is changed, and the business logic processing object and / or the parameter checking object corresponding to the interface in the external object encapsulation module are changed; the interface is connected with the interface data module and the external object encapsulation module.

4. The oilfield GIS componentized application program interface verification method of claim 1, wherein, The interface metadata comprises an interface name, an interface version and interface configuration data; based on the interface configuration data, an existing target interface is determined, and a new interface is obtained by adding new configuration to the existing target interface based on the existing configuration of the existing target interface; The interface configuration data specifically comprises: determining the interface communication protocol corresponding to each interface, and determining the interface configuration data corresponding to each interface according to the data parsing specification corresponding to each interface communication protocol; wherein the interface communication protocol comprises at least one of a hypertext transfer protocol and a remote procedure call protocol, and the parsing specification is used to define the parsing method corresponding to each interface type and the configuration data item.

5. The oilfield GIS componentized application program interface verification method of claim 1, wherein, The dynamic checking comprises parameter matching, parameter data type checking, parameter range checking and logical relationship checking between parameters.

6. The oilfield GIS componentized application program interface verification method of claim 5, wherein, The parameter matching checking steps are as follows: the parameter list transmitted when the interface is called is obtained, and is compared with the parameter list defined in the interface metadata one by one to check whether the transmitted parameters are missing or redundant, and if matched, the next step of checking is continued; The parameter data type checking steps are as follows: the data type of the transmitted parameter is extracted, and is compared with the type defined in the interface parameter metadata, and if the types are consistent, the next step of checking is continued; The parameter range checking steps are as follows: the value of the transmitted parameter is obtained, and it is checked whether the parameter value is within the value range, and if the parameter value is within the value range, the next step of checking is continued; The logical relationship checking steps between parameters are as follows: all related parameter values are obtained, and are checked according to the logical relationship rules, and if the logical relationship is met, the checking is passed.

7. An oilfield GIS componentized application program interface verification system, characterized by, The method comprises the following steps: An interface configuration module is arranged for setting an access point for receiving interface call requests from different modules based on the componentized application, and corresponding interface metadata is arranged at the interface of the access point; A data acquisition module is arranged for initiating an interface call request by the componentized application and transmitting interface parameters through the access point; An interface checking module is arranged for performing dynamic checking of the interface parameters according to the interface metadata, and realizing interface checking after the dynamic checking.

8. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the steps of the oilfield GIS componentized application interface checking method according to any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8. The computer program, when executed by a processor, implements the steps of the oilfield GIS componentized application program interface verification method according to any one of claims 1-6.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the oilfield GIS componentized application program interface verification method according to any one of claims 1-6.

Images