A file generation method and a computing device

Abstract

This application provides a file generation method and computing device, relating to the field of computing device technology, and solves the problem that business flow execution objects cannot quickly and accurately identify business flow data generated by canvas components. The method includes: receiving initial business flow data of a business flow to be processed generated by a first canvas component; the data format of the initial business flow data conforms to the data format defined by the first canvas component; converting the initial business flow data according to preset structured format rules to obtain target business flow data of the business flow to be processed; the data format of the target business flow data conforms to the data format defined by the structured format rules; obtaining the object type of the business flow execution object executing the business flow to be processed, and converting the target business flow data into a business flow execution file recognizable by the business flow execution object according to the object type.

Description

Technical Field

[0001] This application relates to the field of computing device technology, and in particular to a file generation method and computing device. Background Technology

[0002] With the deepening of enterprise digital transformation, business process management (BPM) systems are widely used in scenarios such as approval workflows, work order processing, and robotic process automation (RPA) orchestration. Creating business flows, as a core component of a BPM system, is typically designed visually using a graphical canvas component, and the designed business flow data is executed by calling the business flow execution object.

[0003] As a front-end design tool, the canvas component can receive user drag-and-drop and connection operations, and generate business flow data describing the business flow structure, so that the business flow execution object can process the business flow.

[0004] However, different canvas components generate data in different formats, and these data formats often differ from the file formats required by the business flow execution object, which makes it impossible for the business flow execution object to quickly and accurately identify the business flow data generated by the canvas component. Summary of the Invention

[0005] This application provides a file generation method and computing device, which solves the problem that the business flow execution object cannot quickly and accurately identify the business flow data generated by the canvas component.

[0006] In a first aspect, embodiments of this application provide a file generation method, the method comprising: receiving initial business flow data of a business flow to be processed generated from a first canvas component; the data format of the initial business flow data satisfying the data format defined by the first canvas component; converting the initial business flow data into a data format according to preset structured format rules to obtain target business flow data of the business flow to be processed; the data format of the target business flow data satisfying the data format defined by the structured format rules; obtaining the object type of the business flow execution object that executes the business flow to be processed, and converting the target business flow data into a business flow execution file recognizable by the business flow execution object according to the object type; the business flow execution file being used to request and invoke the business flow execution object to execute the business flow to be processed.

[0007] This application's embodiments introduce structured format rules as an intermediate conversion layer to uniformly convert the initial business flow data generated by the first canvas component into target business flow data defined by the structured format rules. This eliminates the need for the first canvas component to be concerned with the specific format requirements of the backend business flow execution object, and the business flow execution object does not need to adapt to the data formats of different canvas components. Regardless of the data format used by the first canvas component to define the business flow data, as long as it can be converted through structured format rules, a business flow execution file that the business flow execution object can recognize can be generated. This decouples the strong relationship between the front-end canvas component and the back-end business flow execution object, eliminating the need to develop separate adaptation code for each combination of canvas component and business flow execution object, thereby significantly reducing the development cost of multi-platform adaptation.

[0008] Secondly, since the embodiments of this application do not limit the specific type of the first canvas component, any canvas component capable of generating business flow data can be used as the first canvas component. When enterprises need to build low-code platforms or customized process designers, they can freely choose more lightweight, easier-to-integrate, or more suitable open-source canvas components for specific business scenarios without worrying about the incompatibility between the data format generated by the selected canvas component and the backend business flow execution object, thereby significantly improving the freedom of front-end technology selection.

[0009] In some embodiments, the initial business flow data is converted into a data format according to a preset structured format rule to obtain the target business flow data of the business flow to be processed, including: extracting the node information of each business node in the initial business flow data; determining the node semantics of each business node based on the node information of each business node, and determining the data fields mapped by each business node in the data structure defined by the structured format rule based on the node semantics; filling the node information of each business node into the data fields mapped in the data structure defined by the structured format rule, and assembling the filled data according to the data structure defined by the structured format rule to obtain the target business flow data.

[0010] In this embodiment, by extracting the node information of each business node in the initial business flow data, determining the data fields mapped in the data structure defined by the structured format rules according to the node semantics, and filling the node information into the corresponding data fields before assembly, the initial business flow data described by different canvas components using different private data formats is accurately converted into target business flow data defined by unified structured format rules, laying a unified data foundation for the subsequent generation of business flow execution files.

[0011] In some embodiments, node information includes: node type, extended attributes, and node connection relationships; the extended attributes are used to store the business configuration parameters of the business node in key-value pairs.

[0012] In this embodiment, by defining node information including node type, extended attributes, and node connection relationships, and explicitly storing business configuration parameters in key-value pairs for extended attributes, the target business flow data can fully retain the type attributes of business nodes, business configuration parameters, and flow relationships between nodes. This ensures the integrity of business semantics and provides the full amount of information required for subsequent conversion and execution.

[0013] In some embodiments, when the node type is a gateway type, the extended attribute contains a condition array, where each condition element is used to define the branch routing logic of the service node of the gateway type.

[0014] In this embodiment, by limiting the extended attributes to include a condition array when the node type is a gateway type, and each condition element is used to define the branch routing logic, the complex condition branch logic of the gateway node can be centrally and explicitly expressed in the unified target business flow data. This avoids the parsing complexity caused by the branch conditions being scattered in the connection, and makes it easier for the subsequent converter to accurately generate sequential flow elements with condition expressions.

[0015] In some embodiments, converting target business flow data into a business flow execution file recognizable by the business flow execution object, based on the object type, includes: determining a set of conversion rules for object type adaptation based on the object type; the set of conversion rules is used to define the mapping relationship between data fields in the structured format rules and data elements in the business flow execution file recognizable by the business flow execution object; determining the conversion rule for each data field in the target business flow data from the set of conversion rules, and converting the corresponding data field according to the conversion rule to obtain multiple data elements; assembling the multiple data elements according to a preset layout style to obtain a business flow execution file recognizable by the business flow execution object.

[0016] In this embodiment, by determining the appropriate set of conversion rules based on the object type, determining the conversion rules for each data field from the set of conversion rules and converting them into multiple data elements, and then assembling them into a business flow execution file according to a preset layout style, automatic adaptation and conversion from unified target business flow data to a file format recognizable by the specific business flow execution object is achieved, ensuring that the generated business flow execution file conforms to the syntax specifications and deconstruction requirements of the target execution object.

[0017] In some embodiments, the method further includes: obtaining node metadata of the business node to be registered; the node metadata includes: node type, node display name, node display icon, execution binding method, input data structure, and output data structure; the execution binding method is used to indicate the business execution method required when the corresponding business node is called, the input data structure is used to indicate the data structure of the input data required when the corresponding business node is called, and the output data structure is used to indicate the data structure of the output data after the corresponding business node is called; if the node metadata of the business node to be registered meets the registration conditions, the node metadata is sent to the first canvas component to add the business node to be registered to the list of registered business nodes, so that the first canvas component displays the list of registered business nodes including business nodes whose node metadata meets the registration conditions on the node list display interface.

[0018] In this embodiment, by obtaining the node metadata of the business node to be registered and adding it to the list of registered business nodes when the registration conditions are met, and simultaneously sending the node metadata to the first canvas component, the first canvas component displays the list of registered business nodes. This allows business personnel or low-code developers to dynamically extend new business node types simply by configuring node metadata, without modifying the core code. The front-end canvas component automatically loads and displays the newly added nodes, thus decoupling the node definition from the system core code.

[0019] In some embodiments, the method further includes: parsing the business flow execution file to obtain the node type of each business node in the business flow to be processed; obtaining the execution binding method, input data structure, and output data structure of each business node in the business flow to be processed from the list of registered business nodes according to the node type of each business node; obtaining the input data of each business node from the processing flow context information of the business flow to be processed according to the input data structure of each business node; sending the corresponding input data to each business node according to the execution binding method of each business node; receiving the processing result generated by each business node according to the corresponding input data; and determining the business processing result of the business flow to be processed according to the processing result of each business node in the business flow to be processed.

[0020] In this embodiment, by parsing the business flow execution file to obtain the node type, the corresponding execution binding method, input data structure and output data structure can be obtained from the list of registered business nodes according to the node type. Then, based on this information, the corresponding input data to be sent to each business node is determined and sent to each business node, so that each business node generates a processing result based on the corresponding input data. This achieves unified scheduling and execution of registered business nodes, allowing different business nodes to share the same execution framework without having to write dedicated execution code for each node type.

[0021] Furthermore, by obtaining the input data of each business node from the processing flow context information of the business flow to be processed, it can be ensured that the input data is real-time and accurate, thus avoiding the problem of reduced accuracy of the processing results generated by the business nodes.

[0022] In some embodiments, the method further includes: obtaining the output data structure of each business node from the business node list according to the node type of each business node; adding the processing result of the current business node to the processing flow context information of the business flow to be processed if the processing result of the current business node satisfies the data structure defined by the output data structure; the current business node is any business node in the business flow to be processed.

[0023] In this embodiment, by verifying the processing results returned by the business nodes according to the output data structure and writing them into the processing flow context information of the business flow to be processed, a complete closed-loop management of the execution process of the business nodes is realized. This can improve the standardization of the output data of the business nodes and reliably pass the processing results to subsequent nodes for use.

[0024] In a second aspect, embodiments of this application provide a computing device including a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computing device to implement the methods provided in the first aspect and its possible embodiments described above.

[0025] Thirdly, embodiments of this application provide a computer-readable storage medium comprising: computer software instructions; when the computer software instructions are executed in a computing device, they cause the computing device to implement the methods provided in the first aspect and its possible embodiments.

[0026] Fourthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a computing device, cause the computing device to perform the steps of the related method described in the first aspect above, so as to implement the method of the first aspect above.

[0027] The beneficial effects of the second to fourth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0028] Figure 1 A schematic diagram of the logical hierarchy architecture of a computing device provided in an embodiment of this application; Figure 2 A flowchart illustrating a file generation method provided in an embodiment of this application; Figure 3 A flowchart illustrating another file generation method provided in this application embodiment; Figure 4 A flowchart illustrating another file generation method provided in this application embodiment; Figure 5 A flowchart illustrating another file generation method provided in this application embodiment; Figure 6 A flowchart illustrating another file generation method provided in this application embodiment; Figure 7 A flowchart illustrating another file generation method provided in this application embodiment; Figure 8 A flowchart illustrating another file generation method provided in this application embodiment; Figure 9 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0030] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0031] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0032] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0033] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0034] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0035] As described in the background section, the creation of business flows, as a core component of a business process management system, typically relies on the Business Process Model and Notation (BPMN) 2.0 standard. It involves visual design using a graphical canvas component and deploying the model to a backend process engine (such as Camunda, Flowable, Activiti, etc.) for execution.

