WO2025091762A1 - Interconnection method, electronic device and storage medium - Google Patents

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

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

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

During the digital transformation of the insurance sector, there is a need for connections between different ecological partners. For example, a large insurance company may have a stable insurance business system, but the ecological 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 the above ecological partners with the insurance business system, it is often difficult to connect due to the different configurations of their systems and the insurance business system. For example, having a different data file format from the insurance business system can make it difficult for the business system to interact with the ecological partner's system, and the transmitted files are difficult to be read by the recipient, which ultimately leads to a connection failure.

In the process of docking between insurance companies and ecological partners, the systems of insurance companies and ecological partners usually have their own data format rules, and the docking of the two systems requires the system of one party to be mapped to the data structure of the other party's system. It can be understood that the weaker party's system usually follows the data rule format of the other party. For example, if a small insurance company asks a large bank to sell products on its behalf, the small insurance company needs to follow the data rule format of the large bank. For another example, if a large insurance company docks with a small travel company, and the small travel company assists in selling insurance products, the small travel company needs to follow the data rule format of the large insurance company. Usually, hard coding can be used to adapt to the other party's system, but this requires modifying the system code itself. Adjusting the system code through hard coding will have unpredictable effects on system stability. Therefore, for situations where both parties insist on their own data rule formats, it is usually difficult for both parties to reach an agreement on the docking strategy. The above situations will make the docking and management between systems very complicated.

Summary of the invention

The embodiments of the present application propose 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 a first client of a business system and a second client of an 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 a corresponding atomic component from a preset atomic component library according to the docking task flow and mounting it to a task node of the docking task flow, obtaining a second task flow, and determining an 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 as a target configuration file. When the first client needs to dock with the second client, the first client or the second client is obtained. The call request sent by the second client calls the access interface, thereby realizing the connection between the first client and the second client.

In the first aspect, an embodiment of the present application provides a docking method, which is applied to the server side, and 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, 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 to the target configuration file, and completing the docking of the first client and the second client.

