Rapael-based workflow design method and system

Abstract

The invention provides a workflow design method and system based on Raphael. The workflow design method comprises the following steps: constructing a flow chart comprising a starting node, a task node, an ending node and a flow line through a WEB flow designer developed based on a Raphael vector graphics library; an executor attribute and a Grouping script used for injecting service logic are configured for each task node, and a condition judgment script is configured for each outbound connecting line; according to the method, a flow chart is serialized into a flow definition file in a JSON format, then the flow definition file in the JSON format is analyzed into structured data, an executable flow model is further generated, then a workflow engine is utilized to execute Grouping scripts of task nodes one by one, and corresponding task node instances are generated; according to the configured connection line condition, the circulation line meeting the script verification condition is judged, the next ready node is generated, the to-be-processed person is pushed to the required executor, and the process is repeated and successively passes through the multiple nodes until the process is ended, so that the coupling degree between the workflow and the service system is effectively reduced, and the method has the characteristics of high flexibility, strong expansibility and the like.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a workflow design method and system based on Raphael. Background Art

[0002] Workflow refers to the process of modeling the logic and rules for organizing tasks in a business process in an orderly manner in a computer system and automating the process through computation. The logic and rules for organizing tasks in a workflow are represented in a computer using an appropriate model and then computed. Its core is to automatically transfer documents, information, or tasks between multiple participants according to predetermined rules to achieve specific business goals. The primary problem workflow solves is the process of automatically transferring documents, information, or tasks between multiple participants according to predetermined rules to achieve a specific business goal. This ensures smooth business processes while improving efficiency, reducing errors, and ensuring information security and consistency.

[0003] As the core component of workflows, the workflow engine provides core solutions that are crucial for each application system, such as determining information routing and content levels based on roles, division of labor, and conditions. It provides critical support functions, enabling different application systems to determine information routing and content levels based on changing roles, division of labor, and conditions. Specifically, the workflow engine is responsible for parsing and executing process definitions, managing the lifecycle of process instances, and providing the necessary service interfaces for integration with other systems. These features are crucial for building flexible and responsive enterprise applications.

[0004] Currently, workflows have been widely used in various systems. However, most workflow solutions currently on the market have several major limitations: 1) Customized development: Existing workflow systems are usually customized and developed for specific business needs, lacking versatility and flexibility. 2) Insufficient scalability: As the business develops, existing systems often find it difficult to quickly adapt to new needs, resulting in high expansion costs and low scalability. 3) High degree of coupling with business systems: The tight integration of traditional workflows with business systems increases the difficulty of maintenance and reduces the portability and reusability of the system. 4) Complex process design: Complex process design requires users to have a high level of technical skills, which limits the ability of non-technical personnel to participate in process optimization.

[0005] These issues are particularly prominent in the shipping industry, as shipping operations involve numerous processes and collaboration among multiple parties, placing higher demands on process flexibility and adaptability. Therefore, there is an urgent need for a new workflow design method and engine that can simplify process design, lower the development threshold, and enhance the system's scalability and flexibility to better serve complex industry environments like shipping. Summary of the Invention

[0006] To address existing workflow issues such as high coupling with business systems, low scalability, and complex process design, the present invention provides a workflow design method based on Raphael. This method effectively reduces the coupling between workflows and business systems while offering advantages such as high flexibility and strong scalability. This method significantly lowers the barrier to entry for workflow use and can meet the needs of business systems for timely workflow modification based on actual conditions. The present invention also relates to a workflow design system based on Raphael.

[0007] The technical solutions of the present invention are as follows:

[0008] A workflow design method based on Raphael, characterized by comprising the following steps:

[0009] Process creation steps: Using the Web process designer developed based on the Raphael vector graphics library, construct a flow chart using its toolbar and canvas, including a start node, at least one task node, an end node, and multiple outgoing connections connecting the nodes. Each task node is configured with executor attributes and a Groovy script for injecting business logic, and each outgoing connection line is configured with a conditional judgment script for determining the flow direction. The flow chart is then serialized into a process definition file in JSON format.

[0010] Process parsing step: Parse the JSON formatted process definition file into structured data, and then generate an executable process model. The process model includes rules for node relationships, data transfer, script execution timing, and task allocation.

[0011] Process running steps: execute the process model, generate a node instance of the start node to mark the start of the process; locate the first task node based on the node relationship rules defined in the process model; according to the script execution timing rules, use the workflow engine to execute the Groovy script of the first task node, generate a task node instance according to the business logic defined in the Groovy script, and follow the data transmission rules to pass the data required for task execution to the task node instance, and according to the task allocation rules and the executor attributes of the task node, use the message middleware to push the to-do tasks generated based on the task node instance to the target user; then, according to the condition judgment script of all outgoing connection lines of the first task node, filter out the outgoing connection lines with the result of true, and activate the downstream nodes corresponding to the filtered outgoing connection lines to obtain the next ready node of the first task node;

