Low-code development data merging method and apparatus

Abstract

A low-code development data merging method and apparatus. The method comprises: receiving a merging operation triggered by a user at a low-code development client, wherein the merging operation indicates multiple versions of workflow files to be merged, each version of workflow file comprises a workflow, and the workflow is used for indicating a processing flow of a corresponding service function; in response to the merging operation, displaying a workflow set at the low-code development client, wherein the workflow set is used for describing multiple first workflows comprised in the multiple versions of said workflow files; and receiving an editing operation triggered by the user at the low-code development client, the editing operation being used for indicating editing of the user for the workflow set, and in response to the editing operation, generating a merged workflow file, the merged workflow file comprising at least one second workflow obtained by editing the workflow set by the user. According to the present application, a multi-version workflow merging solution is provided, thereby supporting multi-person low-code collaborative development, and thus being capable of improving the development efficiency.

Description

A method and device for merging low-code development data

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on July 4, 2023, with application number 202310813203.1 and application name “A method for merging multi-version data”, the entire contents of which are incorporated by reference into this application; this application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on September 14, 2023, with application number 202311188663.6 and application name “A method and device for merging low-code development data”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of computer technology, and in particular to a method and device for merging low-code development data. Background Art

[0004] With the rapid development of IT and mobile internet, more and more traditional enterprises are using technology to transform their processes and management to reduce costs and increase efficiency, making business development more efficient and standardized. However, during this digital transformation, they often encounter problems such as low construction efficiency, long system development cycles, and high development barriers. Low-code development (LCD) has become an effective solution to these problems.

[0005] Low-code development is a visual approach to application development. By encapsulating code into visual components, it enables the "drag-and-drop" development of application systems. This technology aims to enable developers to quickly build applications using minimal or no coding (zero code), rather than the traditional coding approach. Developers of varying experience levels can use a graphical user interface (GUI) to drag and drop components to build required functionality, such as business processes, logic, and data models. This significantly improves development efficiency and reduces enterprise project development and maintenance costs.

[0006] However, current low-code development is usually done by developers using a single version manually, without considering the collaborative development scenario of multiple people, which affects development efficiency and is particularly unsuitable for the development needs of large-scale applications such as rapidly developing artificial intelligence and supercomputing.

[0007] Summary of the Invention

[0008] The embodiments of the present application provide a method and device for merging low-code development data, which are used to implement a multi-person collaborative development technology that supports a low-code development platform, and are conducive to improving development efficiency.

[0009] In a first aspect, the present application provides a method for merging low-code development data, which can be applied to a low-code development platform or a device equipped with a low-code development tool. The low-code development platform can be capable of providing low-code development services. In one possible application scenario, the low-code development platform is a cloud resource, and users can use the low-code development services provided by the low-code development platform to perform zero / low-code development, with the development content saved in the form of workflow files.

[0010] The following is an example of application to a low-code development platform. In this method: the low-code development platform receives a merge operation triggered by a user in a low-code development client, and the merge operation is used to indicate multiple versions of workflow files to be merged. In one possible example, the low-code development platform can provide a low-code development interface and display the low-code development interface in the low-code development client. The low-code development interface is used to prompt the user to input or select multiple versions of workflow files to be merged. In one example, the low-code development interface may include all versions of workflow files developed by the user for the same project. The merge operation may be that the user selects the workflow file to be merged from all versions of the files displayed on the low-code development interface, wherein each version of the workflow file contains at least one workflow. Taking one of the workflows as an example, the workflow is used to indicate the processing flow of the corresponding business function. Specifically, the workflow includes multiple nodes, and each node in the workflow is used to indicate a processing link (or processing step) in the processing flow represented by the workflow. Afterwards, the low-code development platform responds to the merge operation and displays a workflow set on the low-code development client. The workflow set includes multiple workflows (hereinafter referred to as multiple first workflows) included in the multiple versions of the workflow files to be merged; in one possible example, the low-code development platform can provide a low-code development interface and display the low-code development interface on the low-code development client. The low-code development interface is used to display the workflow set. The user can edit the workflow set in the low-code development interface. Accordingly, the low-code development platform receives the editing operation triggered by the user, and the editing operation is used to instruct the user to edit the workflow set; the low-code development platform responds to the editing operation and generates a merged workflow file corresponding to the multiple versions of the workflow files to be merged. The merged workflow file includes at least one workflow obtained after the user edits the workflow set (each workflow in the at least one workflow obtained after editing is recorded as a second workflow).

[0011] Through the above method, users are supported to create multiple versions of workflows and merge multiple versions of workflows. Users can select the multi-version workflows to be merged through a visual interface, and edit the multi-version workflows to be merged, thereby completing the merging of multiple versions of workflows, providing flexibility, saving time and costs for developers' low-code development, meeting the needs of collaborative development by multiple people or development teams, and improving development efficiency.

[0012] In one possible design, the workflow set includes information of each third workflow in at least one third workflow, and the at least one third workflow is obtained by merging the multiple first workflows, or the workflow set includes form data, the form data includes information of each node in the multiple nodes included in each third workflow, or the form data includes information of each first workflow.

[0013] Through the above method, by comparing and merging multiple first workflows, at least one third workflow can be obtained, providing a preliminary merger of multiple first workflows. At the same time, displaying the information of the third workflow to the user can reduce the amount of information that the user needs to edit, making the merging process more simplified and intuitive, and improving the merging efficiency.

[0014] In one possible design, the low-code development client is also used to display homogeneous nodes and / or heterogeneous nodes; wherein, heterogeneous nodes refer to nodes that are different in multiple first workflows, and homogeneous nodes include any node other than heterogeneous nodes among all the nodes included in the multiple first workflows; the editing operation on the workflow collection includes one or more of the following operations: the retention operation of one or more homogeneous nodes in the workflow collection, the deletion operation of one or more homogeneous nodes in the workflow collection, the retention operation of one or more heterogeneous nodes in the workflow collection, the deletion operation of one or more heterogeneous nodes in the workflow collection, and the parameter configuration operation of one or more heterogeneous nodes in the workflow collection.

[0015] Through the above method, the differences between workflow versions can be compared horizontally to obtain homogeneous nodes and / or heterogeneous nodes, and the homogeneous nodes and / or heterogeneous nodes in the workflow set can be displayed to the user. The differences between multiple versions and the merging process can be visualized, providing users with references through multiple dimensions, which is conducive to improving the merging efficiency. In addition, when merging multiple versions of workflows, node-granular editing operations are supported, maximizing the flexibility of user operations and meeting various merging needs.

[0016] In one possible design, the low-code development platform may further determine at least one first-level node in the multiple workflows to be merged, wherein the isomorphic nodes include at least one first-level node, and the first-level nodes include nodes used to indicate the same processing link in the multiple first workflows. Alternatively, in one possible design, the low-code development platform may further determine at least one first-level node in the multiple first workflows, and determine at least one second-level node from the at least one first-level node, wherein the isomorphic nodes include at least one second-level node, and the second-level nodes include first-level nodes configured with the same parameter values ​​in the multiple first workflows.

[0017] Through the above method, multiple ways of comparing the differences between multiple versions of workflows are supported, workflow comparisons of different precisions are achieved, and corresponding workflow differences are recommended based on merging requirements, providing merging flexibility.

[0018] In one possible design, the method for a low-code development platform to determine at least one first-level node in multiple workflows to be merged includes: converting each workflow file into graph data based on the conversion rules corresponding to each version of the workflow file to be merged; using the graph data corresponding to multiple versions of the workflow files as input data of an isomorphic subgraph mining algorithm to obtain at least one first-level node output by the isomorphic subgraph mining algorithm.

