Method and device for merging low-code development data

Abstract

The invention discloses a low-code development data merging method and device, and the method comprises the steps: receiving a merging operation triggered by a user at a low-code development client, the merging operation indicating a to-be-merged workflow file of multiple versions, the workflow file of each version comprising a workflow, and the workflow being used for indicating a processing flow of a corresponding service function; in response to the merging operation, displaying a workflow set on the low-code development client, the workflow set being used for describing a plurality of first workflows included in a plurality of versions of workflow files to be merged; an editing operation triggered by a user at the low-code development client is received, the editing operation is used for indicating the user to edit the workflow set, a combined workflow file is generated in response to the editing operation, and the combined workflow file comprises at least one second workflow obtained after the user edits the workflow set. According to the method, a multi-version workflow merging scheme is provided, multi-user low-code collaborative development is supported, and the development efficiency can be improved.

Description

[0001] This application claims the priority of the Chinese patent application filed with the Intellectual Property Office of the People's Republic of China on July 4, 2023, with application number 202310813203.1 and invention name "A Method for Merging Multi-version Data", all contents of which are incorporated by reference in this application. Technical Field

[0002] 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

[0003] With the rapid development of IT technology and mobile Internet, more and more traditional enterprises have begun to transform their processes and management through technical means in order to reduce costs and increase efficiency, making business development more efficient and standardized. In the process of digital transformation, problems such as low construction efficiency, long system construction cycle, and high development threshold are often encountered. Low-code development (LCD) has become an effective way to solve this problem.

[0004] Low-code development is a method of developing applications through visualization. By encapsulating the code into visual components, it realizes the technology of developing application systems by "drag and drop", aiming to allow developers to quickly build applications with a small amount of code or even no coding (zero code), instead of using the traditional way of writing code. Developers with different experience levels can use a graphical user interface to use drag-and-drop components to build the required functions such as business processes, logic and data models, which can greatly improve development efficiency and save enterprise project development and maintenance costs.

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

[0006] A method and device for merging low-code development data provided in an embodiment of the present application are used to implement a multi-person collaborative development technology that supports a low-code development platform, which is conducive to improving development efficiency.

[0007] 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 with a low-code development tool. The low-code development platform can be capable of providing low-code development services. In a 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, and the development content is saved in the form of a workflow file.

[0008] 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 may 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 may provide a low-code development interface and display the low-code development interface on the low-code development client, and 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, and 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, and 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).

[0009] Through the above method, users are supported to create multiple versions of workflows and to 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 multi-version workflows, providing flexibility, saving time and cost for developers in low-code development, meeting the needs of collaborative development by multiple people or development teams, and improving development efficiency.

[0010] In one possible design, the workflow set includes information of each third workflow in at least one third workflow, and 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.

[0011] 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, and 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.

[0012] 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 nodes included in the multiple first workflows; the editing operation on the workflow collection includes one or more of the following operations: a retention operation on one or more isomorphic nodes in the workflow collection, a deletion operation on one or more isomorphic nodes in the workflow collection, a retention operation on one or more heterogeneous nodes in the workflow collection, a deletion operation on one or more heterogeneous nodes in the workflow collection, and a parameter configuration operation on one or more heterogeneous nodes in the workflow collection.

[0013] 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, and reference can be provided to users 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 requirements.

[0014] In one possible design, the low-code development platform may also determine at least one first-level node in multiple workflows to be merged, and 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 multiple first workflows. Alternatively, in one possible design, the low-code development platform may also determine at least one first-level node in multiple first workflows, and determine at least one second-level node from the at least one first-level node, and 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 multiple first workflows.

[0015] Through the above method, multiple ways are supported to compare the differences of multiple versions of workflows, to achieve workflow comparisons of different precisions, and to recommend corresponding workflow differences based on merging requirements, providing flexibility in merging.

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

[0017] In one possible design, when the editing operation includes a parameter configuration operation 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.

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

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

[0020] 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 functions can be implemented by hardware, or by executing 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 execute 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.

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

[0022] In a fourth aspect, the present application also provides a computer-readable storage medium, which stores instructions, and when the computer-readable storage medium is run 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 method of the first aspect.

[0023] In the fifth aspect, the present application also provides a computer program product comprising instructions, which, when executed 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.

[0024] In the sixth aspect, the present application also provides a computer chip, which is connected to a memory, and the chip is used to read and execute software programs stored in the memory, and 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