[0036] Specifically, a canvas component can be deployed on the computing device. This canvas component provides a visual process design interface, which contains various process node components (such as start nodes, task nodes, gateway nodes, end nodes, etc.). Designers can drag and drop the required node components onto the canvas area and define the flow order and conditions between nodes through connection operations.

[0037] In response to user operations, the computing device generates business flow data in memory that describes the business flow created by the user. This business flow data is typically organized in a format defined by the BPMN 2.0 standard and stores the identifier, type, location information, extended attributes, and connection relationships between nodes in the process in the form of Extensible Markup Language (XML).

[0038] After the designers complete the process design, the deployment operation is triggered. The computing device exports the business flow data stored in memory into a standard process definition file and submits the file to the process engine. After receiving the process definition file, the process engine parses it, extracts the node information, connection relationships and configuration parameters in the file, and builds an executable process instance structure within the engine.

[0039] Subsequently, when a business request triggers the process, the process engine creates a process instance based on the deployed process definition, executes it sequentially according to the node order, calls the corresponding business logic, and records the status and variables during the process execution.

[0040] However, in actual implementation, creating business workflows faces a serious coupling problem between the front-end canvas and the back-end engine. Mainstream open-source workflow engines are deeply bound to their official canvas components (such as BPMN.js), making it difficult for enterprises to flexibly choose other lighter, easier-to-integrate, or more suitable open-source canvas components (such as LogicFlow, AntV X6, G6, BPMN-mxgraph, etc.) when building low-code platforms or customized workflow designers. This not only limits the freedom of front-end technology selection but also significantly increases the development and maintenance costs of multi-platform adaptation.

[0041] Furthermore, BPMN 2.0 itself is a complex specification based on Extensible Markup Language, containing a large amount of enterprise-level semantics and redundant structures. For lightweight application scenarios (such as simple approval and task distribution), its model size is large, its parsing efficiency is low, and its learning curve is steep, making it difficult for non-BPMN 2.0 native canvases to directly understand or efficiently render.

[0042] Based on this, embodiments of this application provide a file generation method that can receive initial business flow data of a business flow to be processed generated by a first canvas component. The data format of this initial business flow data conforms to the data format defined by the first canvas component. Next, the initial business flow data can be converted according to preset structured format rules to obtain target business flow data of the business flow to be processed. The data format of this target business flow data conforms to the data format defined by the structured format rules. Subsequently, the object type of the business flow execution object that executes the business flow to be processed can be obtained, and the target business flow data can be converted into a business flow execution file recognizable by the business flow execution object based on the object type. This business flow execution file is used to request and invoke the business flow execution object to execute the business flow to be processed.

[0043] As can be seen from the above, this embodiment of the application introduces structured format rules as an intermediate conversion layer to uniformly convert the initial business flow data generated by the first canvas component into the target business flow data defined by the structured format rules. This eliminates the need for the first canvas component to be concerned with the specific format requirements of the backend business flow execution object, and the business flow execution object does not need to adapt to the data formats of different canvas components. Regardless of the data format used by the first canvas component to define the business flow data, as long as it can be converted through structured format rules, a business flow execution file that the business flow execution object can recognize can be generated. This decouples the strong relationship between the front-end canvas component and the back-end business flow execution object, eliminating the need to develop separate adaptation code for each combination of canvas component and business flow execution object, thereby significantly reducing the development cost of multi-terminal adaptation.

[0044] Secondly, since the embodiments of this application do not limit the specific type of the first canvas component, any canvas component capable of generating business flow data can be used as the first canvas component. When enterprises need to build low-code platforms or customized process designers, they can freely choose more lightweight, easier-to-integrate, or more suitable open-source canvas components for specific business scenarios without worrying about the incompatibility between the data format generated by the selected canvas component and the backend business flow execution object, thereby significantly improving the freedom of front-end technology selection.

[0045] The system architecture of the embodiments of this application will be described below as an example.

[0046] The file generation method provided in this application embodiment can be applied to computing devices.

[0047] This application does not impose any restrictions on the specific form of the computing device. For example, the computing device can be a server. The server can be a single server or a server cluster consisting of multiple servers. In some embodiments, the server cluster can also be a distributed cluster, which is not limited in this application. As another example, the computing device can specifically be a terminal device. The terminal device can be referred to as: terminal, user equipment (UE), terminal device, access terminal, user unit, user station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or user equipment, etc. Specifically, the terminal device can be a mobile phone, augmented reality (AR) device, virtual reality (VR) device, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc.

[0048] When a computing device executes the file generation method provided in this application embodiment, it can divide the internal structure of the computing device into multiple logical levels according to the method execution logic. For example, such as... Figure 1 As shown, the computing device may include: a front-end process canvas layer, an intermediate presentation layer, a back-end process engine layer, and a business execution system.

[0049] The front-end process canvas layer provides a visual process design interface, interacts with users, generates initial business flow data, and manages business node registration.

[0050] In one possible implementation, the front-end flow canvas layer can include multiple canvas components, such as a first canvas component, a second canvas component, etc.

[0051] Users can perform business flow creation operations on various canvas components (such as the first canvas component) to generate initial business flow data for the business flow to be processed. The data format of this initial business flow data conforms to the data format defined by the first canvas component.

[0052] The intermediate representation layer is used to receive the initial business flow data of the business flow to be processed generated by the canvas component (such as the first canvas component) in the front-end process canvas layer, and convert the initial business flow data into a unified intermediate representation (i.e. target business flow data), thereby decoupling the front-end canvas component from the back-end business flow execution object.

[0053] In one possible implementation, the intermediate representation layer may include an adapter (also known as a multi-source adapter module) for parsing the initial business flow data generated by different canvas components (such as LogicFlow, ReactFlow, BPMN-js, etc.) and converting it into a unified intermediate representation (i.e., the target business flow data).

[0054] The backend process engine layer is used to convert the target business flow data generated by the intermediate presentation layer into a business flow execution file that can be recognized by the specific business flow execution object, thereby achieving adaptation to different business flow execution objects.

[0055] The backend process engine layer can include a converter factory module, a node converter module library, and an assembler module.

[0056] The converter factory module is used to obtain the object type of the business flow execution object to be processed, and determine the set of conversion rules that are suitable for that object type. This set of conversion rules is used to define the mapping relationship between the data fields in the structured format rules and the data elements in the business flow execution file that the business flow execution object can recognize.

[0057] The converter factory module is also used to obtain the node converter corresponding to each data field in the target business flow data from the node converter module library, and distribute each data field in the target business flow data to the corresponding node converter for conversion processing.

[0058] The node converter module library stores multiple node converters. Each node converter corresponds to a data field type or a business node type. It is used to convert the field content of the corresponding data field in the target business flow data into data elements in the business flow execution file that can be recognized by the business flow execution object, according to the conversion rules defined in the conversion rule set.

[0059] Optionally, the node converter module library supports dynamic expansion. When it is necessary to adapt to new business flow execution object types or new data field types, new node converters can be registered in the node converter module library.

[0060] The assembler module receives multiple data elements converted by each node converter in the node converter module library, and assembles the multiple data elements according to a preset layout style to obtain a business flow execution file that can be recognized by the business flow execution object.

[0061] The preset layout style defines the organizational structure of data elements in the business flow execution file, including the arrangement order of data elements, hierarchical relationships, indentation format, and file header and footer information. The assembler module is also used to perform integrity verification on the business flow execution file after assembly to ensure that the file format meets the parsing requirements of the business flow execution object.

[0062] The business flow execution object can be deployed in the backend process engine layer or in the business execution system. It is used to parse the business flow execution file, obtain the input data of each business node in the business flow to be processed based on the parsing results, and send the corresponding input data to each business node in the business flow to be processed.

[0063] The business execution system includes multiple business nodes. Each business node is used to call the corresponding business logic to complete the processing flow of the business node based on the input data sent by the business flow execution object, thereby obtaining the corresponding processing result.

[0064] The business flow execution object can also define the complete business processing result of the business flow to be processed based on the processing result of each business node.

[0065] Figure 2 It further demonstrates the module composition within each level and the flow of data between levels.

[0066] Combination Figure 1 ,like Figure 2As shown, the front-end workflow canvas layer can contain multiple canvas components of different types, such as canvas component 1, canvas component 2, canvas component 3, canvas component 4, etc. These canvas components can be open-source canvas components implemented using different technologies such as LogicFlow, ReactFlow, and BPMN-js. Different canvas components use different proprietary data formats when generating business flow data.

[0067] The intermediate representation layer is located between the front-end process canvas layer and the back-end process engine layer. It is used to convert the initial business flow data generated by the front-end process canvas layer into a unified intermediate representation (i.e., target business flow data), thereby decoupling the front-end canvas component from the back-end business flow execution object (also known as the back-end engine).

[0068] The adapter in this layer is used to parse the initial business flow data generated by different canvas components and using different proprietary data formats, and convert them into a unified intermediate representation. Regardless of which canvas component is used on the front end, the output target business flow data after the adapter conversion uses the same data format defined by the same structured format rules, thus shielding the differences between the front end canvas components.

[0069] The backend process engine layer can call different backend process engines and use a converter to convert the target business flow data generated by the intermediate presentation layer into a business flow execution file that can be recognized by the business flow execution object.

[0070] like Figure 2 As shown, the backend process engine can include backend process engine 1, backend process engine 2, and backend process engine 3, etc. These backend process engines can be different types of execution engines such as Camunda, Flowable, and Activiti. These backend process engines can generate corresponding and recognizable business flow execution files for different types of business flow execution objects.

[0071] Optional, such as Figure 2As shown, the aforementioned business flow execution objects can be different types of business flow execution objects, such as those corresponding to artificial intelligence services (AI), optical character recognition (OCR), natural language processing (NLP), risk control systems (RCS), microservices (MS), application programming interfaces (APIs), form engines (FE), and permission control centers (PCCs) (used to provide permission control).

[0072] The business execution system connects with the backend process engine layer. After receiving the business flow execution file, the business flow execution object can parse the file content, obtain the input data of each business node in the business flow to be processed based on the parsing results, and send the corresponding input data to each business node in the business flow to be processed, thereby completing the execution of the business flow to be processed.

[0073] During collaborative work, the business execution system schedules each business node sequentially according to the node order and dependencies defined in the business flow execution file. When a node completes its execution, its output data is used as the input data for the next node and transmitted between business nodes through a data interaction mechanism.

[0074] The aforementioned data interactions can be performed using a unified data format (such as JavaScript object notation (JSON) objects) and through predefined interface specifications (such as representational state transfer API (REST API) or message queues).