That is, a configuration file is obtained from the server, and the first task flow (i.e., docking task flow) is determined according to the configuration file, and 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 to the first task flow. The mounted first task flow contains atomic components that can execute each task node, and then the second task flow (i.e., 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.

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.

Therefore, in the process of obtaining the target configuration file, it is only necessary to select the required atomic components 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 in the system terminal to be docked, which will not affect the system stability of the system to be docked, nor does it need to occupy any local storage resources and local computing resources. It is simple to implement and can be applied to the docking between systems equipped with lightweight terminals (such as wearable devices, etc.).

In a possible implementation of the first aspect, obtaining a configuration file and determining the first task flow according to the obtained configuration file includes: obtaining the configuration file, wherein the configuration file is used to characterize a connection process between the first client and the second client; and determining the first task flow according to the obtained configuration file.

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

In some embodiments, the user can 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.

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 in 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; mounting one or more first atomic components to each task node in the first task flow to obtain the second task flow.

That is, the server 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. Furthermore, the docking task flow may be split into multiple task nodes, and each task node may correspond to a corresponding docking function, which may 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 then the docking function may be realized through at least one atomic component. The atomic component implements the docking function that can be performed by the first task flow.

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.

In some embodiments, a visual task flow editing interface can be provided for a terminal used by a user to develop or maintain an interface, in which a preset atomic component library interface area is provided, and the interface area contains icons corresponding to instantiated atomic components. The user can configure the attribute parameters of the instantiated atomic components by dragging, clicking, etc., and then visualize the icons of the instantiated atomic components as each task node of the first task flow.

In a possible implementation of the first aspect, 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 in the second task flow.

That is, the interface endpoint exposed to the outside 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.

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.

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 connected 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 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.

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.

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

In some embodiments, the server can create a new text document (docker file), which contains all the commands and instructions for the user to create an image, and then the configured second task flow and all the atomic components mounted on it can be packaged as a service (docker image) and pushed to the image warehouse. Then, you can select the runtime environment site, call the preset cloud platform deployment API, deploy the text to the runtime site and run it, and call the gateway registration API to register the access interface of the target configuration file to the gateway.

In other embodiments, each task node (i.e., each docking step) in the task flow executed by calling the API corresponding to the target configuration file can record log information, and the gateway can summarize the log information after collecting it. Thus, the middle layer can realize the online configuration, verification, packaging, publishing, post-publishing verification, error troubleshooting or log viewing of the system docking interface, forming a one-stop online docking platform without coding, reducing the loss of engineering links and the inefficiency caused by hard-coded docking methods.

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

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

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, when one or more programs are executed by the one or more processors, the electronic device executes the docking method provided by the first aspect and various possible implementations.

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.

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 by the above-mentioned first aspect and various possible implementations.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows a schematic diagram of a system docking;

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

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

FIG4 is a schematic diagram showing a scenario in which a middle layer generates a target configuration file according to an embodiment of the present application;

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

FIG5B shows a schematic diagram of a visualized atomic component editing interface according to some embodiments of the present application;

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

FIG. 7 shows a block diagram of a server 203 according to an embodiment of the present application.

DETAILED DESCRIPTION

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 in conjunction with the accompanying drawings and specific implementation methods.

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

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 limitation here.

The following describes in detail the scenario of implementing system docking based on hard coding in conjunction with FIG. 1 .

FIG1 shows a schematic diagram of a system docking.

Referring to Figure 1, 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, thereby ensuring that the business system S-1 and the access system S-2 can be successfully connected.

In some embodiments, 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 obtains its computing engine to implement agent sales of insurance.

It is understandable that if multiple access systems need to be connected, different connection layers need to be customized for different access systems. In addition, the code corresponding to the connection layer is often mixed with the code of the business system. If the code of the connection layer needs to be modified and maintained, it will affect the stability of the business code. Frequent changes in connection 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 connection layer is relatively long, which makes the cost of maintaining, modifying and updating the connection layer relatively high.

In addition, if both systems want to maintain their own data rules, it will be difficult to achieve the docking process.

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 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. 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.

It should be understood that the target configuration file is decoupled from the codes 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 the terminal 201, and the second client 021 of the access system can be set in the 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 modifying the above-mentioned target configuration file, it will not affect the code of the business system or the access system, thereby reducing the cost of maintenance, modification and update of the target configuration file.

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 providing atomic components with data rule verification function, data structure conversion function, switch function or routing function, each component corresponds to a function, that is, a single atomic component is a component corresponding to a single minimum function, which is conducive 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 achieve the modification of all task nodes in the task flow that use the verification function, saving time and effort.

It should be understood that the tasks involved in the process of docking the first client 011 to the second client 021 can be pieced together based on multiple atomic components. For example, the tasks for docking the first client 011 and the second client 021 can be determined based on the configuration file. The task flow of the client 021 can then select the required atomic components according to the specific tasks of the task flow, and can arrange and combine the selected atomic components according to the task flow to obtain the above-mentioned target configuration file.

The implementation process of a docking method in the embodiment of the present application is described in detail below in conjunction with Figure 3. It can be 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 repeated.

S301, obtaining a configuration file.

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 the docking between the two.

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

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 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 options, if the user selects option A "Yes", it can be determined that the task node containing "data format conversion" is included in the docking task flow, which is convenient for providing the docking system with a data format conversion function.

S302: Determine a docking task flow according to the acquired configuration file.

Exemplarily, the server 203 can read the acquired configuration file and determine the docking task flow defined in the configuration file, where the docking task flow is an ordered set of docking tasks required to be performed when the first client 011 is docked with the second client 021. For example, reading the configuration file can determine each task node included in the docking task flow, and each task node corresponds to a single docking task and can execute a portion of the docking function.

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.

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

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

S303, mounting the corresponding atomic component from the preset atomic component library into the docking task flow, and obtaining the target task flow and the corresponding access address.

For example, 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. The combination of subcomponents realizes the docking function corresponding to the docking task flow.

In some embodiments, the docking task flow can be split into multiple task nodes, each of which has 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 mount the selected atomic component into the task flow in sequence according to the docking task flow, so as to realize the docking function that can be executed by the task flow through at least one atomic component.

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 the processing logic needs to be accessed 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.

In some embodiments, the server 203 may configure a single externally exposed access address for multiple atomic components in the target task flow, for example, configuring a single API (singular API) for obtaining access requests and the endpoint corresponding to the API for the target task flow. Then, when the server 203 detects that any system calls the above single API (i.e., accesses the endpoint corresponding to the API), it may run each task node in the docking task flow to implement inter-system docking processing.

S304, encapsulating the target task flow into a target configuration file.

Exemplarily, the server 203 may encapsulate the target task flow into a target configuration file in a preset format and store it locally in 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, and the target configuration file describes all data information required for the docking process.

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 may subsequently call the target configuration file through a single API.

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

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.

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 of the first client 011 and the second client 021.

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 the singular API, it executes the target configuration file to implement docking processing for the first client 011 and the second client 021.

It can be understood that in the 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, and then the encapsulated target configuration file is obtained, and the docking process of the first client 011 and the second client 021 is realized through the target configuration file. It can be understood that the target configuration file It 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 achieve docking between systems through a series of call chains corresponding to the docking task flow encapsulated therein, which is convenient to use.

In addition, in the process of obtaining the target configuration file, it is only necessary to select the required atomic components from the preset atomic component library, without online programming, which reduces the difficulty of obtaining the docking file. In addition, there is no need to add any code locally in the terminal 201 where the first client 011 is located or the terminal 202 where the second client 021 is located, which will not affect the system stability of the first client 011 and the second client 021, and there is no need to occupy any local storage resources and local computing resources. The implementation is simple and can be applied to the docking between systems carried by lightweight terminals (such as wearable devices, etc.).

In some embodiments, referring to FIG. 4 , the server 203 may provide an intermediate layer 030 for implementing the above steps S301 to S304. The intermediate layer 030 may generate the target configuration file 031 mentioned above according to the configuration file mentioned above, and package and store the target configuration file 031 in the server 203. The target configuration file 031 may also be published so that the first client 011 and the second client 021 may call the target configuration file 031 for docking. It can be understood that the intermediate layer 030 does not affect the first client 011 and the second client 021 involved in the docking process. The intermediate layer 030 may provide functions such as configuration components, verification testing of components, configuration and verification of task flows, packaging and publishing of the target configuration file 031, and/or logging. That is, the intermediate layer 030 provides users with a one-stop generation platform for the target configuration file 031, which effectively reduces the cost waste caused by waiting for each link in software engineering management. In addition, the intermediate layer 030 is easy to dock with cloud infrastructure, such as serverless cloud infrastructure such as lambda.

In some embodiments, the middle layer 030 can use cloud native language and its open source framework, and expand the open source framework. The middle layer deliverable (such as target configuration file) developed by the middle layer 030 is small in size, usually no more than 20MB, which greatly reduces the occupation of runtime resources.

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

FIG5A shows 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.

It can be understood that the execution subject 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 subject of a single step will not be described in detail.

S501, creating a task flow of an integration task for docking with a computing engine online.

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 integrating tasks for 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.

In some embodiments, the created empty task flow can be instantiated as a visual task flow icon, so that the instantiated atomic component can 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. The user 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.

S502, obtaining a configuration file input by a user, and generating each task node of a task flow.

It is understood that the configuration file can be input by the user through the first client 011 to the server 203 or the intermediate layer 030 provided by the server 203, or can be input by the user through the second client 021 to the server 203 or the intermediate layer 030 provided by the server 203. The intermediate layer 030 provided. The configuration file can be the configuration attributes and attribute parameters used by the first client 011 for docking, or can be the configuration attributes and attribute parameters used by the second client 021 for docking. The server 203 or the intermediate layer 030 provided by the server 203 can determine the process required for the first client 011 and the second client 021 to dock through the configuration file, and determine each task node of the task flow based on the process. For example, when the first client 011 is connected to the second client 021, data rule verification processing is required, and 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 the processing step to the task flow, which can form a task node for data rule verification.

In some embodiments, a target configuration file editing application for generating a target configuration file may be provided in the server 203, and the target configuration file editing application may provide a target configuration file editing interface for the user in the client of the user designing and developing the docking process. It should be understood that the above-mentioned user may be an interface developer or a system maintenance personnel. In the target configuration file editing interface, each task node in the task flow described above may be instantiated and displayed in the editing area of the above-mentioned editing interface, forming a visual task flow, which is convenient for the user to edit the target configuration file.

S503, selecting a required atomic component from a preset atomic component library, and mounting the selected atomic component to each task node.

Exemplarily, after determining each task node of the task flow, the capability required to execute each task node can be split into at least one minimum functional unit, and the required atomic components can be selected from the preset atomic component library according to the determined minimum functional unit, and the selected atomic components can be mounted in each task node, so that at least one atomic component cooperates to realize 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, and 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.

It should be understood that the configuration data of all atomic components have tenant attributes and whether they are shared attributes. As a result, each atomic component can accept data in JSON or extensible markup language (XML) format as input data, and the output format can be any one of JSON or XML. For example, by inputting input data in JSON format, output data in JSON or XML format can be obtained; by inputting input data in XML format, output data in JSON or XML format can also be obtained. 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 is not limited here.

It should be understood that the above-mentioned atomic components can provide a variety of functions, and the processing logic corresponding to the function can be diversified, for example, it can verify input data, convert input data format, input data routing processing, etc. 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. Then, in the docking scenario where the first client 011 is an insurance business system and the second client 021 is a bank system, the converter can be applied to convert the XML protocol data model formulated by the Association for Insurance Data Standards (ACORD) into the JSON protocol data model required by the premium calculation engine.

It should be understood that the data format conversion purpose of converting the above-mentioned 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 are not changed, that is, the content has not changed substantially. This enables docking processing for systems that apply different data rule formats.

In other embodiments, the converter may also be used for data structure conversion and field mapping processing.

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

In some embodiments, atomic components may include atomic components with various functions such as converters, verifiers, routers, etc. The atomic components with the above-mentioned different functions 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-mentioned atomic components.

In some embodiments, the middle layer 030 can provide a visual task flow editing interface for the terminal used by the user to develop or maintain the interface. In the editing interface, a preset atomic component library interface area is set, and the interface area contains icons corresponding to the instantiated atomic components. The user can configure the attribute parameters of the instantiated atomic components by dragging, clicking, etc., and then visualize the icons of the instantiated atomic components as each task node of the docking task flow.

Referring to FIG5B , 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 dragging 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. The value logic of the corresponding component configuration parameters can be determined according to the operation parameters such as the trajectory corresponding to the user's dragging operation and the position at the end of the operation, and then the configuration parameters of "Part 1" and "Part 2" are determined, and 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.

It should be understood that the above parts are modules with finer functional granularity than atomic components, such as a part for obtaining a date, a part for comparing two numbers, a part for assigning a value, etc. The above parts can be used to configure the complete functions required by the atomic components.

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

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 result 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 necessary 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 the interface endpoint of the first client 011 can be called when executing the docking task flow to realize data interaction with the first client 011.

Exemplarily, the server 203 can determine the interface access address of the calculation engine of the first client 011 that needs to be called according to each task node in the docking task flow, that is, the interface endpoint of the first client 011 that needs to be called, so as to facilitate the corresponding docking processing using the first client 011 in the task flow. In some embodiments, during the process of the server 203 executing the task flow, the task flow includes the docking processing of switching the data in the task node 3 to the first client 011 in the task node 4, for example, passing the data obtained by the task node 3 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 the subsequent task node 5. Therefore, it is necessary to configure the interface endpoint corresponding to the calculation engine of the first client 011 as the attribute parameter of the above-mentioned task node 4. It should be understood that corresponding to the case of configuring the interface endpoint of the premium calculation engine for the task node 4, when the server 203 executes the task node 4, it can send the docking data to the premium calculation engine of the first client 011 by calling the above-mentioned configured interface endpoint to obtain the return information, so as to facilitate the execution of subsequent tasks and realize the docking processing between systems.

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

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.

S506, saving the entire target task flow as a target configuration file in JSON format.

It can be understood that the above-mentioned 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 the singular API to implement the docking process.

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 can 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.

S507, publish and register the target configuration file to the gateway.

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 preset cloud platform deployment API, deploy the text to the runtime site and run it, and call the gateway's registration API to register the target configuration file's access interface to the gateway.

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

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 can be recorded with log information, and the gateway can summarize the above log information after collecting it. In some implementations, the server 203 can provide users with an online query page for users to query the recorded log information.

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

Furthermore, 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 two docking parties, effectively reducing the risks of the systems of the two docking parties.

In some embodiments, the middle layer 030 can use cloud native languages and related frameworks to effectively reduce resource utilization, run fast, and have strong expansion capabilities. For example, it can support multi-tenant mechanisms, and reusable atomic components can be shared between tenants to meet the many-to-many needs between ecosystems in digital connections.

The process of docking the application interface is described in detail below with reference to the relevant drawings.

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

Referring to FIG. 6 , according to some embodiments of the present application, a workflow is designed based on a scenario in which an insurance broker system is connected to a premium calculation system. The workflow may include:

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.

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).