[0025] Figure 1 A schematic diagram of a system architecture that may be applicable to the embodiments of the present application;

[0026] Figure 2 A schematic diagram of a user interface provided in an embodiment of the present application;

[0027] Figure 3 A flowchart for a low-code development-related technology;

[0028] Figure 4 A schematic diagram of the process of data merging for low-code development provided in an embodiment of the present application;

[0029] Figure 5 A flowchart of a method for merging low-code development data provided in an embodiment of the present application;

[0030] Figure 6 A schematic diagram of a first merging interface provided in an embodiment of the present application;

[0031] Figure 7 A schematic diagram of the comparison of workflows before and after merging provided in an embodiment of the present application;

[0032] Figure 8 A schematic diagram showing another comparison of workflows before and after merging provided in an embodiment of the present application;

[0033] Fig. 9 A schematic diagram of converting a workflow into graph data provided in an embodiment of the present application;

[0034] Fig.10 A schematic diagram of a process for determining homogeneous parts and heterogeneous parts based on graph data provided in an embodiment of the present application;

[0035] Fig.11 One of the schematic diagrams of a second merging interface provided in an embodiment of the present application;

[0036] Fig.12 A schematic diagram of a third merging interface provided in an embodiment of the present application;

[0037] Fig.13 A second schematic diagram of a second merging interface provided in an embodiment of the present application;

[0038] Fig.14 A third schematic diagram of a second merging interface provided in an embodiment of the present application;

[0039] Fig.15 A schematic diagram of a third workflow provided in an embodiment of the present application;

[0040] Fig.16 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0041] Fig.17 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0042] Fig.18 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0043] Fig.19 A schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] 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 called a low-code development service). Users can use the low-code development platform to develop applications by leasing the cloud service.

[0045] See also Figure 1 As shown in (a), Figure 1 (a) is a schematic diagram of a system that may be applicable to the embodiment of the present application, such as Figure 1 As shown in (a), the system includes a low-code development platform 200 and a low-code development client 101. Among them, the low-code development client 101 and the low-code development platform 200 can communicate through a network (such as the Internet).

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

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

[0048] The low-code development platform 200 is used to provide low-code development services. The user 132 can log in to the low-code development platform 200 through the browser, web plug-in and other tools in the low-code development client 101, and does not need to install the low-code development software locally on the low-code development client 101. It should be noted that in order to keep it simple, 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. The corresponding low-code development instances are used to provide services for each user. In some possible cases, the multiple users respectively operate their own low-code development clients to develop different business functions of the same application, or multiple users are used to develop the same business functions of the same application, or the multiple users can also develop the same business functions of different applications, and so on. These situations can be called a low-code development platform for multi-person collaborative development. In some descriptions, the application here can also be called a project or project.

[0049] In another application scenario, see Figure 1As shown in (b), user 133 installs low-code development tool (or software) 201 in the local low-code development client 102. Low-code development tool 201 can be a developer desktop / web tool, IDE plug-in, etc. It can be understood that low-code development tool 201 has software functions related to low-code development provided by low-code development platform 200. User 133 can run the low-code development tool 201 in the low-code development client 102 to develop applications. In some possible situations, multi-person collaborative development on the low-code development platform also includes multiple users adopting Figure 1 (b) or some users adopt Figure 1 (a) is used for development, while the rest of the users adopt Figure 1 Developed in the manner of (b).

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

[0051] Among them, the component library includes a series of low-code components (referred to as components), including general components and special components, etc. General components are usually encapsulated from common, general, and basic codes, and special components include encapsulated from special business codes, or special components also include components encapsulated from workflows. The canvas area is the "programming" area, which supports users (such as developers) to add components in the canvas area, set the connection relationship between components, configure the parameters of components, and other operations. Developers can drag the corresponding components from the component library to the canvas area according to the business process of the application to be developed. This requires developers to clearly know the required components, configure the parameters of the components, and splice the components through connections. After the splicing is completed, multiple components can form a workflow. That is, a workflow is used to describe the processing flow of one or more functions of a business. Each component constitutes a functional node in the workflow, which is used to indicate a processing link in the processing flow. Among them, according to the position of the component in the workflow, the component can be divided into a trigger and an action. The trigger is located at the first node of the workflow and is the condition for the workflow to start running. Components other than triggers in the workflow are called actions. Node is a general term for triggers and actions in a workflow.