[0019] In one possible design, when the editing operation includes parameter configuration operations on one or more heterogeneous nodes in a workflow set, the low-code development platform receives the editing operation triggered by the user in the low-code development client, which may include: taking a heterogeneous node as an example, the low-code development platform receives the parameter value entered by the user in the low-code development client or selected from the candidate parameter list of the heterogeneous node; wherein the candidate parameter list includes different parameter values ​​configured for the heterogeneous node in multiple workflows to be merged.

[0020] Through the above method, the parameter values ​​configured for the heterogeneous nodes in multiple first workflows are determined, and the parameter values ​​are loaded into the candidate parameter list of the heterogeneous nodes to provide a reference for the user. The user does not need to manually compare multiple versions of the workflow, which is conducive to improving the merging efficiency.

[0021] In one possible design, a node includes a low-code component, which includes one or more of the following: a trigger, a connector, an action, and a workflow.

[0022] In the second aspect, the present application also provides a computing device, which has the function of implementing the behavior of the low-code development platform in the method example of the first aspect above. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The function can be implemented by hardware, or by executing the corresponding software through hardware. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the computing device includes a receiving module, a processing module, and optionally, a display module and a determination module. These modules can perform the functions of the behavior of the low-code development platform in the method example of the first aspect above. Please refer to the detailed description in the method example for details, which will not be repeated here.

[0023] On the third aspect, the present application also provides a computing device cluster, which includes at least one computing device, and the at least one computing device has the function of implementing the low-code development platform behavior in the above-mentioned first aspect. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The structure of each computing device includes a processor and a memory, and the processor is configured to support the computing device to perform part or all of the functions of the low-code development platform behavior in the above-mentioned first aspect and any possible implementation of the first aspect. The memory is coupled to the processor, which stores the necessary program instructions and data for the computing device. The structure of the computing device also includes a communication interface for communicating with other devices.

[0024] In a fourth aspect, the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium runs on a computer, it enables the computer to execute part or all of the functions of the low-code development platform behavior in the above-mentioned first aspect and any possible implementation of the first aspect.

[0025] In the fifth aspect, the present application also provides a computer program product containing instructions, which, when running on a computer, enables the computer to execute part or all of the functions of the low-code development platform behavior in the above-mentioned first aspect and any possible implementation of the first aspect.

[0026] In the sixth aspect, the present application also provides a computer chip, which is connected to a memory and is used to read and execute software programs stored in the memory, and to perform part or all of the functions of the low-code development platform behavior in the above-mentioned first aspect and any possible implementation method of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] FIG1 is a schematic diagram of a system architecture that may be applicable to embodiments of the present application;

[0028] FIG2 is a schematic diagram of a user interface provided in an embodiment of the present application;

[0029] Figure 3 is a schematic diagram of a process flow of low-code development related technologies;

[0030] FIG4 is a schematic diagram of a process of data merging for low-code development provided by an embodiment of the present application;

[0031] FIG5 is a flow chart of a method for merging low-code development data provided in an embodiment of the present application;

[0032] FIG6 is a schematic diagram of a first merging interface provided in an embodiment of the present application;

[0033] FIG7 is a schematic diagram showing a comparison of workflows before and after merging according to an embodiment of the present application;

[0034] FIG8 is a schematic diagram showing another comparison of workflows before and after merging according to an embodiment of the present application;

[0035] FIG9 is a schematic diagram of converting a workflow into graph data according to an embodiment of the present application;

[0036] FIG10 is a schematic diagram of a process for determining homogeneous parts and heterogeneous parts based on graph data according to an embodiment of the present application;

[0037] FIG11 is a schematic diagram of a second merging interface provided in an embodiment of the present application;

[0038] FIG12 is a schematic diagram of a third merging interface provided in an embodiment of the present application;

[0039] FIG13 is a second schematic diagram of a second merging interface provided in an embodiment of the present application;

[0040] FIG14 is a third schematic diagram of a second merging interface provided in an embodiment of the present application;

[0041] FIG15 is a schematic diagram of a third workflow provided in an embodiment of the present application;

[0042] FIG16 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0043] FIG17 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0044] FIG18 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0045] FIG19 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The low-code development provided in this application has multiple application scenarios. In one application scenario, the low-code development platform uses cloud resources to provide users with a cloud service (such as a low-code development service). Users can use the low-code development platform to develop applications by leasing the cloud service.

[0047] Referring to FIG1(a), FIG1(a) is a schematic diagram of a system that may be applicable to an embodiment of the present application. As shown in FIG1(a), the system includes a low-code development platform 200 and a low-code development client 101. The low-code development client 101 and the low-code development platform 200 can communicate through a network (such as the Internet).

[0048] The low-code development client 101 can be a user device used by the user 132, which can be a desktop computer, laptop computer, tablet, vehicle-mounted terminal, mobile phone or other device.

[0049] Optionally, the system may also include a cloud management platform, and the functions of the cloud management platform include: providing an access interface (such as an interface or API). User 132 can operate the low-code development client 101 to remotely access the access interface to register a cloud account and password on the cloud management platform, and log in to the cloud management platform. After the cloud management platform successfully authenticates the cloud account and password, user 132 can further pay to select and purchase cloud services on the cloud management platform, such as low-code development services, cloud computing services, etc. After the purchase is successful, the cloud management platform notifies the cloud resources to provide services to the user. For example, taking the low-code development service as an example, after the purchase is successful, the cloud management platform 200 provides the user 132 with the account and password for logging into the low-code development platform 200, and provides a connection entrance. After the user 132 clicks on the connection entrance and enters the account and password, he can log in to the low-code development platform 200, thereby using the low-code development platform 200 to develop applications.

[0050] The low-code development platform 200 is used to provide low-code development services. Users 132 can log in to the low-code development platform 200 through tools such as browsers and web plug-ins in the low-code development client 101. There is no need to install the low-code development software locally on the low-code development client 101. It should be noted that for simplicity, Figure 1 (a) only shows one user 132 and one low-code development client 101. In practice, the low-code development platform 200 can provide low-code development services to multiple users at the same time. Different users correspond to different low-code development instances, and each user uses a corresponding low-code development instance to provide services. In some possible situations, the multiple users operate their respective low-code development clients to develop different business functions of the same application, or multiple users are used to develop the same business function of the same application, or the multiple users can also develop the same business function of different applications, etc. These situations can be referred to as multi-person collaborative development on a low-code development platform. In some descriptions, the application here can also be referred to as a project or project.

[0051] In another application scenario, as shown in FIG1(b), user 133 installs a low-code development tool (or software) 201 in a local low-code development client 102. The low-code development tool 201 can be a developer desktop / web tool, IDE plug-in, etc. It can be understood that the low-code development tool 201 has software functions related to low-code development provided by the low-code development platform 200. User 133 can run the low-code development tool 201 in the low-code development client 102 to develop an application. In some possible cases, multi-person collaborative development on the low-code development platform also includes multiple users using the method of FIG1(b) for development, or some users using the method of FIG1(a) for development, and the rest of the users using the method of FIG1(b) for development.

[0052] Figure 2 is a schematic diagram of a user interface for low-code development provided by this embodiment. As shown in Figure 2, the user interface may include a component library and a canvas area.