[0012] Process termination step: Starting from the ready node, repeat the principles and processes executed for the first task node in the process running step, continue to advance the execution of the process until reaching the end node and generating a node instance of the end node, marking the termination of the process.

[0013] Preferably, in the process creation step, the flow chart further includes a gateway node, the gateway node includes an exclusive gateway and a parallel gateway, all outgoing connection lines of the exclusive gateway are configured with a conditional judgment script, and all outgoing connection lines of the parallel gateway are not configured with a conditional judgment script;

[0014] In the process running step, during the execution of the process model, if an exclusive gateway is encountered, the condition judgment scripts of each outgoing connection line of the exclusive gateway are executed in sequence until the first outgoing connection line with a true result is found and the downstream node corresponding to the outgoing connection line is activated; if a parallel gateway is encountered, the downstream nodes corresponding to all outgoing connections of the parallel gateway are activated.

[0015] Preferably, in the process running step, during the execution of the process model, the status data of each node is also obtained in real time, the status data is converted into JSON format and mapped into a corresponding process tracking diagram through the process designer, and the process tracking diagram is visually displayed for users to track the current status of the process.

[0016] Preferably, the status data includes process variables and the execution status, completion time and executor of each node, and the process variables include approval results and amount.

[0017] Preferably, in the process parsing step, the structured data includes node metadata and connection line metadata, the node metadata includes type, executor attribute and Groovy script path, and the connection line metadata includes source node, target node and conditional judgment script;

[0018] In the process running step, the message middleware includes ActiveMQ and RabbitMQ.

[0019] A workflow design system based on Raphael, characterized by comprising a process creation module, a process analysis module, a process running module and a process termination module connected in sequence,

[0020] The process creation module uses a web process designer developed based on the Raphael vector graphics library to construct a flow chart including a start node, at least one task node, an end node, and multiple outgoing connection lines connecting the nodes through its toolbar and canvas; configures executor attributes and a Groovy script for injecting business logic for each task node, and configures a conditional judgment script for determining the flow direction for each outgoing connection line; then serializes the flow chart into a process definition file in JSON format and transmits it to the process parsing module;

[0021] The process parsing module parses the process definition file in JSON format into structured data, and then generates an executable process model. The process model includes rules for node relationships, data transfer, script execution timing, and task allocation;

[0022] The process running module executes the process model, generates a node instance of the start node to mark the start of the process; locates the first task node based on the node relationship rules defined in the process model; executes the Groovy script of the first task node using the workflow engine according to the script execution timing rules, generates a task node instance according to the business logic defined in the Groovy script, and at the same time follows the data transmission rules to pass the data required for task execution to the task node instance, and uses the message middleware to push the to-do tasks generated based on the task node instance to the target user according to the task allocation rules and the executor attributes of the task node; then, based on the condition judgment script of all outgoing connection lines of the first task node, filters out the outgoing connection lines with the result of true, and activates the downstream nodes corresponding to the filtered outgoing connection lines to obtain the next ready node of the first task node;

[0023] The process termination module takes the ready node as the starting point, repeats the principles and processes executed for the first task node in the process running module, and continuously advances the execution of the process until it reaches the end node and generates a node instance of the end node, marking the termination of the process.

[0024] Preferably, in the process creation module, the flow chart also includes a gateway node, and the gateway node includes an exclusive gateway and a parallel gateway. All outgoing connection lines of the exclusive gateway are configured with a conditional judgment script, and all outgoing connection lines of the parallel gateway are not configured with a conditional judgment script; in the process running module, during the execution of the process model, if an exclusive gateway is encountered, the conditional judgment scripts of each outgoing connection line of the exclusive gateway are executed in sequence until the first outgoing connection line with a true result is found and the downstream node corresponding to the outgoing connection line is activated; if a parallel gateway is encountered, the downstream nodes corresponding to all outgoing connection lines of the parallel gateway are activated.

[0025] Preferably, in the process running module, during the execution of the process model, the status data of each node is obtained in real time, the status data is converted into JSON format and mapped into a corresponding process tracking diagram through the process designer, and the process tracking diagram is visually displayed for users to track the current status of the process.

[0026] Preferably, the status data includes process variables and the execution status, completion time and executor of each node, and the process variables include approval results and amount.

[0027] Preferably, in the process parsing module, the structured data includes node metadata and connection line metadata, the node metadata includes type, executor attribute and Groovy script path, and the connection line metadata includes source node, target node and condition judgment script;

[0028] In the process running module, the message middleware includes ActiveMQ and RabbitMQ.

[0029] The beneficial effects of the present invention are:

