Interconnection method, electronic device and storage medium

Abstract

Provided in the embodiments of the present application are an interconnection method, an electronic device, and a computer-readable storage medium, which are applied to a server side and can set a target configuration file for the interconnection between a first client of a service system and a second client of a target system. A generation process of the target configuration file comprises: on the basis of an acquired configuration file, generating an interconnection task flow of the target configuration file; selecting a corresponding atomic component from a preset atomic component library according to the interconnection task flow, and mounting the same to a task node of the interconnection task flow, so as to obtain a second task flow; determining an access interface of the target configuration file according to the interconnection task flow, configuring an access port of the target system into the second task flow, and then packaging the second task flow as the target configuration file; and, when the first client needs to interconnect with the second client, acquiring a calling request sent by the first client or second client to call the access interface, so as to achieve the interconnection between the first client and the second client.

Description

Docking method, electronic device, and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on October 31, 2023, with application number 202311436165.9 and application name “Docking method, electronic device and storage medium”. The entire contents of the above application are incorporated by reference into this application. Technical Field

[0002] The present invention relates to the technical field of intelligent terminals, and in particular to a docking method, an electronic device, and a computer-readable storage medium. Background Art

[0003] During the digital transformation of the insurance sector, there is a need to connect 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, banks, post offices, car rental companies, etc.). In the process of connecting the systems of these ecosystem partners with the insurance business system, there are often difficulties in connection due to the different configurations of their systems and the insurance business system. For example, different data file formats from the insurance business system can make it difficult for the business system to exchange information with the ecosystem partner's system, and the transferred files are difficult for the recipient to read, ultimately leading to connection failure.

[0004] When integrating with insurance companies and ecosystem partners, each system typically has its own data formatting rules. Interfacing these two systems requires mapping one system to the other's data structure. Understandably, the weaker party's system often adheres to the other's data formatting rules. For example, if a small insurance company entrusts a large bank to sell its products, the smaller insurance company must adhere to the bank's data formatting rules. Another example is if a large insurance company integrates with a small travel company, where the small travel company assists in selling insurance products. Hard-coding the system to adapt to the other party's system is often feasible, but this requires modifying the company's own system code. Hard-coding system code can have unpredictable impacts on system stability. Therefore, when both parties adhere to their own data formatting rules, reaching a consensus on the integration strategy is often difficult. These situations significantly complicate the integration and management of these systems.

[0005] Summary of the Invention

[0006] The embodiment of the present application proposes a docking method, an electronic device and a computer-readable storage medium, which are applied to the server side and can set a target configuration file for docking between the first client of the business system and the second client of the access system. The generation process of the target configuration file includes: generating a docking task flow of the target configuration file based on the acquired configuration file, selecting the corresponding atomic component from the preset atomic component library according to the docking task flow and mounting it into the task node of the docking task flow, obtaining the second task flow, and 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 as a target configuration file. When the first client needs to dock with the second client, the access interface is called by obtaining the call request sent by the first client or the second client, so as to realize the docking of the first client and the second client.

[0007] In the first aspect, an embodiment of the present application provides a docking method, which is applied to the server side. 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 into the first task flow, obtaining a second task flow and an access address of the second task flow; encapsulating the second task flow into a target configuration file; obtaining a call request from the first client or the second client for the target configuration file, and completing the docking of the first client and the second client.

[0008] That is, a configuration file is obtained from the server side, and the first task flow (i.e., the docking task flow) is determined based on the configuration file. Then, the atomic component corresponding to the docking task in the first task flow is selected from the preset atomic component library, and the atomic component is mounted into the first task flow. The mounted first task flow contains the atomic component that can execute each task node, and then the second task flow (i.e., the target task flow) can be obtained, and the access address of the second task flow can be configured. The second task flow is encapsulated as a target configuration file, for example, the second task flow is encapsulated as a target configuration file in JSON format, and the target configuration file describes all the data information required for the docking process.

[0009] 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. The docking task corresponding to the second task flow can be loaded by calling the single access interface, and the docking task can be run to complete the docking of the first client and the second client.

[0010] Therefore, in the process of obtaining the target configuration file, only the required atomic components need to be selected from the preset atomic component library, without the need for online programming, which reduces the difficulty of obtaining the docking file. In addition, there is no need to add any code locally on the system terminal to be docked, which will not affect the system stability of the docking system, nor does it require any local storage resources or local computing resources. The implementation is simple and can be applied to the docking between systems equipped with lightweight terminals (such as wearable devices).