[0075] For scenarios involving the parallel execution of multiple business flow execution objects, the business execution system also supports concurrent scheduling and result aggregation to ensure that the entire business flow is executed correctly according to predefined logic. Furthermore, the business execution system records the execution status, input / output data, and exception information of each node for easy monitoring and auditing.

[0076] Through the collaborative work of the above four-layer architecture, the embodiments of this application realize unified process modeling and execution from diverse canvas components to multiple backend engines, significantly reducing the limitations of front-end technology selection and back-end adaptation costs, and improving the flexibility and execution efficiency of business processes.

[0077] The aforementioned modules work together to form the complete processing flow of the file generation method provided in this application embodiment. The specific implementation process of each module's function at each level can be found in the following description, and will not be repeated here.

[0078] It should be pointed out that, Figure 1 The hierarchical architecture shown does not constitute a limitation on the internal structure of computing devices, except... Figure 1 In addition to the individual levels and modules shown, a computing device may include more or fewer levels and / or modules than shown, or combine certain levels and / or modules, or have different arrangements of levels and / or modules.

[0079] The document generation method provided in the embodiments of this application will be described in detail below.

[0080] like Figure 3 The diagram shown is a flowchart illustrating a file generation method provided in an embodiment of this application. The file generation method includes: S301. Receive initial business flow data from the business flow to be processed generated by the first canvas component.

[0081] The initial business flow data has a data format that meets the data format defined by the first canvas component.

[0082] The First Canvas component is a visual process design tool deployed on computing devices, providing users with a graphical process design interface. This interface includes various types of business node components, such as start nodes, end nodes, user task nodes, service task nodes, and gateway nodes. Users can drag and drop the required business node components from the component library onto the canvas area, and define the flow order and conditional branches between various business nodes through connection operations.

[0083] When a user performs a business flow creation operation on the first canvas component, the first canvas component responds to the operation by generating initial business flow data in memory that describes the business flow to be processed. This initial business flow data is organized using a proprietary data format defined by the first canvas component itself, which is used to support the first canvas component in displaying, editing, and storing the business flow.

[0084] Next, the first canvas component can send the generated initial business flow data of the business flow to be processed to the intermediate presentation layer, so that the intermediate presentation layer can subsequently convert the initial business flow data according to the preset structured format rules to obtain the target business flow data of the business flow to be processed.

[0085] In one feasible approach, the initial business flow data includes at least the node identifier, node type, node location information, node extended attributes, and connection relationships between nodes for each business node.

[0086] Among them, the node extended attributes store the business configuration parameters of the business node in the form of key-value pairs, such as node name, handler configuration, timeout time, etc.

[0087] It should be noted that the proprietary data formats used by the first canvas components implemented with different technologies vary. For example, the LogicFlow canvas component, ReactFlow canvas component, and BPMN-js canvas component each define different data structures to describe the business flow.

[0088] The first canvas component in this application embodiment can be any of the canvas components described above, or it can be other types of visual process design tools. This application embodiment does not limit this.

[0089] In one possible implementation, before the user performs the business flow creation operation, the business nodes to be registered can be pre-added to the list of registered business nodes through the node registration module, and the list of registered business nodes can be displayed on the node list display interface of the first canvas component for the user to drag and drop. The specific process of node registration will be described in detail in subsequent embodiments.

[0090] S302. Convert the initial business flow data according to the preset structured format rules to obtain the target business flow data of the business flow to be processed.

[0091] The target business flow data must conform to the data format defined by the structured format rules.

[0092] After generating the initial business flow data, this data needs to be converted into a unified intermediate representation to decouple the front-end canvas component from the back-end business flow execution object. For this purpose, the intermediate representation layer can obtain preset structured format rules.

[0093] Structured format rules, also known as JSON Schema, define a unified data structure that is independent of specific canvas components, used to describe the various business nodes and their relationships in the business flow.

[0094] In one feasible approach, this structured formatting rule (i.e., JSON Schema) is designed as a structured, extensible intermediate presentation layer specification containing the following core fields: The schema version field identifies the version number of the structured format rule, facilitating subsequent compatibility management. When the structured format rule is upgraded or changed, this field allows differentiation between different versions of the rule definition, ensuring the correctness of data conversion and backward compatibility.

[0095] The `nodes` field describes all the business nodes contained in the pending business flow. The `nodes` list is an array structure, where each element corresponds to a business node. Each business node contains the following subfields: Node identifier (id): A string used to uniquely identify the business node, which cannot be repeated within the same business flow.

[0096] Node type (type): Used to identify the type of business node, such as start event, user task, exclusive gateway, AI preprocess, etc.

[0097] Node Name (name): The display name used to show the business node, making it easy for users to identify and understand.

[0098] Extended properties: These are used to store the business configuration parameters of this business node in key-value pairs. Extended properties support nested structures, which can flexibly accommodate personalized configurations for different business scenarios, such as assignee configuration, form key, confidence threshold, etc.

[0099] The edges field describes the flow relationships between various business nodes in the pending business flow. The edges list is an array structure, where each element corresponds to a edge, and each edge contains the following subfields: edge identifier (id), source node identifier (source), and target node identifier (target).

[0100] The connection identifier is a string used to uniquely identify the connection. The source node identifier is the node identifier of the starting business node of the connection. The target node identifier is the node identifier of the target business node of the connection.

[0101] In one possible implementation, for gateway-type business nodes, their extended attributes also include a conditions array field. The conditions array explicitly defines the branching routing logic of the gateway node in array form. Each condition element in the array defines the mapping relationship between the condition expression of a branch and the target node identifier that the branch points to. Through the conditions array, routing rules in complex branching scenarios such as exclusive gateways and inclusive gateways can be clearly expressed.

[0102] When converting the initial business flow data according to the aforementioned structured format rules, the node information of each business node in the initial business flow data can be extracted first. Based on this node information, the semantics of each business node can be determined, thereby identifying the data fields mapped to each business node in the data structure defined by the structured format rules. Subsequently, the node information of each business node is filled into the data fields mapped in the data structure defined by the structured format rules, and the filled data is then assembled according to the data structure defined by the structured format rules to form the complete target business flow data.

[0103] The specific implementation details regarding the node information (including node type, extended attributes, and node connection relationships), the condition array structure of gateway type nodes, the method for determining node semantics, and the mapping relationship between node information and data fields will be described in detail in subsequent embodiments.

[0104] The target business flow data is organized using a data format defined by structured format rules. Its data structure is independent of the private data format of the first canvas component itself, but instead adopts a unified intermediate representation that is decoupled from the front-end canvas component.

[0105] Through the above conversion process, regardless of the private data format used by the first canvas component to describe the business flow, it can be converted into unified target business flow data. This target business flow data supports efficient parsing in lightweight application scenarios and retains the personalized configuration capabilities of business nodes through extended attribute fields, thus laying a unified data foundation for subsequently generating recognizable business flow execution files for different business flow execution objects.

[0106] S303. Obtain the object type of the business flow execution object to be processed, and convert the target business flow data into a business flow execution file that can be recognized by the business flow execution object according to the object type.

[0107] Among them, the business flow execution file is used to request and invoke the business flow execution object to execute the business flow to be processed.

[0108] After obtaining the target business flow data, it is necessary to convert this unified intermediate representation into a business flow execution file that can be recognized and executed by the specific business flow execution object.

[0109] A business flow execution object refers to the entity that actually performs business processing functions, such as AI service business objects, OCR business objects, and NLP business objects. Since different business flow execution objects require different file formats, adaptation and conversion are necessary based on the object type of the business flow execution object.

[0110] Specifically, the object type of the business flow execution object that executes the pending business flow can be obtained. This object type identifies the specific type or technology stack of the target business flow execution object, such as artificial intelligence service type, microservice type, form engine type, etc. This object type can be obtained by parsing parameters in the business flow creation request, reading configuration files, or querying the list of registered business flow execution objects.

[0111] After obtaining the object type, the target business flow data is converted into a business flow execution file that can be recognized by the business flow execution object, based on the object type. This conversion process requires generating a file format that conforms to the syntax specifications of the target business flow execution object, according to the business node structure defined in the target business flow data.

[0112] In one possible approach, the computing device can call upon the converter factory module, node converter module library, and assembler module in the backend process engine layer to collaboratively complete the conversion operation.

[0113] The converter factory module can determine the appropriate set of conversion rules based on the object type. This set of conversion rules defines the mapping relationship between data fields in the structured format rules and data elements in the business flow execution file that can be recognized by the business flow execution object.

[0114] The node converter module library stores multiple node converters. Each node converter corresponds to a data field type or a business node type. It is used to convert the field content of the corresponding data field in the target business flow data into data elements in the business flow execution file that can be recognized by the business flow execution object, according to the conversion rules defined in the conversion rule set.

[0115] The assembler module assembles the multiple data elements obtained from the converters at each node according to a preset layout style to form a complete business flow execution file.

[0116] In one alternative implementation, when the target business flow needs to be scheduled and executed by the Camunda process engine, the computing device first calls the Camunda process engine, which then generates a process definition file in XML format under BPMN2.0 based on the target business flow data.

[0117] This process definition file defines the execution logic of the business flow, including the node order, branching conditions, and task allocation rules. Subsequently, when the business flow instance starts, the Camunda process engine parses the process definition file, sequentially calls the corresponding business flow execution objects (such as AI services, microservices, form engines, etc.) to perform specific business operations according to the defined logic, and passes the execution results between nodes.

[0118] Through the above conversion process, the generated target business flow execution file can be directly parsed and executed by the target business flow execution object, or parsed by the backend process engine and then scheduled for execution by the business flow execution object. This achieves the adaptation and conversion from a unified intermediate representation to a file format recognizable by the specific business flow execution object. The specific definition of the conversion rule set, the registration and invocation mechanism of the node converter, and the conversion implementation details for different types of business flow execution objects will be described in detail in subsequent embodiments.

[0119] The following describes in detail the specific process of converting initial business flow data into target business flow data in the embodiments of this application.

[0120] The method described above for converting the initial business flow data according to preset structured format rules to obtain the target business flow data to be processed specifically includes: S302-1. Extract the node information of each business node from the initial business flow data.

[0121] After obtaining the initial business flow data, it is necessary to extract the node information of each business node from the data for subsequent semantic parsing and data mapping. The initial business flow data is organized using a private data format defined by the first canvas component, which contains all the information describing the business flow structure. By parsing this data and traversing the business node objects within it, the node information of each business node is extracted one by one.

[0122] In some embodiments, node information includes: node type, extended attributes, and node connection relationships.

