Interconnection methods, electronic devices and storage media

Abstract

This application proposes a docking method, electronic device, and computer-readable storage medium, applied to a server, which can set a target configuration file for docking between a first client of a business system and a second client of a target system. The generation process of the target configuration file includes: generating a docking task flow based on the obtained configuration file; selecting corresponding atomic components from a preset atomic component library and attaching them to the task nodes of the docking task flow according to the docking task flow to obtain a second task flow; determining the access interface of the target configuration file according to the docking task flow and configuring the access port of the target system into the second task flow; and then packaging the second task flow into the target configuration file. When the first client needs to dock with the second client, it obtains the call request sent by the first client or the second client and calls the access interface to achieve docking between the first client and the second client.

Description

Technical Field

[0001] This invention relates to the field of smart terminal technology, and more specifically to a docking method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In the process of digital transformation in the insurance industry, there is a need for connectivity between different ecosystem partners. For example, a large insurance company may have a stable insurance business system, but the ecosystem partners surrounding the insurance company may be involved in different industries (such as e-commerce, retail, automobile manufacturing, banking, post offices, car rental companies, etc.). During the integration process between the systems of these ecosystem partners and the insurance business system, difficulties often arise due to differences in configuration. For instance, different data file formats may hinder information exchange between the business system and the ecosystem partner's system, making it difficult for the receiving party to read the transmitted files, ultimately leading to integration failure.

[0003] In the process of connecting insurance companies and ecosystem partners, both systems typically have their own data format rules. Connecting these two systems requires mapping one system's data structure to the other's. Understandably, the weaker system usually follows the other's data format rules. For example, if a small insurance company asks a large bank to sell its products, the small insurance company must follow the large bank's data format rules. Similarly, if a large insurance company connects with a small travel agency, with the small travel agency assisting in selling insurance products, the small travel agency must follow the large insurance company's data format rules. While hard-coding can be used to adapt to the other's system, this requires modifying one's own system code. Adjusting system code through hard-coding can have unpredictable impacts on system stability. Therefore, when both parties insist on their own data format rules, it is usually difficult for them to reach an agreement on a connection strategy. All of these situations make system connection and management extremely complex. Summary of the Invention

[0004] This application proposes a docking method, electronic device, and computer-readable storage medium, applied to a server, which can set a target configuration file for docking between a first client of a business system and a second client accessing the system. The generation process of the target configuration file includes: generating a docking task flow based on the obtained configuration file; selecting corresponding atomic components from a preset atomic component library and attaching them to the task nodes of the docking task flow according to the docking task flow to obtain a second task flow; determining the access interface of the target configuration file according to the docking task flow; configuring the access port of the target system into the second task flow; and then packaging the second task flow into the target configuration file. When the first client needs to dock with the second client, it obtains the call request sent by the first or second client and calls the access interface to achieve docking between the first and second clients.

[0005] In a first aspect, embodiments of this application provide a docking method applied to a server. The method includes: obtaining a configuration file; determining a first task flow based on the obtained configuration file; determining an atomic component corresponding to the task content of the first task flow from a preset atomic component library; mounting the atomic component to the first task flow to obtain a second task flow and its access address; encapsulating the second task flow into a target configuration file; obtaining a call request from a first client or a second client to the target configuration file; and completing the docking of the first client and the second client.

[0006] The process involves retrieving a configuration file from the server and determining the first task flow (i.e., the docking task flow) based on this file. Then, atomic components corresponding to the docking tasks in the first task flow are selected from a pre-defined atomic component library and attached to the first task flow. The attached first task flow contains atomic components capable of executing each task node, thus yielding the second task flow (i.e., the target task flow), whose access address is configured. The second task flow is then encapsulated into a target configuration file, for example, a JSON-formatted target configuration file containing all the data information required for the docking process.

[0007] In some embodiments, the access address of the second task flow can be configured as a single access interface exposed by the second task flow. Calling this single access interface can load the docking task corresponding to the second task flow and run the docking task to complete the docking of the first client and the second client.

[0008] Therefore, in obtaining the target configuration file, only the required atomic components need to be selected from the preset atomic component library, eliminating the need for online programming and reducing the difficulty of obtaining the interface files. Furthermore, no code needs to be added locally on the system terminal to be interfaced, thus not affecting the system stability of the interfaced system, nor occupying any local storage or computing resources. This simple implementation can be applied to interface between systems on lightweight terminals (such as wearable devices).

[0009] In one possible implementation of the first aspect above, obtaining the configuration file and determining the first task flow based on the obtained configuration file includes: obtaining the configuration file, wherein the configuration file is used to characterize the docking process between the first client and the second client; and determining the first task flow based on the obtained configuration file.

[0010] This configuration file can be the configuration data that users send to the server through a client used to design the integration process.

[0011] In some embodiments, users can determine the required integration task process of the system to be integrated by answering a questionnaire, and then save the integration task process as a configuration file and store it on the server.

[0012] In one possible implementation of the first aspect above, determining the atomic component corresponding to the task content of the first task flow from the preset atomic component library, and attaching the atomic component to the first task flow to obtain the second task flow includes: selecting one or more required first atomic components from the preset atomic component library according to the task content of each task node in the first task flow; attaching one or more first atomic components to each task node in the first task flow to obtain the second task flow.