[0011] In a possible implementation of the first aspect, obtaining a configuration file and determining the first task flow based on the obtained configuration file includes: obtaining a configuration file, where the configuration file is used to represent a docking process between the first client and the second client; and determining the first task flow based on the obtained configuration file.

[0012] That is, the configuration file may be configuration data sent by the user to the server via a client for designing a docking process.

[0013] In some embodiments, the user may determine the docking task process required by the system to be docked by answering a questionnaire, and then save the docking task process as a configuration file and store it in the server.

[0014] In a possible implementation of the first aspect above, an atomic component corresponding to the task content of the first task flow is determined from a preset atomic component library, and the atomic component is mounted to the first task flow to obtain a second task flow, including: 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; and mounting one or more first atomic components to each task node in the first task flow to obtain the second task flow.

[0015] That is, a preset atomic component library can be stored in the server, and the preset atomic component library can provide multiple atomic components. Each atomic component is a component corresponding to a single minimum function, and the docking function corresponding to the docking task flow can be realized by combining the atomic components. Furthermore, the docking task flow can be split into multiple task nodes, and each task node corresponds to a corresponding docking function, and the docking function 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 preset atomic component library, and mount the selected atomic component into the first task flow in sequence according to the first task flow, and the docking function that can be executed by the first task flow can be realized through at least one atomic component.

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

[0017] In some embodiments, a visual task flow editing interface can be provided for a user's terminal used to develop or maintain an interface. Within this editing interface, a preset atomic component library interface area is provided, which contains icons corresponding to instantiated atomic components. Users can configure the attribute parameters of the instantiated atomic components by dragging, clicking, or other methods, and then visually splice the icons of the instantiated atomic components into each task node of the first task flow.

[0018] In a possible implementation of the first aspect, the method for determining the access address of the second task flow includes: configuring an access interface of the second task flow based on a first atomic component in the second task flow.

[0019] That is, the interface endpoint exposed by the second task flow is the interface call address of the docking request, which can be used to receive data passed in from the access party, for example, it can be used to obtain insurance policy data. In some embodiments, a single access interface exposed to the outside can be configured 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.

[0020] In a possible implementation of the first aspect above, mounting the atomic component into the first task flow to obtain the second task flow also 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 in the first task flow to obtain the second task flow.

[0021] That is, in the process of mounting the atomic component to the first task flow to obtain the second task flow, the access address of the system to be docked can be configured as the access address of the relevant routing task in the first task flow, so as to facilitate direct access to the system to be docked during the execution of the routing task. That is, when running the second task flow, the routing task can directly access the first client or the second client.

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

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

[0024] In some embodiments, the server can create a new text document (Docker file) that contains all the commands and instructions for the user to create an image. It can then package the configured second task flow and all the atomic components mounted on it into a service (Docker image) and push it to the image repository. Subsequently, it can select a runtime environment site, call the API deployed by the preset cloud platform, deploy the text to the runtime site and run it, and call the gateway's registration API to register the access interface of the target configuration file with the gateway.

[0025] In other embodiments, each task node in the task flow (i.e., each docking step) executed by calling the API corresponding to the target configuration file can record log information, and the gateway can summarize the collected log information. As a result, the middle layer can implement online configuration, verification, packaging, release, post-release verification, error troubleshooting, or log viewing of the system docking interface, forming a one-stop online docking platform that does not require coding, reduces engineering losses, and reduces the inefficiency caused by hard-coded docking methods.

[0026] In a possible implementation of the first aspect above, the atomic components include at least: a data rule verification component, a data routing and delivery component, and a data format conversion component.

[0027] That is, the atomic component at least includes data rule verification function, data routing function and data format conversion function.

[0028] In the second aspect, an embodiment of the present application also provides an electronic device, comprising: one or more processors; one or more memories; one or more memories storing one or more programs, which, when one or more programs are executed by the one or more processors, enables the electronic device to execute the docking method provided in the first aspect and various possible implementations.

[0029] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium, characterized in that instructions are stored on the storage medium, and when the instructions are executed on a computer, the computer executes the docking method provided by the above-mentioned first aspect and various possible implementations.

[0030] In a fourth aspect, an embodiment of the present application further provides a computer program product, characterized in that it includes a computer program / instruction, which, when executed by a processor, implements the docking method provided in the above-mentioned first aspect and various possible implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] FIG1 shows a schematic diagram of a system docking;