[0030] The present invention provides a workflow design method based on Raphael. First, a WEB process designer developed based on the Raphael vector graphics library is provided to construct a flowchart consisting of a start node, at least one task node, an end node and multiple outgoing connection lines connecting the nodes through a toolbar and a canvas. Through an intuitive operation interface, the design of complex business processes is simplified, the design threshold is lowered, and user participation and work efficiency are improved. The executor attribute and the Groovy script for injecting business logic are configured for each task node. For each task node, the executor attribute is accurately configured. This attribute is used to clarify the execution subject of the task. At the same time, the Groovy script for injecting business logic is injected to achieve flexible customization of specific business rules. A conditional judgment script is configured for each outgoing connection line, that is, a conditional judgment logic is configured for each outgoing connection line. The logic is presented in the form of a script. Now, it is used to determine the flow direction of the process, allows the specific definition of the task leader of each node, and implements business logic processing through custom scripts, which enhances the flexibility and adaptability of the process, achieves low coupling with the business system, and completes the preliminary design and construction of the workflow. It not only defines the basic framework of the workflow, but also incorporates business logic and execution rules, so that the workflow has preliminary execution logic and business functions, laying the foundation for subsequent analysis and operation, and realizing the setting of process structure and basic rules in workflow design from the perspective of process construction; then serialize the flowchart into a process definition file in JSON format. By serializing the process definition in a standardized format (such as JSON), the process definition can be easily imported and used by other systems or applications without redeveloping or significantly modifying the existing system, thereby achieving low-coupling embedded features and lowering the threshold for using workflows.The JSON-formatted process definition file is then parsed into structured data to generate an executable process model. This process model contains rules for node relationships, data transfer, script execution timing, and task allocation. It is used to guide the process execution according to business logic, transform the abstract design into a specific execution model, support rapid deployment and adjustment of the process, improve the system's responsiveness and flexibility, and complete the transformation from design to executable model. This realizes the key transition from abstract design to specific executable solutions in workflow design, ensuring that the workflow has clear guiding rules in subsequent operations. Finally, the process model is executed to generate a node instance of the start node to mark the start of the process. The workflow engine executes the Groovy script of the first task node to generate a task node instance. Based on the executor properties of the task node, the message middleware is used to push the to-do tasks generated based on the task node instance to the target user. By automatically assigning tasks and notifying relevant personnel, manual intervention is reduced and work efficiency is improved. At the same time, the message middleware ensures the reliability and timeliness of information transmission. The conditional judgment script filters out the outgoing connection lines with the result of true, and activates the downstream nodes corresponding to the filtered outgoing connection lines to obtain the next ready node of the first task node. The process direction is dynamically determined based on the actual business logic, which ensures the accuracy and adaptability of the process and enables the system to flexibly respond to various business changes. From generating a node instance of the start node to mark the process start, to completing the execution of task nodes, task allocation and node flow according to various rules, until the next ready node is obtained, this series of operations is carried out according to the designed process model and rules, realizing the actual operation of the workflow, completing the entire process from workflow design to execution, and achieving the ultimate goal of workflow design, that is, realizing the automated flow of business processes and the orderly execution of tasks to meet the actual needs of the business system; based on the ready node and repeating the principle process of executing the first task node until reaching the end node and generating a node instance of the end node, marking the termination of the process, the workflow is completely decoupled from the business system, helping to monitor and manage the entire process life cycle, and improving the controllability and transparency of the overall business process. Through the entire process of process design, analysis, operation, promotion and termination, from process construction, rule setting, model transformation to actual execution, the workflow design based on Raphael was completely completed and realized, making it highly flexible and scalable, solving the problems existing in the existing workflow and meeting the design requirements of the business system for the workflow.

[0031] The present invention achieves complete decoupling of workflows and business systems through a technical combination of visual process design (Raphael) + dynamic script injection (Groovy) + standardized JSON storage + event-driven execution, while integrating design and operation. It has the advantages of high flexibility and strong scalability, and can meet the needs of business systems to modify workflows in a timely manner according to actual conditions. It can enable dynamic adjustment and real-time tracking of processes in complex business scenarios such as shipping, reduce development and maintenance costs, and support high-concurrency, multi-branch automated flows. Through visual process design (Raphael), the design of business logic is separated from the specific business system; Groovy scripts are configured at each task node to implement specific business logic processing, allowing dynamic insertion or modification of business logic without affecting the entire workflow framework. By using scripts in the process to process business logic, the separation of process definition and business logic execution is achieved, further reducing the coupling degree; the results of process design are serialized into JSON format data for easy storage, transmission and parsing, and the use of standardized data exchange formats allows process definitions to exist independently of any specific business system, enhancing flexibility and portability; each connection line can be set with a conditional judgment script, which allows the process direction to be dynamically adjusted according to actual business needs without modifying the core workflow engine or the business system itself, effectively reducing the coupling degree between the workflow and the business system, not only improving the flexibility and scalability of the system, but also making maintenance and updating simpler and more direct. In addition, the present invention significantly reduces the threshold for using workflows through easy-to-use interfaces, testability of processes and scalability of node behaviors, and is particularly suitable for enterprise environments that need to flexibly respond to changes in business needs. In addition, developers can easily add customized behaviors (through executable scripts) to achieve automated flow of processes.