[0123] Node types are used to identify the role and function of a business node in a business process. Node types can include start node types, end node types, user task node types, service task node types, gateway node types, etc. Gateway node types can be further subdivided into exclusive gateway types, inclusive gateway types, and parallel gateway types. Node type information is a crucial basis for subsequently determining node semantics and selecting transformation rules.

[0124] Extended attributes are used to store business configuration parameters for business nodes in key-value pairs. Extended attributes are a flexible data structure that can be dynamically expanded according to the needs of different business nodes. For example, for user task type business nodes, extended attributes can include handler configuration (such as specifying a user, role, or expression), form key-value pairs (used to associate form templates), timeout parameters, and other configuration parameters. For service task type business nodes, extended attributes can include service call address, request parameter mapping, retry strategy, and other configuration parameters. For AI preprocessing type business nodes, extended attributes can include model identifier, confidence threshold, and other configuration parameters.

[0125] Node connections describe the flow order and dependencies between business nodes. Node connections are typically represented as a list of lines, where each line records the source node identifier and the target node identifier, indicating that the business flow transitions from the source node to the target node for continued execution. For scenarios with conditional branches, node connections also include conditional expressions to define the specific logic for branch routing.

[0126] In some embodiments, when the node type is a gateway type, the extended attributes include a condition array. The specific structure of the condition array (including the mapping relationship between condition expressions and target node identifiers) has been described in detail in S302 and will not be repeated here.

[0127] After extracting the node information, this information is temporarily stored in a structured form for later use in determining node semantics and mapping data fields.

[0128] In one optional implementation, basic information such as node type, node identifier, and node name can be directly extracted from the corresponding field values. Key-value pairs in extended attributes can retain their original structure. Node connection relationships can be organized into a list of source and target node pairs. For the condition array of gateway type nodes, the condition expression in each condition element can be associated with and stored as the target node identifier. After extraction, complete descriptive information for all business nodes in the initial business flow data is obtained, laying the foundation for subsequent conversion into a data structure defined by a unified structured format rule.

[0129] S302-2. Determine the node semantics of each business node based on the node information of each business node, and determine the data fields mapped by each business node in the data structure defined by the structured format rules based on the node semantics.

[0130] After extracting the node information of each business node, it is necessary to perform semantic parsing on this information to understand the actual business meaning of each business node in the business process and map it to the corresponding data field in the data structure defined by the structured format rules.

[0131] Specifically, the semantics of each business node are determined based on its node information. Node semantics characterizes the business meaning and functional role of the business node within the business flow, such as a user approval node, service call node, conditional branch node, start node, and end node. The determination of node semantics can be based on a comprehensive assessment of multiple factors, including node type, node name, business configuration parameters in extended attributes, and the node's contextual position within the business flow.

[0132] In one feasible approach, a mapping table between node types and node semantics can be pre-established. For example, user task node types in the first canvas component can be mapped to user approval semantics, service task node types to service call semantics, and exclusive gateway node types to conditional branch semantics. For nodes whose extended attributes contain specific business configuration parameters, the node semantics can be further refined; for example, service task nodes containing model identifiers and confidence threshold configurations can be identified as having artificial intelligence preprocessing semantics.

[0133] In another possible approach, a pre-trained semantic recognition model can be invoked. Node information is input into the model, and the model outputs the corresponding node semantics. Based on natural language processing technology, the semantic recognition model performs semantic understanding on textual information such as node names and descriptions, thereby more accurately identifying the business meaning of the nodes. For example, when the node name is "supervisor approval," the semantic recognition model can identify it as "user approval" semantics; when the node name is "calling a risk control interface," the semantic recognition model can identify it as "service call" semantics.

[0134] After determining the node semantics of each business node, the data fields mapped to each business node in the data structure defined by the structured format rules are determined based on the node semantics. The structured format rules define a unified data structure independent of the front-end canvas component. This data structure contains multiple predefined data fields, each corresponding to a specific type of business node or node attribute.

[0135] For business nodes whose semantics are user approval, they are mapped to the user task data field in the node list defined by the structured format rules. This data field describes the steps in the business process that require manual intervention and includes subfields such as node identifier, node name, and extended attributes. Among them, the extended attribute subfield is used to store business parameters such as handler configuration and form key values.

[0136] For business nodes whose semantics are service calls, they are mapped to the service task data field in the node list. This data field describes the steps that require calling external services or performing automated processing, and the extended attribute subfields are used to store service call addresses, request parameter mappings, retry strategies, and other configuration information.

[0137] For business nodes whose semantics are conditional branches, they are mapped to the gateway data field in the node list. This data field describes the branch routing logic in the business process, and the extended attribute subfield contains a condition array used to define the conditional expressions of each branch and the mapping relationship with the target node.

[0138] For business nodes whose node semantics are start node or end node, map them to the start event data field or end event data field in the node list, respectively.

[0139] For node connections, they are mapped to a list of connections defined by structured format rules. Each connection corresponds to a data field containing a connection identifier, a source node identifier, and a target node identifier. For gateway type nodes, each condition element in the condition array is mapped to a condition expression attribute of the connection.

[0140] Through the semantic parsing and mapping process described above, a corresponding data field in the data structure defined by the structured format rules is determined for each business node, laying the foundation for subsequently filling the node information into the corresponding data fields in the data structure. This node semantic-based mapping method enables different canvas components to use different naming or classification methods for nodes with the same business meaning, and can still be uniformly mapped to the standard data fields defined by the structured format rules through semantic recognition, thereby achieving decoupling between the front-end canvas component and the back-end data format.

[0141] S302-3. Fill the node information of each business node into the data field mapped in the data structure defined by the structured format rules, and assemble the filled data according to the data structure defined by the structured format rules to obtain the target business flow data.

[0142] After determining the data fields mapped to each business node in the data structure defined by the structured format rules, the extracted node information needs to be filled into the corresponding data fields one by one, and assembled according to the data structure defined by the structured format rules to form complete target business flow data.

[0143] Specifically, this application can create data structure instances defined by structured format rules. These data structure instances are data objects conforming to JSON format, with their structure predefined by the structured format rules. The data object contains top-level fields such as a node list field and a connection list field, where the node list field stores information about all business nodes, and the connection list field stores information about the connections between all nodes.

[0144] Next, the computing device can fill the node identifier of the current business node into the identifier field of the newly created node in the node list according to the mapping relationship determined above. The node identifier is used to uniquely identify the node in the business flow. It is used for reference in the connection list, log recording, monitoring tracing, and application programming interface calls, ensuring traceability throughout the entire process from the modeling stage to the execution stage.

[0145] The computing device can fill in the node type of the current business node in the type field. The node type uses predefined enumeration values ​​in the structured format rules, such as start event, user task, exclusive gateway, end event, etc. These enumeration values ​​are not related to the specific node type names in the front-end canvas component, but instead use standard semantic types decoupled from the front-end.

[0146] The computing device can fill in the node name of the current business node into the name field. The node name is the display name set by the user for this node in the first canvas component, used to provide readable information in subsequent process monitoring and log display.

[0147] The computing device can populate the extended attributes of the current business node into the extended attribute field. An extended attribute is a key-value pair object used to store the business configuration parameters of that business node. The computing device directly copies the extended attribute content of that node (such as handler configuration, service call address, form key-value pairs, confidence threshold, etc.) from the initial business flow data into the extended attribute field.

[0148] For gateway-type service nodes, the extended attributes also include a condition array. Each condition element in the condition array defines the mapping relationship between the condition expression and the target node identifier to which the condition points. The computing device converts each condition element in the condition array into the standard format of the condition array entry in the extended attribute field, ensuring that each condition expression can be correctly parsed by subsequent conversion steps.

[0149] To populate the connection list, the computing device can iterate through all the node connections extracted in the above steps. For each connection, the computing device can generate a new connection identifier to uniquely identify the connection. This connection identifier can be consistent with the connection identifier in the initial business flow data, or it can be regenerated by the computing device, but it must be ensured to be unique in the target business flow data.

[0150] Next, the computing device fills the source node identifier into the source node identifier field, which corresponds to the node identifier of the starting service node, and fills the target node identifier into the target node identifier field, which corresponds to the node identifier of the target service node.

[0151] For the connection relationships corresponding to gateway type nodes, the computing device also needs to fill the corresponding condition expressions in the condition array into the condition expression field of the connection object to ensure that the branch routing logic is fully expressed at the connection level.

[0152] After filling in all node and connection information, the computing device fills in the corresponding values ​​for other necessary top-level fields (such as the schema version field) in the data structure defined by the structured format rules. The schema version field is used to identify the version number of the current structured format rule, facilitating subsequent compatibility management and version evolution.

[0153] Subsequently, the computing device serializes the completed data structure instance according to the data structure defined by the structured format rules, generating target business flow data that conforms to the structured format rules. This target business flow data is a structured text object, in which the node list field contains complete information about all business nodes, the connection list field contains complete information about the connection relationships between all nodes, and information such as node identifiers and connection identifiers are fully preserved.

[0154] Through the above-described filling and assembly process, regardless of the proprietary data format used by the first canvas component to describe the business flow, the computing device can convert it into unified target business flow data. This target business flow data is organized using structured format rules decoupled from the front-end canvas component, laying a unified data foundation for subsequently generating recognizable business flow execution files for different business flow execution objects.

[0155] Furthermore, because the original node and connection identifiers are retained, the entire lifecycle from process modeling to process execution, including logging, monitoring and alarms, and application programming interface calls, can be traced back to the business nodes defined in the modeling stage, which facilitates problem localization and operation and maintenance management.

[0156] The following describes in detail the specific process of converting target business flow data into a business flow execution file in the embodiments of this application.

[0157] A method for a computing device to convert target business flow data into a business flow execution file recognizable by the business flow execution object based on the object type, specifically including: S303-1. The computing device determines a set of conversion rules for object type adaptation based on the object type.

[0158] The conversion rule set is used to define the mapping relationship between data fields in the structured format rules and data elements in the business flow execution file that can be recognized by the business flow execution object.

[0159] After obtaining the object type of the business flow execution object to be processed, the computing device needs to determine a set of transformation rules that are compatible with that object type. The set of transformation rules is used to define the mapping relationship between data fields in the structured format rules and data elements in the business flow execution file that the business flow execution object can recognize.

[0160] In one feasible approach, since different process engines (such as Camunda, Flowable, Activiti, etc.) may recognize different data formats, the computing device first converts the target business flow data into an intermediate format file that can be recognized by the process engine corresponding to the target business flow data.

[0161] This intermediate format file follows the process engine's own specifications (such as BPMN2.0 XML format), which includes the node composition of the business flow, the flow relationship, and the configuration parameters of each node.