[0013] The server can store a pre-defined library of atomic components. This library provides multiple atomic components, each corresponding to a single, minimal function. The docking functionality corresponding to the docking task flow can be achieved by combining these atomic components. Furthermore, the docking task flow can be broken down into multiple task nodes, each with its own docking function, which can be obtained by combining at least one atomic component. Therefore, the server only needs to select the atomic component corresponding to the first task flow from the pre-defined library and sequentially attach the selected atomic component to the first task flow to achieve the docking functionality that the first task flow can execute using at least one atomic component.

[0014] In one possible implementation of the first aspect above, attaching one or more first atomic components to each task node in the first task flow to obtain a second task flow includes: detecting a user's drag operation on an instantiated first atomic component, modifying the attribute parameters of the first atomic component corresponding to the drag operation based on the drag operation, and determining the second task flow based on the modified one or more first atomic components.

[0015] In some embodiments, a visual task flow editing interface can be provided for the terminal used by the user to develop or maintain the interface. This editing interface includes a preset atomic component library area containing icons corresponding to the instantiated atomic components. Users can configure the attribute parameters of the instantiated atomic components by dragging, clicking, or other methods, thereby visually piecing together the icons of the instantiated atomic components to form each task node of the first task flow.

[0016] In one possible implementation of the first aspect above, the method for determining the access address of the second task flow includes: configuring the access interface of the second task flow based on the first atomic component within the second task flow.

[0017] The interface endpoint exposed by the second task flow is the interface call address for the docking request, which can be used to receive data from the access party, such as retrieving policy data. In some implementations, a single access interface can be configured to be exposed to the outside world for one or more access addresses corresponding to one or more first atomic components in the second task flow, so that users can call the single access interface to access one or more first atomic components in the second task flow and run the second task flow to achieve system docking.

[0018] In one possible implementation of the first aspect above, mounting the atomic component to the first task flow to obtain the second task flow further includes: configuring the first access address of the first client and / or the second access address of the second client as the access address of the relevant routing task within the first task flow to obtain the second task flow.

[0019] In other words, during the process of mounting atomic components to the first task flow to obtain the second task flow, the access address of the system to be connected can be configured as the access address of the relevant routing task within the first task flow. This makes it easier to directly access the system to be connected during the execution of the routing task. That is, when the second task flow is run, the routing task can directly access the first client or the second client.

[0020] In one possible implementation of the first aspect above, encapsulating the second task flow into a target configuration file includes: encapsulating the second task flow into a target configuration file in JSON format.

[0021] That is, the second task flow can be encapsulated as a target configuration file in JSON format for easy calling.

[0022] In some embodiments, the server can create a new text document (Docker file) containing all the commands and instructions for creating the image. This document can then package the configured second task flow and all its atomic components into a service (Docker) image and push it to the image repository. Subsequently, a runtime environment site can be selected, and the API deployed by the preset cloud platform can be called to deploy the text document to the runtime site and run it. The gateway's registration API can then be called to register the access interface of the target configuration file with the gateway.

[0023] In other embodiments, each task node in the task flow (i.e., each integration step) that calls the API corresponding to the target configuration file can record log information, which the gateway can then aggregate. Thus, this middleware layer can realize online configuration, verification, packaging, deployment, post-deployment verification, error troubleshooting, and log viewing of system integration interfaces, forming a one-stop online integration platform. This eliminates the need for coding, reduces engineering overhead, and mitigates the inefficiencies associated with hard-coded integration methods.

[0024] In one possible implementation of the first aspect above, the atomic component includes at least: a data rule validation component, a data routing and transmission component, and a data format conversion component.

[0025] That is, an atomic component should include at least data rule validation, data routing and transmission, and data format conversion functions.

[0026] Secondly, embodiments of this application also provide an electronic device, including: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by the one or more processors, cause the electronic device to execute the docking method provided in the first aspect and various possible implementations.

[0027] Thirdly, embodiments of this application also provide a computer-readable storage medium, characterized in that the storage medium stores instructions that, when executed on a computer, cause the computer to perform the docking method provided in the first aspect and various possible implementations described above.

[0028] Fourthly, embodiments of this application also provide a computer program product, characterized in that it includes a computer program / instruction, which, when executed by a processor, implements the interface method provided by the first aspect and various possible implementations described above. Attached Figure Description

[0029] Figure 1 A schematic diagram of system docking is shown;

[0030] Figure 2 A schematic diagram of a system docking scenario is shown according to an embodiment of this application;

[0031] Figure 3 A schematic diagram illustrating the specific implementation process of a docking method is shown in the embodiments of this application;

[0032] Figure 4 A schematic diagram of a scenario for generating a target configuration file in an intermediate layer is shown according to an embodiment of this application;

[0033] Figure 5A A flowchart illustrating a method for obtaining a target configuration file based on an intermediate layer is shown according to some embodiments of this application;

[0034] Figure 5B A schematic diagram of a visual atomic component editing interface is shown according to some embodiments of this application;

[0035] Figure 6 A schematic diagram of a dual-system docking workflow is shown according to an embodiment of this application;

[0036] Figure 7 A block diagram of a server 203 is shown according to an embodiment of this application. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0038] The illustrative embodiments of this application include, but are not limited to, docking methods, electronic devices, and computer-readable storage media.

[0039] It is understood that the electronic device to which this application applies can be a server. The applicable server can be a cloud server, physical server, high-bandwidth server, high-defense server, leased line server, or cluster server, etc., which are leased types of servers. In addition, the applicable server can be a complex instruction set computer (CISC) architecture server or a reduced instruction set computer (RISC) architecture server, without any limitation.

[0040] The following is combined with Figure 1 This paper provides a detailed explanation of scenarios where system integration is achieved through hard coding.