[0032] The present invention also relates to a workflow design system based on Raphael, which corresponds to the above-mentioned workflow design method based on Raphael, and can be understood as a system that implements the above-mentioned workflow design method based on Raphael, including a process creation module, a process parsing module, a process running module and a process termination module connected in sequence. The modules work together and achieve complete decoupling of workflows and business systems through the technical combination of visual process design (Raphael) + dynamic script injection (Groovy) + standardized JSON storage + event-driven execution, so that processes in complex business scenarios such as shipping can be dynamically adjusted and tracked in real time, and development and maintenance costs can be reduced, while supporting high concurrency and multi-branch automated flows. Through visual process design (Raphael), the design of business logic is separated from the specific business system; Groovy scripts are configured at each task node to implement specific business logic processing, allowing dynamic insertion or modification of business logic without affecting the entire workflow framework. By using scripts in the process to process business logic, the separation of process definition and business logic execution is achieved, further reducing the degree of coupling; the results of process design are serialized into JSON format data for easy storage, transmission and parsing, and the use of standardized data exchange formats allows process definitions to exist independently of any specific business system, enhancing flexibility and portability; each connection line can be set with a conditional judgment script, which allows the process direction to be dynamically adjusted according to actual business needs without modifying the core workflow engine or the business system itself, thereby achieving complete decoupling of workflow and business system, which not only improves the flexibility and scalability of the system, but also makes maintenance and updates simpler and more direct. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a flow chart of the workflow design method based on Raphael of the present invention.

[0034] Figure 2 Schematic diagram of the node type of the present invention.

[0035] Figure 3 It is a schematic diagram of the workflow application of the present invention. DETAILED DESCRIPTION

[0036] The present invention will be described below with reference to the accompanying drawings.

[0037] The present invention relates to a workflow design method based on Raphael, which provides a convenient visual UI design interface based on Raphael, so that developers and business personnel can directly click icons to draw corresponding processes, and support Groovy script tasks. Script tasks can be configured in each link, and the script is responsible for specific business logic to achieve decoupling of workflows and business systems; the process engine is used to run business target processes to build corresponding target process instances. The present invention solves the current problems of limited workflow processing capabilities, poor scalability, and high development thresholds through a lightweight process design method and workload engine, reduces the coupling between workflows and business systems, integrates design and operation, has the advantages of high flexibility and strong scalability, and can meet the needs of business systems to modify workflows in a timely manner according to actual conditions. The flowchart of this method is as follows Figure 1 As shown, the following steps are included in sequence:

[0038] 1. Process creation steps: The user uses the WEB process designer developed based on the Raphael vector graphics library to build a flowchart containing a start node, at least one task node, an end node, and multiple outgoing connection lines (flow lines) connecting each node; wherein, the WEB process designer is used to draw the required business process. The WEB process designer is mainly divided into three parts, including a toolbar, a canvas, and a form property configuration area. 1) Toolbar: used to perform operations such as creating a new flowchart, adding and deleting nodes, and saving process definitions; 2) Canvas: allows users to draw the required flowchart on the canvas by dragging and connecting nodes; 3) Form property configuration area: used to configure metadata properties of processes, nodes, and connection lines, including name, code, description, etc. The form property configuration area is also used to edit the following properties: process form properties: including process code, process name, and process description; node form properties: including name, code, executor, start condition, node action, end condition, etc.; flow line properties: including name, node action, etc.

[0039] Flowchart drawing is also a process of process modeling, which includes the modeling of several important areas such as process definition, node definition, flow line definition, executor definition, and related data element definition.

[0040] 1) Process definition: Process definition models and describes the process, providing contextual information for other entities in the process.

[0041] 2) Node definition: A process consists of multiple nodes, each corresponding to a work unit in the process. A typical node activity can be performed by a person. Nodes are divided into four categories: start nodes, task nodes, gateway nodes, and end nodes. Figure 2 As shown. Start and end nodes (such as Figure 2The leftmost circular icon in the figure is very simple and marks the beginning and end of a process. Figure 2 The middle rectangular icon represents the work items that need to be completed in the actual business. During the process execution, they are dispatched to specific users according to the executors (roles, users) configured on the nodes. Gateway nodes (such as Figure 2 The diamond icon on the far right of the node indicates that the current node is divided into two types: single-select and concurrent. Single-select means that the current node is split into two or more subsequent branches. After execution, you can only choose to trigger one subsequent branch to execute, that is, multiple-choice; concurrent means that after a certain node, multiple nodes are split concurrently, and these multiple activities are executed at the same time.

[0042] 3) Flowline definition: A connection line between nodes. A flowline has three properties: source node, target node, and condition. A flowline can be conditional or unconditional. The condition can be set by specifying a script file path or directly writing executable script code. The final execution result is a Boolean value: true means the flow continues, false means the flow does not continue. Scripts are based on the Groovy language.

[0043] 4) Executor definition: describes the executors of processes and nodes. Executors can be users, roles, or a combination of both.