[0032] FIG2 shows a schematic diagram of a system docking scenario according to an embodiment of the present application;

[0033] FIG3 shows a schematic diagram of a specific implementation process of a docking method according to an embodiment of the present application;

[0034] FIG4 shows a schematic diagram of a scenario in which an intermediate layer generates a target configuration file according to an embodiment of the present application;

[0035] FIG5A is a schematic flow chart of a method for obtaining a target configuration file based on an intermediate layer according to some embodiments of the present application;

[0036] FIG5B shows a schematic diagram of a visual atomic component editing interface according to some embodiments of the present application;

[0037] FIG6 shows a schematic diagram of a dual-system docking workflow according to an embodiment of the present application;

[0038] FIG7 shows a block diagram of a server 203 according to an embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0040] Illustrative embodiments of the present application include, but are not limited to, docking methods, electronic devices, and computer-readable storage media.

[0041] It can be understood that the electronic device applicable to the present application can be a server, wherein the applicable server can be a cloud server, a physical server, a large bandwidth server, a high-defense server, a dedicated line server or a group server and other rental type servers. In addition, the applicable server can be a complex instruction set computing (CISC) architecture server or a reduced instruction set computing (RISC) architecture server, and there is no restriction here.

[0042] The following describes in detail the scenario of implementing system docking based on hard coding with reference to FIG1 .

[0043] FIG1 shows a schematic diagram of system docking.

[0044] Referring to Figure 1, if the insurance company's business system S-1 needs to be connected to the bank's access system S-2, a hard-coded connection layer is written in the business system S-1 in a hard-coded manner to connect the data standards of the business system S-1 and the access system S-2, ensuring that the business system S-1 and the access system S-2 can be successfully connected.

[0045] In some implementations, a hard-coded docking layer may also be written into the bank's access system S-2 to access the insurance company's business system S-1 to obtain its computing engine, thereby enabling agent sales of insurance.

[0046] It is understandable that if you need to connect to multiple access systems, you need to customize different docking layers for different access systems. In addition, the code corresponding to the docking layer is often mixed with the code of the business system. If you need to modify and maintain the code of the docking layer, it will affect the stability of the business code. Frequent changes in docking requirements will have a significant impact on the stability of both the business system and the access system. For example, if you need to modify the access layer written in a hard-coded manner, you need to pull the code of the access layer to the local storage of the terminal used to develop the system. After the coding is completed in the terminal, the modified access layer code will be submitted, packaged and published. It is understandable that the overall process of maintaining, modifying and updating the docking layer is relatively long, which makes the cost of maintaining, modifying and updating the docking layer relatively high.

[0047] In addition, if both systems want to maintain their own data rules, it will be difficult to achieve docking processing.

[0048] In view of this, in order to solve the problem of complex docking processing between the above-mentioned business system and the access system, an embodiment of the present application proposes a docking method, which is applied to the server side and can set a target configuration file for docking between the first client of the business system and the second client of the access system. The generation process of the target configuration file includes: generating a docking task flow (i.e., a first task flow) of the target configuration file based on the acquired configuration file, selecting the corresponding atomic component from the preset atomic component library according to the docking task flow and mounting it to the task node of the docking task flow, obtaining the second task flow, and 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 as a target configuration file. When the first client needs to dock with the second client, the call request sent by the first client or the second client is obtained to call the access interface, so as to realize the docking of the first client and the second client. It should be understood that the target configuration file is an ordered set of tasks performed during the docking process between the first client and the second client.

[0049] It should be understood that the target configuration file is decoupled from the code of the first client and the second client, and the target configuration file can be independently written, modified, and maintained. For example, assuming that the first client of the business system and the second client of the access system are respectively set in different terminals, referring to Figure 2, the first client 011 of the business system can be set in terminal 201, and the second client 021 of the access system can be set in terminal 202. Corresponding to this docking scenario, the first client 011 and the second client 021 can call the target configuration file 031 proposed in the embodiment of the present application through remote communication to complete the docking process. And the target configuration file 031 can be stored in the 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 above-mentioned target configuration file exists independently and is decoupled from the code of the business system client or the code of the access system client, when the above-mentioned target configuration file is modified, it will not affect the code of the business system or the access system, thereby reducing the cost of maintaining, modifying, and updating the target configuration file.