[0041] Figure 1 A schematic diagram of system docking is shown.

[0042] refer to Figure 1 If the insurance company's business system S-1 needs to interface with the bank's access system S-2, a hard-coded interface layer is written in the business system S-1 to enable the data standards of the business system S-1 and the access system S-2 to be compatible, thus ensuring successful interface between the business system S-1 and the access system S-2.

[0043] In some implementations, a hard-coded interface layer can also be written into the bank's access system S-2 to access the insurance company's business system S-1 and obtain its computing engine in order to realize the agency sale of insurance.

[0044] It's understandable that if multiple access systems need to be integrated, different integration layers need to be customized for each system. Furthermore, the code corresponding to the integration layer is often mixed with the business system code. Modifying and maintaining the integration layer code will affect the stability of the business code, and frequent changes in integration requirements can significantly impact the stability of both the business and access systems. For example, if a hard-coded access layer needs to be modified, the code must be pulled to the local storage of the terminal used for development, coded on the terminal, and then submitted, packaged, and released. This overall process of maintaining, modifying, and updating the integration layer is understandably lengthy, resulting in high costs.

[0045] Furthermore, if both systems involved in the connection wish to maintain their own data rules, it will be difficult to achieve the connection process.

[0046] In view of this, to address the complex interfacing issues between the aforementioned business system and the access system, this application proposes an interfacing method applied to the server side. This method allows for setting a target configuration file for interfacing between a first client of the business system and a second client of the access system. The generation process of this target configuration file includes: generating an interfacing task flow (i.e., a first task flow) based on the obtained configuration file; selecting corresponding atomic components from a preset atomic component library and attaching them to the task nodes of the interfacing task flow according to the interfacing task flow to obtain a second task flow; determining the access interface of the target configuration file based on the interfacing task flow; configuring the access port of the target system into the second task flow; and then packaging the second task flow into the target configuration file. When the first client needs to interface with the second client, it obtains a call request sent by either the first or second client and invokes the access interface to achieve interfacing between the first and second clients. It should be understood that the target configuration file is an ordered set of tasks executed during the interfacing process between the first and second clients.

[0047] It should be understood that the target configuration file is decoupled from the code of the first and second clients, and this target configuration file can be written, modified, and maintained independently. For example, assuming that the first client of the business system and the second client accessing the system are set up on different terminals, refer to... Figure 2 The first client 011 of the business system can be located in terminal 201, and the second client 021 of the access system can be located in terminal 202. Corresponding to this docking scenario, the first client 011 and the second client 021 can complete the docking process by remotely communicating with the target configuration file 031 proposed in this embodiment. The target configuration file 031 can be stored in server 203. For example, the second client 021 can call the algorithm logic of the business system S-1 corresponding to the target configuration file 031. Since the code of the target configuration file exists independently and is decoupled from the code of the business system client or the access system client, modifying the target configuration file will not affect the code of the business system or the access system, reducing the cost of maintaining, modifying, and updating the target configuration file.

[0048] In some embodiments, server 203 may include a preset atomic component library, which provides atomic components that implement the above-mentioned functions. For example, it may provide atomic components with data rule validation, data structure transformation, switching, or routing functions. Each component corresponds to one function; that is, a single atomic component corresponds to a single minimum function. This facilitates the design and composition of task flows and makes it easier to reuse and share single functions. For example, a data rule validation function can be instantiated as a reusable atomic component. When reusing this function, simply attach the atomic component to the task node in the task flow that needs to reuse the validation function to add the validation function to the task flow. When a user wants to change the data rule validation function, they only need to modify the atomic component to modify all task nodes in the task flow that use the validation function, saving time and effort.

[0049] It should be understood that the tasks involved in the process of the first client 011 docking with the second client 021 can be constructed based on multiple atomic components. For example, the task flow for docking the first client 011 and the second client 021 can be determined based on the configuration file. Then, the required atomic components can be selected according to the specific tasks of the task flow, and the selected atomic components can be arranged and combined according to the task flow to obtain the target configuration file mentioned above.

[0050] The following is combined with Figure 3 The implementation process of one docking method in the embodiments of this application is described in detail. It can be understood that... Figure 3 The execution entity for each step of the process shown can be server 203. The execution entity for a single step will not be described in detail.

[0051] S301, Get Configuration File.

[0052] For example, the configuration file is used to define the docking task flow between the first client 011 and the second client 021, that is, to define what data processing needs to be performed between the first client 011 and the second client 021 to achieve docking between the two.

[0053] In some embodiments, the configuration file can be configuration data sent by a user to server 203 through a client that designs the integration process. For example, when the first client 011 is an insurance business system and the second client 021 is a banking system, in the scenario where the insurance business system integrates with the banking system, server 203 can obtain the configuration file for integration from other servers or locally on server 203. For example, the configuration file may include a format conversion task for converting the data format of premium data received by the insurance business system into a data format readable by the banking system. When the data format of the premium data is inconsistent with the data format specified by the banking system, server 203 can convert the data format of the premium data into a data format readable by the banking system.

[0054] In some embodiments, users can determine the required docking task flow for the system to be docked by answering a questionnaire, and then save the docking task flow as a configuration file stored on server 203. The questionnaire can provide multiple options for docking tasks, such as: "Is data format conversion required?" Option A is "Yes," and Option B is "No." By collecting user selections on the docking task flow through the questionnaire, the required task flow for the docking system is determined based on the selections, and the above task flow is saved as a configuration file. This configuration file can then generate multiple task nodes in the docking task flow. For example, in the example of the options above, if the user selects option A "Yes," then the docking task flow includes a task node for "data format conversion," facilitating the provision of data format conversion functionality to the docking system.