[0044] 5) Definition of related data elements: data created or used during the execution of the process definition. These data are used by various expressions defined in nodes and processes (flow line conditions, gateway condition calculations).

[0045] Each model definition will generate a corresponding instance during the process execution, which is used to record relevant information such as creation time, execution status, actual executor, etc.

[0046] Then, configure the executor properties and the Groovy script for injecting business logic for each task node, and configure the conditional judgment script for each outgoing connection line to determine the flow direction; then serialize the flowchart into a process definition file in JSON format.

[0047] 2. Process parsing step: A JSON parsing library can be used to parse the process definition file in JSON format into structured data, and then generate an executable process model, which contains rules for node relationships, data transfer, script execution timing and task allocation. After being parsed into structured data, the structured data is also persisted, that is, the structured data is permanently stored in a database or file system to ensure that the process definition can be reused, version managed and distributed for a long time. Preferably, the JSON parsing library includes the Jackson library, the Gson library and the Fastjson library. Preferably, the structured data includes node metadata and connection line metadata, the node metadata includes type, executor attributes and Groovy script path, and the connection line metadata includes source node, target node and conditional judgment script.

[0048] 3. Process running steps: Execute tasks in an orderly manner according to the defined process model (i.e., process map), generate a node instance each time a node is passed (i.e., use the workflow engine to execute the Groovy script of the task node one by one and generate the corresponding task node instance), record the executor corresponding to the node, judge the script according to the configured connection line conditions, verify the connection lines that meet the conditions, generate the next ready node, push the to-do items to the required executor, and repeat this process of passing through several nodes one by one until the process ends. Specifically, the process model is executed to generate a node instance of the start node to mark the start of the process; based on the node relationship rules defined in the process model, the first task node is located; according to the script execution timing rules, the Groovy script of the first task node is executed using the workflow engine, and the task node instance is generated according to the business logic defined in the Groovy script. At the same time, following the data transmission rules, the data required for task execution is passed to the task node instance, and according to the task allocation rules and the executor properties of the task node, the message middleware (such as ActiveMQ or RabbitMQ) is used to push the to-do tasks generated based on the task node instance to the target user; then, according to the condition judgment script of all outgoing connection lines of the first task node, the outgoing connection lines with the result of true are filtered out, and the downstream nodes corresponding to the filtered outgoing connection lines are activated to obtain the next ready node (next node to-be-operated task) of the first task node. Among them, the workflow engine is the core of the workflow implementation and can be embedded in the target application to call and execute. It is responsible for interpreting and executing the process definition model, generating the work items corresponding to the task nodes, and managing the life cycle of the work items (initialization, assignment of executors, execution, termination). The workflow engine includes the following contents:

[0049] 1) Script management: Dynamically execute various expressions or script files defined in nodes and processes (flow lines, gateways).

[0050] 2) Event management: Publish the start and end events of process instances and nodes, and call the corresponding event handlers through the listener mode.

[0051] 3) Message management: After a to-do task is generated, a message is sent to proactively notify the person in charge. This is implemented based on ActiveMQ and RabbitMQ.

[0052] 4) External services: The services here refer to the interfaces provided to applications for calling, including deploying process definitions, starting / triggering process instances, and querying historical operation data.

[0053] The present invention provides a lightweight embedded workflow engine with two advantages: first, it is embedded, which lowers the threshold for using workflows; second, it is developer-friendly, as reflected in the easy-to-read interface, testability of the process, and scalability of node behaviors. It is very convenient to add customized behaviors (through executable scripts) during the process operation, thereby realizing the automated flow of processes.

[0054] Preferably, during the execution of the process model, the status data of each node is obtained in real time, the status data is converted into JSON format and mapped into a corresponding process tracking diagram through the process designer, and the process tracking diagram is visually displayed for the user to track the current status of the process. This process can also be understood as process tracking. Process tracking is the reverse process of the process parsing step. The process instance is organized into a parseable data format and mapped into a corresponding flowchart by the process designer, which allows the user to track the current status of the process. Further preferably, the status data includes process variables and the execution status of each node (such as the execution status of the start node / task node / gateway node / end node), completion time and executor, and the process variables include business data such as approval results and amount.