[0162] Subsequently, the computing device parses the intermediate format file through the process engine, and according to the node order, branch conditions and task allocation rules defined in the file, sequentially calls the corresponding business flow execution objects (such as AI services, OCR services, microservices, form engines, etc.) to perform specific business operations, and transmits the execution results between nodes.

[0163] In another possible approach, the computing device can directly convert the target business flow data into a business flow execution file that the business flow execution object can recognize, based on the object type of the business flow execution object, without going through the intermediate conversion of the process engine. For example, when the business flow execution object itself has process scheduling capabilities, the computing device can directly generate a business flow execution file that the object can parse and execute.

[0164] After determining the object type, the computing device searches for and selects a set of conversion rules that matches the object type from multiple pre-stored sets of conversion rules. The set of conversion rules defines complete conversion rules for a specific object type, including the following rules: Data field mapping rules are used to define the correspondence between various data fields in the structured format rules (such as node identifier field, node type field, node name field, extended attribute field, connection identifier field, source node identifier field, target node identifier field, etc.) and data elements in the business flow execution file that can be recognized by the business flow execution object.

[0165] Node type conversion rules are used to define the mapping relationship between predefined node type enumeration values ​​in the structured format rules and the corresponding element types in the business flow execution file that the business flow execution object can recognize. For different types of business flow execution objects, the same node type may be mapped to different element types or configuration methods.

[0166] Extended attribute conversion rules are used to define how each key-value pair in the extended attribute field of the structured format rules is converted into an extended element or configuration parameter in the business flow execution file that can be recognized by the business flow execution object.

[0167] For example, when the business flow execution object is a business service called by the Camunda process engine, the assignee configuration in the extended attributes should be converted to `` in the intermediate format file. <camunda:assignee>The extended element is subsequently parsed by the Camunda process engine and used to invoke the corresponding business flow execution object. Through extended attribute conversion rules, adaptation to proprietary extensions of different process engines can be achieved, thereby indirectly adapting to different methods of invoking business flow execution objects.

[0168] Gateway condition transformation rules are used to define how each condition element in the condition array of a structured format rule is transformed into a condition expression element in the business flow execution file that can be recognized by the business flow execution object.

[0169] When the intermediate transformation method of the process engine is adopted, each condition element is first converted into a condition expression element in the intermediate format file (such as the sequential flow element and its condition expression attribute in the BPMN2.0 standard). After being parsed by the process engine, the corresponding business flow execution object is called according to the result of the condition expression.

[0170] Formatting style rules define the organizational structure of the transformed data elements in the business flow execution file, including the order of data elements, hierarchical relationships, indentation format, and file header and footer information. Different business flow execution objects or process engines may have different requirements for file formatting styles. Formatting style rules ensure that the generated business flow execution file conforms to the parsing specifications of the target object.

[0171] In one optional implementation, the conversion rule set supports dynamic expansion and registration. When it is necessary to adapt to new business flow execution object types, the computing device can register new conversion rules with the conversion rule set through a preset interface without modifying the original code. This open registration mechanism gives the file generation method of this application embodiment good scalability and can flexibly adapt to new business flow execution objects that may emerge in the future.

[0172] S303-2 The computing device determines the transformation rule for each data field in the target business flow data from the set of transformation rules, and transforms the corresponding data fields according to the transformation rules to obtain multiple data elements.

[0173] After determining the set of conversion rules that are compatible with the object type of the business flow execution object, the computing device needs to traverse each data field in the target business flow data, determine the corresponding conversion rule for each data field, and perform the conversion operation of the data field according to the conversion rule to generate multiple independent data elements.

[0174] In one optional implementation, the computing device can obtain a data structure instance of the target business flow data. This data structure instance is a JSON object organized according to structured format rules, containing top-level fields such as a node list field, a connection list field, and a pattern version field. The node list field stores node information for multiple business nodes, and each business node contains subfields such as a node identifier field, a node type field, a node name field, and extended attribute fields. The connection list field stores connection information for multiple connections, and each connection contains subfields such as a connection identifier field, a source node identifier field, and a target node identifier field.

[0175] The computing device iterates through each data field in the above data structure instance, and searches for a conversion rule that matches the field path in the conversion rule set based on the field path of the current data field in the structured format rules.

[0176] The conversion rule set predefines different conversion rules for different field paths. For example, for a node type field, the conversion rule defines how to convert the enumeration value in the structured format rules into the corresponding element type in the business flow execution file that the business flow execution object can recognize. For the processor configuration field in the extended attributes, the conversion rule defines how to convert the content of this field into an extended element that the business flow execution object can recognize. For a connection field, the conversion rule defines how to convert the connection information into a sequential flow element that the business flow execution object can recognize.

[0177] In one feasible approach, the computing device can invoke a converter factory module to determine the conversion rules and distribute the converters. The converter factory module retrieves the node converter instance corresponding to the data field from the node converter module library, based on the data field's field type or node type.

[0178] The node converter module library stores multiple node converters, each corresponding to a data field type or a business node type. For example, the user task converter is used to handle the conversion of user task type nodes, the service task converter is used to handle the conversion of service task type nodes, the gateway converter is used to handle the conversion of gateway type nodes, and the connection converter is used to handle the conversion of connection fields.

[0179] The node converter module library supports dynamic expansion. When it is necessary to adapt to new data field types or new business node types, a new node converter can be registered in the node converter module library.

[0180] Next, the computing device performs format conversion, structural reorganization, or semantic mapping on the field content of the current data field according to the defined conversion rules, generating corresponding data elements. The specific content of the conversion operation differs for different types of fields. For the node identifier field, the conversion rule defines a direct mapping between the string value of this field and the node element identifier attribute in the business flow execution file that the business flow execution object can recognize. The original value of the node identifier remains unchanged during the conversion process, ensuring full traceability from the modeling phase to the execution phase.

[0181] For node type fields, the conversion rule definition maps the predefined node type enumeration values ​​in the structured format rules to the corresponding element types in the business flow execution file that the business flow execution object can recognize.

[0182] For the node name field, the conversion rule definition maps the string value of this field to the name attribute or display label of the node in the business flow execution file that can be recognized by the business flow execution object, so as to provide readable information in process monitoring and log display.

[0183] For extended attribute fields, the transformation rule definition converts each key-value pair in the extended attribute field into an extended element or configuration parameter in the business flow execution file that can be recognized by the business flow execution object.

[0184] For the condition array field of gateway type nodes, the transformation rule defines how each condition element in the condition array is converted into a condition expression element recognizable by the business flow execution object. Each condition element contains a mapping between the condition expression and the target node identifier. The transformation rule maps each condition element to a sequential flow element, maps the condition expression to the condition expression attribute of that sequential flow element, and maps the target node identifier to the target node attribute of that sequential flow element.

[0185] For the connection identifier, source node identifier, and target node identifier fields, the conversion rules define that the values ​​of these fields are directly mapped to the corresponding attributes of sequential flow elements in the business flow execution file that the business flow execution object can recognize. Connection identifiers are mapped to the identifier attributes of sequential flow elements, source node identifiers to source node attributes, and target node identifiers to target node attributes. For connections corresponding to gateway type nodes, the conditional expressions in the condition array also need to be mapped to the conditional expression attributes of the sequential flow elements.

[0186] Next, the computing device collects and temporarily stores the data elements generated after each data field is transformed, forming a data element set. Each data element corresponds to a component in a business flow execution file that the business flow execution object can recognize, such as an XML element, a JSON object, or a piece of configuration code. These data elements remain relatively independent, but they are connected logically through association fields such as node identifiers and connection identifiers. They need to be assembled according to a preset layout style to form a complete business flow execution file.

[0187] During the conversion process, for data fields in the target business flow data that are not covered by the conversion rules, the computing device can process them according to a preset default processing strategy, such as ignoring the field, retaining the original value as a comment, or generating a prompt message. For abnormal situations that occur during the conversion process (such as incorrect data field format, missing conversion rules, incompatible target formats, etc.), the computing device can record error logs and generate corresponding prompt messages to help users locate and correct problems.

[0188] Through the above conversion process, the computing device converts the content of each data field in the target business flow data into data elements recognizable by the business flow execution object, resulting in multiple independent data elements. These data elements collectively constitute the entire content of the business flow execution file, preparing for subsequent assembly steps.

[0189] S303-3. The computing device assembles multiple data elements according to a preset layout style to obtain a business flow execution file that can be recognized by the business flow execution object.

[0190] The default formatting style defines the organizational structure of data elements in the business flow execution file. Different types of business flow execution objects may have different requirements for the file formatting style. For business flow execution files using XML format (such as BPMN2.0 format), the default formatting style defines the name and namespace of the root element, the order of each data element, the hierarchical relationship between elements, the indentation format, the organization of attributes and child elements, and the declaration information in the file header. For business flow execution files using JSON format, the default formatting style defines the field order of the top-level object, the hierarchical structure of nested objects, the arrangement of array elements, and the indentation format.

[0191] After assembly, the computing device performs integrity verification on the generated file to ensure that the file format conforms to the parsing requirements of the business flow execution object. This includes checking whether the root element is correct, whether required elements exist, whether the reference relationships between elements are valid, and whether the file encoding conforms to the specifications. If the verification passes, the computing device outputs the assembly result as a business flow execution file that can be recognized by the business flow execution object. This file can be directly sent to the business flow execution object for parsing and execution, or it can be parsed by the process engine and then scheduled by the corresponding business flow execution object to perform specific business operations.

[0192] Through the above assembly process, the computing device integrates scattered data elements into a business flow execution file with a complete structure and standardized format, realizing a complete conversion from a unified intermediate representation to a file format recognizable by specific business flow execution objects.

[0193] The specific process of registering a business node in the embodiments of this application is described in detail below.

[0194] In some embodiments, the file generation method provided in this application further includes a process of registering business nodes. Through this registration process, business personnel or low-code platform developers can dynamically add custom business nodes (such as invoice AI recognition nodes, contract compliance review nodes, etc.) to the computing device for use during business flow creation, achieving flexible expansion of business functions without modifying the core code. In this case, the file generation method provided in this application further includes: Obtain the node metadata of the business node to be registered, and if the node metadata of the business node to be registered meets the registration conditions, send the node metadata to the first canvas component so that the first canvas component can display a list of registered business nodes, including business nodes whose node metadata meets the registration conditions, on the node list display interface.

[0195] The node metadata includes: node type, node display name, node display icon, execution binding method, input data structure, and output data structure. The execution binding method indicates the business execution method required when the corresponding business node is invoked; the input data structure indicates the data structure of the input data required when the corresponding business node is invoked; and the output data structure indicates the data structure of the output data after the corresponding business node is invoked.

[0196] In one feasible approach, the computing device can provide a node management interface through which business personnel or low-code platform developers fill in configuration information such as node type identifier, node display name, node display icon, execution binding method, input data structure, and output data structure.