[0050] In some embodiments, the server 203 may include a preset atomic component library, which may provide atomic components that implement the above functions, such as atomic components with data rule verification function, data structure conversion function, switch function or routing function, each component corresponding to one function, that is, a single atomic component is a component corresponding to a single minimum function, which is beneficial to the design and composition of the task flow, and is convenient for the reuse and sharing of a single function. For example, a data rule verification function is instantiated as a reusable atomic component. When the function is reused, it is only necessary to mount the atomic component on the task node that needs to reuse the verification function in the task flow, and the verification function can be added to the task flow. When the user wants to change the data rule verification function, it is only necessary to modify the atomic component to modify all the task nodes in the task flow that use the verification function, saving time and effort.

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

[0052] The implementation process of a docking method in an embodiment of the present application is described in detail below with reference to Figure 3. It is understood that the execution subject of each step of the process shown in Figure 3 can be the server 203, and the execution subject of a single step will not be described in detail.

[0053] S301, obtain a configuration file.

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

[0055] In some embodiments, the configuration file can be configuration data sent to server 203 by a user through a client that designs the integration process. For example, if the first client 011 is an insurance business system and the second client 021 is a banking system, in a scenario where the insurance business system integrates with the banking system, server 203 can obtain the configuration file for integration from another server 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. If 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.

[0056] In some embodiments, the user can determine the docking task flow required by the system to be docked by answering a questionnaire, and then save the docking task flow as a configuration file and store it in the server 203. The questionnaire can provide multiple options for docking tasks, for example: "Is data format conversion required?" Option A is "Yes" and Option B is "No". The user's selection results for the docking task flow are collected through the questionnaire, and the task flow required for the docking system is determined based on the selection results, and the above-mentioned task flow is saved as a configuration file. The configuration file can generate multiple task nodes in the docking task flow. For example, in the example of the above-mentioned options, if the user selects option A "Yes", it can be determined that the task node "Data format conversion" is included in the docking task flow, which is convenient for providing the data format conversion function for the docking system.

[0057] S302: Determine the docking task flow according to the acquired configuration file.

[0058] For example, the server 203 can read the obtained configuration file and determine the docking task flow defined in the configuration file. The docking task flow is an ordered set of docking tasks required to be performed when the first client 011 and the second client 021 are docked. 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 function.

[0059] In some embodiments, the configuration file may be a docking task process input by a user, which defines the docking tasks required for the first client 011 and the second client 021 to be docked.

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

[0061] In some other embodiments, the configuration file may be a docking task process determined by the server 203 according to the configuration data of the first client 011 and the configuration data of the second client 021 .

[0062] S303: Mount the corresponding atomic component from the preset atomic component library into the docking task flow to obtain the target task flow and the corresponding access address.

[0063] Exemplarily, the server 203 may store a preset atomic component library, which may provide multiple atomic components. Each atomic component is a component corresponding to a single minimum function, and the docking function corresponding to the docking task flow may be realized by combining the atomic components.

[0064] In some embodiments, the docking task flow can be split into multiple task nodes, each of which corresponds to 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 a preset atomic component library and mount the selected atomic component into the task flow in sequence according to the docking task flow, thereby realizing the docking function that the task flow can perform through at least one atomic component.

[0065] It can be understood that the atomic component can have a corresponding access address, thereby configuring the access address of the docking task flow. For example, each atomic component has a corresponding processing logic, and it is necessary to access the processing logic to implement the function corresponding to the atomic component. Therefore, the atomic component is mounted in the task node, and the access address of the atomic component can be added to the docking task flow as an attribute parameter of the atomic component, thereby configuring the target task flow (i.e., the second task flow) and the access address corresponding to the target task flow.

[0066] In some embodiments, server 203 can configure a single, externally exposed access address for multiple atomic components in the target task flow. For example, server 203 can configure a single API (singular API) for obtaining access requests and an endpoint corresponding to the API for the target task flow. Subsequently, upon detecting that any system calls the single API (i.e., accesses the endpoint corresponding to the API), server 203 can execute each task node in the docking task flow to implement inter-system docking processing.

[0067] S304: Encapsulate the target task flow into a target configuration file.

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

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

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

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

[0072] It is understandable that the server 203 can receive a call request from the first client 011 or the second client 021 for the access address of the target task flow, and run the stored target configuration file based on the call request to achieve docking between the first client 011 and the second client 021.

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