[0055] S302, determine the docking task flow based on the obtained configuration file.

[0056] For example, server 203 can read the acquired configuration file and determine the docking task flow defined in the configuration file. This docking task flow is an ordered set of docking tasks required when the first client 011 docks with the second client 021. For example, reading the configuration file can determine each task node included in the docking task flow. Each task node corresponds to a single docking task and can execute a portion of the docking functions.

[0057] In some embodiments, the configuration file can be a user-input docking task flow, which defines the docking tasks required for the docking of the first client 011 and the second client 021.

[0058] In other embodiments, the configuration file can be a docking task flow pre-stored by the first client 011 for docking with the second client 021.

[0059] In some other embodiments, the configuration file can be the docking task flow determined by the server 203 based on the configuration data of the first client 011 and the configuration data of the second client 021.

[0060] S303: The corresponding atomic component is mounted from the preset atomic component library to the docking task flow to obtain the target task flow and the corresponding access address.

[0061] For example, server 203 may store a preset atomic component library, which can provide multiple atomic components, each of which is a component corresponding to a single minimum function. The docking function corresponding to the docking task flow can be realized by combining the atomic components.

[0062] In some embodiments, the above-mentioned docking task flow can be divided into multiple task nodes, each task node having a corresponding docking function, which can be obtained by combining at least one atomic component. Therefore, the server 203 only needs to select the atomic component corresponding to the docking task flow from the preset atomic component library, and sequentially mount the selected atomic component into the task flow according to the docking task flow, so that the docking function that the task flow can execute can be realized through at least one atomic component.

[0063] It's understandable that atomic components can have corresponding access addresses, which allows configuring the access addresses for the connected task flows. For example, each atomic component has corresponding processing logic, which needs to be accessed to implement the functionality of the atomic component. Therefore, by attaching atomic components to task nodes, the access addresses of the atomic components, as attribute parameters of the atomic components, can be added to the connected task flow, thereby configuring the target task flow (i.e., the second task flow) and its corresponding access addresses.

[0064] In some embodiments, server 203 can configure a single externally exposed access address for multiple atomic components in the target task flow. For example, it can configure a single API (singular API) for obtaining access requests and the endpoint corresponding to that API for the target task flow. Subsequently, when server 203 detects any system call to the aforementioned single API (i.e., access to the endpoint corresponding to that API), it can run each task node in the docking task flow to achieve inter-system docking processing.

[0065] S304 encapsulates the target task flow into a target configuration file.

[0066] For example, server 203 can encapsulate the target task flow into a target configuration file in a preset format and store it locally on server 203. For instance, server 203 can encapsulate the target task flow into a target configuration file in JavaScript object notation (JSON) format, which describes the data information required for all the docking processes.

[0067] In some embodiments, the target configuration file can be stored in the server 203, so that the first client 011 or the second client 021 can call the target configuration file through a single API.

[0068] In other embodiments, server 203 can configure the access address of the interfaced system into the target task flow. For example, if a banking system wants to access an insurance business system to obtain data related to the insurance business system's computing engine, the banking system can run the target configuration file by calling a single API.

[0069] S305: Obtain the call request for the target configuration file from the first client or the second client, and complete the connection between the first client and the second client.

[0070] It is understood that server 203 can receive a call request from the first client 011 or the second client 021 to access the target task flow address, and run the stored target configuration file based on the call request to realize the connection between the first client 011 and the second client 021.

[0071] In some embodiments, server 203 may run a docking engine, load a target configuration file using the docking engine, and wait for a call request from the first client 011 or the second client 021. If server 203 detects a call request to the singular API, it executes the target configuration file to perform docking processing for the first client 011 and the second client 021.

[0072] It is understood that steps S301 to S305 in this embodiment determine the docking task flow through a configuration file, select atomic components from a preset atomic component library to be mounted into the docking task flow, determine the access address of the docking task flow based on the mounted atomic components, and thus obtain the encapsulated target configuration file. The docking processing for the first client 011 and the second client 021 is then achieved through this target configuration file. It is understood that this target configuration file has the data structure desired by the access party (e.g., the second client 021), can be called by both the first client 011 and the second client 021, and can achieve inter-system docking through a series of call chains corresponding to its encapsulated docking task flow, making it convenient to use.

[0073] Furthermore, obtaining the target configuration file only requires selecting the necessary atomic components from a pre-defined atomic component library, eliminating the need for online programming and reducing the difficulty of obtaining the interface files. Moreover, no code needs to be added locally on terminal 201 where the first client 011 resides or terminal 202 where the second client 021 resides, thus not affecting the system stability of the first client 011 and the second client 021, and requiring no local storage or computing resources. This simple implementation allows it to be applied to inter-system interfaces on lightweight terminals (such as wearable devices).

[0074] In some embodiments, reference Figure 4 Server 203 can provide an intermediate layer 030 for implementing steps S301 to S304 above. This intermediate layer 030 can generate the target configuration file 031 mentioned above based on the configuration file, package and store the target configuration file 031 on server 203, or publish the target configuration file 031 so that the first client 011 and the second client 021 can call the target configuration file 031 for integration. It is understood that the intermediate layer 030 does not affect the first client 011 and the second client 021 participating in the integration process. The intermediate layer 030 can provide functions such as configuring components, verifying and testing components, configuring and verifying task flows, packaging and publishing the target configuration file 031, and / or logging. In other words, the intermediate layer 030 provides users with a one-stop platform for generating the target configuration file 031, effectively reducing the cost waste caused by waiting between different stages in software engineering management. Furthermore, the intermediate layer 030 is easy to integrate with cloud infrastructures, such as serverless cloud infrastructures like Lambda.