S-2, pass the received request data to an inbound validator, and use the inbound validator to verify whether the incoming data is valid. If the inbound validator is executed successfully, continue to step S-3.

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

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

For example, the upload converter is used to convert the request structure of the XML protocol under the ACORD model provided by the insurance broker system into the data protocol and data format expected by the target computing engine. The upload converter can be identified as the insurance broker system ACORD converter (BrokerACORDTransformer).

S-4, the router component passes the received converted data to the API provided by the calculation engine of the premium calculation system, and receives the return information of 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".

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

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 InsureMORating Transformer.

It can be seen that the connected insurance brokerage system still retains its own data structure as the ACORD XML request structure. It still uses its own data structure when 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 can be understood that through the above steps S-1 to S-6, the insurance brokerage system ACORD singular API can pass the ACORD XML request data to the insurance brokerage system ACORD validator component to verify the legality of the incoming data. If it is not legal, the target task flow stops. If it is legal, the ACORD XML request data will continue to be passed to the insurance brokerage system ACORD converter component, and the insurance brokerage system ACORD converter component will convert the ACORD XML request into a request format acceptable to the premium calculation engine InsureMO Rating API. 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. Then, the InsureMO Rating response information returned by the InsureMORating API will be passed to the next verification component for verification. Corresponding to the legality of the verification result, it will be passed to the next converter component for conversion, converted into an ACORD XML response structure and returned to the insurance brokerage system.