[0053] The component library includes a series of low-code components (referred to as components for short), including general components and specialized components. General components typically encapsulate common, general, and basic code, while specialized components include encapsulating specific business code or workflows. The canvas area is the "programming" area, where users (such as developers) can add components, set connections between components, and configure component parameters. Developers can drag and drop components from the component library to the canvas area based on the business process of the application to be developed. This requires developers to clearly identify the required components, configure the component parameters, and connect them together using wires. After the components are connected, they form a workflow. A workflow describes the processing flow of one or more business functions. Each component constitutes a functional node in the workflow, indicating a processing step in the process. Components can be divided into triggers and actions based on their position in the workflow. Triggers are located at the first node of the workflow and are the conditions for starting the workflow. Components other than triggers in a workflow are called actions. Node is a general term for triggers and actions in a workflow.

[0054] For example, as shown in FIG2 , a workflow includes the following sequence: Node 1: receiving an http request → Node 2: obtaining a list of cloud servers → Node 3: forwarding the http request to the cloud server → Node 4: the cloud server processes the http request → Node 5: the cloud server returns a response to the http request. Among them, nodes 1, 2, 3, 4, and 5 are respectively a link in the processing flow, wherein node 1 is a trigger, and nodes 2-5 are operations. The data form used to save the workflow in the low-code development platform 200 includes a workflow file (or workflow canvas). In this embodiment, for the same project, the low-code development platform 200 can distinguish different versions of the workflow of the project generated by the user through different versions of the workflow file. It can be understood that the new workflow obtained by the user editing the old version of the workflow can be saved in the new version of the workflow file.

[0055] As can be seen, on a low-code development platform, developers can develop applications by simply dragging and dropping, which can significantly reduce the development difficulty and shorten the development cycle, allowing for rapid generation and delivery of applications. Currently, many cloud vendors offer low-code development services. However, existing low-code development services still have many problems, such as:

[0056] In a related technology, low-code development services don't support the creation of multiple versions of workflow files. When developers use low-code development services to develop applications, they manually create workflow files, select components, configure complex logic, fill in node parameters, debug workflows, and finally publish workflows. This process is done entirely using a single version, without using other workflows or other versions of files. This solution fails to meet the needs of collaborative development within a low-code development platform.

[0057] In another related technology, the low-code development service supports the creation of multi-version workflow files. Users can query all versions of the files of the project to which the file belongs in the historical versions of a certain version of the workflow file (hereinafter referred to as the file). However, due to file version protection, the workflow in the old version file will be locked, and the user can only view it but cannot modify the workflow itself in the old version file. Alternatively, the user can also add the old version workflow as a "component" to the canvas area of ​​the new version file as a node in the new version workflow, but this solution can only add new functions to the old version workflow, that is, add new components to the old version workflow, but cannot modify the old version workflow itself. If the user needs to modify the old version workflow, referring to the process shown in Figure 3, the user can only create a new workflow file and copy and paste the old version workflow into the blank canvas or preset template of the new workflow file to redo it. At this time, the user is allowed to modify the pasted old version workflow itself to generate a new workflow (the modified workflow in Figure 3).

[0058] Although the new workflow and the old version workflow in Figure 3 may be two workflow versions edited for the same business function, there is no version association between the file used to save the new workflow (such as file A) and the file used to save the old version workflow (such as file B) (the file names of the two may also be completely different). In other words, the historical version of file B does not include file A, and the historical version of file A does not include file B. Users cannot find file A in the historical version of file B, nor can they find file B in the historical version of file A. When comparing file A and file B, they can only manually browse and find the two files for comparison. In other words, in existing low-version development services, some business-related workflow files are completely separated, which may require the same developer or development team to invest a lot of time in manually comparing versions and modifying parameter configurations, which is very inconvenient for developers. This solution also cannot meet the needs of multi-person collaborative development on low-code development platforms.

[0059] To sum up, the existing low-code development platforms do not support collaborative development by multiple people or development teams, and do not support collaborative development by the same developer based on multi-version workflow files. This seriously affects development efficiency and cannot meet business needs, especially the development needs of large-scale parallel applications used in artificial intelligence, supercomputing and other systems.

[0060] In view of this, the present application provides a method for merging low-code development data, which specifically provides a merging technology for visually presenting multiple versions of workflows. A possible process of the merging technology is shown in Figure 4: the developer can open a certain version of the workflow file, obtain one or more new versions of the workflow file based on the workflow of that version, and trigger the merging of the multiple versions of the workflow file to determine the workflow set of the multiple versions of the workflow to be merged. Afterwards, the multiple versions of the workflow can be mined to determine the isomorphic parts and heterogeneous parts in the multiple versions of the workflow, and the workflow set and similarities and differences of the multiple versions of the workflow can be visually presented to guide the developer to complete the multi-version merge. This technology supports the same user to compare and merge multiple versions of workflows, or supports multiple users or development teams to carry out collaborative development and debugging according to business needs. For the multiple versions of workflow files obtained by collaborative development, the comparison and merging of multiple versions of workflows can be triggered, which further saves time and costs for users or development teams using low-code development platforms for collaborative development, and improves overall development efficiency and online progress.

[0061] Next, the technical solution provided by this embodiment will be specifically described using the system shown in Figure 1 as an example. It should be understood that the two system architectures shown in Figure 1 are merely illustrative, showing only the components related to the embodiments of the present invention, but Figure 1 does not specifically limit the application of the present invention.

[0062] FIG5 is a flow chart corresponding to a method for merging low-code data provided in an embodiment of the present application. In FIG1(a), the method can be executed by the low-code development platform 200. In FIG1(b), the method can be executed by the low-code development client 102 or a component of the low-code development client 102 (such as a processor). For ease of explanation, the following will be introduced in conjunction with the system shown in FIG1(a). As shown in FIG5, the method may include the following steps:

[0063] Step 501: receiving a merge operation triggered by a user on a first merge interface for multiple versions of workflow files.

[0064] The low-code development platform 200 can be used to provide a first merged interface for low-code development. The "providing" here can refer to the low-code development platform 200 having the function of providing the first merged interface, or can refer to the low-code development platform 200 sending a resource for displaying the first merged interface to the low-code development client 101, so that the low-code development client 101 uses the resource to display the first merged interface.

[0065] In one embodiment, the low-code development platform 200 provides a user interface for triggering the merge of multiple versions of workflows (referred to as the first merge interface), as shown in Figure 6 (b) which is a schematic diagram of the first merge interface, and Figure 6 (a) which is another user interface for triggering the first merge interface. As shown in Figure 6 (b), the first merge interface may include a file list and a confirmation button for triggering the merge of the selected multiple versions of the workflow. The file list may include information about multiple workflow files, such as the version or name of the workflow file (not shown in Figure 6), the number of connectors, operations, and logical relationships included in the workflow of this version, etc. For example, each version number in Figure 6 (b) represents a workflow file, and each workflow file generally includes a workflow. Therefore, each version of the workflow file here can also represent the corresponding version of the workflow. Each version of the workflow file corresponds to a check box for the user to select, which is convenient for operation. The user can select the workflow file in the check box and click the confirmation button to trigger the merge operation of the selected workflow file. Accordingly, the low-code development platform 200 receives the merge operation triggered by the user in the first merge interface.

[0066] Among them, the connector can be understood as a collection of operations that handle the same type of business. In an optional manner, the low-code development platform 200 supports the combination of multiple operations into a connector. For cloud vendors, the connector may refer to a certain cloud service. Connectors can also be stored in a component library, and developers can drag connectors from the component library to the canvas area, that is, the workflow may include connectors. An operation may refer to an API that performs a certain function. For cloud vendors, it may refer to a specific API in a certain cloud service. Logical relationships refer to non-API operations, such as for / while loop logic and if / else conditional judgment logic. It should be understood that in the low-code development services or literature records provided by different cloud vendors, components, triggers, operations, nodes, connectors, and logical relationships may have different names, and this application does not limit this.