[0055] 4. Process termination step: Starting from the ready node, repeat the principles and processes of executing the first task node in the process running step, continue to advance the execution of the process until reaching the end node and generating a node instance of the end node, marking the termination of the process.

[0056] Preferably, the flowchart also includes a gateway node, and the gateway node includes an exclusive gateway and a parallel gateway. All outgoing connection lines of the exclusive gateway are configured with a conditional judgment script, and all outgoing connection lines of the parallel gateway are not configured with a conditional judgment script; when encountering a gateway node, a gateway node instance is generated and branch logic is executed according to its type (i.e., exclusive gateway and parallel gateway): if an exclusive gateway is encountered, the conditional judgment scripts of each outgoing connection line of the exclusive gateway are executed in sequence until the first outgoing connection line with a true result is found and the downstream node corresponding to the outgoing connection line is activated; if a parallel gateway is encountered, the downstream nodes corresponding to all outgoing connection lines of the parallel gateway are activated, and all generated node instances record the execution timestamp and status information.

[0057] Example:

[0058] like Figure 3 As shown in the figure, taking the typical procurement process of ship management business as an example, the actual configuration and application of the process are demonstrated. Figure 3 As can be seen in the figure, the process consists of a start and end node, an application submission node, seven approval nodes, and two gateways, all connected by flow lines. First, there's a start node, marking the start of the process; next, there's a submission node, which serves as the entry point for procurement personnel to initiate their application; then, there are seven approval nodes, corresponding to different levels of approval; and finally, an end node, marking the end of the process. These nodes are connected by connecting lines (flow lines). Of particular note are the two gateway nodes, which determine the path of the process. The first important gateway appears after Review 1. This is an exclusive gateway (also known as a single-choice split mode or split gateway). This gateway sets three possible branch paths: the first is a return to the application submission node (review return), for unsuccessful approvals; the second is a path to Review 2, applicable to purchases with a value of no more than 100,000 yuan; and the third is a path to Review 3, applicable to purchases with a value exceeding 100,000 yuan. Of course there can be N branches. This scenario only has 3 branches. These three paths are mutually exclusive, which means that only one of the paths will be selected for execution under any circumstances (that is, one and only one will be triggered for execution). The system will check the conditions of each path in turn, execute the first path that meets the conditions, and other paths will be automatically ignored. The second key gateway is located after Review 4, which is a parallel gateway (or co-signing mode). Unlike the exclusive gateway, the two branches of this gateway will be activated at the same time (both branches must be executed), and the process will not continue until both approval nodes (Review 5 and Review 6) have completed the approval. This design is often used in scenarios where multiple departments or positions need to approve at the same time. For example, financial audits and technical audits can be carried out in parallel to improve approval efficiency.

[0059] The execution process of the process is as follows: First, the purchasing staff fills out and submits the purchase application, and the system automatically creates a new process instance. The start node is completed immediately and enters the submit application node. After the purchasing staff completes and submits the application form, the system will generate a to-do task for Review 1 and push it to the pre-configured approver. When the approver of Review 1 completes the approval, the gateway node ends, all branches of the gateway node are found, and the flow conditions (expressions or script codes) configured for the three branches are executed in sequence. The flow line with a TRUE execution result is selected. In other words, the system will determine the subsequent direction based on the approval result: If the approver chooses to reject, the process will return to the submit application node, and the purchasing staff will need to modify the application content and resubmit it; if the approval is passed, the system will automatically choose whether to enter Review 2 or Review 3 based on the size of the application amount.

[0060] After completing Review 2 or Review 3, the process will enter Review 4. After Review 4 is completed, the system will activate both Review 5 and Review 6 nodes. These two approval tasks can be performed simultaneously or completed one after another. When one of them is executed, a gateway node instance will be generated. When both approval nodes are executed, the gateway node will automatically close and execute downward to generate an Review 7 node instance. That is, both Review 5 and Review 6 must be completed before entering the final Review 7 link. Review 7 is the last approval link, and after completion, the entire procurement approval process is officially completed. Throughout the process, the system will fully record the processing status of each node, including the person who processed it, the processing time, and the processing results, to ensure that the entire approval process is traceable and auditable, which not only ensures the rigor of the approval, but also improves work efficiency. In particular, through intelligent routing and parallel processing, the overall approval time is greatly shortened.

[0061] The present invention also relates to a workflow design system based on Raphael, which corresponds to the workflow design method based on Raphael and can be understood as a system for implementing the above method. The system includes a process creation module, a process parsing module, a process running module and a process termination module connected in sequence. Specifically,

[0062] The process creation module uses a web process designer developed based on the Raphael vector graphics library to construct a flow chart including a start node, at least one task node, an end node, and multiple outgoing connection lines connecting the nodes through its toolbar and canvas; configures executor attributes and a Groovy script for injecting business logic for each task node, and configures a conditional judgment script for determining the flow direction for each outgoing connection line; then serializes the flow chart into a process definition file in JSON format and transmits it to the process parsing module;