[0197] In another possible approach, node metadata is defined through an external configuration file (such as in YAML or JSON format). The computing device loads the configuration file from a specified path when it starts up or periodically, and reads the node type definitions within it.

[0198] In another possible approach, the computing device receives node metadata pushed by an external system via an application programming interface (API) to remotely register the node type.

[0199] Node type is used to uniquely identify the business node. For example, "AI ocrinvoice" identifies the AI ​​invoice recognition node, and "contract compliance check" identifies the contract compliance review node. This node type identifier is globally unique within the system and is used to identify the node type in subsequent process design, data storage, and runtime calls.

[0200] The node display name is used to present to the user on the node list display interface of the front-end canvas component, such as invoice AI recognition or contract compliance review. The display name uses language that is easy for business users to understand, so that users can quickly identify the node function when dragging and dropping the design.

[0201] Node display icons are icon identifiers displayed along with node display names on the node list display interface of the front-end canvas component. Icons can be font icon names, image resource paths, or icon identifiers from a predefined icon library, used to enhance the visual recognizability of nodes and improve user experience.

[0202] The execution binding method indicates the business execution method required when the corresponding business node is invoked. Execution binding methods can include various types, such as indicating that an external service is called via Hypertext Transfer Protocol (HTTP), or indicating the execution of a preset script, such as a sandbox script.

[0203] The input data structure represents the data structure required when the corresponding business node is invoked. Defined in JSON Schema format, the input data structure describes which parameters need to be passed when invoking the target business, the data type of each parameter (e.g., string, number, boolean, object), whether a parameter is required, and the range or format constraints of the parameter's values. For example, for the invoice AI recognition node, the input data structure could define the `image url` field as a required string to specify the address of the invoice image to be recognized.

[0204] The output data structure represents the data structure of the output data after the corresponding business node is invoked. The output data structure is also defined using JSON Schema format, describing which fields are included in the result returned by the target business, the data type of each field, and the meaning of each field. For example, for the invoice AI recognition node, the output data structure can define the amount field as a numeric type to represent the invoice amount, and the confidence field as a numeric type to represent the recognition confidence level.

[0205] After the computing device obtains the node metadata of the business node to be registered, it performs registration condition verification on the node metadata. The purpose of registration condition verification is to ensure the integrity and validity of the node metadata, and to avoid incomplete or incorrectly formatted node types affecting subsequent process design and runtime execution.

[0206] In one feasible approach, the computing device can verify the completeness of required fields in the node metadata. Node type, node display name, and binding method are required fields. If any of these required fields are missing, the registration conditions are not met, the computing device generates a prompt message, and terminates the registration process.

[0207] In another possible implementation, the computing device can verify the uniqueness of the node type. The computing device checks if the same node type identifier already exists in the list of registered business nodes. If the node type identifier already exists, the registration condition is not met, the computing device generates a prompt message and terminates the registration process to avoid type conflicts caused by duplicate registration.

[0208] In another possible approach, the computing device can verify the format and validity of the execution binding method, such as verifying whether the execution target address is a valid URL format.

[0209] In another possible approach, the computing device can validate the format of both the input and output data structures. The device checks whether the input and output data structures conform to the JSON Schema specification, including whether field definitions are valid, data types are supported, and required fields are explicitly defined. If the data structure format is incorrect, the registration conditions are not met, the computing device generates a prompt message, and terminates the registration process.

[0210] If the node metadata of a business node to be registered meets the registration requirements, the computing device adds the business node to the list of registered business nodes based on the node metadata. The list of registered business nodes can be stored in a database, configuration file, or memory cache to maintain information on all available business nodes in the computing device. Once added, the business node becomes a built-in, usable node for subsequent process design.

[0211] After the computing device adds the business node to be registered to the list of registered business nodes, it displays the list of registered business nodes on the node list display interface of the first canvas component.

[0212] Specifically, the computing device reads the node display names and icons of all business nodes from the list of registered business nodes and generates corresponding node entries in the toolbar or node panel of the front-end canvas component. When a user opens the first canvas component, they can see the newly registered business nodes displayed in the node list and add them directly to the process design by dragging and dropping.

[0213] When the computing device starts up or the first canvas component is initialized, the computing device retrieves a list of all registered node types from the node type registry. It then sends a request to the registry via an application programming interface to obtain node metadata (including node type identifier, node display name, node display icon, input data structure, etc.) for all current node types. This retrieval process can be synchronous (completed during page load) or asynchronous (refreshed periodically in the background), and this embodiment does not limit this.

[0214] After receiving the list of node types, the front-end canvas component dynamically generates corresponding node icons in the process canvas's node toolbar based on the node display name and icon for each node type. For newly registered node types (such as invoice AI recognition), the front-end automatically adds the corresponding node entry to its toolbar, allowing users to see the new node without any additional configuration. When the node type registry is updated (e.g., adding, modifying, or deleting node types), the front-end receives update notifications via long-connection polling or push notifications and refreshes the node toolbar in real time to ensure consistency with the registry.

[0215] When a user drags a node from the toolbar to the canvas area, the front-end canvas component automatically sets the node type field of that business node based on the node type identifier. For example, after dragging the Invoice AI Recognition node, its node type field is automatically set to AI ocrinvoice. Simultaneously, the front-end canvas component dynamically generates the node's attribute configuration panel based on the input data structure of that node type. The attribute panel displays all configuration items defined by the input data structure, including field names, field types, whether they are required, and value ranges. For example, for the Invoice AI Recognition node, if the input data structure defines an image url field, the attribute panel will display an image address input box where the user can enter a specific image address or dynamically bind variable values ​​from the process context through variable expressions.

[0216] After the user completes the configuration in the properties panel, the front-end canvas component organizes all information of the current business node (including node type identifier, node display name, user-filled extended attributes, etc.) according to a unified JSON Schema format. When saving the process, the node is written to the node list field in the target business flow data, where the node type field is AI ocrinvoice, and the extended attribute field contains the user-configured input parameters (such as the value of the image URL). The saved target business flow data adopts a data format defined by a unified structured format rule, which is independent of the specific implementation of the front-end canvas component.

[0217] Through the aforementioned registration and rendering mechanism, low-code platforms or business process management systems can dynamically extend the capabilities of business nodes through simple configuration without modifying the core code. Business users can drag and drop and use custom nodes just like built-in nodes. The front-end canvas automatically adapts to the display and configuration interface of the new nodes, and the back-end general execution agent automatically calls the corresponding target business based on the registered execution binding method. This configurable node extension mechanism significantly improves the system's flexibility and scalability.

[0218] The specific process of processing the business flow to be processed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0219] In some embodiments, the file generation method provided in this application further includes a process of executing processing on the business flow to be processed. Through this execution process, the computing device can dynamically invoke corresponding business capabilities based on the registered node metadata, without needing to write dedicated code for each node type. In this case, such as Figure 4 As shown, the document generation method provided in this application embodiment further includes: S401. Parse the business flow execution file to obtain the node type of each business node in the business flow to be processed.

[0220] After generating the business flow execution file, the business flow execution object can parse the business flow execution file. The business flow execution file is organized in a format that the business flow execution object can recognize (such as BPMN2.0 XML format), which contains the definition information of all business nodes in the business flow to be processed, including node identifier, node type, node name, extended attributes, and the connection relationships between nodes.

[0221] In one possible approach, after parsing the business flow execution file and obtaining the parsing result, the business flow execution object can also send the parsing result to the generic execution agent (Generic Node Executor) so that the generic execution agent can perform subsequent business processing operations.

[0222] The general execution proxy is a unified execution component responsible for handling the execution logic of all registered business nodes. In this embodiment, the general execution proxy processes all types of business nodes through a unified call entry point, thus decoupling node definition from execution logic.

[0223] When parsing the business flow execution file, the business flow execution object can traverse each business node in the file and extract the node type field of each business node, such as user task, service task, AI ocrinvoice, contractcompliance check, etc.

[0224] S402. Based on the node type of each business node, obtain the execution binding method and input data structure of each business node from the list of registered business nodes.

[0225] In one feasible approach, after obtaining the node type of each business node, the business flow execution object queries the node type registry based on that node type and retrieves the node metadata corresponding to that node type from the list of registered business nodes. The node metadata includes configuration information such as execution binding method, input data structure, and output data structure.

[0226] S403. Based on the input data structure of each business node, obtain the input data of each business node from the processing flow context information of the business flow to be processed.

[0227] When a business flow execution object processes a corresponding business node, it first extracts the required input data from the processing context information of the business flow to be processed, based on the input data structure of that business node.

[0228] The process context information is the variable storage space during process execution, containing data from various sources, including process variables, form data, local variables, system variables, and global constants. Process variables are maintained at the process instance level and are accessible throughout the entire process lifecycle. Form data is data filled in and submitted by the user in the task form. Local variables are temporary variables at the current node or task level. System variables include system information built into the engine, such as the current user and timestamp. Global constants are fixed values ​​configured by the system, such as service addresses and default thresholds.

[0229] In one possible implementation, the business flow execution object can parse the variable mapping relationships predefined for that business node in the business flow execution file. These variable mapping relationships indicate the corresponding paths between fields in the input data structure and the data sources in the processing flow context information.

[0230] The business flow execution object can read the actual values ​​of each field from the processing flow context information according to the variable mapping relationship, and perform type conversion and validity verification on the read actual values ​​according to the data type and validation rules defined in the input data structure.

[0231] S404. Based on the execution binding method of each business node, send the corresponding input data to each business node.

[0232] After acquiring and validating the input data, the business flow execution object checks whether the input data conforms to the data structure defined in the input data structure definition, including whether required fields exist, whether the data types match, and whether format constraints are met. If the input data does not meet the requirements of the input data structure, the general execution agent can adopt preset exception handling strategies, such as terminating the process execution, transferring it to manual processing, continuing execution using default values, or generating an error message.

[0233] Provided that the input data of the current business node meets the data structure defined in the input data structure definition, the business flow execution object sends the corresponding input data to each business node according to the execution binding method of each business node.

[0234] For example, when the execution binding method is a REST API call, the business flow execution object constructs a Hypertext Transfer Protocol request (such as an HTTP POST request) based on the execution target address specified in the execution binding method, and sends the input data as request parameters (such as a JSON request body or form parameters) to the external service corresponding to the execution target address, i.e., the business node.

[0235] S405. Receive the processing results generated by each service node based on the corresponding input data, and determine the service processing result of the service flow to be processed based on the processing results of each service node in the service flow to be processed.