[0067] In addition, the file list in FIG6(b) generally only includes all versions of workflow files for a project, which is convenient for users to view. Optionally, the file list may also include workflow files for other projects, such as third-party workflow files, which can be workflow files downloaded by users from the cloud or open source platforms, etc., without specific limitation.

[0068] The above describes the content of the first merge interface. Methods for triggering the display of the first merge interface may include:

[0069] Method 1: The low-code development platform 200 provides a "Merge Multiple Versions" button for triggering the first merge interface, as shown in FIG6(a). This button is located in an independent user interface. The low-code development platform receives a user click operation on the Merge Multiple Versions button and displays the first merge interface shown in FIG6(b) in response to the click operation. Alternatively, this button can be located in the canvas area, menu bar, or toolbar (not shown in FIG2) of the user interface shown in FIG2, without specific limitation.

[0070] Method 2: The low-code development platform provides a command line window or shortcut key operation. Users can trigger the low-code development platform to display the first merge interface by entering or selecting specific commands or specific shortcut key operations in the command line window.

[0071] It should be noted that the user interfaces shown in Figure 6 (a) and Figure 6 (b) are examples. In practice, the first merge interface can be any variation of the format shown in Figure 6 (b) or have more or less content relative to Figure 6 (b). For example, the file list of the first merge interface applicable to this embodiment can also include detailed information for each workflow file, such as creation time, version number, etc., or the file list does not include the number of connectors / operations / logical relationships, etc. This application does not limit the content of the first merge interface and the user interface for triggering the first merge interface. In addition, it should be noted that the method for triggering the low-code development platform to display the first merge interface applicable to this embodiment is not limited to the several methods listed above. Any method that can trigger the display of the first merge interface is applicable to this embodiment, such as triggering by voice or gesture, etc. This application does not limit this method.

[0072] The multiple versions of workflow files to be merged can include multiple versions of workflow files generated by the same user, or multiple versions of workflow files generated by multiple users through collaborative development. The workflow files generated by multiple users can be synchronized and updated across one or more users using relevant data synchronization technologies (e.g., Git data synchronization methods). Alternatively, the workflow files generated by multiple users can be manually aggregated, for example, by downloading the workflow files for the corresponding projects from other users, or by all users sending their respective workflow files belonging to the same project to the same device. The specific details are not limited here.

[0073] Step 502: The low-code development platform triggers multi-version comparison and merging in response to the merge operation.

[0074] In this embodiment, the process of comparing and merging multiple versions may include the following steps:

[0075] In step 503, the low-code development platform determines a workflow set based on multiple versions of workflow files to be merged.

[0076] The workflow set is used to describe the multiple workflows included in the multiple versions of the workflow files to be merged (hereinafter referred to as the multiple workflows to be merged). Exemplarily, the workflow set is a superset of the multiple workflows to be merged, and the superset is used to indicate all nodes included in the multiple workflows to be merged.

[0077] In one embodiment, the workflow set includes at least one workflow obtained by merging multiple workflows to be merged. In this case, determining the workflow set may include merging the multiple workflows to be merged to generate at least one merged workflow. For ease of distinction, each workflow to be merged may be referred to as a first workflow, and each workflow obtained after the merge may be referred to as a second workflow.

[0078] In one scenario, the low-code development platform 200 generates a second workflow based on multiple first workflows.

[0079] For example, please refer to Figure 7. Taking a workflow file including a workflow as an example, Figure 7 (a) shows multiple first workflows included in multiple workflow files to be merged with version numbers v1, v2, v3 and v4. The low-code development platform merges these four versions of the first workflow to obtain the second workflow shown in Figure 7 (b). The components included in the second workflow are the union of the nodes included in the four versions of the first workflow. In the second workflow, the connection relationship between any two adjacent nodes is determined based on the connection relationship between the two nodes in a certain old version of the workflow. That is, the second workflow is used to describe all components included in the multiple first workflows to be merged and the connection relationship between the components.

[0080] In another case, the low-code development platform 200 generates multiple second workflows based on multiple first workflows.

[0081] Taking a second workflow as an example, the second workflow can be generated by merging part of the first workflow to be merged, or the second workflow can be the first workflow itself. For example, multiple first workflows include five versions, namely v1, v2, v3, v4 and v5. Two second workflows may be generated based on the five first workflows. For example, one of the second workflows is generated based on the first workflows of versions v1, v2, and v3, and the other second workflow is generated based on the first workflows of versions v4 and v5. Alternatively, one of the second workflows is generated based on the first workflows of versions v1, v2, v3, and v4, and the other second workflow is the same as the first workflow of version v5.

[0082] It should be noted that the second workflow included in the workflow set in (b) of Figure 7 is displayed in the form of workflow data. The workflow set in this embodiment can also be in other data forms. For example, the workflow set includes graph data corresponding to each second workflow (the graph data will be introduced below and will not be repeated here), or the workflow set includes descriptive information of the nodes included in each second workflow (which will be introduced below in conjunction with Figure 13 and will not be repeated here), etc. This embodiment does not limit this.

[0083] In another embodiment, the workflow set includes information of each first workflow in the plurality of first workflows (which will be described below in conjunction with FIG. 14 and will not be repeated here).

[0084] It should be understood that the multiple first workflows to be merged can be different versions generated based on the same workflow, or different versions generated based on different workflows, and can be written by the same developer or multiple developers, without specific limitation.

[0085] In an optional manner, the workflow set may also include difference information of the multiple first workflows, and the difference information is used to indicate the homogeneous parts and / or heterogeneous parts in the multiple first workflows. The following describes how to determine the homogeneous parts and heterogeneous parts in the multiple first workflows through step 504.

[0086] In step 504 , the low-code development platform 200 determines the homogeneous parts and / or heterogeneous parts in the multiple first workflows to be merged.

[0087] The isomorphic part includes nodes included in multiple first workflows (referred to as isomorphic nodes). Optionally, the isomorphic part also includes lines included in multiple first workflows (referred to as isomorphic edges).

[0088] In some cases, isomorphic nodes refer to nodes (denoted as first-level nodes) used to indicate the same processing flow, and first-level nodes can be nodes with the same component type. For example, in Figure 7 (a), the four first workflows all include node 1, node 4, node 5, node 9, and node 11 in Figure 7 (b), then the isomorphic nodes determined based on the four versions of the first workflow include node 1, node 4, node 5, node 9, and node 11. Isomorphic edges refer to lines included in all four versions, and the nodes at both ends of the line are the same. For example, the line between node 4 and node 5 is an isomorphic edge. Accordingly, the heterogeneous part includes any node (denoted as a heterogeneous node) other than the isomorphic node (first-level node) in the workflow set determined based on multiple first workflows, and optionally, it may also include any edge (denoted as a heterogeneous edge) other than the isomorphic edge.

[0089] In other cases, the homogeneous node is a secondary node, which refers to a node in multiple first workflows that indicates the same processing flow and is configured with the same parameter values ​​in multiple first workflows. That is, the secondary node includes the primary nodes configured with the same parameter values ​​in multiple first workflows. Accordingly, the heterogeneous portion includes any node (referred to as a heterogeneous node) other than the homogeneous portion (secondary node) in the workflow set determined based on the multiple first workflows, and optionally, any edge (referred to as a heterogeneous edge) other than the homogeneous edge.

[0090] The following is a flow chart of a method for determining homogeneous parts and heterogeneous parts, taking the second case as an example. Please refer to FIG8 and FIG9 for understanding. The method may include the following steps:

[0091] Step 504 - 1 : The low-code development platform 200 converts the workflow files of each version to be merged into graph data.