[0075] In some embodiments, the middleware 030 can employ cloud-native languages ​​and their open-source frameworks, while also extending the open-source frameworks. The middleware deliverables (e.g., target configuration files) developed through middleware 030 are small in size, typically no larger than 20MB, significantly reducing the consumption of runtime resources.

[0076] The following is combined with Figure 5A and Figure 5B The process of obtaining the target configuration file 031 through the intermediate layer 030 is described in detail.

[0077] Figure 5A A schematic flowchart of a method for obtaining a target configuration file based on an intermediate layer is shown according to some embodiments of this application.

[0078] Understandable. Figure 5A The execution entity for each step of the process shown can be server 203 or intermediate layer 030 provided by service 203. The execution entity for a single step will not be described in detail.

[0079] S501, an online task flow for creating integrated tasks that interface with the computing engine.

[0080] It is understandable that server 203 or the intermediate layer 030 provided by server 203 can create an empty task flow online for integrating tasks of the computing engine of the first client 011, so that at least one docking task in the task flow can be configured according to the configuration file input by the user.

[0081] In some embodiments, the created empty task flow can be instantiated as a visual task flow icon, so that the instantiated atomic components can be attached to the task flow to form a visual docking task flow. It can be understood that the instantiated docking task flow facilitates users to visually add, delete, modify, and query it. Users can quickly modify the docking task flow within the visual editing area provided by server 203, making the modification of the docking task flow intuitive and convenient.

[0082] S502: Obtain the configuration file input by the user and generate the various task nodes of the task flow.

[0083] It is understood that the configuration file can be input by the user through the first client 011 into the server 203 or the intermediate layer 030 provided by the server 203, or by the user through the second client 021 into the server 203 or the intermediate layer 030 provided by the server 203. This configuration file can contain the configuration attributes and parameter information used for connection by the first client 011 or the second client 021. Through this configuration file, the server 203 or the intermediate layer 030 provided by the server 203 can determine the process required for the connection between the first client 011 and the second client 021, and determine the various task nodes in the task flow based on this process. For example, when the first client 011 connects to the second client 021, data rule verification processing is required. Therefore, there will be a data rule verification processing step in the process. The server 203 or the intermediate layer 030 provided by the server 203 adds this processing step to the task flow, forming a task node for data rule verification.

[0084] In some embodiments, server 203 may include a target configuration file editing application for generating target configuration files. This application can provide a target configuration file editing interface for users within the client that designs and develops the integration process. It should be understood that the users can be interface developers or system maintenance personnel. Within the target configuration file editing interface, each task node in the task flow described above can be instantiated and displayed within the editing area of ​​the interface, forming a visual task flow that facilitates user editing of the target configuration file.

[0085] S503 selects the required atomic components from the preset atomic component library and mounts the selected atomic components to each task node.

[0086] For example, after determining the various task nodes in the task flow, the capabilities required to execute each task node can be broken down into at least one minimum functional unit. Based on the determined minimum functional unit, the required atomic components can be selected from a preset atomic component library, and the selected atomic components are mounted into each task node so that at least one atomic component works together to implement the docking function required by the corresponding task node. It should be understood that the task flow at this time becomes an ordered set containing at least one atomic component. The task flow can be executed by calling the above atomic components in sequence to realize the docking processing of the first client 011 and the second client 021.

[0087] It should be understood that all atomic components have tenant and shared attributes in their configuration data. This allows each atomic component to accept data in JSON or Extensible Markup Language (XML) format as input, while the output format can be either JSON or XML. For example, inputting JSON data will yield JSON or XML output data; similarly, inputting XML data will also yield JSON or XML output data. It is understood that the input data for atomic components can be any data conforming to the JSON or XML protocol, and this is not limited here.

[0088] It should be understood that the aforementioned atomic components can provide a variety of functions, and the corresponding processing logic can be diverse, such as validating input data, converting input data formats, and routing input data. The output of atomic components with different functions corresponds to their respective functions. For example, an atomic component used for model conversion can be a converter. In a scenario where the first client 011 is an insurance business system and the second client 021 is a banking system, this converter can be applied to convert the XML protocol data model defined by the Insurance Data Standards Association (ACORD) into the JSON protocol data model required by the premium calculation engine.

[0089] It should be understood that by using the converter as an atomic component to achieve the data format conversion from the ACORD model to the JSON model, the protocol format between the two can be modified without altering the content of the input data. For example, if the address includes street A as input data, the data rule format of "<address value = address1>" and "<street>A" can be changed to ""address":"A"". The delimiters and statement rules change, but the attribute values ​​remain the same, meaning the content is not substantially altered. This allows for interoperability between systems using different data rule formats.

[0090] In other embodiments, the converter can also be used for data structure transformation and field mapping.

[0091] In some embodiments, during the configuration of the atomic components described above, unit testing can be completed through online verification via server 203.

[0092] In some embodiments, atomic components may include various atomic components with different functions such as converters, verifiers, and routers. A preset atomic component library can be used to classify and manage the atomic components with different functions, and a unified page can be provided to users for maintaining atomic components with different functions, so as to facilitate users to generate and maintain the atomic components.