[0236] The business flow execution object processes the business logic corresponding to each business node in the pending business flow sequentially, according to the node order and flow relationship defined in the business flow execution file. After each business node is processed, its processing result is added to the processing flow context information for use by subsequent nodes. When all business nodes have been executed and the end node is reached, the business flow execution object determines the final business processing result of the pending business flow based on the execution status of the entire process. The final business processing result may include the process execution status (success, failure, partial success, etc.), a summary of the output data of each node, execution time statistics, and exception information.

[0237] During node execution, for gateway-type business nodes, the business flow execution object determines branch routing based on the condition array in the extended attributes. Each condition element in the condition array contains a mapping relationship between a condition expression and the target node identifier. The business flow execution object evaluates the condition expression in each condition element sequentially, calculates using the variable values ​​in the processing flow context information, and selects the first branch that meets the condition as the next node.

[0238] For example, in the exclusive gateway of the invoice reimbursement process, the condition array defines that when confidence < 0.8, it redirects to the manual review node, and when confidence >= 0.8, it redirects to the automatic approval node. The business flow execution object judges based on the value of ocrResult.confidence in the current processing flow context information and automatically routes to the corresponding node.

[0239] In some embodiments, the business flow execution object can also obtain the output data structure of each business node from the business node list according to the node type of each business node, and add the processing result of the current business node to the processing flow context information of the business flow to be processed if the processing result of the current business node satisfies the data structure defined by the output data structure.

[0240] The current business node is any business node in the business flow to be processed.

[0241] In other words, after receiving the processing result returned by the business node, the business flow execution object verifies the result according to the output data structure of the current business node.

[0242] The output data structure is defined using JSON Schema format, describing the field names, field types, and field meanings contained in the processing results returned by the business nodes. The business flow execution object checks whether the processing results meet the field structure, data type, and validation rules defined in the output data structure.

[0243] If the processing result meets the data structure defined in the output data structure definition, the business flow execution object determines the processing result as the correct processing result for the current business node and adds the processing result to the processing flow context information of the business flow to be processed.

[0244] For example, for the AI-powered invoice recognition node, the output data structure defines the `amount` and `confidence` fields. The business flow execution object writes the amount and confidence level from the recognition result into process variables. These process variables can be referenced by subsequent business nodes; for example, the gateway node can determine whether manual review is needed based on the confidence level.

[0245] If the processing result does not meet the data structure defined in the output data structure definition, the business flow execution object can adopt a preset exception handling strategy, such as recording an error log, generating a default output value, transferring to manual processing, or terminating the process execution.

[0246] This application embodiment also supports runtime hot update functionality for the node type registry. The node type registry provides a dynamic registration interface, allowing node type definitions to be dynamically added, modified, or deleted during system runtime via an application programming interface (API). When a new node type is registered or an existing node type is modified, the registry triggers an update event, notifying the front-end canvas component and the business flow execution object to synchronize.

[0247] The front-end canvas component can receive update notifications from the node type registry center via persistent connections, polling, or push notifications, refreshing the node toolbar in real time to ensure consistency with the registry center. When a business user adds a new node type (such as a contract compliance review node), the front-end canvas component can automatically display that node in the toolbar without restarting the front-end service.

[0248] When processing business logic corresponding to a business node, the business flow execution object needs to query the node type registry to obtain node metadata. To improve query efficiency, the business flow execution object can cache the obtained node metadata locally and set a cache time-to-live (TTL). When the node type registry is updated, the business flow execution object retrieves the latest node metadata from the registry after the cache expires, achieving real-time configuration effectiveness. Through this mechanism, adding or modifying node types does not require restarting the service, truly achieving configuration-as-it-is.

[0249] The following example, using the invoice reimbursement process, illustrates the method provided in this application.

[0250] Business personnel first register an invoice AI recognition node through the node type registration center, configure the node type identifier as AI ocrinvoice, the node display name as invoice AI recognition, and the execution binding method as rest:https: / / ai-service / api / ocr. The input data structure defines the image url field as a required string type, and the output data structure defines the amount and confidence fields as numeric types.

[0251] After registration, the front-end canvas component automatically retrieves a list of node types from the registration center and displays the Invoice AI Recognition node icon in the node toolbar. Business users drag the Invoice AI Recognition node to the canvas area and configure the image source in the properties panel to `${form.image url}`, indicating that the invoice image address is obtained from the form data. Business users also add an exclusive gateway node to the process, configuring an array of conditions: when confidence < 0.8, redirect to the manual review node; when confidence >= 0.8, redirect to the automatic approval node.

[0252] After business personnel complete and save the process design, the computing device converts the process model into target business flow data (in a unified JSON Schema format). The node type for the AI-generated invoice recognition node is AI ocrinvoice, and its extended attributes include an image URL field mapping. Subsequently, the computing device converts the target business flow data into a business flow execution file that can be recognized by the business flow execution object.

[0253] After the process is deployed, the process instance is started when a user submits an expense report. The business flow execution object parses the business flow execution file and executes the invoice AI recognition node. Based on the node type AI ocrinvoice, the business flow execution object queries the node type registry center to obtain the execution binding method as a REST API call, defining the image url field as the input data structure. The business flow execution object retrieves the actual value of the image url (the address of the invoice image submitted by the user) from the processing flow context information. After successful verification, it sends an HTTP request to https: / / ai-service / api / ocr to invoke the OCR service.

[0254] The OCR service returns the recognition result, including the amount and confidence level. The business flow execution object verifies the returned result based on the output data structure and writes the amount and confidence level into the process variables `ocrResult.amount` and `ocrResult.confidence`. Subsequently, the business flow execution object executes the exclusive gateway node, making branch decisions based on the value of the `confidence` variable. If the confidence level is below 0.8, the process automatically jumps to the manual review node; if the confidence level is not lower than 0.8, the process automatically jumps to the automatic approval node. The entire process requires no Java code writing or modification of BPMN extension configuration; a complete invoice recognition and approval process can be achieved solely through configuring node metadata and process design.

[0255] This application's embodiment decouples node definition from execution logic by introducing a node type registry and a business flow execution object. Node metadata (including node type identifier, node display name, node display icon, execution binding method, input data structure, and output data structure) is externalized as configurable registration items and uniformly managed by an independent node type registry. Business personnel or low-code developers can add nodes simply through configuration, without any programming or service restarts, significantly improving the system's flexibility and scalability.

[0256] The following describes in detail, with reference to the accompanying drawings, the specific process of updating the business flow execution file through different canvas components in the embodiments of this application.

[0257] The file generation method provided in this application supports the reuse and updating of business processes across canvas components. Users can create business processes on the first canvas component, generate target business flow data, and then import the data into the second canvas component for viewing, editing, and updating. The updated process can still be converted into a business flow execution file that can be recognized by the business flow execution object.

[0258] To enable data interoperability between different canvas components, this application embodiment develops a bidirectional format conversion adapter for each supported canvas component. The bidirectional format conversion adapter includes a forward adapter and a reverse adapter. The forward adapter parses and maps the private data structure generated by the canvas component to standard fields of a unified JSON Schema. The reverse adapter converts the unified JSON Schema into the rendering data format required by the target canvas component. All adapters follow the same set of semantic mapping rules to ensure consistency in the expression of the same business semantics (such as user task nodes and exclusive gateway nodes) across different canvas components.

[0259] Semantic mapping rules define the conversion relationship between standard fields in the unified JSON Schema and corresponding fields in the private data structures of each canvas component. For example, for a user task node, the semantic mapping rules stipulate that regardless of whether it is in the first or second canvas component, the business semantics of this node is a process that requires manual intervention. The unified JSON Schema uses "user task" as the value of the node type field, and the adapters of each canvas component uniformly map the corresponding fields in their private data structures (such as user-node in LogicFlow and bpmn-user-task in X6) to "user task" according to this rule.

[0260] In this case, such as Figure 5 As shown, in some embodiments, the document generation method provided in this application further includes: S501. Obtain the current business flow data of the business flow to be processed.

[0261] The current business flow data is obtained by converting the target business flow data according to the data format defined by the second canvas component in response to importing the target business flow data into the second canvas component, and the current business flow data meets the data format defined by the second canvas component.

[0262] When a user needs to import a business process created on the first canvas component into the second canvas component for viewing or editing, the target business flow data is first retrieved from storage. The target business flow data is a process definition file organized in a unified JSON Schema format, which contains a list of nodes and a list of edges.

[0263] After obtaining the target business flow data, the reverse adapter corresponding to the second canvas component is called to convert the data format of the target business flow data according to the data format defined by the second canvas component. The reverse adapter is used to convert the unified JSONSchema into the rendering data format required by the target canvas component.

[0264] During the transformation process, the reverse adapter first reads the node list and connection list from the target business flow data. For each node in the node list, the reverse adapter maps the node type field in the unified JSON Schema to the corresponding node type identifier in the private data format of the second canvas component, according to semantic mapping rules.

[0265] After completing the above transformation, the reverse adapter outputs the generated data structure as the current business flow data. This current business flow data is organized using the private data format of the second canvas component, which can be directly parsed and rendered by the second canvas component.

[0266] S502, Receive the initial business flow data of the updated business flow generated by the second canvas component performing a business flow update operation on the current business flow data.

[0267] After acquiring the current business flow data of the business flow to be processed, the current business flow data generated by the reverse adapter can be provided to the second canvas component. The second canvas component parses this data and renders a complete business process diagram on the canvas area based on fields such as node position information, style information, node type, node name, and extended attributes. Users can view the structure and configuration of the process on the second canvas component and perform editing operations, such as adding new nodes, deleting nodes, modifying node attributes, adjusting node positions, modifying connection relationships, and modifying gateway branch conditions.

[0268] When a user performs a business flow update operation on the second canvas component, the computing device responds to the operation by generating initial business flow data for the updated business flow in memory. This initial business flow data is organized using the second canvas component's proprietary data format to support the second canvas component in displaying, editing, and storing the updated business flow.

[0269] Similar to the initial business flow data generated in S301, the initial business flow data of the updated business flow contains the node information (including node type, extended attributes, etc.) of each business node in the updated business flow and the connection relationship between nodes, but its data format meets the data format defined by the second canvas component.

[0270] S503. Perform data format conversion on the initial business flow data of the updated business flow according to the structured format rules to obtain the target business flow data of the updated business flow.

[0271] After generating the initial business flow data for the updated business flow, this data needs to be converted back into a unified intermediate representation for subsequent generation of business flow executable files or import into other canvas components. To do this, the forward adapter corresponding to the second canvas component is called to perform data format conversion on the initial business flow data.

[0272] The forward adapter is used to parse and map the private data format of canvas components to standard fields of a unified JSON Schema. The forward adapter follows the same semantic mapping rules as the reverse adapter, ensuring consistency of the same business semantics across different canvas components.