[0074] It can be understood that in steps S301 to S305 of the embodiment of the present application, the docking task flow is determined through the configuration file, and the atomic component mounted in the docking task flow is selected from the preset atomic component library, and the access address of the docking task flow is determined according to the mounted atomic component, thereby obtaining the encapsulated target configuration file, and the docking processing of the first client 011 and the second client 021 is implemented through the target configuration file. It can be understood that the target configuration file has the data structure expected by the access party (such as the second client 021), can be called by the first client 011 and the second client 021, and can realize the docking between the systems through a series of call chains corresponding to the encapsulated docking task flow, which is convenient to use.

[0075] Furthermore, in the process of obtaining the target configuration file, only the required atomic components need to be selected from a preset atomic component library, without the need for online programming, which reduces the difficulty of obtaining the docking file. Furthermore, there is no need to add any code locally to the terminal 201 where the first client 011 is located, or the terminal 202 where the second client 021 is located. This does not affect the system stability of the first client 011 and the second client 021, nor does it require the use of any local storage resources or local computing resources. The implementation is simple and can be applied to the docking between systems equipped on lightweight terminals (such as wearable devices, etc.).

[0076] In some embodiments, referring to FIG. 4 , server 203 may provide an intermediate layer 030 for implementing steps S301 to S304. This intermediate layer 030 may generate the target configuration file 031 described above based on the configuration file described above, package and store this target configuration file 031 on server 203, and publish this target configuration file 031 so that the first client 011 and the second client 021 can call this target configuration file 031 for docking. It will be appreciated that this intermediate layer 030 does not affect the first client 011 and the second client 021 involved in the docking process. This intermediate layer 030 may 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, this intermediate layer 030 provides users with a one-stop platform for generating target configuration files 031, effectively reducing the costly wait times caused by interoperability between various links in software engineering management. Furthermore, this intermediate layer 030 facilitates docking with cloud infrastructure, such as serverless cloud infrastructure like Lambda.

[0077] In some embodiments, the middle layer 030 can use cloud-native languages ​​and open source frameworks, while also extending the open source framework. The middle layer deliverables (e.g., target configuration files) developed using the middle layer 030 are small in size, typically no larger than 20MB, significantly reducing runtime resource usage.

[0078] The process of obtaining the target configuration file 031 through the intermediate layer 030 will be described in detail below with reference to FIG. 5A and FIG. 5B .

[0079] FIG5A shows a flow chart of a method for obtaining a target configuration file based on an intermediate layer according to some embodiments of the present application.

[0080] It can be understood that the execution entity of each step of the process shown in Figure 5A can be the server 203 or the intermediate layer 030 provided by the service 203, and the execution entity of a single step will not be described in detail.

[0081] S501, creating a task flow for an integration task for docking with a computing engine online.

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

[0083] In some embodiments, the created empty task flow can be instantiated as a visual task flow icon to facilitate the instantiated atomic components to be mounted in the task flow to form a visual docking task flow. It can be understood that the instantiated docking task flow is convenient for users to visually add, delete, modify, and check it. Users can quickly modify the above docking task flow in the visual editing area provided by the server 203, making the operation of modifying the docking task flow intuitive and convenient.

[0084] S502: Obtain the configuration file input by the user and generate each task node of the task flow.

[0085] It is understood that the configuration file can be input by the user into the server 203 or the intermediate layer 030 provided by the server 203 via the first client 011, or can be input by the user into the server 203 or the intermediate layer 030 provided by the server 203 via the second client 021. This configuration file can include configuration attributes and attribute parameters for the first client 011 to connect, or configuration attributes and attribute parameters for the second client 021 to connect. The server 203 or the intermediate layer 030 provided by the server 203 can use this configuration file to determine the process required for the connection between the first client 011 and the second client 021, and determine the various task nodes of 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. In this case, a data rule verification processing step will be included in the process. The server 203 or the intermediate layer 030 provided by the server 203 will add this processing step to the task flow, forming a task node for data rule verification.

[0086] In some embodiments, server 203 may be provided with a target configuration file editing application for generating a target configuration file. This target configuration file editing application may provide a target configuration file editing interface to the user within the client that designs and develops the docking process. It should be understood that the user may be an interface developer or system maintenance personnel. Within the target configuration file editing interface, each task node within the task flow described above may be instantiated and displayed within the editing area of ​​the editing interface, forming a visual task flow that facilitates user editing of the target configuration file.

[0087] S503: Select the required atomic components from the preset atomic component library, and mount the selected atomic components to each task node.