[0093] In some embodiments, the intermediate layer 030 can provide a visual task flow editing interface for the user's terminal used for developing or maintaining interfaces. This editing interface includes a preset atomic component library area containing icons corresponding to the instantiated atomic components. Users can configure the attribute parameters of the instantiated atomic components through dragging, clicking, or other methods, thereby visually piecing together the icons of the instantiated atomic components to form each task node in the task flow.

[0094] refer to Figure 5B The visual atomic component editing interface R provides a preset atomic component library interface area R-1 on the left and an atomic component editing area R-2 on the right. The intermediate layer 030 detects that the user's drag operation on the "Part 1" and "Part 2" icons in R-1 moves them to the atomic component editing area R-2. Based on the user's drag trajectory and the position at the end of the operation, the system determines the value logic of the corresponding component configuration parameters, thereby determining the configuration parameters of "Part 1" and "Part 2". Based on these configuration parameters, "Part 1" and "Part 2" are set within the atomic component to achieve the required functionality. The visualized editing of instantiated atomic component icons facilitates users' maintenance of historical target configuration files.

[0095] It should be understood that the above-mentioned components are modules with finer-grained functionality compared to atomic components, such as components for retrieving dates, comparing two numbers, and assigning values. These components can be used to configure the complete functionality required by the atomic components.

[0096] S504, configure the interface endpoint corresponding to the computing engine in the first client.

[0097] It should be understood that if only atomic components are configured within the docking task flow, only the components used to execute the task nodes can be determined. However, it is also necessary to configure the pusher of the execution results obtained by each execution node. For example, if a task node needs to perform path switching, it is necessary not only to mount the path switching component but also to determine the target path for path switching. Therefore, the interface endpoint of the first client 011 used for access can be configured into the docking task flow, so that when executing the docking task flow, the interface endpoint of the first client 011 can be called to realize data interaction with the first client 011.

[0098] For example, server 203 can determine the interface access address of the computing engine of the first client 011 to be called, i.e., the interface endpoint of the first client 011 to be called, based on each task node in the docking task flow, so as to facilitate the corresponding docking processing using the first client 011 in the task flow. In some embodiments, during the execution of the task flow by server 203, the task flow includes docking processing that switches the path of data in task node 3 to the first client 011 within task node 4. For example, the data obtained from task node 3 is passed to the premium calculation engine of the first client 011 to obtain the return information of the premium calculation engine interface, so as to facilitate the data rule verification processing in subsequent task node 5. Therefore, it is necessary to configure the interface endpoint corresponding to the computing engine of the first client 011 as the attribute parameter of the aforementioned task node 4. It should be understood that, corresponding to the case of configuring the interface endpoint of the premium calculation engine for task node 4, when server 203 executes task node 4, it can send the docking data to the premium calculation engine of the first client 011 by calling the configured interface endpoint to obtain the return information, so as to facilitate the execution of subsequent tasks and realize the inter-system docking processing.

[0099] S505 configures the interface endpoints exposed to the outside world for the entire target task flow.

[0100] It is understandable that the interface endpoints exposed by the target task flow are the interface call addresses for connection requests, which can be used to receive data from the access party, such as obtaining policy data.

[0101] S506 stores the entire target task stream as a target configuration file in JSON format.

[0102] It is understandable that the above target task flow can be packaged into a target configuration file in JSON format and stored locally on server 203, so that when the first client 011 and the second client 021 connect, they can run the target configuration file by calling the singular API to achieve the connection process.

[0103] In some embodiments, server 203 may create a new text document (Docker file) containing all the commands and instructions for creating the image, which can then package the configured target task flow and all atomic components mounted on it into a service (Docker) image and push it to the image repository.

[0104] S507 publishes and registers the target configuration file with the gateway.

[0105] In some embodiments, after packaging the target configuration file into a text image and pushing it to the image repository, a runtime environment site can be selected, the API deployed by the preset cloud platform can be called, the text image can be deployed to the runtime site and run, and the access interface of the target configuration file can be registered with the gateway by calling the gateway's registration API.

[0106] By registering the target configuration file with the gateway, input data from the target task flow can be automatically extracted as API requests, making it easy for users to submit API requests online and call the API corresponding to the target configuration file through the gateway, such as a singular API.

[0107] In some embodiments, each task node in the target task flow (i.e., each docking step) executed by calling the API corresponding to the target configuration file can record log information, which the gateway can summarize after collecting. In some embodiments, the server 203 can provide users with an online query page for querying the recorded log information.

[0108] It is understood that through the above steps S501 to S507, a target configuration file can be constructed on server 203 or the intermediate layer 030 provided by server 203 using atomic components and configuration files, and this target configuration file can be published and registered to the gateway. At this time, the intermediate layer 030 can realize online configuration, verification, packaging, publication, post-publication verification, error troubleshooting, or log viewing of the system interface, forming a one-stop online interface platform. No coding is required, reducing the loss of engineering links and reducing the inefficiency caused by hard-coded interface methods.

[0109] Furthermore, the API exposed by the middle layer 030 can be registered on the gateway, so the connecting party only needs to configure its endpoint for calling the API to complete the connection process, without involving the system code of the two parties, effectively reducing the risk to the systems of the two parties.

[0110] In some embodiments, the aforementioned middleware 030 can employ cloud-native languages ​​and related frameworks, effectively reducing resource consumption, achieving high operating speed, and possessing strong scalability. For example, it can support multi-tenancy mechanisms, allowing reusable atomic components to be shared among tenants, meeting the many-to-many needs of ecosystems in digital connectivity.