[0273] S504. Based on the object type, convert the target business flow data of the updated business flow into a business flow execution file that can be recognized by the business flow execution object.

[0274] After obtaining the target business flow data of the updated business flow, the object type of the business flow execution object that executes the business flow to be processed is obtained in the same way as in S303. Based on the object type, the target business flow data is converted into a business flow execution file that the business flow execution object can recognize. This business flow execution file is used to request and invoke the business flow execution object to execute the updated business flow.

[0275] For example, such as Figure 6 As shown, the front-end process canvas layer includes a first canvas component and a second canvas component, which are used to support process modeling for different canvas components. The initial business flow data generated by the first canvas component is converted into a data format through an adapter to obtain unified target business flow data, which is then passed to the intermediate presentation layer.

[0276] The intermediate presentation layer stores or processes the target business flow data and converts it into current business flow data recognizable by the second canvas component through an adapter, enabling cross-canvas reuse. The intermediate presentation layer also passes the target business flow data to the backend process engine layer after data transformation processing. The backend process engine layer generates a business flow execution file and calls the business flow execution object to execute it.

[0277] Through the aforementioned cross-canvas reuse process, this embodiment of the application achieves seamless switching of business processes between different canvas components. Users can create processes on the first canvas component, import process data into the second canvas component for viewing and editing, and still generate business flow execution files recognizable by the business flow execution object for deployment and execution after editing. The entire process is based on a unified JSON Schema as an intermediate presentation layer. By developing bidirectional adapters for each canvas component and following the same set of semantic mapping rules, the consistency of expression of the same business semantics across different canvas components is ensured, achieving the goal of one-time modeling, multi-terminal rendering, and unified execution. Users can freely select or switch canvas components according to project needs without having to develop separate adapters for each canvas component to interface with the backend business flow execution object, significantly reducing the cost of front-end technology selection and integration.

[0278] In some embodiments, such as Figure 7 As shown in the figure, this diagram illustrates the core interactive flow of the file generation method in the dynamic expansion and execution phases in the embodiments of this application.

[0279] In the front-end process canvas layer, users model processes by dragging and dropping business nodes and configuring node attributes. When specific business requirements necessitate domain customization, users define new node types through an extension mechanism. This includes configuring node type identifiers, node display names, execution binding methods, input data structures, output data structures, and other node metadata information, and registering the new nodes. This node metadata is registered to the node type registry center in the intermediate presentation layer, enabling the dynamic addition of domain-specific nodes. The node type registry center uniformly manages all registered business node types, supports updating the registry center, and achieves runtime hot updates.

[0280] After registration, the front-end workflow canvas layer automatically loads new nodes, which users can directly drag and drop in the canvas component. The initial business flow data generated by the front-end is converted by the adapter and stored in the intermediate presentation layer in a unified JSON Schema format.

[0281] When the process is deployed and executed, the backend process engine layer calls the general execution agent. This general execution agent executes the process, invoking services based on the node type of the current business node, obtaining the execution binding method, input data structure, and output data structure corresponding to that node, processing the business logic, and returning the processing results to the frontend or writing them into the process context for use by subsequent nodes. The entire process achieves a complete closed loop from node definition, registration, frontend loading to backend execution, demonstrating the flexible scalability for integration into existing processes.

[0282] In some embodiments, such as Figure 8 As shown in the figure, this diagram illustrates the core function of the unified intermediate representation layer as the sole source of fact in multi-module collaboration in the embodiments of this application.

[0283] The intermediate presentation layer stores target business flow data defined using structured format rules. This data is independent of the specific implementations of the front-end canvas component and the back-end business flow execution object. Around the intermediate presentation layer, multiple business modules collaborate based on the same process metadata.

[0284] Specifically, the process node semantic module reads the node type, node name, and extended attributes from the intermediate presentation layer to understand the business meaning of the business process.

[0285] The form field configuration module interacts with the form designer based on the form key values ​​in the extended attributes of the user task node, automatically loading the corresponding form and binding the form to the process.

[0286] The permission rules module requests permission verification from the permission center during process execution based on the permission configuration in the node's extended attributes, ensuring that only authorized users can access sensitive nodes or fields.

[0287] The AI ​​service scheduler invokes the corresponding AI capabilities based on the extended attributes of the AI ​​preprocessing nodes (such as model identifiers and confidence thresholds) and writes the processing results back to the intermediate representation layer.

[0288] The business object manager generates or parses business objects based on the business object structure defined in the extended properties of business nodes, enabling data transfer between different nodes.

[0289] The process engine acts as the execution scheduler, loading the process definition from the intermediate presentation layer and driving the process instance to run, while interacting with the aforementioned modules during execution.

[0290] With this architecture centered on the intermediate presentation layer, each module does not need to care on which canvas component the process was initially designed on, nor does it need to care on which engine will ultimately execute it. All modules share the same process metadata, avoiding the problems of duplicate definitions and inconsistent configurations. This truly achieves the goal of modeling once and reusing across multiple platforms, significantly improving the development efficiency and consistency of the low-code platform.

[0291] In an exemplary embodiment, this application also provides a file generation apparatus. This file generation apparatus may be a computing device that performs the aforementioned file generation method, or it may be a processor within the computing device. The file generation apparatus may include one or more functional modules for implementing the file generation method of the above method embodiments.

[0292] This application also provides a computing device. Figure 9 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Figure 9 As shown, the computing device 100 includes: one or more memories 120, one or more processors 110, a communication bus 140, and a communication interface 130. The processors 110 and memories 120 are connected via the communication bus 140; the one or more memories 120 are used to store computer program code, which includes computer instructions; when the one or more processors 110 execute the computer instructions, the computing device 100 performs the file generation method provided in this embodiment.

[0293] Optionally, the memory 120 may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc. The embodiments of this application do not impose any limitations on this.

[0294] The processor 110 may be a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof, and the embodiments of this application do not impose any limitations on this.

[0295] The communication bus 140 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. This communication bus 140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 9 It is represented by a single thick line, but this does not mean that there is only one bus or one type of communication bus.

[0296] Communication interface 130 uses any transceiver-like device for communicating with other devices or communication networks, such as control systems, radio access networks (RAN), wireless local area networks (WLAN), etc.

[0297] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0298] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; for example, the related hardware can be a processor of a computing device. The program instructions can be stored in the above-described computer-readable storage medium, and when executed, they can implement the processes of the above method embodiments. The computer-readable storage medium can be memory. The above-described computer-readable storage medium can also be an external storage device, such as a hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Further, the above-described computer-readable storage medium can include both memory and external storage devices. The above-described computer-readable storage medium is used to store the above-described computer program instructions and other programs and data required by the above-described file generation method.

[0299] This application also provides a computer program product comprising a computer program that, when run on a computing device, causes the computing device to execute any of the file generation methods provided in the above embodiments.

[0300] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple components. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0301] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

[0302] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / camunda:assignee>

Claims

1. A method for generating a file, characterized in that, include: Receive initial business flow data from the pending business flow generated by the first canvas component; The data format of the initial business flow data satisfies the data format defined by the first canvas component; The initial business flow data is converted according to the preset structured format rules to obtain the target business flow data of the business flow to be processed; the data format of the target business flow data satisfies the data format defined by the structured format rules. Obtain the object type of the business flow execution object that executes the business flow to be processed, and convert the target business flow data into a business flow execution file that can be recognized by the business flow execution object according to the object type; the business flow execution file is used to request the business flow execution object to execute the business flow to be processed.

2. The method according to claim 1, characterized in that, The step of converting the initial business flow data according to preset structured format rules to obtain the target business flow data of the business flow to be processed includes: Extract the node information of each business node from the initial business flow data; The node semantics of each business node are determined based on the node information of each business node, and the data fields mapped by each business node in the data structure defined by the structured format rules are determined based on the node semantics. The node information of each business node is filled into the data field mapped in the data structure defined by the structured format rules, and the filled data is assembled according to the data structure defined by the structured format rules to obtain the target business flow data.

3. The method according to claim 2, characterized in that, The node information includes: node type, extended attributes, and node connection relationships; the extended attributes are used to store the business configuration parameters of the business node in key-value pairs.

4. The method according to claim 3, characterized in that, When the node type is a gateway type, the extended attribute contains a condition array, and each condition element in the condition array is used to define the branch routing logic of the service node of the gateway type.

5. The method according to any one of claims 1-4, characterized in that, The step of converting the target business flow data into a business flow execution file recognizable by the business flow execution object according to the object type includes: Based on the object type, a set of conversion rules adapted to the object type is determined; the set of conversion rules is used to define the mapping relationship between the data fields in the structured format rules and the data elements in the business flow execution file that the business flow execution object can recognize; From the set of transformation rules, determine the transformation rule for each data field in the target business flow data, and transform the corresponding data field according to the transformation rule to obtain multiple data elements; The multiple data elements are assembled according to a preset layout style to obtain a business flow execution file that can be recognized by the business flow execution object.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain the node metadata of the business node to be registered; the node metadata includes: node type, node display name, node display icon, execution binding method, input data structure and output data structure; the execution binding method is used to indicate the business execution method required when the corresponding business node is called, the input data structure is used to indicate the data structure of the input data required when the corresponding business node is called, and the output data structure is used to indicate the data structure of the output data after the corresponding business node is called; If the node metadata of the business node to be registered meets the registration conditions, the node metadata is sent to the first canvas component so that the first canvas component displays a list of registered business nodes, including those whose node metadata meets the registration conditions, on the node list display interface.

7. The method according to claim 6, characterized in that, The method further includes: The business flow execution file is parsed to obtain the node type of each business node in the business flow to be processed; Based on the node type of each business node, obtain the execution binding method and input data structure of each business node from the list of registered business nodes; Based on the input data structure of each business node, the input data of each business node is obtained from the processing flow context information of the business flow to be processed; According to the execution binding method of each business node, send the corresponding input data to each business node; Receive the processing results generated by each of the service nodes based on the corresponding input data; The business processing result of the business flow to be processed is determined based on the processing result of each business node in the business flow to be processed.

8. The method according to claim 7, characterized in that, The method further includes: Based on the node type of each business node, obtain the output data structure of each business node from the list of business nodes; If the processing result of the current business node satisfies the data structure defined in the output data structure definition, the processing result of the current business node is added to the processing flow context information of the business flow to be processed; the current business node is any business node in the business flow to be processed.

9. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a computing device, the method as described in any one of claims 1-8 is implemented.

10. A computing device, characterized in that, The computing device includes a processor and a memory; the processor is coupled to the memory. The memory is used to store computer instructions; The computer instructions are loaded and executed by the processor to enable the computing device to perform the method as described in any one of claims 1-8.

Images