[0052] For example, if Figure 2A workflow is shown, and the workflow sequence includes: Node 1: receiving http request → Node 2: obtaining cloud server list → Node 3: forwarding http request to cloud server → Node 4: cloud server processing http request → Node 5: 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-node 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.

[0053] It can be seen that on the low-code development platform, developers can develop applications by "drag and drop", which can greatly reduce the difficulty of development and shorten the development cycle, and complete the rapid generation and delivery of applications. At present, many cloud vendors provide low-code development services, however, the existing low-code development services still have many problems, such as:

[0054] In a related technology, low-code development services do not support the creation of multi-version workflow files. When developers use low-code development services to develop applications, they are manually developing with a single version from the creation of workflow files, component selection, complex logic configuration, node parameter filling, workflow debugging to the final workflow release. No other workflows or other versions of files are used. It can be seen that this solution cannot meet the needs of multi-person collaborative development on the low-code development platform.

[0055] In another related technology, low-code development services support the creation of multi-version workflow files. Users can query all versions of the project to which a certain version of a workflow file (hereinafter referred to as the file) belongs in the historical version. However, due to file version protection, the workflow in the old version file will be locked, and users can only view but cannot modify the workflow itself in the old version file. Alternatively, users can also add the old version of the workflow as a "component" to the canvas area of ​​the new version file as a node in the new version of the workflow, but this solution can only add new functions based on the old version of the workflow, that is, add new components based on the old version of the workflow, but cannot modify the old version of the workflow itself. If the user needs to modify the old version of the workflow, see Figure 3In the process shown, the user can only create a new workflow file and copy and paste the old version of the 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 of the workflow itself to generate a new workflow ( Figure 3 ).

[0056] Although Figure 3 The new workflow and the old version workflow may be two workflow versions edited for the same business function, but 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 it is necessary to compare file A and file B, they can only manually browse and find the two files for comparison and viewing. In other words, in the existing low-version development service, some business-related multiple 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 a low-code development platform.

[0057] 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, which 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.

[0058] 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 multi-version workflows, such as Figure 4A possible process of the merging technology shown is as follows: developers can open a certain version of a workflow file, obtain one or more new versions of workflow files based on the workflow of that version, and trigger the merge of the multiple versions of workflow files to determine the workflow set of the multiple versions of workflows to be merged. After that, the multiple versions of workflows can be mined to determine the isomorphic and heterogeneous parts in the multiple versions of workflows, and the workflow sets and similarities and differences of multiple versions of workflows can be visualized to guide developers 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 divide the work according to business needs for collaborative development and debugging. For the multiple versions of workflow files obtained by collaborative development, the comparison and merge of multiple versions of workflows can be triggered, which further saves time and cost for users or development teams using low-code development platforms for collaborative development, and improves overall development efficiency and online progress.

[0059] Next, apply to Figure 1 Taking the system shown in FIG. 1 as an example, the technical solution provided by this embodiment is specifically described. It should be understood that Figure 1 The two system architectures shown are merely exemplary and only provide components related to the embodiments of the present invention. Figure 1 This is not intended to limit the application of the present invention.

[0060] Figure 5 A flowchart corresponding to a method for merging low-code data provided in an embodiment of the present application. Figure 1 In (a), the method can be executed by the low-code development platform 200. Figure 1 In (b), the method can be executed by the low-code development client 102 or a component (such as a processor) of the low-code development client 102. For ease of explanation, the following will be combined with Figure 1 The system shown in (a) is introduced as follows: Figure 5 As shown, the method may include the following steps:

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

[0062] The low-code development platform 200 can be used to provide a first merged interface for low-code development. The "providing" here may refer to the low-code development platform 200 having the function of providing the first merged interface, or may 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.