[0111] The process of connecting to the application interface is explained in detail below with reference to the relevant attached diagrams.

[0112] Figure 6 A schematic flowchart of a dual-system docking workflow is shown according to an embodiment of this application. It can be understood that... Figure 6The execution entity for each step of the process shown can be server 203 or the intermediate layer 030 provided by server 203. The execution entity for a single step will not be described in detail.

[0113] refer to Figure 6 According to some embodiments of this application, a workflow is designed for a scenario where an insurance brokerage system connects to a premium calculation system. This workflow may include:

[0114] S-1 receives input data from the insurance brokerage system via a singular API, allowing the access party to pass in its request information by calling the API.

[0115] It is understandable that this singular API is a pre-configured target configuration file access interface, which can be identified as the ACORD singular API (BrokerACORDSingularAPI) of the insurance brokerage system.

[0116] S-2: Pass the received request data to an inbound validator. The inbound validator verifies whether the data is valid. If the inbound validator executes successfully, proceed to step S-3.

[0117] The upload validator can be identified as the Insurance Broker System ACORD Validator (BrokerACORDValidator).

[0118] S-3 uses an inbound transformer to convert the data protocol and format passed in by the access party into the data protocol and format expected by the target computing engine.

[0119] For example, this upload converter can be used to convert the request structure of the XML protocol under the ACORD model provided by the insurance brokerage system into the data protocol and data format expected by the target computing engine. This upload converter can be identified as the Insurance Brokerage System ACORD Converter (BrokerACORDTransformer).

[0120] S-4, the router component passes the received, transformed data to the API provided by the premium calculation system's calculation engine and receives the return information from the target calculation engine API. The API provided by the premium calculation system's calculation engine can be identified as "InsureMORatingAPI," and thus, the router component can be identified as "Route toInsureMORatingAPI."

[0121] S-5, Download the outbound validator to validate the return information of the computation engine API. If valid, proceed to step S-6. This outbound validator can be identified as "InsureMORating Validator".

[0122] S-6, the download converter, transforms the information returned by the computing engine API into the data protocol and format expected by the insurance brokerage system. This download converter can be identified as the InsureMORating Transformer.

[0123] It is evident that the connected insurance brokerage system retains its own data structure as the ACORD XML request structure. When calling the ACORD singular API of the insurance brokerage system exposed by the target task flow (i.e., the access interface of the target configuration file generated by the task flow), it still uses its own data structure.

[0124] It is understood that, through steps S-1 to S-6 above, the ACORD singular API of the insurance brokerage system can pass the ACORD XML request data to the ACORD validator component of the insurance brokerage system to verify the legality of the incoming data. If it is invalid, the target task flow stops. If it is valid, the ACORD XML request data continues to be passed to the ACORD converter component of the insurance brokerage system. The ACORD converter component of the insurance brokerage system converts the ACORD XML request into a request format acceptable to the InsureMO Rating API of the premium calculation engine. Then, the converted data is passed to the routing component, which can route the request in the above request format to the InsureMORating API of the target premium calculation engine. It should be understood that the access address of the InsureMORating API can be specified in the task flow through the configuration file. Subsequently, the InsureMO Rating response information returned by the InsureMORating API is passed to the next verification component for verification. If the verification result is valid, it is passed to the next converter component for conversion, converted into an ACORD XML response structure, and returned to the insurance brokerage system.

[0125] Therefore, it can be seen that the data structure returned by the premium calculation engine received by the insurance brokerage system also conforms to the data structure expected by the insurance brokerage system. This fully reuses the ACORD XML request and response structures of the insurance brokerage system. The insurance brokerage system does not need to write new code to adapt to the data format of the premium calculation engine, nor does it need to write code for data validation and transformation. The insurance brokerage system only needs to add a triggering logic for data interaction with the target configuration file. For example, it can pass the ACORD XML request to the task flow corresponding to the target configuration file, which is the singular API exposed by the insurance brokerage system, and receive the returned ACORD XML response. Therefore, using the target configuration file to achieve inter-system integration can effectively avoid impacting the processing of other programs in the systems being integrated.

[0126] Figure 7 A block diagram of a server 203 is shown according to an embodiment of this application. In some embodiments, the server 203 may include one or more processors 804, system control logic 808 connected to at least one of the processors 804, system memory 812 connected to the system control logic 808, non-volatile memory (NVM) 816 connected to the system control logic 808, and network interface 820 connected to the system control logic 808.

[0127] In some embodiments, processor 804 may include one or more single-core or multi-core processors. In some embodiments, processor 804 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments where server 203 employs an evolved node b (eNB) 101 or a radio access network (RAN) controller 102, processor 804 may be configured to perform various corresponding embodiments.

[0128] In some embodiments, system control logic 808 may include any suitable interface controller to provide any suitable interface to at least one of the processors 804 and / or any suitable device or component communicating with system control logic 808.

[0129] In some embodiments, system control logic 808 may include one or more memory controllers to provide an interface to system memory 812. System memory 812 may be used to load and store data and / or instructions. In some embodiments, the memory 812 of server 203 may include any suitable volatile memory, such as suitable dynamic random access memory (DRAM).

[0130] NVM / memory 816 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. In some embodiments, NVM / memory 816 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of a hard disk drive (HDD), a compact disc (CD) drive, and a digital versatile disc (DVD) drive.