It can be seen that the data structure returned by the premium calculation engine received by the insurance brokerage system also complies with the data structure expected by the insurance brokerage system. In this way, the ACORD XML request structure and ACORD XML response structure of the insurance brokerage system are fully reused. 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 to do data verification and data conversion. The insurance brokerage system only needs to add a The trigger logic for data interaction with the target configuration file, for example, sends 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 receives the return in the ACORD XML response format. Therefore, the application of the target configuration file to achieve inter-system docking can effectively avoid the impact on other program processing of the docking systems.

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.

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 special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In an embodiment where the server 203 uses an enhanced base station (evolved node b, eNB) 101 or a radio access network (radio access network, RAN) controller 102, the processor 804 may be configured to execute various embodiments that comply with the present invention.

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 .

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).

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.

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

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 above-described construction method. In some embodiments, instructions 824, hardware, firmware, and/or software components thereof may be additionally/alternatively placed in system control logic 808, network interface 820, and/or processor 804.

The network interface 820 may include a transceiver for providing a radio interface for the server 203, and then communicating with any other suitable device (such as a front-end module, an antenna, etc.) through 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 with instructions (not shown in the figure), and when at least one of the processors 804 executes the instructions, the server 203 implements the above-mentioned docking method.

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

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).

The server 203 may further include an input/output (I/O) device 832. The I/O device 832 may include a user interface to enable a user to interact with the server 203; and a peripheral component interface design to enable peripheral components to interact with the server 203. In some embodiments, the server 203 further includes a sensor for determining at least one of an environmental condition and location information related to the server 203.

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.

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.