[0092] In one embodiment, the graph data conversion method includes, for each workflow file to be merged, obtaining a conversion rule corresponding to the workflow file, and generating graph data based on the conversion rule corresponding to the workflow file.

[0093] Those skilled in the art will appreciate that workflows, both in back-end storage and front-end interface rendering, are based on workflow canvas code. This canvas code represents information such as the connection relationships and node parameters of each node in the workflow. The conversion rules for workflow canvas code may vary among low-code developers and cloud service providers. Currently, workflow canvas code is available in formats such as JSON and DSL.

[0094] For example, assuming that in the above example, the workflow canvas code of the first workflow of version v1 is in json format, and the workflow canvas code of the first workflow of version v2 is in DSL format, in step 504-1, the low-code development platform can respectively obtain the conversion rules corresponding to the workflow canvas code in json format (recorded as the first conversion rule) and the conversion rules corresponding to the workflow canvas code in DSL format (recorded as the second conversion rule). Then, based on the first conversion rule, the workflow canvas code of the first workflow of version v1 is converted into graph data, and based on the second conversion rule, the workflow canvas code of the first workflow of version v2 is converted into graph data, and so on. Among them, the conversion rules corresponding to the workflow canvas codes of each format can be user-defined and submitted to the low-code development platform 200 or pre-set in the system (such as the low-code development platform 200 or the cloud management platform, etc.), and are not specifically limited.

[0095] The types of graph data include, but are not limited to, one or more of the following: adjacency matrix, incidence matrix, vertex subgraph, in / out edge subgraph, vertex type subgraph, neighbor sampling subgraph, etc., without specific limitation.

[0096] Taking the adjacency matrix as an example, Figure 10 is a schematic diagram of converting a workflow file into an adjacency matrix provided by this embodiment, wherein Figure 10 shows the first workflow included in the workflow file, and the graph data converted based on the first workflow includes at least one adjacency matrix, each element of the adjacency matrix is ​​used to describe the connection relationship between two nodes in the first workflow. Exemplarily, an element value of 1 indicates that the two atoms have a connection relationship, and 0 indicates that the two atoms do not have a connection relationship.

[0097] Through the above method, multiple workflow files to be merged are converted into graph data in sequence.

[0098] Step 504 - 2 : Based on the graph data corresponding to the multiple workflow files to be merged, use an isomorphic subgraph mining algorithm to determine the first-level nodes in the multiple first workflows to be merged.

[0099] For example, in the above example, the adjacency matrix or correlation matrix corresponding to the multiple workflow files is input into the isomorphic subgraph mining algorithm to obtain the output result of the isomorphic subgraph mining algorithm, which is used to indicate the first-level nodes in the multiple first workflows to be merged.

[0100] Among them, isomorphic subgraph mining algorithms include but are not limited to: for example, Ullmann, VF2, Weisfeiler-Lehman, etc. The process of using the isomorphic subgraph mining algorithm to obtain the output result can be found in the relevant technical introduction, which will not be highlighted here. It should be understood that the implementation process of different isomorphic subgraph mining algorithms and the type of graph data required in the implementation process may be different. For example, as shown in Figure 9, some isomorphic subgraph mining algorithms require vertex subgraphs, in / out edge subgraphs, edge type subgraphs, vertex type subgraphs, neighbor sampling subgraphs, etc. in addition to the adjacency matrix or association matrix in the intermediate implementation process. The specific construction can be based on the needs of the algorithm, and this embodiment does not limit this.

[0101] Step 504 - 3 : Filter out the second-level nodes from the first-level nodes.

[0102] For example, the screening method may include: for each parameter of each configured parameter value included in each first-level node, by comparing the string of the parameter value filled in multiple workflows of the parameter of the first-level node to determine whether the parameter value configured for the parameter is consistent, if consistent, then continue to compare the next parameter, or the multiple parameters can be compared synchronously, without specific limitation, if the comparison results of all parameters are consistent, for example, the first-level node includes parameter A and parameter B, if the parameter value configured for parameter A in the above-mentioned four versions of the workflow is the same (for example, the parameter A of the first-level node in these four versions of the workflow is filled in as string A), and the parameter value configured for parameter B in the four versions of the workflow is also the same (for example, the parameter B of the first-level node in these four versions of the workflow is filled in as string B), then the first-level node is determined to be a second-level node. When there are multiple first-level nodes, each first-level node is screened separately in the above-mentioned manner.

[0103] Step 504 - 4 : Determine heterogeneous parts in the plurality of first workflows to be merged.

[0104] The heterogeneous part is determined based on the workflow set and the homogeneous part of the multiple first workflows. Please refer to the above introduction and will not be repeated here.

[0105] It should be noted that step 504 is an optional step and is not a step that must be performed.

[0106] In step 505 , the low-code development platform 200 provides a second merging interface, which is used to display a workflow set corresponding to the multiple first workflows to be merged.

[0107] In one embodiment, the second merge interface displays each second workflow in the workflow set in a canvas format. Optionally, the canvas may also display homogeneous parts and / or heterogeneous parts of the second workflow.

[0108] Exemplarily, taking a second workflow as an example, as shown in FIG11 , the second merge interface includes a Show All option and a Show Differences option. When the user clicks the Show All option, the second merge interface can display the second workflow in the canvas area, as shown in FIG11 (a). When the user clicks the Show Differences option, the second merge interface displays the heterogeneous nodes in the second workflow on the basis of displaying the second workflow, as shown in FIG11 (b). Alternatively, a method with the same display effect also includes marking the homogeneous nodes in the second workflow in the second merge interface without marking the heterogeneous nodes. Of course, homogeneous and heterogeneous nodes can also be marked at the same time, without specific limitation.

[0109] Among them, the second merge interface can also provide other operable controls to the user. Specifically, in the second merge interface, each node in the multi-version workflow supports the user to implement operations such as retention and deletion by clicking. For example, each node in the second workflow corresponds to a delete key. The user clicks the delete key of the corresponding node to delete the node, and the corresponding node that has not clicked the delete key is the node that the user indicates to retain. Alternatively, the second merge interface can also provide a retain key corresponding to the node without displaying the delete key. The user indicates the node that needs to be retained by operating the retain key, and the node that has not clicked the retain key is the node that the user indicates to delete. In addition to the retain and delete operations, the user can also perform other edits to the second workflow in the canvas area, such as modifying the connection relationship between nodes, changing the parameter value of the node, etc.

[0110] The following is an introduction to the process of users configuring the parameters of heterogeneous nodes in this embodiment. See Figure 12. The interface shown in Figure 12 (referred to as the third merge interface) can be a pop-up window triggered by the user for a heterogeneous node in the second merge interface, which is used to configure the parameter values ​​of the heterogeneous node. The user can directly fill in the corresponding parameter values ​​(which can be values ​​or text, etc.) in each parameter. Alternatively, the user can also select a parameter value from the candidate list of the parameter provided in the interface. The candidate list of the parameter includes the parameter values ​​of the parameter of the heterogeneous node that are configured in one or more first workflows. For example, in the above example, the heterogeneous node appears in both the v2 and v3 versions of the first workflow. The heterogeneous node includes parameter C. In the v2 version of the first workflow, the parameter C of the heterogeneous node is configured with parameter value 1, and in the v3 version of the first workflow, the parameter C of the heterogeneous node is configured with parameter value 2. In the third merge interface, the candidate list of parameter C of the heterogeneous parameter includes parameter value 1 and parameter value 2. The user can select one of the parameter values ​​in the candidate list and exit the third merge interface. At this point, the configuration of a parameter of the heterogeneous node in the second merging interface is completed.

[0111] The above-mentioned operations triggered on the workflow set can be called editing operations. Optionally, the editing operation can also add new nodes in the canvas area, configure parameter values ​​of new nodes, etc.