[0063] The process parsing module uses a JSON parsing library to parse the process definition file in JSON format into structured data, and then generates an executable process model. The process model contains rules for node relationships, data transfer, script execution timing, and task allocation;

[0064] The process running module executes the process model, generates a node instance of the start node to mark the start of the process; rules, locates the first task node; according to the script execution timing rules, uses the workflow engine to execute the Groovy script of the first task node, generates a task node instance according to the business logic defined in the Groovy script, and follows the data transmission rules to pass the data required for task execution to the task node instance, and according to the task allocation rules and the executor attributes of the task node, uses the message middleware to push the to-do tasks generated based on the task node instance to the target user; then, according to the condition judgment script of all outgoing connection lines of the first task node, filters out the outgoing connection lines with the result of true, and activates the downstream nodes corresponding to the filtered outgoing connection lines to obtain the next ready node of the first task node;

[0065] The process termination module takes the ready node as the starting point, repeats the principles and processes executed for the first task node in the process running module, and continuously advances the execution of the process until it reaches the end node and generates a node instance of the end node, marking the termination of the process.

[0066] Preferably, in the process creation module, the flowchart also includes a gateway node, and the gateway node includes an exclusive gateway and a parallel gateway. All outgoing connection lines of the exclusive gateway are configured with a conditional judgment script, and all outgoing connection lines of the parallel gateway are not configured with a conditional judgment script; in the process running module, during the execution of the process model, if an exclusive gateway is encountered, the conditional judgment scripts of each outgoing connection line of the exclusive gateway are executed in sequence until the first outgoing connection line with a true result is found and the downstream node corresponding to the outgoing connection line is activated; if a parallel gateway is encountered, the downstream nodes corresponding to all outgoing connection lines of the parallel gateway are activated.

[0067] Preferably, in the process running module, during the execution of the process model, the status data of each node is obtained in real time, the status data is converted into JSON format and mapped into the corresponding process tracking diagram through the process designer, and the process tracking diagram is visually displayed for users to track the current status of the process.

[0068] Preferably, the status data includes process variables and the execution status, completion time and executor of each node, and the process variables include the approval result and amount.

[0069] Preferably, in the process parsing module, the structured data includes node metadata and connection line metadata, the node metadata includes type, executor attribute and Groovy script path, and the connection line metadata includes source node, target node and condition judgment script;

[0070] In the process running module, the message middleware includes ActiveMQ and RabbitMQ.

[0071] The Raphael-based workflow design method and system provided by the present invention achieves complete decoupling of workflows and business systems through a technical combination of visual process design (Raphael) + dynamic script injection (Groovy) + standardized JSON storage + event-driven execution, allowing processes in complex business scenarios such as shipping to be dynamically adjusted and tracked in real time, reducing development and maintenance costs, while supporting high-concurrency, multi-branch automated flows.

[0072] It should be noted that the specific embodiments described above can enable those skilled in the art to more fully understand the present invention, but do not limit the present invention in any way. Therefore, although this specification has described the present invention in detail with reference to the drawings and embodiments, those skilled in the art should understand that the present invention can still be modified or replaced with equivalents. In short, all technical solutions and improvements that do not depart from the spirit and scope of the present invention should be included in the scope of protection of the patent for the present invention.

Claims

1. A workflow design method based on Raphael, characterized in that: The following steps are involved: Process creation steps: Using the Web process designer developed based on the Raphael vector graphics library, construct a flow chart using its toolbar and canvas, including a start node, at least one task node, an end node, and multiple outgoing connections connecting the nodes. Each task node is configured with executor attributes and a Groovy script for injecting business logic, and each outgoing connection line is configured with a conditional judgment script for determining the flow direction. The flow chart is then serialized into a process definition file in JSON format. Process parsing step: Parse the JSON formatted process definition file into structured data, and then generate an executable process model. The process model includes rules for node relationships, data transfer, script execution timing, and task allocation. Process running steps: executing the process model, generating a node instance of the start node to mark the process start; Locate the first task node based on the node relationship rules defined in the process model; According to the script execution timing rules, the workflow engine is used to execute the Groovy script of the first task node, and a task node instance is generated according to the business logic defined in the Groovy script. At the same time, following the data transmission rules, the data required for task execution is passed to the task node instance, and according to the task allocation rules and the executor attributes of the task node, the message middleware is used to push the to-do tasks generated based on the task node instance to the target user; then, according to the condition judgment script of all outgoing connection lines of the first task node, the outgoing connection lines with the result of true are filtered out, and the downstream nodes corresponding to the filtered outgoing connection lines are activated to obtain the next ready node of the first task node; Process termination step: Starting from the ready node, repeat the principles and processes executed for the first task node in the process running step, continue to advance the execution of the process until reaching the end node and generating a node instance of the end node, marking the termination of the process.