In some embodiments, the sensors may include, but are not limited to, gyroscope sensors, accelerometers, proximity sensors, ambient light sensors, and positioning units. 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).

The various embodiments disclosed in the present application may be implemented in hardware, software, firmware, or a combination of these implementation methods. The embodiments of the present application may be implemented as a computer program or program code executed 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.

Program code can be applied to input instructions to perform 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, 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.

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

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, instructions may be distributed over a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, floppy disks, optical disks, optical disks, 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. Accordingly, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

In the accompanying drawings, some structural or method 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 required. Instead, 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 structural or method features in a particular figure does not mean that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.

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 method 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 proposed by the present application. In addition, in order to highlight the innovative part of the present application, the above-mentioned device embodiments of the present application do not introduce units/modules that are not closely related to solving the technical problems proposed by the present application, which does not mean that there are no other units/modules in the above-mentioned device embodiments.

It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are only used 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", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including 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, the elements defined by the sentence "including one" do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Although the present application has been illustrated 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 (10)

A docking method, applied to a server, is 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. The docking method according to claim 1, characterized in that the acquiring the configuration file and determining the first task flow according to the acquired configuration file comprises: 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. 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 the second task flow comprises: 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. The docking method according to claim 3, characterized in that mounting one or more of the first atomic components to each task node in the first task flow to obtain the second task flow comprises: 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. 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. 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 comprises: 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. The docking method according to claim 1, characterized in that encapsulating the second task flow into a target configuration file comprises: The second task flow is encapsulated as a target configuration file in JSON format. The docking method according to claim 1 is 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. An electronic device, characterized in that it comprises: 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. 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 according to any one of claims 1 to 8.