[0112] In another embodiment, the second merge interface displays the workflow set in a form. Optionally, the form may also display the homogeneous parts and / or heterogeneous parts of the second workflow.

[0113] For example, taking the workflow set including a second workflow as an example, the form can display the second workflow through the node dimension. As shown in Figure 13, the form may include, but is not limited to, one or more of the following: all nodes included in the second workflow (all nodes may be arranged in order according to the logical relationship between the nodes), each node's http method, URI, description information, the number of times it appears in multiple first workflows, the version number of the occurrence, and user operation options (such as including retain items and / or delete items). It is understood that a node that appears in all versions of the workflow is a first-level node. When the same parameters of the first-level node are configured with the same parameter values ​​in all versions of the workflow, the first-level node is also a second-level node.

[0114] As another example, the form can also display the workflow collection through the version dimension, as shown in Figure 14. The form may include but is not limited to the information of each version of the workflow file, such as the version number, the number of connectors or operations or logical relationships included, content details, etc. Among them, when the user clicks on the content details of a certain version of the workflow file, the information of the nodes included in the workflow in the workflow file (and the nodes are arranged in a logical order) can be loaded and displayed. The information of each node may include but is not limited to: the http method, URI, description information, the number of occurrences in multiple first workflows, the version number of the occurrence, etc. of each node. Please refer to the relevant introduction in the example of Figure 13, which will not be repeated here. The user can trigger the editing operation through this form, including checking the version of the workflow file that needs to be retained, thereby indicating the nodes that need to be retained in the second workflow and the connection relationship between the nodes.

[0115] Through the above method, the differences between multiple versions of the workflow can be displayed in the form of a visual canvas or form, so that users can merge them into the final version.

[0116] It should be noted that the above-mentioned methods of presenting workflow collections in canvas or form are merely examples; any method that can present workflow collections to users is applicable to this embodiment. It should also be noted that the methods of presenting difference information in Figures 11-14 are merely examples; this application also supports other methods of presenting difference information, such as distinguishing first-level nodes in heterogeneous nodes, i.e., nodes that differ only in parameter values, etc., without specific limitation.

[0117] Step 506, the low-code development platform 200 receives the editing operation triggered by the user in the second merge interface.

[0118] Step 507: The low-code development platform 200 generates a merged workflow file in response to the editing operation.

[0119] The workflow file includes at least one workflow obtained after the user edits the workflow set (each workflow in the at least one workflow is recorded as a third workflow). For example, if the user edits the second workflow shown in Figure 11, such as deleting the "Set pagesize" node, "Loop" node, "Conditional judgment" node, and "Filter group" node in the second workflow, while retaining the remaining nodes, in response to the editing operation, the low-code development platform can obtain the third workflow shown in Figure 15.

[0120] Optionally, before generating the third workflow, node connectivity verification (to check for isolated nodes) and integrity verification (to check that all required parameters are complete) can also be included. Developers can also generate subsequent business code and design files based on the generated third workflow, such as full code in languages ​​such as Java, Python, or Go, or API design files required for subsequent business operations.

[0121] It should be noted that the process steps shown in the method embodiment of Figure 5 are only an example. In practice, the isomorphic parts can be recommended to the user after the isomorphic parts are determined, and then the heterogeneous parts are determined, and then the heterogeneous parts are recommended to the user. There is no specific limitation. In addition, it should be noted that in (b) of Figure 1, the low-code development client 102 running the low-code development tool 201 can execute the method executed by the low-code development platform 200 in the method embodiment of Figure 5 above. All methods that can be applied to low-code development are applicable to the embodiments of this application. It should also be noted that the above-mentioned method of completing workflow merging through multiple merging interfaces is only an example. In practice, more or fewer merging interfaces can be used to assist users in completing workflow merging, and this embodiment does not limit this.

[0122] Through the above design, a multi-version workflow merging method for low-code development is provided. In this method, workflow creation supports multiple versions, allowing multiple users or development teams to collaborate on development. After completion, the differences between versions can be compared horizontally. It also supports merging multi-version workflow nodes (including connectors, operations, and other granularities), and can visualize the differences and merging process of multiple versions. Users can choose to retain or discard nodes and connection relationships through the visual interface, saving developers time and costs for low-code development and improving development efficiency. It ensures low-code collaborative development and helps teams release services quickly and accurately.

[0123] In addition to the above problems, the defects of the low-code development services currently provided by cloud vendors also include: In a related technology, the triggering method of the file version in the low-code development service is passive triggering, and the file version generated by the user using the low-code development service is not controlled by the user. Specifically, the file name and version number of the new version file generated by the user based on the old version file cannot be determined by the user. For example, after the user edits and saves the workflow in a certain version file, a new file will be generated. The version number of the new file will automatically increase by 1. The user cannot actively create a version, and the file name of the new file can only use the file name of the old version file and cannot be edited by the user. For example, suppose the file name + version number of an old version file is abc.V1, where abc is the file name and V1 is the version number. If the user edits the old version file, the file name + version number of the new file generated will be abc.V2.

[0124] In response to this, the present embodiment also provides a technical support that allows users to edit a certain version of a workflow file based on viewing the version of the workflow file. That is, the user can open any old version of the workflow file and edit the workflow in the opened file, such as adding nodes, deleting nodes, modifying connection relationships, configuring parameters, etc. The version name and version number of the edited workflow file can be defined by the user. This allows users to create versions independently, and users can add new functions based on the old version of the workflow, modify the functions of the old version of the workflow, and when adding the old version of the workflow to the new version of the workflow, they can also directly modify the old version of the workflow without having to redo it based on a blank canvas or preset template. This will not result in the fragmentation of multiple workflow files with business relevance in terms of version, making it easier for users to search and compare, and providing users with flexibility and convenience. In an optional way, the present embodiment can also manage user accounts with such permissions by setting user permissions, so that this technical support is not open to all users to ensure the security and traceability of application development.

[0125] Based on the same inventive concept as the method embodiment, the embodiment of the present application further provides a computing device for executing the method executed by the low-code development platform 200 in the method embodiment of FIG5 . As shown in FIG16 , in one example, a computing device 1600 includes a receiving module 1602 and a processing module 1603. Optionally, it also includes a display module 1601 and a determination module 1604. Specifically, in the computing device 1600, each module is connected via a communication path.

[0126] Receiving module 1602 is used to receive a merge operation triggered by a user in a low-code development client (such as the first merge interface displayed in the low-code development client), and the merge operation indicates the merging of multiple versions of workflow files; wherein, each version of the workflow file contains at least one workflow, and the workflow is used to indicate the processing flow of the corresponding business function; for details, please refer to the description of step 501, which will not be repeated here.

[0127] Processing module 1603 is used to display a workflow collection in the low-code development client in response to a merge operation. The workflow collection is used to describe multiple first workflows included in multiple versions of workflow files to be merged. For details, please refer to the description of steps 502 to 505, which will not be repeated here.

[0128] Receiving module 1602 is also used to receive editing operations triggered by users in the low-code development client. The editing operation is used to instruct the user to edit the workflow set. For details, please refer to the description of step 506, which will not be repeated here.

[0129] Processing module 1603 is further configured to generate, in response to the edit operation, a merged workflow file corresponding to the multiple versions of the workflow files. The merged workflow file includes at least one second workflow resulting from the user editing the workflow set. For details, refer to the description of step 507 and will not be repeated here.