[0088] For example, after determining each task node of 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 mounted into each task node, so that at least one atomic component cooperates to implement the docking function required by the corresponding task node. It should be understood that the task flow at this point becomes an ordered set containing at least one atomic component. The task flow can be executed by calling the aforementioned atomic components in sequence, thereby achieving docking processing for the first client 011 and the second client 021.

[0089] It should be understood that the configuration data of all atomic components have tenant attributes and whether they are shared attributes. This allows each atomic component to accept data in JSON or extensible markup language (XML) format as input data, and the output format can be either JSON or XML. For example, by inputting input data in JSON format, you can obtain output data in JSON or XML format; by inputting input data in XML format, you can also obtain output data in JSON or XML format. It can be understood that the input data of an atomic component can be any data that complies with the JSON or XML protocol, and this is not limited here.

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

[0091] It should be understood that the data format conversion purpose of converting the ACORD model to the JSON model is achieved through the atomic component of the converter. The protocol format between the two can be modified, and the data content of the input data will not be changed. For example, if the address contains street A as input data, the data rule format of "<address value = address 1>" and "<street> A" can be changed to the data rule format of ""address": "A"". The delimiters and statement expression rules in the statement are changed, but the attribute values ​​do not change, that is, the content does not undergo any substantial change. This allows for docking processing for systems that use different data rule formats.

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

[0093] In some embodiments, during the configuration process of the above atomic components, online verification can be performed through the server 203 to complete unit testing.

[0094] In some embodiments, atomic components may include atomic components with various functions such as converters, validators, routers, etc. The atomic components with different functions mentioned above may be classified and managed through a preset atomic component library, and a unified page for maintaining atomic components with different functions may be provided to users, so as to facilitate users to generate and maintain the above atomic components.

[0095] In some embodiments, the middle layer 030 can provide a visual task flow editing interface for users to develop or maintain interfaces. In this editing interface, a preset atomic component library interface area is provided, which contains icons corresponding to instantiated atomic components. Users can configure the attribute parameters of the instantiated atomic components by dragging, clicking, etc., and then visually splice the icons of the instantiated atomic components into each task node of the docking task flow.

[0096] Referring to Figure 5B, the left side of the visual atomic component editing interface R provides a preset atomic component library interface area R-1, and the right side provides an atomic component editing area R-2. The middle layer 030 detects that the user's drag operation on the "Part 1" icon and the "Part 2" icon in R-1 is to drag "Part 1" and "Part 2" to the atomic component editing area R-2. Then, according to the operation parameters such as the trajectory corresponding to the user's drag operation and the position at the end of the operation, the corresponding component configuration parameter value logic can be determined, and then the configuration parameters of "Part 1" and "Part 2" can be determined. Based on the configuration parameters, "Part 1" and "Part 2" are set in the atomic component to realize the functions required by the atomic component. Visual editing of instantiated atomic component icons facilitates users to maintain historical target configuration files.

[0097] It should be understood that the above components are modules with finer functional granularity than atomic components, such as components for obtaining dates, comparing two numbers, assigning values, etc. The above components can be used to configure the complete functionality required by atomic components.

[0098] S504: Configure the interface endpoint corresponding to the computing engine in the first client.

[0099] It should be understood that if only atomic components are configured in the docking task flow, only the components used to execute the task node 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 execute path switching, it is not only necessary to mount the path switching component, but also to determine the target path of the 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.

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

[0101] S505: Configure the interface endpoints exposed to the outside by the entire target task flow.

[0102] It can be understood that the interface endpoint exposed by the target task flow is the interface call address of the docking request, which can be used to receive data passed in from the access party, for example, it can be used to obtain insurance policy data.

[0103] S506: Save the entire target task flow as a target configuration file in JSON format.

[0104] It is understandable that the above target task flow can be packaged into a target configuration file in JSON format and stored locally on the server 203, so that when the first client 011 and the second client 021 are docked, the target configuration file can be run by calling a singular API to implement docking processing.

[0105] In some embodiments, the server 203 can create a new text document (docker file), which contains all the commands and instructions for the user to create an image, and 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.

[0106] S507: Publish and register the target configuration file to the gateway.

[0107] In some embodiments, after the target configuration file is packaged into a text image and pushed to the image repository, you can select a runtime environment site, call the API deployed by the preset cloud platform, deploy the text to the runtime site and run it, and call the gateway's registration API to register the access interface of the target configuration file to the gateway.

[0108] Since the target profile is registered with the gateway, the input data in the target task flow can be automatically extracted as an API request, making it convenient for users to submit API requests online and call the API corresponding to the target profile through the gateway, such as a singular API.