2. The workflow design method based on Raphael according to claim 1, characterized in that: In the process creation step, the flowchart further includes a gateway node, and the gateway node includes an exclusive gateway and a parallel gateway. All outgoing connection lines of the exclusive gateway are configured with a conditional judgment script, and all outgoing connection lines of the parallel gateway are not configured with a conditional judgment script; In the process running step, when an exclusive gateway is encountered during the execution of the process model, the condition judgment scripts of each outgoing connection line of the exclusive gateway are executed in sequence until the first outgoing connection line with a true result is found and the downstream node corresponding to the outgoing connection line is activated; If a parallel gateway is encountered, the downstream nodes corresponding to all outgoing connections of the parallel gateway are activated.

3. The workflow design method based on Raphael according to claim 1, characterized in that: In the process running step, during the execution of the process model, the status data of each node is obtained in real time, the status data is converted into JSON format and mapped into a corresponding process tracking diagram through the process designer, and the process tracking diagram is visually displayed for users to track the current status of the process.

4. The workflow design method based on Raphael according to claim 3, characterized in that: The status data includes process variables and the execution status, completion time and executor of each node. The process variables include approval results and amount.

5. The workflow design method based on Raphael according to claim 1, characterized in that: In the process parsing step, the structured data includes node metadata and connection line metadata, the node metadata includes type, executor attribute and Groovy script path, and the connection line metadata includes source node, target node and condition judgment script; In the process running step, the message middleware includes ActiveMQ and RabbitMQ.

6. A workflow design system based on Raphael, characterized in that: It includes the process creation module, process parsing module, process running module and process termination module connected in sequence. The process creation module uses a web process designer developed based on the Raphael vector graphics library to construct a flow chart including a start node, at least one task node, an end node, and multiple outgoing connection lines connecting the nodes through its toolbar and canvas; configures executor attributes and a Groovy script for injecting business logic for each task node, and configures a conditional judgment script for determining the flow direction for each outgoing connection line; then serializes the flow chart into a process definition file in JSON format and transmits it to the process parsing module; The process parsing module parses the process definition file in JSON format into structured data, and then generates an executable process model. The process model includes rules for node relationships, data transfer, script execution timing, and task allocation; The process running module executes the process model and generates a node instance of a start node to mark the process start; Locate the first task node based on the node relationship rules defined in the process model; According to the script execution timing rules, the workflow engine is used to execute the Groovy script of the first task node, and a task node instance is generated according to the business logic defined in the Groovy script. At the same time, following the data transmission rules, the data required for task execution is passed to the task node instance, and according to the task allocation rules and the executor attributes of the task node, the message middleware is used to push the to-do tasks generated based on the task node instance to the target user; then, according to the condition judgment script of all outgoing connection lines of the first task node, the outgoing connection lines with the result of true are filtered out, and the downstream nodes corresponding to the filtered outgoing connection lines are activated to obtain the next ready node of the first task node; The process termination module takes the ready node as the starting point, repeats the principles and processes executed for the first task node in the process running module, and continuously advances the execution of the process until it reaches the end node and generates a node instance of the end node, marking the termination of the process.

7. The Raphael-based workflow design system according to claim 6, characterized in that: In the process creation module, the flow chart further includes a gateway node, the gateway node includes an exclusive gateway and a parallel gateway, all outgoing connection lines of the exclusive gateway are configured with a conditional judgment script, and all outgoing connection lines of the parallel gateway are not configured with a conditional judgment script; In the process running module, when an exclusive gateway is encountered during the execution of the process model, the condition judgment scripts of each outgoing connection line of the exclusive gateway are executed in sequence until the first outgoing connection line with a true result is found and the downstream node corresponding to the outgoing connection line is activated; If a parallel gateway is encountered, the downstream nodes corresponding to all outgoing connections of the parallel gateway are activated.

8. The Raphael-based workflow design system according to claim 6, characterized in that: In the process operation module, during the execution of the process model, the status data of each node is obtained in real time, the status data is converted into JSON format and mapped into the corresponding process tracking diagram through the process designer, and the process tracking diagram is visually displayed for users to track the current status of the process.

9. The Raphael-based workflow design system according to claim 8, characterized in that: The status data includes process variables and the execution status, completion time and executor of each node. The process variables include approval results and amount.

10. The Raphael-based workflow design system according to claim 6, characterized in that: In the process parsing module, the structured data includes node metadata and connection line metadata. The node metadata includes type, executor attribute and Groovy script path. The connection line metadata includes source node, target node and condition judgment script. In the process running module, the message middleware includes ActiveMQ and RabbitMQ.

Images