[0130] In one possible implementation, the workflow collection includes information about each third workflow in at least one third workflow, and the low-code development client is used to display each third workflow, and at least one third workflow is obtained by merging multiple first workflows, or the workflow collection includes form data, and the low-code development client is used to display the form data, and the form data includes information about each node in the multiple nodes included in each third workflow, or the form data includes information about each first workflow.

[0131] In one possible implementation, the low-code development client is also used to display (such as through a second merge interface) homogeneous nodes and / or heterogeneous nodes in the workflow set; wherein, heterogeneous nodes include nodes that are different in multiple first workflows, and homogeneous nodes include any node in the workflow set except heterogeneous nodes; for details, please refer to the description of step 504, which will not be repeated here.

[0132] The editing operation includes one or more of the following operations: retaining one or more homogeneous nodes in the workflow set, deleting one or more homogeneous nodes in the workflow set, retaining one or more heterogeneous nodes in the workflow set, deleting one or more heterogeneous nodes in the workflow set, and configuring parameters for one or more heterogeneous nodes in the workflow set. For details, please refer to the description of step 506 and will not be repeated here.

[0133] In one possible implementation, determination module 1604 is configured to determine at least one first-level node in the multiple first workflows. A homogeneous node includes at least one first-level node, and a first-level node includes nodes indicating the same step in the multiple first workflows. For details, refer to the description of step 504 and are not repeated here.

[0134] In one possible implementation, determination module 1604 is configured to determine at least one first-level node in the multiple first workflows, where a first-level node includes nodes indicating the same step in the multiple first workflows; and to determine at least one second-level node from the at least one first-level node, where a homogeneous node includes at least one second-level node, where a second-level node includes first-level nodes configured with the same parameter values ​​in the multiple first workflows. For details, refer to the description of step 504 and are not repeated here.

[0135] In one possible implementation, when the determination module 1604 uses the isomorphic subgraph mining algorithm to determine at least one first-level node in multiple first workflows, it is specifically used to: convert each workflow file into graph data based on the conversion rules corresponding to each version of the workflow file in the multiple versions of the workflow files to be merged; use the graph data corresponding to the multiple versions of the workflow files as input data of the isomorphic subgraph mining algorithm to obtain at least one first-level node output by the isomorphic subgraph mining algorithm. In one possible implementation, the editing operation includes a parameter configuration operation on one or more heterogeneous nodes in the workflow set; when the receiving module 1602 receives the editing operation triggered by the user in the low-code development client (such as the third merge interface), it is specifically used to: for each heterogeneous node in the one or more heterogeneous nodes, receive the parameter value entered by the user in the third merge interface or selected from the candidate parameter list of the heterogeneous node; wherein the third merge interface is a pop-up window triggered by the user for the heterogeneous node in the second merge interface, and the candidate parameter list includes different parameter values ​​configured for the heterogeneous node in the multiple first workflows. For details, please refer to the description of step 504, which will not be repeated here.

[0136] In one possible implementation, a node includes a low-code component, which includes one or more of the following: a trigger, a connector, an action, and a workflow.

[0137] In a possible implementation, the display module 1601 is configured to display the first merge interface, the second merge interface, and the second merge interface.

[0138] For example, the implementation of the processing module 1603 in the computing device 1600 is described below. Similarly, the implementation of the display module 1601, the receiving module 1602, and the determination module 1604 can refer to the implementation of the processing module 1603.

[0139] When implemented by software, the processing module 1603 may be an application or code block running on a computer device. The computer device may be at least one of a physical host, a virtual machine, a container, and other computing devices. Furthermore, the above-mentioned computer device may be one or more. For example, the processing module 1603 may be an application running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed in the same availability zone (AZ) or in different AZs. The multiple hosts / virtual machines / containers used to run the application may be distributed in the same area.

[0140] The data can be distributed in different regions, where a region can usually include multiple AZs.

[0141] Similarly, multiple hosts / virtual machines / containers used to run the application can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Typically, a region can include multiple VPCs, and a VPC can include multiple AZs.

[0142] When implemented through hardware, processing module 1603 may include at least one computing device, such as a server. Alternatively, processing module 1603 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0143] The multiple computing devices included in processing module 1603 can be distributed in the same AZ or in different AZs. The multiple computing devices included in processing module 1603 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in processing module 1603 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0144] It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods. The functional modules in the embodiments of the present application can be integrated into one module, or each module can exist physically separately, or two or more modules can be integrated into one module, for example, the display module 1601 and the receiving module 1602 are integrated into one module, or the display module 1601 and the receiving module 1602 are the same module. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0145] This application also provides a computing device 1700. As shown in Figure 17, computing device 1700 includes a bus 1702, a processor 1704, a memory 1706, and a communication interface 1708. Processor 1704, memory 1706, and communication interface 1708 communicate with each other via bus 1702. Computing device 1700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1700.

[0146] Bus 1702 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG17 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 1702 may include a path for transmitting information between various components of computing device 1700 (e.g., memory 1706, processor 1704, and communication interface 1708).

[0147] The processor 1704 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0148] The memory 1706 may include volatile memory, such as random access memory (RAM). The processor 1704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0149] Memory 1706 stores executable program code, and processor 1704 executes the executable program code to implement the functions of the aforementioned display module 1601, receiving module 1602, processing module 1603, and determination module 1604, thereby implementing the low-code development data merging method. In other words, memory 1706 stores instructions for computing device 1600 to execute the low-code development data merging method provided in this application.

[0150] The communication interface 1708 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1700 and other devices or a communication network.

[0151] The present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0152] As shown in Figure 18, the computing device cluster includes at least one computing device 1700. The memory 1706 in one or more computing devices 1700 in the computing device cluster may store the same instructions for executing the merging method of low-code development data.

[0153] In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also store partial instructions for executing the method for merging low-code development data. In other words, the combination of one or more computing devices 1700 can jointly execute the instructions for executing the method for merging low-code development data.

[0154] It should be noted that the memory 1706 in different computing devices 1700 in the computing device cluster can store different instructions, each for executing a portion of the functions of the data access device. In other words, the instructions stored in the memory 1706 in different computing devices 1700 can implement the functions of one or more of the display module 1601, the receiving module 1602, the processing module 1603, and the determination module 1604.

[0155] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network (WAN) or a local area network (LAN), among others. FIG. 19 illustrates a possible implementation. As shown in FIG. 19 , two computing devices 1700A and 1700B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1706 in the computing device 1700A stores instructions for executing the functions of the display module 1601 and the receiving module 1602. Simultaneously, the memory 1706 in the computing device 1700B stores instructions for executing the functions of the processing module 1603 and the determination module 1604.

[0156] It should be understood that the functionality of the computing device 1700A shown in FIG19 may also be implemented by multiple computing devices 1700. Similarly, the functionality of the computing device 1700B may also be implemented by multiple computing devices 1700.

[0157] The embodiment of the present application also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to the connection method of the computing device cluster described in Figures 18 and 19. The difference is that the memory 1706 in one or more computing devices 1700 in the computing device cluster can store the same instructions for executing the merging method of low-code development data.

[0158] In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also store partial instructions for executing the method for merging low-code development data. In other words, the combination of one or more computing devices 1700 can jointly execute the instructions for executing the method for merging low-code development data.

[0159] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the computer program product causes the at least one computing device to execute a method for merging low-code development data, or instructs the computing device to execute a method for merging low-code development data.

[0160] An embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a method for merging low-code development data, or instruct the computing device to execute a method for merging low-code development data.

[0161] Optionally, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.

[0162] The software-implemented portion of the above-mentioned embodiment can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0163] The various illustrative logic units and circuits described in the embodiments of the present application can be implemented or operated by a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or the design of any combination thereof. The general-purpose processor can be a microprocessor, alternatively, the general-purpose processor can also be any traditional processor, controller, microcontroller or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other similar configuration to implement.