[0109] In some embodiments, each task node (i.e., each docking step) in the target task flow executed by calling the API corresponding to the target configuration file may record log information, and the gateway may summarize the collected log information. In some embodiments, the server 203 may provide an online query page for the user to query the recorded log information.

[0110] It can be understood that through the above steps S501 to S507, a target configuration file can be constructed using atomic components and configuration files on server 203 or the intermediate layer 030 provided by server 203, and the target configuration file can be published and registered with the gateway. At this time, the intermediate layer 030 can implement functions such as online configuration, verification, packaging, publishing, post-publishing verification, error troubleshooting, and log viewing of the system docking interface, forming a one-stop online docking platform that does not require coding, reduces engineering losses, and reduces the inefficiency caused by hard-coded docking methods.

[0111] Moreover, the API exposed by the middle layer 030 can be registered on the gateway, so the docking party only needs to configure the endpoint for calling the API to complete the docking process, without involving the system codes of the docking parties, effectively reducing the risks of the docking systems of the two parties.

[0112] In some embodiments, the middle layer 030 can utilize cloud-native languages ​​and related frameworks to effectively reduce resource utilization, achieve high speed operation, and enhance scalability. For example, it can support multi-tenancy mechanisms, where reusable atomic components can be shared between tenants, meeting the many-to-many needs of ecosystems in digital connectivity.

[0113] The following describes in detail the process of connecting to the application interface with the relevant drawings.

[0114] Figure 6 shows a schematic diagram of a dual-system docking workflow according to an embodiment of the present application. It is understood that the execution entity of each step of the process shown in Figure 6 can be the server 203 or the intermediate layer 030 provided by the server 203, and the execution entity of a single step will not be repeated.

[0115] Referring to FIG6 , according to some embodiments of the present application, a workflow is designed based on a scenario where an insurance broker system is connected to a premium calculation system. The workflow may include:

[0116] S-1, receiving input data from the insurance brokerage system through a singular API, so that the access party can pass in its request information by calling the API.

[0117] It can be understood that the singular API is a configured target configuration file access interface, which can be identified as the insurance broker system ACORD singular API (Broker ACORD Singular API).

[0118] S-2, passing the received request data to an inbound validator, and verifying whether the incoming data is valid through the inbound validator. If the inbound validator is executed successfully, proceed to step S-3.

[0119] The upload verifier may be identified as an insurance broker system ACORD validator (BrokerACORDValidator).

[0120] S-3, using an inbound transformer to convert the data protocol and data format input by the access party into the data protocol and data format expected by the target computing engine.

[0121] For example, the upload converter is 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. The upload converter can be identified as the insurance brokerage system ACORD converter (BrokerACORDTransformer).

[0122] S-4. The router component passes the converted data to the API provided by the calculation engine of the premium calculation system and receives the response information from the target calculation engine API. The API provided by the calculation engine of the premium calculation system can be identified as "InsureMORatingAPI," and thus the router component can be identified as "Route to InsureMORatingAPI."

[0123] S-5, the outbound validator verifies the return information of the computing engine API, and if it is valid, proceeds to step S-6. The outbound validator can be identified as "InsureMORating Validator".

[0124] S-6, the download converter converts the information returned by the calculation engine API into the data protocol and format expected by the insurance brokerage system. The download converter can be identified as an InsureMORating converter (InsureMORatingTransformer).

[0125] It can be seen from this that the connected insurance brokerage system still retains its own data structure as the ACORD XML request structure. In the process of calling the insurance brokerage system ACORD singular API exposed by the target task flow (that is, the access interface of the target configuration file generated by the task flow), it still uses its own data structure.

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

[0127] As can be seen, the data structure returned by the premium calculation engine to the insurance brokerage system also conforms to the data structure expected by the insurance brokerage system. This fully reuses the insurance brokerage system's ACORD XML request and ACORD XML response structures, eliminating the need for the insurance brokerage system to write new code to adapt to the premium calculation engine's data format, nor does it require code for data validation and conversion. The insurance brokerage system simply needs to add trigger logic for data interaction with the target configuration file. For example, this involves passing the ACORD XML request to the singular API exposed by the insurance brokerage system, whose task flow corresponds to the target configuration file, and receiving the response in ACORD XML response format. Therefore, using the target configuration file to achieve inter-system integration effectively avoids impacting other program processing on both systems.

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

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

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

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

[0132] 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.