[0063] In one embodiment, the low-code development platform 200 provides a user interface (referred to as the first merge interface) for triggering a multi-version workflow merge, such as Figure 6 (b) is a schematic diagram of a first merging interface, Figure 6 (a) is another user interface for triggering the first merged interface. Figure 6 As shown in (b), the first merge interface may include a file list and a confirmation button for triggering a merge of the selected multi-version workflow. The file list may include information of multiple workflow files, such as the version or name of the workflow file ( Figure 6 (not shown), the number of connectors, operations, and logical relationships included in the workflow of this version, etc. For example, Figure 6 In (b), each version number represents a workflow file, and each workflow file usually 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. Correspondingly, the low-code development platform 200 receives the merge operation triggered by the user in the first merge interface.

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

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

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

[0067] Method 1: The low-code development platform 200 provides a "Merge multiple versions" button for triggering the first merge interface, such as Figure 6 As shown in (a), the button is located in an independent user interface. The low-code development platform receives a user's click operation on the merge multiple versions button, and displays the following in response to the click operation: Figure 6 Alternatively, the button may be located at Figure 2 The canvas area or menu bar or toolbar of the user interface shown ( Figure 2 Not shown), no specific limitation is given.

[0068] 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 merged interface by entering or selecting specific commands or specific shortcut key operations in the command line window.

[0069] It should be noted that Figure 6 (a) and Figure 6 The user interfaces shown in (b) are all examples. In practice, the first merge interface may be Figure 6 Any deformation of the format shown in (b) or with relative Figure 6 (b) more or less content, etc. For example, the file list of the first merge interface applicable to this embodiment may also include detailed information of 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, and any method that can trigger the display of the first merge interface is applicable to this embodiment, such as triggering by voice or gesture, and this application does not limit this method.

[0070] The multiple versions of workflow files to be merged may include multiple versions of workflow files generated by the same user, or multiple versions of workflow files generated by multiple users through collaborative development, wherein the workflow files generated by multiple users can be synchronized and updated at one or more users through relevant data synchronization technology (such as git data synchronization method, etc.). Alternatively, the workflow files generated by multiple users are manually aggregated, for example, the workflow files of the corresponding projects are downloaded from other users respectively, or all users send their respective workflow files belonging to the same project to the same device, without specific limitation.

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

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

[0073] Step 503: The low-code development platform determines a workflow set based on multiple versions of workflow files to be merged.

[0074] The workflow set is used to describe multiple workflows included in multiple versions of workflow files to be merged (hereinafter referred to as 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.

[0075] 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 recorded as a first workflow, and each workflow obtained after the merger may be recorded as a second workflow.

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

[0077] For example, see Figure 7 , take 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 the first workflows of these four versions to obtain the following: Figure 7 In the second workflow shown in (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.

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

[0079] Taking a second workflow as an example, the second workflow may be generated by merging part of the first workflow to be merged, or the second workflow may 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 three versions v1, v2 and v3, and the other second workflow is generated based on the first workflows of two versions v4 and v5. Alternatively, one of the second workflows is generated based on the first workflows of four versions v1, v2, v3 and v4, and the other second workflow is the same as the first workflow of version v5.

[0080] It should be noted that Figure 7 The second workflow included in the workflow set in (b) is displayed in the form of workflow data. The workflow set in this embodiment can also be in other data forms, such as the workflow set including 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 description information of the nodes included in each second workflow (the description will be combined with Fig.13 Introduction, no further details are given here), etc., and this embodiment does not limit this.

[0081] In another embodiment, the workflow set includes information of each first workflow in the plurality of first workflows (hereinafter referred to as Fig.14 Introduction, no further elaboration here).

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

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

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

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

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

[0087] In other cases, the isomorphic node is a secondary node, which refers to a node in multiple first workflows that indicates the same processing flow, and the node is configured with the same parameter value in multiple first workflows. That is, the secondary node includes the primary nodes configured with the same parameter value in multiple first workflows. Correspondingly, the heterogeneous part includes any node (referred to as a heterogeneous node) other than the isomorphic part (secondary node) in the workflow set determined based on multiple first workflows, and optionally, it may also include any edge (referred to as a heterogeneous edge) other than the isomorphic edge.

[0088] The following is a flow chart of a method for determining the isomorphic parts and the heterogeneous parts, taking the second case as an example. Figure 8 and Fig. 9 It is understood that the method may include the following steps:

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

[0090] In one implementation, 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.

[0091] Those skilled in the art will know that the workflow is based on the workflow canvas code when it is stored in the backend and rendered in the front-end interface. The canvas code can represent the connection relationship of each node in the workflow and the parameters of the node and other information. The conversion rules of the workflow canvas code defined by each low-code development vendor and cloud service vendor may be different. The current workflow canvas code includes json format, DSL format and other formats.

[0092] 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 the system (such as the low-code development platform 200 or the cloud management platform, etc.) preset, and are not specifically limited.

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

[0094] Taking the adjacency matrix as an example, Fig.10 A schematic diagram of converting a workflow file into an adjacency matrix is ​​provided for this embodiment, wherein: Fig.10 The first workflow included in the workflow file is shown. 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.

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

[0096] 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 primary nodes in the multiple first workflows to be merged.

[0097] For example, in the above example, the adjacency matrices or association matrices corresponding to the multiple workflow files are respectively input into the isomorphic subgraph mining algorithm to obtain the output result of the isomorphic subgraph mining algorithm, which is used to indicate the primary nodes in the multiple first workflows to be merged.

[0098] Among them, isomorphic subgraph mining algorithms include but are not limited to: for example, Ullmann, VF2, Weisfeiler-Lehman, etc. The process of using isomorphic subgraph mining algorithms to obtain output results can be found in the relevant technical introduction, which will not be explained 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, see Fig. 9 As shown, some isomorphic subgraph mining algorithms require, in addition to the adjacency matrix or association matrix, vertex subgraphs, inbound / outbound edge subgraphs, edge type subgraphs, vertex type subgraphs, neighbor sampling subgraphs, etc. in the intermediate implementation process. These can be constructed specifically according to the needs of the algorithm, and this embodiment does not limit this.

[0099] Step 504 - 3 : Filter out the secondary nodes from the primary nodes.

[0100] 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 four versions of the workflow is the same (for example, the parameter A of the first-level node in the 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 the four versions of the workflow is filled in as string B), then determine that the first-level node is a second-level node. When there are multiple first-level nodes, each first-level node is screened in the above manner.

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

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

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

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

[0105] In one embodiment, the second merge interface displays each second workflow in the workflow set in a canvas form. Optionally, the homogeneous part and / or heterogeneous part of the second workflow can also be displayed in the canvas.

[0106] For example, take the second workflow as an example, see Fig.11 As shown, the second merge interface includes a display all option and a display difference option. When the user clicks the display all option, the second merge interface can display the second workflow in the canvas area. Fig.11 (a). The user clicks the Show Differences option, and the second merge interface displays the second workflow and marks the heterogeneous nodes therein. Fig.11 (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, both homogeneous nodes and heterogeneous nodes may be marked at the same time, which is not specifically limited.

[0107] 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 indicated by the user to be retained. Alternatively, the second merge interface can also provide a retention key corresponding to the node without displaying the delete key. The user indicates the node that needs to be retained by operating the retention key, and the node that has not clicked the retention key is the node indicated by the user to be deleted. In addition to the retention operation and the deletion operation, the user can also perform other edits on the second workflow in the canvas area, such as modifying the connection relationship between nodes, changing the parameter value of the node, etc.

[0108] The following is an introduction to the process of configuring the parameters of heterogeneous nodes by the user in this embodiment. Fig.12 As shown, Fig.12 The interface shown (recorded 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 value of the heterogeneous node. The user can directly fill in the corresponding parameter value (which can be a value 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 has appeared in the first workflows of both v2 and v3 versions. The heterogeneous node includes parameter C. In the first workflow of v2 version, parameter C of the heterogeneous node is configured with parameter value 1, and in the first workflow of v3 version, parameter C of the heterogeneous node is configured with parameter value 2. Then, 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 time, the configuration of a parameter of the heterogeneous node in the second merge interface is completed.

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

[0110] In another embodiment, the second merge interface displays the workflow set in a form. Optionally, the isomorphic parts and / or heterogeneous parts in the second workflow can also be displayed in the form.

[0111] For example, taking the workflow set including a second workflow as an example, the form can display the second workflow through the node dimension, see Fig.13 As shown, the form may include but is not limited to one or more of the following: all nodes included in the second workflow (these all nodes may be arranged in the order of logical relationships between the nodes), the http method, URI, description information of each node, the number of occurrences in multiple first workflows, the version number of the occurrences, and user operation options (such as including retention items and / or deletion items). It can be understood that a node that has appeared in all versions of the workflow is a first-level node, and when the same parameter of the first-level node is configured with the same parameter value in all versions of the workflow, the first-level node is also a second-level node.

[0112] For example, the form can also display the workflow set by version dimension, see Fig.14 As shown in , 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, the user clicks on the content details of a certain version of the workflow file to load and display the information of the nodes included in the workflow in the workflow file (and the nodes are arranged in a logical order). 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 occurrences, etc. of each node, see Fig.13 The relevant introduction in the example will not be repeated here. The user can trigger the editing operation through the form, including checking the version of the workflow file to be retained, thereby indicating the nodes and the connection relationships between the nodes that need to be retained in the second workflow.

[0113] 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 a final version.

[0114] It should be noted that the above-mentioned method of presenting a workflow set in the form of a canvas or a form is only an example, and any method that can present a workflow set to a user is applicable to this embodiment. Figure 11-Figure 14The method of representing difference information is only an example. The present application also supports representing difference information in other ways, such as distinguishing the first-level nodes in heterogeneous nodes, that is, nodes with different parameter values, etc., without specific limitation.

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

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

[0117] 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). Fig.11 The second workflow shown in the figure is edited, such as deleting the "Set pagesize" node, the "Loop" node, the "Conditional Judgment" node, and the "Filter Grouping" node in the second workflow, and retaining the remaining nodes. In response to the editing operation, the low-code development platform can obtain the following Fig.15 The third workflow is shown.

[0118] Optionally, before generating the third workflow, it may also include: node connectivity check (for checking whether there are isolated nodes) and integrity check (for checking whether all required parameters are filled in). Developers may also generate subsequent business codes, design files, etc. based on the generated third workflow, such as generating full code in languages ​​such as Java / Python / Go or API design files required for subsequent business.

[0119] It should be noted that Figure 5 The process steps shown in the method embodiment are only an example. In practice, the isomorphic parts may be recommended to the user after the isomorphic parts are determined, and then the heterogeneous parts are determined and then recommended to the user. The specific details are not limited. In addition, it should be noted that in Figure 1 In (b), the low-code development client 102 runs the low-code development tool 201 to execute the above Figure 5 The method executed by the low-code development platform 200 in the method embodiment is applicable to all low-code development methods in the present application embodiment. 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.

[0120] Through the above design, a multi-version workflow merging method for low-code development is provided. In this method, the creation of workflows supports multiple versions, allowing multiple users or development teams to collaborate in development. After completion, the differences between versions can be compared horizontally, and it supports merging multi-version workflow nodes (including connectors, operations and other granularities). It 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 time and cost for developers in low-code development and improving development efficiency. It ensures low-code collaborative development and helps the services developed by the team to be released quickly and accurately.

[0121] 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 generated new file will be abc.V2.

[0122] In view of this, the present embodiment also provides a technical support, which allows the user to edit a certain version of the workflow file on the basis of viewing the workflow file of the same version, 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. In this way, the user can create a version independently, and the user can add new functions on the basis of the old version of the workflow, and can also 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, the old version of the workflow can also be modified directly, without the need to redo it based on a blank canvas or a preset template, so that multiple workflow files with business relevance will not be split in version, which is convenient for users to search and compare, and provides flexibility and convenience for users. In an optional way, the present embodiment can also manage user accounts with such permissions by setting user permissions, so that the technical support is not open to all users to ensure the security traceability of application development.

[0123] Based on the same inventive concept as the method embodiment, the present application embodiment also provides a computing device, which is used to execute the above Figure 5The method implemented by the low-code development platform 200 in the method embodiment. Fig.16 As shown, in an example, the 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.

[0124] Receiving module 1602 is used to receive a merge operation triggered by a user in a low-code development client (such as a first merge interface displayed in the low-code development client), and the merge operation indicates a merge 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; please refer to the description of step 501 for details, which will not be repeated here.

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

[0126] Receiving module 1602 is also used to receive editing operations triggered by users in the low-code development client. The editing operations are 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.

[0127] The processing module 1603 is further used to generate a merged workflow file corresponding to multiple versions of the workflow files in response to the editing operation, and the merged workflow file includes at least one second workflow obtained after the user edits the workflow set. For details, please refer to the description of step 507, which will not be repeated here.

[0128] In one possible implementation, the workflow collection includes information of 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 of each node in the multiple nodes included in each third workflow, or the form data includes information of each first workflow.

[0129] 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 a workflow collection; wherein heterogeneous nodes include nodes that are different in multiple first workflows, and homogeneous nodes include any node in the workflow collection except heterogeneous nodes; for details, please refer to the description of step 504, which will not be repeated here.

[0130] The editing operation includes one or more of the following operations: a reservation 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 reservation 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. For details, please refer to the description of step 506, which will not be repeated here.

[0131] In a possible implementation, the determination module 1604 is used to determine at least one first-level node in the plurality of first workflows, wherein the isomorphic node includes at least one first-level node, and the first-level node includes nodes used to indicate the same link in the plurality of first workflows. For details, please refer to the description of step 504, which will not be repeated here.

[0132] In a possible implementation, the determination module 1604 is used to determine at least one first-level node in the multiple first workflows, where the first-level node includes nodes in the multiple first workflows that indicate the same link; and to determine at least one second-level node from the at least one first-level node, where the isomorphic node includes at least one second-level node, where the second-level node includes first-level nodes that are configured with the same parameter value in the multiple first workflows. For details, please refer to the description of step 504, which will not be repeated here.

[0133] In a 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: based on the conversion rules corresponding to each version of the workflow file in the multiple versions of the workflow files to be merged, convert each workflow file into graph data; 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 a possible implementation, the editing operation includes parameter configuration operations 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 one or more heterogeneous nodes, receive the parameter value input 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 multiple first workflows. For details, please refer to the description of step 504, which will not be repeated here.

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

[0135] In a possible implementation, the display module 1601 is used to display the first merged interface, the second merged interface, and the second merged interface.

[0136] Exemplarily, the implementation of the processing module 1603 in the computing device 1600 is described below by taking the processing module 1603 as an example. 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.

[0137] When implemented by software, the processing module 1603 may be an application or a 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 region or in different regions. Typically, a region may include multiple AZs.

[0138] Similarly, multiple hosts / virtual machines / containers for running 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.

[0139] When implemented by hardware, the processing module 1603 may include at least one computing device, such as a server, etc. Alternatively, the processing module 1603 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), etc. 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.

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

[0141] 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. There may be other division methods in actual implementation. The functional modules in the embodiments of the present application may be integrated into one module, or each module may exist physically separately, or two or more modules may be integrated into one module, for example, the prompt module 1601 and the receiving module 1602 are integrated into one module, or the prompt 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.

[0142] The present application also provides a computing device 1700. Fig.17 As shown, computing device 1700 includes: bus 1702, processor 1704, memory 1706 and communication interface 1708. Processor 1704, memory 1706 and communication interface 1708 communicate through bus 1702. Computing device 1700 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 1700.

[0143] The bus 1702 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.17 The bus 1702 may include a path for transmitting information between various components of the computing device 1700 (eg, the memory 1706, the processor 1704, and the communication interface 1708).

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

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

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

[0147] 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 communication networks.

[0148] The embodiment of 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 smart phone.

[0149] like Fig.18 As shown, 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.

[0150] In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also respectively 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 may jointly execute instructions for executing the method for merging low-code development data.

[0151] It should be noted that the memory 1706 in different computing devices 1700 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the data access device. That is, the instructions stored in the memory 1706 in different computing devices 1700 can implement the functions of one or more modules of the display module 1601, the receiving module 1602, the processing module 1603, and the determination module 1604.

[0152] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.19 A possible implementation is shown. Fig.19 As shown, 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. At the same time, the memory 1706 in the computing device 1700B stores instructions for executing the functions of the processing module 1603 and the determination module 1604.

[0153] It should be understood that Fig.19 The functionality of the computing device 1700A shown in FIG. 1700A 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.

[0154] The present application embodiment also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to that of Fig.18 and Fig.19 The connection mode of the computing device cluster. The difference is that 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.

[0155] In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also respectively 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 may jointly execute instructions for executing the method for merging low-code development data.

[0156] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or 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 at least one computing device is caused to execute the method for merging low-code development data, or the computing device is instructed to execute the method for merging low-code development data.

[0157] The 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 hard disk). 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.

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

[0159] The software-implemented part in 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 may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may 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 may be transmitted from a website site, a computer, a server, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server, or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that includes one or more available media integrated. The available medium may 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)), etc.

[0160] 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 of the above functions. The general-purpose processor can be a microprocessor, and optionally, 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.

[0161] The steps of the method or algorithm described in the embodiments of the present application can be directly embedded in the software unit executed by the hardware, the processor, or a combination of the two. The software unit can be stored in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM or other storage media of any form 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 can write information to the storage medium. Alternatively, the storage medium can also be integrated into the processor. The processor and the storage medium can be arranged in an ASIC.

[0162] 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, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0163] Although the present application has been described in conjunction with specific features and embodiments thereof, it is obvious 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 exemplary illustrations of the present application as defined by the appended claims, and are deemed to have covered any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, a person skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

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 workflow file 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 users 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, 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 includes a workflow, and the workflow is used to indicate a processing flow of a corresponding business function; 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