[0164] The steps of the methods or algorithms described in the embodiments of the present application can be directly embedded in hardware, software units executed by a processor, or a combination of the two. The software units can be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or other storage media in any form known in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium can also be integrated into the processor. The processor and storage medium can be arranged in an ASIC.

[0165] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0166] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, the present application is intended to include such modifications and variations if they fall within the scope of the claims of the present application and their equivalents.

Claims

1. A method for merging low-code development data, characterized in that: The method comprises: Receive a merge operation triggered by a user in a low-code development client, wherein the merge operation indicates merging multiple versions of workflow files; wherein each version of the workflow file includes a workflow, and the workflow is used to indicate a processing flow of a corresponding business function; In response to the merging operation, displaying a workflow set on the low-code development client, the workflow set being used to describe a plurality of first workflows included in the plurality of versions of workflow files to be merged; Receiving an editing operation triggered by a user in the low-code development client, wherein the editing operation is used to instruct the user to edit the workflow set; In response to the editing operation, a merged workflow file corresponding to the multiple versions of the workflow files is generated, and the merged workflow file includes at least one second workflow obtained after the user edits the workflow set.

2. The method according to claim 1, characterized in that The workflow set includes information of each third workflow in at least one third workflow, and the at least one third workflow is obtained by merging the multiple first workflows, or, The workflow set includes form data, where the form data includes information of each node among the multiple nodes included in each third workflow, or the form data includes information of each first workflow.

3. The method according to claim 1 or 2, characterized in that The workflow includes a plurality of nodes, each node is used to indicate a link in the processing flow; the low-code development client is also used to display homogeneous nodes and / or heterogeneous nodes in the workflow set; wherein the heterogeneous nodes include nodes that are different in the plurality of first workflows to be merged, and the homogeneous nodes include any node in the workflow set except the heterogeneous nodes; The editing operation includes one or more of the following operations: A retention operation on one or more homogeneous nodes in the workflow set, a deletion operation on one or more homogeneous nodes in the workflow set, a parameter configuration operation on one or more homogeneous nodes in the workflow set, a retention operation on one or more heterogeneous nodes in the workflow set, a deletion operation on one or more heterogeneous nodes in the workflow set, and a parameter configuration operation on one or more heterogeneous nodes in the workflow set.

4. The method according to claim 3, characterized in that The method further comprises: At least one first-level node in the plurality of first workflows is determined, the isomorphic nodes include the at least one first-level node, and the first-level nodes include nodes used to indicate a same link in the plurality of first workflows.

5. The method according to claim 3, characterized in that The method further comprises: Determine at least one first-level node in the plurality of first workflows to be processed, wherein the first-level node includes nodes in the plurality of first workflows that are used to indicate a same link; At least one secondary node is determined from the at least one primary node, the isomorphic nodes include the at least one secondary node, and the secondary nodes include the primary nodes configured with the same parameter values ​​in the multiple first workflows.

6. The method according to claim 4 or 5, characterized in that The determining of at least one primary node in the plurality of first workflows includes: converting each of the plurality of versions of the workflow files into graph data; The graph data corresponding to the multiple versions of the workflow files are used as input data of an isomorphic subgraph mining algorithm to obtain the at least one primary node output by the isomorphic subgraph mining algorithm.

7. The method according to any one of claims 3 to 6, characterized in that: The editing operation includes a parameter configuration operation on one or more heterogeneous nodes in the workflow set; Receive editing operations triggered by the user in the low-code development client, including: For each heterogeneous node among the one or more heterogeneous nodes, a parameter value input by a user in the low-code development client or selected from a candidate parameter list of the heterogeneous node is received; wherein the candidate parameter list includes different parameter values ​​configured for the heterogeneous node in the multiple first workflows.

8. The method according to any one of claims 1 to 7, characterized in that: The node includes a low-code component, which includes one or more of the following: a trigger, a connector, an operation, and a workflow.

9. A computing device, characterized in that: The device comprises: A receiving module is used to receive a merge operation triggered by a user in a low-code development client, wherein the merge operation indicates merging multiple versions of workflow files; wherein each version of the workflow file contains a workflow, and the workflow is used to indicate the processing of the corresponding business function. Management process; A processing module, configured to display a workflow set on the low-code development client in response to the merging operation, wherein the workflow set is used to describe a plurality of first workflows included in a plurality of versions of workflow files to be merged; The receiving module is further used to receive an editing operation triggered by a user in the low-code development client, wherein the editing operation is used to instruct the user to edit the workflow set; The processing module is further configured to generate, in response to the editing operation, a merged workflow file corresponding to the multiple versions of the workflow files, wherein the merged workflow file includes at least one second workflow obtained after the user edits the workflow set.

10. The device according to claim 9, characterized in that The workflow set includes information of each third workflow in at least one third workflow, and the at least one third workflow is obtained by merging the multiple first workflows, or, The workflow set includes form data, where the form data includes information of each node among the multiple nodes included in each third workflow, or the form data includes information of each first workflow.

11. The device according to claim 9 or 10, characterized in that The workflow includes a plurality of nodes, each node is used to indicate a link in the processing flow; the low-code development client is also used to display homogeneous nodes and / or heterogeneous nodes in the workflow set; wherein the heterogeneous nodes include nodes that are different in the plurality of first workflows to be merged, and the homogeneous nodes include any node in the workflow set except the heterogeneous nodes; The editing operation includes one or more of the following operations: A retention operation on one or more homogeneous nodes in the workflow set, a deletion operation on one or more homogeneous nodes in the workflow set, a retention operation on one or more heterogeneous nodes in the workflow set, a deletion operation on one or more heterogeneous nodes in the workflow set, and a parameter configuration operation on one or more heterogeneous nodes in the workflow set.

12. The device according to claim 11, characterized in that The device also includes a determination module; The determination module is used to determine at least one first-level node in the multiple first workflows, the isomorphic nodes include the at least one first-level node, and the first-level nodes include nodes used to indicate the same link in the multiple first workflows.

13. The device according to claim 11, characterized in that The device also includes a determination module; The determination module is used to determine at least one first-level node in the multiple first workflows, the first-level node includes nodes in the multiple first workflows used to indicate the same link; determine at least one second-level node from the at least one first-level node, the isomorphic node includes the at least one second-level node, and the second-level node includes the first-level nodes configured with the same parameter values ​​in the multiple first workflows.

14. The device according to claim 12 or 13, characterized in that When the determination module uses the isomorphic subgraph mining algorithm to determine at least one first-level node in the multiple first workflows, it is specifically used to: convert each workflow file into graph data based on the conversion rules corresponding to each version of the workflow files in the multiple versions of the workflow files to be merged; use the graph data corresponding to the multiple versions of the workflow files as input data of the isomorphic subgraph mining algorithm to obtain the at least one first-level node output by the isomorphic subgraph mining algorithm.

15. The device according to any one of claims 11 to 14, characterized in that: The editing operation includes a parameter configuration operation on one or more heterogeneous nodes in the workflow set; When receiving an editing operation triggered by a user in the low-code development client, the receiving module is specifically used to: for each of the one or more heterogeneous nodes, receive a parameter value input by the user in the low-code development client or selected from a candidate parameter list of the heterogeneous node; wherein the candidate parameter list includes different parameter values ​​configured for the heterogeneous node in the multiple first workflows.

16. The device according to any one of claims 9 to 15, characterized in that: The node includes a low-code component, which includes one or more of the following: a trigger, a connector, an operation, and a workflow.

17. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 8.

18. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 8.

19. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 8.

Images