[0133] NVM / storage 816 may include a portion of storage resources on the device where server 203 is installed, or it may be accessible to the device but not necessarily part of the device. For example, NVM / storage 816 may be accessed over a network via network interface 820 .

[0134] In particular, system memory 812 and NVM / storage 816 may include, respectively, a temporary copy and a permanent copy of instructions 824. Instructions 824 may include instructions that, when executed by at least one of processors 804, cause server 203 to implement the aforementioned construction method. In some embodiments, instructions 824, hardware, firmware, and / or software components thereof may additionally or alternatively reside in system control logic 808, network interface 820, and / or processor 804.

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

[0136] 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.

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

[0138] Server 203 may further include input / output (I / O) devices 832. I / O devices 832 may include a user interface to enable a user to interact with server 203; peripheral component interfaces may also be designed to enable peripheral components to 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.

[0139] In some embodiments, the user interface may include, but is not limited to, a display (e.g., an LCD 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., an LED flash), and a keyboard.

[0140] 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.

[0141] In some embodiments, the sensors may include, but are 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 a positioning network (e.g., Global Positioning System (GPS) satellites).

[0142] The various embodiments disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program or program code executed on a programmable system, which includes 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.

[0143] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For purposes of this application, a 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.

[0144] Program code can be implemented with a high-level programming language or an object-oriented programming language to communicate with the processing system. Where necessary, program code can also be implemented in assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0145] 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 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 over a network or through other computer-readable media. Therefore, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including but not limited to floppy disks, optical disks, optical discs, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagation signals. Therefore, a machine-readable medium includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0146] In the accompanying drawings, some structural or method features may be shown in a particular arrangement and / or order. However, it should be understood that such a particular arrangement and / or order may not be required. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. In addition, the inclusion of a structural or method feature in a particular figure does not imply that such feature is required in all embodiments, and in some embodiments, such features may not be included or may be combined with other features.

[0147] It should be noted that the units / modules mentioned in the various device embodiments of the present application are all logical units / modules. Physically, a logical unit / module can be a physical unit / module, or a part of a physical unit / module, or can be implemented as a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important. The combination of functions implemented by these logical units / modules is the key to solving the technical problems raised by this application. In addition, in order to highlight the innovative part of this application, the above-mentioned device embodiments of this application do not introduce units / modules that are not closely related to solving the technical problems raised by this application. This does not mean that other units / modules do not exist in the above-mentioned device embodiments.

[0148] It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "including a" does not exclude the presence of other identical elements in the process, method, article or device that includes the element.

[0149] While the present application has been shown and described with reference to certain embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the present application.

Claims

1. A docking method, applied to a server, characterized in that: The method comprises: Obtaining a configuration file, and determining a first task flow according to the obtained configuration file; Determine an atomic component corresponding to the task content of the first task flow from a preset atomic component library, mount the atomic component into the first task flow, and obtain a second task flow and an access address of the second task flow; Encapsulating the second task flow as a target configuration file; A call request for the target configuration file from the first client or the second client is obtained, and the connection between the first client and the second client is completed.

2. The docking method according to claim 1, characterized in that: The step of obtaining a configuration file and determining a first task flow according to the obtained configuration file includes: Obtaining a configuration file, wherein the configuration file is used to characterize a connection process between the first client and the second client; A first task flow is determined according to the acquired configuration file.

3. The docking method according to claim 1, characterized in that: The step of determining an atomic component corresponding to the task content of the first task flow from a preset atomic component library, and mounting the atomic component to the first task flow to obtain a 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; One or more of the first atomic components are mounted to each task node in the first task flow to obtain a second task flow.

4. The docking method according to claim 3, characterized in that: The step of mounting one or more of the first atomic components to each task node in the first task flow to obtain a second task flow includes: Detecting a user's dragging operation on the instantiated first atomic component, and modifying attribute parameters of the first atomic component corresponding to the dragging operation according to the dragging operation; The second task flow is determined based on the modified one or more first atomic components.

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

6. The docking method according to claim 1, characterized in that: The step of mounting the atomic component into the first task flow to obtain the second task flow further includes: The first access address of the first client and / or the second access address of the second client are configured as access addresses of relevant routing tasks in the first task flow to obtain a second task flow.

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

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

9. 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, and when the one or more instructions are executed by the one or more processors, the electronic device executes the docking method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The storage medium stores instructions, which, when executed on a computer, enable the computer to execute the docking method according to any one of claims 1 to 8.

Images