[0131] NVM / Storage 816 may include a portion of the storage resources on the device on which Server 203 is installed, or it may be accessible by the device, but is not necessarily part of the device. For example, NVM / Storage 816 may be accessed over a network via Network Interface 820.

[0132] Specifically, system memory 812 and NVM / memory 816 may each include a temporary copy and a permanent copy of instruction 824. Instruction 824 may include instructions that, when executed by at least one of processors 804, cause server 203 to implement the above-described construction method. In some embodiments, instruction 824, hardware, firmware, and / or its software components may additionally / alternatively reside in system control logic 808, network interface 820, and / or processor 804.

[0133] Network interface 820 may include a transceiver for providing a radio interface to server 203, thereby enabling communication with any other suitable device (such as a front-end module, antenna, etc.) via one or more networks. In some embodiments, network interface 820 may be integrated into other components of server 203. For example, network interface 820 may be integrated into at least one of processor 804, system memory 812, NVM / memory 816, and firmware device with instructions (not shown), wherein server 203 implements the above-described docking method when at least one of processor 804 executes instructions.

[0134] The network interface 820 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the network interface 820 may be a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem.

[0135] In one embodiment, at least one of the processors 804 may be packaged together with the logic of one or more controllers for system control logic 808 to form a system-in-package (SiP). In another embodiment, at least one of the processors 804 may be integrated on the same die with the logic of one or more controllers for system control logic 808 to form a system-on-a-chip (SoC).

[0136] Server 203 may further include an input / output (I / O) device 832. The I / O device 832 may include a user interface enabling users to interact with server 203; the peripheral component interface is designed to allow peripheral components to also interact with server 203. In some embodiments, server 203 may also include sensors for determining at least one of environmental conditions and location information related to server 203.

[0137] In some embodiments, the user interface may include, but is not limited to, a display (e.g., a liquid crystal display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., a light-emitting diode flash), and a keyboard.

[0138] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0139] In some embodiments, the sensor may include, but is not limited to, a gyroscope sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of or interact with the network interface 820 to communicate with components of the positioning network (e.g., Global Positioning System (GPS) satellites).

[0140] The embodiments disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0141] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0142] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0143] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0144] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0145] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0146] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0147] Although this application has been illustrated and described with reference to certain embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made thereto without departing from the scope of this application.

Claims

1. A connection method applied to a server-side interface including a middleware layer, characterized in that, The intermediate layer is a target configuration file generation platform, providing at least one of the following functions: configuration components, verification testing of components, configuration and verification of task flows, packaging and publishing of target configuration files, and / or logging functions. The method includes: By obtaining user questionnaire responses or detecting user drag-and-drop operations on instantiated first atomic components, a configuration file is obtained. This configuration file characterizes the interface between a first client and a second client. The first client and the second client each have their own data format rules. The interface process includes a data structure mapped from the first client to the second client. The configuration file contains a format conversion task for converting the data format received by the first client into a data format readable by the second client. The atomic component includes at least: a data rule validation component, a data routing and transmission component, and a data format conversion component. The code between the first client, the second client, and the server is decoupled. Furthermore, the configuration file corresponds to any one of the following: a user-input interface task process, a pre-stored interface task process for interface with the second client by the first client, or an interface task process determined by the server based on the configuration data of the first client and the configuration data of the second client. The first task flow is determined based on the obtained configuration file; The atomic component corresponding to the task content of the first task flow is determined from the preset atomic component library, and the atomic component is mounted to the first task flow to obtain the second task flow and the access address of the second task flow. The second task flow is encapsulated into a target configuration file, and the access interface of the target configuration file is registered to the gateway; Run the docking engine, use the docking engine to load the target configuration file, and wait for a request to call the target configuration file; Upon detecting a request to call the target configuration file from either the first or second client, the target configuration file is executed to complete the connection between the first and second clients.

2. The docking method according to claim 1, characterized in that, The step of determining the atomic component corresponding to the task content of the first task flow from a preset atomic component library, and attaching the atomic component to the first task flow to obtain the second task flow includes: Based on the task content of each task node in the first task flow, select one or more required first atomic components from the preset atomic component library; By attaching one or more of the first atomic components to each task node in the first task flow, a second task flow is obtained.

3. The docking method according to claim 2, characterized in that, The step of attaching one or more of the first atomic components to each task node in the first task flow to obtain the second task flow includes: The user's drag operation on the instantiated first atomic component is detected, and the attribute parameters of the first atomic component corresponding to the drag operation are modified according to the drag operation. The second task flow is determined based on one or more modified first atomic components.

4. The docking method according to claim 3, characterized in that, The method for determining the access address of the second task flow includes: Configure the access interface of the second task flow based on the first atomic component within the second task flow.

5. The docking method according to claim 1, characterized in that, The step of attaching the atomic component to the first task flow to obtain the second task flow further includes: Configure the first access address of the first client and / or the second access address of the second client as the access address of the relevant routing task within the first task flow to obtain the second task flow.

6. The docking method according to claim 1, characterized in that, The encapsulation of the second task flow into a target configuration file includes: The second task flow is encapsulated as a target configuration file in JSON format.

7. The docking method according to claim 1, characterized in that, The atomic components include at least: a data rule verification component, a data routing and transmission component, and a data format conversion component.

8. An electronic device, characterized in that, include: One or more processors; One or more memories; the one or more memories store one or more instructions that, when executed by the one or more processors, cause the electronic device to perform the docking method of any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The storage medium stores instructions that, when executed on a computer, cause the computer to perform the docking method according to any one of claims 1 to 7.

Images