A method, apparatus, computer equipment, and storage medium for task allocation based on rule-based dynamic configuration.

Abstract

This invention discloses a task allocation method, apparatus, computer device, and storage medium based on rule-based dynamic configuration, relating to the field of workflow engine technology. Specifically, it can be applied to the financial and medical fields, ensuring flexibility while meeting the requirements of financial risk control and clinical diagnosis for traceability and production stability, thus improving the overall reliability and intelligence of the system. The method includes: configuring at least one dynamic rule in a visual rule configuration component, assigning a rule identifier to each dynamic rule starting with a preset prefix; when a workflow node is obtained, obtaining the handler field and identifying whether the handler field starts with the preset prefix; if it starts with the preset prefix, extracting the rule identifier, calling the visual rule configuration component to determine the target dynamic rule indicated by the rule identifier among at least one dynamic rule; calling the visual rule configuration component to execute the target dynamic rule and perform task allocation.

Description

Technical Field

[0001] This invention relates to the field of workflow engine technology, and can be specifically applied to the financial and medical fields. In particular, it relates to a task allocation method, apparatus, computer equipment, and storage medium based on rule-based dynamic configuration. Background Technology

[0002] In time-sensitive sectors such as finance and healthcare, workflow-driven task allocation mechanisms are crucial for ensuring business compliance and operational efficiency, including tasks like credit approval, medical consultations, and tiered surgical authorization. The financial and healthcare sectors are characterized by frequent organizational restructuring, such as bank branch reorganizations and hospital department mergers; approval strategies also often need to be dynamically changed, such as adjusting risk control thresholds in real time according to regulatory policies and flexibly configuring multidisciplinary consultation processes based on patient grading; simultaneously, multi-department and multi-role collaboration is often complex, such as joint credit granting across branches and joint diagnosis and treatment across departments. Therefore, task allocation methods must possess high flexibility, low maintenance costs, and refined authority and responsibility delineation capabilities to support the rapid evolution and dynamic adaptation of business rules.

[0003] In related technologies, when assigning tasks, the handler can be directly specified in the process engine node using hard coding, or the handler mapping relationship can be predefined through a static configuration file; the second is to introduce a rule engine, which separates the assignment logic from the code and achieves dynamic parsing through an independent rule file.

[0004] In the process of developing the relevant technology, the applicant recognized that the relevant technology has at least the following problems: On the one hand, the introduction of the rule engine leads to fragmented allocation logic scattered across multiple rule files, which can easily cause priority conflicts, infinite loops, or rule overriding omissions when multiple people collaborate, reducing the readability and controllability of the system. On the other hand, when problems such as mismatched handling personnel occur, such as mismatch between credit approval authority and responsibility or incorrect departmental affiliation of consulting experts, troubleshooting requires full log retrieval, which affects production stability and is prone to production failures. For fields with high requirements for traceability of responsibility, such as financial risk control and clinical diagnosis and treatment, it is impossible to simultaneously ensure dynamic flexibility and reliability, resulting in poor intelligence. Summary of the Invention

[0005] In view of this, the present invention provides a task allocation method, apparatus, computer device and storage medium based on rule-based dynamic configuration, the main purpose of which is to solve the problem that it is currently impossible to simultaneously take into account dynamic flexibility and reliability assurance.

[0006] According to a first aspect of the present invention, a task allocation method based on rule-based dynamic configuration is provided, the method comprising: Configure at least one dynamic rule in the visual rule configuration component, and assign a rule identifier with a preset prefix to each dynamic rule; When a workflow node is obtained, the handler field is retrieved from the configuration of the workflow node, and it is identified whether the handler field starts with the preset prefix. If it is determined that the processor field begins with the preset prefix, then the rule identifier is extracted from the processor field, and the visual rule configuration component is called to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The visualization rule configuration component is invoked to execute the target dynamic rule, and the list of user identifiers obtained after execution is used as the task handlers of the workflow nodes, and tasks are assigned.

[0007] According to a second aspect of the present invention, a task allocation device based on rule-based dynamic configuration is provided, the device comprising: A configuration module is used to configure at least one dynamic rule in a visual rule configuration component, and to assign a rule identifier with a preset prefix to each dynamic rule; The identification module is used to obtain the handler field from the configuration of the workflow node when a workflow node is obtained, and to identify whether the handler field starts with the preset prefix. The extraction module is used to extract a rule identifier from the processor field if it is determined that the processor field starts with the preset prefix, and to call the visual rule configuration component to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The allocation module is used to call the visual rule configuration component to execute the target dynamic rule, use the list of user identifiers obtained after execution as the task handlers of the workflow nodes, and perform task allocation.

[0008] According to a third aspect of the present invention, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.

[0009] According to a fourth aspect of the present invention, a storage medium is provided having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0010] By employing the above technical solutions, this invention provides a task allocation method, apparatus, computer equipment, and storage medium based on rule-based dynamic configuration. Targeting high-time-sensitivity scenarios such as financial credit approval and medical consultations, this invention centrally manages dynamic rules through a visual rule configuration component. Using a preset prefix as an explicit convention for rule identification, it overcomes problems such as rule fragmentation, priority conflicts, and coverage omissions caused by traditional rule engines. When organizational structures are adjusted or approval strategies change, maintenance personnel only need to modify the corresponding rules in the visual interface, eliminating the need to search and coordinate among multiple rule files, thus reducing maintenance costs and rule conflict risks. Furthermore, since the handler field of workflow nodes directly embeds the rule identifier, the execution process can be traced back to the specific rule. In the event of a handler mismatch, troubleshooting can quickly locate the target rule and its configuration change records, avoiding the inefficiency and uncertainty of full log retrieval. While ensuring flexibility, this invention meets the requirements of financial risk control and clinical diagnosis for traceability and production stability, improving the overall reliability and intelligence of the system.

[0011] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0012] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of an application environment for a task allocation method based on rule-based dynamic configuration in one embodiment of the present invention; Figure 2 This is a flowchart illustrating a task allocation method based on rule-based dynamic configuration in one embodiment of the present invention; Figure 3 This is a flowchart illustrating a specific implementation of step S10; Figure 4 This is a flowchart illustrating a task allocation method based on rule-based dynamic configuration in another embodiment of the present invention; Figure 5 This is another flowchart illustrating a task allocation method based on rule-based dynamic configuration in one embodiment of the present invention; Figure 6 This is a schematic diagram of a task allocation device based on rule-based dynamic configuration in one embodiment of the present invention; Figure 7This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 8 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The task allocation method based on rule-based dynamic configuration provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can configure at least one dynamic rule in the visual rule configuration component based on user actions on the client, assigning a rule identifier to each dynamic rule that begins with a preset prefix. When a workflow node is obtained, the server retrieves the handler field from the workflow node's configuration and checks whether the handler field begins with the preset prefix. If the handler field is determined to begin with the preset prefix, the server extracts the rule identifier from the handler field, calls the visual rule configuration component to determine the target dynamic rule indicated by the rule identifier in at least one dynamic rule, and calls the visual rule configuration component to execute the target dynamic rule. The resulting list of user identifiers is used as the task handlers for the workflow node, and tasks are assigned.

[0015] In this invention, for high-time-sensitivity scenarios such as financial credit approval and medical consultation, a visual rule configuration component is used to centrally manage dynamic rules. A preset prefix is ​​used as an explicit convention for rule identification, overcoming problems such as rule fragmentation, priority conflicts, and coverage omissions caused by traditional rule engines. When organizational structures are adjusted or approval strategies change, maintenance personnel only need to modify the corresponding rules in the visual interface, eliminating the need to search and coordinate across multiple rule files, reducing maintenance costs and rule conflict risks. Furthermore, since the handler field of workflow nodes directly embeds the rule identifier, the execution process can be traced back to the specific rule. In case of handler mismatch, troubleshooting can quickly locate the target rule and its configuration change records, avoiding the inefficiency and uncertainty of full log retrieval. While ensuring flexibility, this meets the requirements of financial risk control and clinical diagnosis for traceability and production stability, improving the overall reliability and intelligence of the system. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a separate server or a server cluster composed of multiple servers. The invention will be described in detail below through specific embodiments.

[0016] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a rule-based dynamic configuration-based task allocation method provided in this embodiment of the invention includes the following steps: S10: Configure at least one dynamic rule in the visual rule configuration component, and assign a rule identifier with a preset prefix to each dynamic rule.

[0017] The rule-based dynamic configuration task allocation method provided by this invention can be applied to task allocation systems in various application scenarios. Task allocation systems are typically implemented through a server-side architecture, using a visual rule configuration component to centrally manage task allocation logic. It employs rule identifiers with preset prefixes, decoupled from the workflow node handler field, to achieve flexible arrangement and efficient execution of allocation rules. In financial scenarios, the task allocation system supports dynamic assignment of tasks such as credit approval and cross-branch joint credit granting. For example, it can adjust the approver rules corresponding to risk control review nodes in real time according to regulatory policies, or automatically update the handler list after branch restructuring as organizational structures change, ensuring business compliance and operational efficiency. In medical scenarios, the task allocation system can be applied to processes such as multidisciplinary consultations and surgical grade authorization. It dynamically configures consultation expert teams based on disease severity or departmental mergers, ensuring that consultation tasks are accurately matched with qualified physicians. Simultaneously, the traceability of rule identifiers meets the high reliability requirements of clinical diagnosis and treatment for responsibility attribution and change records.

[0018] In this embodiment of the invention, a visual rule configuration component is pre-deployed in the task allocation system. This component provides a graphical interface for operation and maintenance personnel or business personnel to use, supporting online addition, modification, or deletion of dynamic rules. A dynamic rule is a unit that encapsulates the calculation logic of the task handler, such as returning a list of user identifiers that meet certain conditions based on department, role, or monetary threshold. In this embodiment, the task allocation system assigns a rule identifier to each dynamic rule. The rule identifier must begin with a preset prefix. This preset prefix distinguishes between static handler fields and dynamic rule calls. In this embodiment, the preset prefix is ​​set to "rules," such as "rulesGetUmByRole," which indicates obtaining user information through a role.

[0019] In this way, the previously fragmented allocation logic is converged through the above process, eliminating priority conflicts and overriding omissions between rule files; at the same time, the explicit convention of the preset prefix provides a reliable foundation for rapid identification and route distribution in subsequent steps, reducing maintenance costs caused by scattered rules.

[0020] For example, in the financial sector, banks can pre-configure the

rulesCreditApprover

rulesMultidisciplinaryTeam

[0021] Among them, such as Figure 3 As shown, in step S10, that is, configuring at least one dynamic rule in the visual rule configuration component and assigning a rule identifier with a preset prefix to each dynamic rule, the following steps are included: S11: Determine the preset visual rule configuration component, and predefine multiple rule types in the visual rule configuration component.

[0022] In this embodiment of the invention, the task allocation system first determines a preset visual rule configuration component. In this embodiment, the visual rule configuration component can be a graphical platform integrating rule definition, testing, version management, and hot reloading. Within the visual rule configuration component, the task allocation system predefines multiple rule types based on common business scenario requirements, specifically including role-based handler mapping rules, hierarchical relationship query rules, and multi-dimensional condition combination rules. Role-based handler mapping rules map user roles, such as approval or review roles, to a specific list of personnel or positions. Hierarchical relationship query rules dynamically deduce handlers based on the organizational hierarchy of the submitter, initiator, or associated personnel, such as direct superiors or department heads. Multi-dimensional condition combination rules combine multiple business dimensions, such as amount range, department affiliation, risk level, and disease severity, through logical combination and condition judgment, outputting a list of user identifiers that meet all conditions. Through these three preset rule types, the task allocation system can cover most task allocation scenarios, providing a standardized classification framework for subsequent rule configuration.

[0023] By categorizing rules according to business semantics through the above process, the problems of chaotic rule definitions and unclear types in traditional rule engines can be avoided. At the same time, the visual rule configuration component serves as a unified rule configuration entry point, enabling business personnel in the financial and medical fields to intuitively understand the purpose of each rule type, reducing the configuration threshold, and laying a structured foundation for subsequent rule conflict detection and version tracing.

[0024] For example, in the financial sector, banks can preset "role-based processor mapping rules" in the visual rule configuration component to assign multiple loan officers to the initial credit review role; in the medical sector, hospitals can preset "role-based processor mapping rules" to map the attending physician role to the list of attending physicians in each department.

[0025] S12: Receive rule configuration parameters, and determine multiple dynamic rules to be configured from various rule types according to the rule configuration parameters.

[0026] In this embodiment of the invention, the task allocation system receives rule configuration parameters input by operations or business personnel through the visual interface of the visual rule configuration component. These parameters may include the rule type selection, the applicable business context description, and the set of conditions for the rule to take effect. Based on these configuration parameters, the task allocation system selects one or more dynamic rules from three predefined rule types that require specific configuration. For example, a user can select the "Multi-dimensional Condition Combination Rule" type on the interface and specify that this rule is used for "Medical Consultation Expert Allocation." The task allocation system then determines to create a new dynamic rule instance for this type or modify an existing rule of the same type, thereby instantiating the abstract rule type into a concrete, editable business rule entry, preparing the rule object level for subsequent detailed parameter configuration.

[0027] In this way, through the explicit selection of rule types in the above process, the task allocation system can automatically verify the matching between the configured parameters and the rule types, avoiding logical errors caused by type mismatch. At the same time, since the rule configuration parameters and rule identifiers are managed separately, when business strategies change, such as regulatory policies adjusting credit approval authority or hospital departments reorganizing and changing consultation rules, users only need to re-enter the configuration parameters and update the corresponding rules, without having to search for definitions scattered in multiple rule files, significantly reducing the risk of production failures caused by configuration omissions or conflicts.

[0028] For example, in the financial sector, a bank, in its visualization rule configuration component, selects the "Multi-dimensional Condition Combination Rule" type for the existing

rulesCreditApprover

rulesMultidisciplinaryTeam

[0029] S13: According to the rule configuration parameters, configure the input parameters, execution logic and return result structure for each dynamic rule in the visual rule configuration component, and assign a preset prefix as the rule identifier for each dynamic rule.

[0030] In this embodiment of the invention, after determining the dynamic rule to be configured, the task allocation system will complete three configurations for each dynamic rule in the visual rule configuration component according to the rule configuration parameters provided by the user. The first configuration is to configure the input parameters, that is, to define which data needs to be obtained from the process context when the rule runs, such as the applicant's department, business amount, patient's age, role code, etc. The second configuration is to configure the execution logic, that is, to write the calculation process of the processor using expression scripts or graphical conditional branches, such as "if the department = 'purchasing' and the amount > 50000, then return 'the vice president in charge', otherwise return the department manager". The third configuration is to configure the return result structure, specifying whether the output after the rule is executed is a single user identifier or a list of user identifiers, and the data format of each identifier.

[0031] After completing the above configuration, each dynamic rule needs to be assigned a rule identifier that begins with a preset prefix. This preset prefix is ​​a string identifier, such as "[rules]", used to distinguish it from the static handler field. Finally, all configured dynamic rules are stored in the visual rule configuration component, supporting real-time testing, version management, and hot deployment.

[0032] In this way, through the structured configuration of input parameters, execution logic, and return results in the above process, each dynamic rule is self-contained and semantically clear, which can eliminate the hidden errors caused by the rule's dependence on external variables in traditional rule engines. The string identifier with the preset prefix serves as the unique reference of the rule in the process node, making the execution path traceable. Once a mismatch of handlers occurs, the operation and maintenance personnel can directly view the complete configuration parameters, input and output structure, and historical change records of the rule in the visual rule configuration component based on the rule identifier on the node, without having to manually search in the full log, thus improving the timeliness and accuracy of fault diagnosis and meeting the requirements of financial risk control and clinical diagnosis for traceability of responsibility and production stability.

[0033] Additionally, in this embodiment of the invention, optionally, during the system startup phase, the task allocation system first initializes the client instance of the visual rule configuration component. This client instance is responsible for encapsulating the network communication logic with the rule configuration center, which can be middleware that supports dynamic configuration. By establishing a long connection or HTTP connection, the client instance can reliably interact with the rule configuration center. The rule configuration center, as a server that centrally stores and manages at least one dynamic rule definition, saves all rule identifiers starting with a preset prefix, along with their corresponding input parameters, execution logic, and return result structure. After successful client instance initialization, the task allocation system automatically subscribes to the rule configuration center for changes to the configured dynamic rules. This means that once an operations and maintenance personnel modify a rule on the visual interface of the visual rule configuration component—for example, adjusting the threshold for credit approval or changing the list of consulting experts—the rule configuration center will push the changes to the subscribed client instances in real time, allowing the new rule to take effect without restarting the application. Subsequently, when the workflow engine reaches a processor field that starts with a preset prefix, the engine will send a rule execution request with the corresponding rule identifier to the rule configuration center through the initialized client instance. The rule configuration center will find the corresponding target dynamic rule based on the identifier, execute the calculation logic defined therein, and return the execution result to the workflow engine, thus completing the node task allocation.

[0034] Through the above process, firstly, rule changes do not require application restarts and support hot updates, which is crucial for time-sensitive fields such as finance and healthcare. Credit approval strategies may be adjusted daily according to regulatory policies, and hospital department scheduling or consultation rules may also change at any time. Hot update capability improves business response speed from weekly to minute-level. Secondly, combined with the dynamic push capability of the configuration center, the task allocation system can realize canary releases and version rollbacks. For example, the correctness of new rules can be verified on a small number of process instances first, and then fully implemented after confirmation. If a problem is found, it can be quickly rolled back to the previous stable version, thereby ensuring the stability and reliability of the production environment. Thirdly, since all rule execution requests are routed to the rule configuration center through a unified client, the execution path is clear and completely recorded. When a mismatch occurs, troubleshooters can directly use the change logs and version history of the configuration center to accurately locate the modification time, modifier, and content of the specific rule, avoiding the inefficiency and uncertainty of relying on full application log retrieval, and meeting the requirements of financial risk control and clinical diagnosis and treatment for traceability of responsibility.

[0035] For example, in the financial or healthcare sectors, a bank or hospital might deploy a rule configuration center. When the task allocation system starts, the visual rule configuration component client initializes and subscribes to all dynamic rules starting with "rules". When new rule requirements are released, operations personnel can directly modify the execution logic of the relevant rules in the visual rule configuration component interface. The rule configuration center pushes the changes in real time, and requests entering that node the next second will automatically execute according to the updated rules.

[0036] Furthermore, in this embodiment of the invention, optionally, the task allocation system supports full lifecycle management of dynamic rules, including rule addition and deletion operations. When operations or business personnel initiate a rule addition command through the visual rule configuration component, the task allocation system first obtains the new configuration parameters of the dynamic rule to be added. The new configuration parameters include the target rule type, input parameter list, execution logic script, return result structure, and custom rule identifier of the dynamic rule to be added. Among them, the target rule type can be a role-based handler mapping rule, a hierarchical relationship query rule, or a multi-dimensional condition combination rule; the input parameter list is used to indicate which data needs to be obtained from the process context when the rule is executed, such as the applicant's department, loan amount, patient age, etc.; the execution logic script is a conditional branch or calculation process written using expression language; the return result structure is used to define whether the output is a single user identifier or a list of user identifiers; the custom rule identifier must start with a preset prefix and must not be duplicated with the existing rule identifiers in the component to ensure the uniqueness of the reference in the process node. Subsequently, the task allocation system automatically matches the corresponding rule template in the visual rule configuration component based on the target rule type. This means that each rule type has a pre-defined standardized configuration framework; for example, the multi-dimensional condition combination rule template will pre-set placeholders for the "condition branch" and "return value mapping" fields. The task allocation system will write the input parameter list, execution logic script, and return result structure into the corresponding fields according to the format requirements of the rule template. Finally, it will bind the custom rule identifier to the identifier field of the rule template, completing the persistent storage of the new rule.

[0037] In this way, the template-based configuration method can lower the threshold for rule definition, and business personnel can quickly extend new allocation logic without writing underlying code. At the same time, the preset prefix and uniqueness verification mechanism can avoid rule identification conflicts from the source. Combined with the version management function of the visual rule configuration component, any subsequent modifications to the rules will generate change records, providing a solid foundation for accountability.

[0038] For example, in the financial or medical fields, when a bank launches a new product or a hospital adds a new consultation rule, a new dynamic rule needs to be added. The operations and maintenance personnel can select the "multi-dimensional condition combination rule" type in the visual rule configuration component, configure the input parameters and execution logic script, and customize the rule starting with "[rules]". The new rule can then be referenced.

[0039] Similarly, the task allocation system also supports rule deletion. When an operations and maintenance personnel initiate a rule deletion command, the task allocation system obtains the specified rule identifier of the dynamic rule to be deleted. Then, in the visual rule configuration component, it traverses all configured dynamic rule storage structures to query rule entries that match the specified rule identifier. If a matching rule entry is found, the task allocation system performs the deletion operation, completely removing the rule entry from the storage structure and releasing the configuration resources it occupies, such as the parsing cache in memory and database storage space. Optionally, a deletion log is recorded for auditing purposes. If the task allocation system does not find any matching rule entries after traversal, it returns a deletion failure indication, informing the user that the rule identifier does not exist or has been deleted. In this way, the process provides a secure and controllable rule recycling capability, preventing obsolete rules from continuing to occupy system resources or being misused by process nodes. When organizational structures are adjusted or business strategies are abolished in the financial or medical fields, dynamic rules that are no longer applicable can be cleaned up in a timely manner, preventing a large number of invalid rules from accumulating, which would lead to reduced readability and maintenance chaos. At the same time, the matching verification before deletion and the clear feedback on deletion failure can prevent production failures caused by accidental deletion of critical rules.

[0040] For example, in the financial or medical fields, if a bank discontinues a product or a hospital cancels a consultation process, the corresponding dynamic rules are no longer needed. The operations and maintenance personnel initiate a deletion command and specify the identifier. The task allocation system finds the corresponding rule in the visual rule configuration component and removes it, releasing the related configuration resources. If any subsequent process node still incorrectly references the rule, it will trigger a downgrade process when the rule cannot be found. At the same time, the deletion operation log can be used for compliance audit traceability.

[0041] S20: When a workflow node is obtained, retrieve the handler field from the workflow node's configuration and identify whether the handler field begins with a preset prefix.

[0042] In this embodiment of the invention, during the execution of the process engine, when a workflow node is obtained, such as a user task node in a BPMN process definition, the task allocation system first reads the handler field in the node configuration. The handler field stores the definition of the node handler in string form. Subsequently, the task allocation system uses string matching logic to identify whether the handler field begins with a preset prefix, such as whether it begins with "rules". Without parsing the rule content, the system can quickly determine whether the current handler configuration is a static fixed value or a dynamic rule call based solely on the prefix.

[0043] In this way, a lightweight prefix recognition mechanism can achieve a clear separation between static and dynamic configurations, avoiding the performance overhead of deep parsing of each field after introducing a complex rule engine. At the same time, the recognition logic is simple and reliable, making it easy to implement a unified node processing human processor in the code, providing a clear entry point for subsequent troubleshooting.

[0044] For example, in finance or healthcare, a field is configured to start with "rules". When the task allocation system recognizes the "rules" prefix, it triggers dynamic rule parsing.

[0045] It should be noted that, in this embodiment of the invention, optionally, before acquiring workflow nodes and identifying the handler field, the task allocation system first needs to complete the design and deployment phase of the process definition. When business personnel or process designers initiate a workflow node creation request through a process modeling tool, the task allocation system responds to the request, acquires the multiple handler roles, hierarchical relationship rules, and multi-dimensional condition combination rules indicated in the request, and automatically constructs multiple role nodes based on these inputs. Each node represents an abstract role of a task to be assigned. Subsequently, according to the hierarchical architecture between roles indicated by the hierarchical relationship rules, such as who reports to whom, which node is in the pre-approval stage, which node is in the post-review stage, and the branching logic in the multi-dimensional condition combination rules, the role nodes are topologically sorted and conditionally branched, ultimately generating a structured workflow diagram. The workflow diagram can be represented in BPMN (Business Process Modeling and Annotation) format. In the generated flowchart, the task allocation system further determines the specific role nodes of the tasks to be assigned as multiple user task nodes, and identifies the "handler" attribute field of each user task node according to the rules specified in advance by the designer. After all node configurations are complete, the task allocation system exports this workflow diagram, which contains rule identifiers, as a workflow definition file, for example, as a .bpmn or .bpmn20.xml file, and deploys this workflow definition file to the workflow engine. The workflow engine can then parse this workflow definition file, retrieve workflow nodes at runtime, and perform prefix identification and dynamic rule invocation on their handler fields.

[0046] In this way, through the above process, firstly, process designers do not need to write any code. They only need to fill in rule identifiers starting with preset prefixes in the visual process modeling tool to bind complex dynamic allocation logic to specific nodes. This lowers the barrier to entry for business personnel, allowing them to directly participate in process configuration without relying on developers to hard-code or edit complex rule files. Secondly, since the rule identifiers are directly associated with the node handler attributes, and the specific logic of the rules is centrally stored in the visual rule configuration component, when the organizational structure is frequently adjusted or the approval strategy changes dynamically, only the corresponding rule content in the visual rule configuration component needs to be modified. There is no need to redesign the flowchart or redeploy the process definition file, achieving decoupling between the process structure and allocation logic and improving business response speed. At the same time, the rule identifiers retained in the process definition file also provide clear anchors for subsequent compliance audits and accountability. Once a handler mismatch occurs, auditors can directly see the rule identifier that the node should have called from the process definition, and then, combined with the change history of the visual rule configuration component, quickly locate the root cause of the problem.

[0047] For example, in the financial sector, a bank needs to design a credit approval process for cross-branch joint credit granting. The process designer creates three user task nodes: initial review node, secondary review node, and final review node. Each user task node is populated with rules starting with "[rules]". After the process designer exports the BPMN file and deploys it, the workflow engine automatically parses these handler fields starting with "[rules]" and retrieves the latest handler list from the visual rule configuration component in real time for each subsequent credit application instance. When a branch is merged, only the mapping logic of the corresponding rules starting with "[rules]" needs to be modified in the visual rule configuration component. All ongoing and newly created loan applications will be automatically assigned to the new loan officers after the merger, without needing to redeploy the flowchart.

[0048] For example, in the medical field, a top-tier hospital designs a multidisciplinary consultation workflow. Medical staff create three user task nodes: a consultation application node, an expert allocation node, and a consultation opinion summary node. Each user task node is configured with rules starting with "[rules]". After configuration, the workflow definition is exported and deployed. When the hospital experiences departmental mergers or changes in expert scheduling, only the expert database mapping and conditional judgment logic corresponding to the rules starting with "[rules]" need to be updated in the visual rule configuration component. The changes take effect immediately, and all newly initiated consultation tasks will be assigned experts according to the new rules, without requiring the workflow designer to modify the BPMN diagram and redeploy.

[0049] Further, in this embodiment of the invention, optionally, to coordinate various handler acquisition strategies and achieve unified invocation of dynamic rules, the task allocation system adds a node handler processor class, namely NodeAssigneeResolver, to the code project. This class is marked by implementing a predefined processor interface such as the AssigneeResolver interface in Java or by using predefined annotations such as @Component or @Service, so that it can be recognized by the dependency injection container of the workflow engine. Internally, the NodeAssigneeResolver class encapsulates complete coordination logic for handler acquisition strategies, specifically including parsing the handler field in the workflow node configuration, determining whether the field starts with a preset prefix, invoking the corresponding rule execution engine to obtain the result for dynamic rules, and falling back to process variables or default fixed values ​​for non-dynamic rules or rule execution failures. In this embodiment of the invention, the node handler processor adopts a strategy pattern design, that is, encapsulating independent strategy implementation classes for different types of handler acquisition methods. NodeAssigneeResolver dynamically selects and delegates the execution to the corresponding strategy based on runtime conditions, possessing good extensibility and maintainability, and ensuring orderly coordination of various value acquisition methods. Finally, the processor returns a unified list of processors, which supports various task allocation scenarios such as single person, multiple people, and candidate groups.

[0050] During system deployment, the workflow engine typically starts as a standalone service. Upon startup, it automatically performs a classpath scan or uses an injection container like a dependency object manager to discover all classes marked with processor interfaces or annotations, including the `NodeAssigneeResolver` class. After instantiating this class, the workflow engine loads it into a processor registry in memory. This registry is a key-value mapping structure, where the key is the processor type or name, and the value is the processor instance. Subsequently, whenever the workflow engine needs to determine the handler for a task node, it directly retrieves the `NodeAssigneeResolver` instance from the registry, identifies and parses the handler field, without repeatedly creating or searching for the processor. This improves runtime efficiency and allows processor replacement or extensions to be automatically registered and effective simply by adding the corresponding processor class to the code and restarting the service.

[0051] Through the above process, the task allocation system can be compatible with the existing code implementation of handler logic, such as the role-based grouping of handler nodes under special rules, achieving code reuse and smooth migration, avoiding the cost of overhauling and rebuilding. Secondly, the processor's three-level fault-tolerance logic, including the judgment of preset prefixes, the call to the visual rule configuration component, and the fallback to process variables or fixed values, ensures that even if there are network fluctuations or rule execution anomalies in the rule configuration center, workflow nodes can still obtain a valid handler, preventing process interruption. This is crucial for time-sensitive scenarios such as financial credit approval and medical consultation. Furthermore, the processor registry makes the entire parsing entry point single and unified. The identification path of all handler fields can be log-tracked and monitored through this processor. Once a handler mismatch occurs, troubleshooters only need to check the execution log of NodeAssigneeResolver to quickly locate at which stage the deviation occurred, improving the efficiency of production problem troubleshooting.

[0052] For example, in the financial sector, a bank's workflow engine originally contained a large amount of hard-coded logic for retrieving approvers. This code was scattered and difficult to maintain. The task allocation system added a NodeAssigneeResolver processor and adopted the strategy pattern. One strategy specifically encapsulated the original "grouping by role" logic as a compatible implementation. When the engine starts, the object management container scans for this processor and registers it in memory. For existing process nodes, their handler fields may not start with "[rules]", and the processor automatically matches the "process variable" or "fixed value" strategy, without requiring modification to the existing process definition. For new credit products, nodes are configured with rules starting with "[rules]", and the processor, upon recognizing the "[rules]" prefix, calls the visual rule configuration component interface to retrieve the green finance department's approval group. When a loan application returns an empty list due to a rule configuration error, the processor triggers a rollback strategy, retrieving the default credit manager from the process variables as the handler, ensuring the process continues, and simultaneously recording an alarm log for maintenance personnel to investigate.

[0053] For example, in the medical field, a top-tier hospital's consultation workflow engine needs to be compatible with the existing manual allocation code based on departmental schedules, while also supporting new dynamic rules. The NodeAssigneeResolver processor encapsulates the logic using a strategy pattern. When the service starts, the processor instance is loaded into the registry. When the emergency department initiates a consultation request, the node handler field begins with "rules," and the processor selects the strategy from the visual rule configuration component for execution. If the visual rule configuration component interface times out due to network issues, the processor automatically degrades to reading the "on-call physician" from the process variables as a fallback. The entire resolution process is uniformly recorded by the processor log. In one instance, a patient was assigned to a physician who had been transferred. By querying the NodeAssigneeResolver execution log, the administrator quickly located the issue as the rule execution returned the user identifier from the old schedule, and then traced back the change history of the visual rule configuration component to find the root cause of the problem.

[0054] S30: If the identified handler field starts with a preset prefix, then extract the rule identifier from the handler field and call the visual rule configuration component to determine the target dynamic rule indicated by the rule identifier in at least one dynamic rule.

[0055] In this embodiment of the invention, when the handler field is identified as starting with a preset prefix, the task allocation system extracts the complete rule identifier from that field. Subsequently, the task allocation system calls the query interface or API provided by the visual rule configuration component, and matches the rule identifier against at least one dynamic rule stored in the component to find the corresponding target dynamic rule. The target dynamic rule contains the specific handler calculation logic, input parameter definitions, and a structural description of the returned result.

[0056] In the above process, using the rule identifier as a unique index ensures an unambiguous mapping from the handler field to the rule definition, avoiding priority conflicts caused by ambiguous rule names or multiple rule files with the same name in traditional rule engines. At the same time, since the rule identifier is directly embedded in the configuration of the workflow node, the execution path is traceable. Once a handler mismatch occurs, the operations and maintenance personnel can directly locate the specific rule definition and its change history in the visualization component based on the rule identifier filled in on the node, without having to search the entire log file.

[0057] For example, in a cross-branch joint credit granting scenario in the financial sector, a review node is configured to begin with "rules". After the task allocation system extracts this identifier, it finds the corresponding joint credit granting approver rule from the visual rule configuration component. In a graded authorization scenario for medical surgery, after the node is configured to begin with "rules" and is extracted, the task allocation system quickly locates the target rule that dynamically matches the authorizer based on the surgical level and physician qualifications.

[0058] S40: Call the visual rule configuration component to execute the target dynamic rule, use the list of user identifiers obtained after execution as the task handlers of the workflow nodes, and assign tasks.

[0059] In this embodiment of the invention, after determining the target dynamic rule, the task allocation system calls the rule execution engine of the visual rule configuration component, passing in relevant parameters from the current process context, such as the applicant's department, role, business amount, and disease severity. The visual rule configuration component then dynamically calculates a list of user identifiers that meet the rule conditions. After execution, the visual rule configuration component returns this list of user identifiers, which the task allocation system uses as the task handler set for the current workflow node. The task allocation module then creates pending tasks and distributes them to each user in the list. It should be noted that if an exception occurs during rule execution or an empty list is returned, the task allocation system will use a preset degradation strategy, such as reverting to a process variable or a fixed handler, to ensure that the process is not interrupted.

[0060] In this way, the above process enables hot updates and real-time effects of rules. When financial regulatory policies are adjusted or hospital departments are reorganized, operations and maintenance personnel only need to modify the calculation logic of the corresponding rule in the visualization component. Subsequently, all workflow nodes that reference the rule identifier will automatically obtain the new list of handlers without restarting the service or redeploying the process definition. At the same time, since the rule execution results are fully recorded, once a mismatch between authority and responsibility or an incorrect departmental affiliation occurs, the rule version and input parameters used in this rule call can be directly traced back through the logs, meeting the requirements of financial risk control and clinical diagnosis and treatment for traceability of responsibility and production stability.

[0061] For example, in a financial scenario, if a bank changes the name of a rule starting with "rules" from "department manager" to "risk committee member", the next credit approval task will be automatically assigned to the new set of approvers. In a medical scenario, if a hospital changes the name of a consulting expert in a rule starting with "rules" from "director of the emergency department" to "head of the emergency department on-call team", subsequent emergency consultation tasks will be immediately assigned to the appropriate personnel according to the new rule.

[0062] Among them, such as Figure 4 As shown, after step S20, that is, when a workflow node is obtained, after retrieving the handler field from the workflow node's configuration and identifying whether the handler field begins with a preset prefix, the method further includes the following steps: S50: If the identified handler field does not start with a preset prefix, then obtain the runtime variable context of the workflow node's process instance. The runtime variable context contains multiple sets of key-value pairs, where the key in each set of key-value pairs is the variable name and the value is the corresponding variable content.

[0063] In this embodiment of the invention, when the workflow engine executes a task node, it first obtains the handler field in the node configuration and identifies whether it begins with a preset prefix. If it is determined that the handler field does not begin with a preset prefix, i.e., the handler field is not dynamically called by a rule, the task allocation system then enters a static or semi-dynamic parsing branch. At this time, the task allocation system obtains the runtime variable context of the process instance to which the current workflow node belongs. The runtime variable context is a set of key-value pairs maintained by the workflow engine during the execution of the process instance. Each key-value pair consists of a variable name and a corresponding variable content. These variables come from the parameters passed in when the process starts, the output generated after the previous node is executed, or intermediate results dynamically set by the script. By obtaining the runtime variable context, it can be determined whether the handler field in the node configuration points to a process variable, thereby realizing the dynamic extraction of the handler from the runtime data. This ensures that when the handler is not obtained through a preset prefix dynamic rule, the task allocation system still has the opportunity to obtain a flexible handler assignment from the process context, rather than directly degenerating into a completely static fixed value.

[0064] In this way, by introducing runtime variable context, the task allocation system expands the parsing scope of the handler field from static strings to dynamic runtime data, enabling task allocation to rely on real-time information generated during process execution, such as the handler recommended by the previous approval node and the responsible department code calculated based on the business amount, thereby improving the flexibility of allocation. At the same time, this mechanism complements the dynamic rules that start with a preset prefix. For calculation logic that does not change frequently or does not require a complex rule engine, the handler can be directly passed through process variables, avoiding the overhead of creating dynamic rules for every simple scenario.

[0065] For example, in a financial loan approval scenario, if the handler field of a "financial review" node is not configured to start with "[rules]", the task allocation system will obtain the runtime variable context of the current loan application process instance. As another example, in a medical consultation scenario, if the handler field of a "department initial consultation" node is configured not to start with "[rules]", the task allocation system will obtain the runtime variable context of the consultation process instance.

[0066] S60: Use the original string of the "person" field as the key name to be matched, and query the runtime variable context to see if there is a variable name that matches the key name to be matched.

[0067] In this embodiment of the invention, the task allocation system uses the original string of the handler field obtained from the node configuration as the key name to be matched, such as

financeAuditor

financeAuditor

[0068] In this way, through the above process, a non-intrusive mapping from the handler field to process variables can be achieved. Business personnel or process designers only need to fill in a string in the handler attribute of the node. If this string happens to be the name of a variable in the process instance, the task assignment system can automatically parse it into the corresponding value without writing any additional expressions or configuration code. This lowers the barrier to entry for dynamic assignment, allowing non-technical personnel to dynamically transfer handlers through simple naming conventions. At the same time, since the query is based on key name matching, it avoids the overhead of complex expression parsing and eliminates runtime exceptions caused by expression syntax errors.

[0069] For example, in the financial field, in a bank's cross-branch joint credit granting process, the "processor" field configuration of the "branch preliminary review" node does not start with "[rules]". The task allocation system uses the string of the "processor" field as the key name to query the runtime variable context, finds that there is indeed a variable in the context with the key name "processor" field, and determines its value.

[0070] For example, in the medical field, in a hospital's multidisciplinary consultation process, the "processor" field configuration of the "image retrieval" node does not begin with "[rules]". The system queries the runtime variable context, finds the variable with the key name "processor" field, and determines its value.

[0071] S70: When the query determines that there is a variable name that matches the key name to be matched, extract the variable value corresponding to the variable name from the runtime variable context and use the variable value as the task handler.

[0072] In this embodiment of the invention, if the query determines that a variable name matching the key name exists, the task allocation system extracts the variable value corresponding to that variable name from the runtime variable context. In this embodiment, the data type of the variable value is a single user identifier, a list of user identifiers, or an expression string that can be parsed into a set of user identifiers. A single user identifier can be the string "jia" or the numeric employee number "1xxx6", or a list of user identifiers of type array or set, or an expression string that can be parsed into a set of user identifiers. After extracting the variable value, the task allocation system standardizes it into a unified user identifier list format. For a single user identifier, it is packaged into a single-element list; for those already in list type, they can be used directly; for expression strings, the corresponding parser is called to calculate them into a user identifier list. Finally, this list serves as the task handler for the current workflow node, and the task allocation module creates pending tasks and distributes them to each user in the list. It should be noted that if the type of a variable value cannot be resolved to any valid user identifier, such as an empty value or an unexpected object, the task assignment system will trigger exception handling or degradation logic, such as logging an alarm and attempting to roll back to the designated handler to ensure that the process is not interrupted.

[0073] For example, in a financial credit approval scenario, if the handler field of a certain "risk review" node does not start with "rules", the task allocation system finds the key name corresponding to the handler field in the runtime variable context. The corresponding variable value is a list of user identifiers. The task allocation system directly uses this as the handler and creates two review tasks.

[0074] For example, in a medical consultation scenario, if the handler field of a certain "test result review" node does not start with "rules", the task allocation system will find that the variable corresponding to the handler field exists, and its value is an expression string. The task allocation system will call the built-in expression engine to parse it, return the list of the chief physician's employee ID of the current laboratory department, and then use it as the handler of the review node.

[0075] S80: When the query determines that there is no variable name that matches the key name to be matched, use the original string of the handler field to generate fixed handler information, and use the handler indicated by the fixed handler information as the task handler.

[0076] In this embodiment of the invention, if the query determines that no variable name matches the key name to be matched, that is, no key name in the runtime variable context matches the original string of the handler field, the task allocation system will enter the fixed handler parsing branch. At this time, the task allocation system treats the original string of the handler field as fixed handler information. Fixed handler information includes username, job code, department identifier, or a multi-user identifier string connected by a separator, such as a single username or job code; it can also be a department identifier, used to identify the entire department, which is then converted by the engine into all members under that department during actual allocation; it can also be a multi-user identifier string connected by a separator. The task allocation system will convert the fixed handler information into a list of user identifiers according to pre-configured parsing rules, such as the default separator being a comma or semicolon. If the string cannot be split or parsed into any valid identifier, the task allocation system will treat it as a single identifier. Finally, the task allocation system will use this list as the task handler, and the task allocation module will complete the task creation and allocation, ensuring that the workflow node can obtain a clear task handler under any circumstances, and that the process will not be suspended or throw an exception due to rule recognition failure or missing variables.

[0077] In this way, through the above process, task assignment in the financial and healthcare fields will not be interrupted due to configuration errors or missing runtime data. Even if the operations and maintenance personnel mistakenly enter a string in the handler field that does not start with "rules" or is not any process variable name, the task assignment system can still treat it as a fixed handler, ensuring that the process is assigned to at least one valid handler, while logging it for subsequent troubleshooting. In addition, fixed handlers support multiple user identifier strings, making it relatively convenient to batch assign static personnel lists.

[0078] For example, in the financial field, in a loan approval process of a bank, the handler field of the "archive" node does not start with "rules", and there is no variable named "handler" in the runtime variable context. The task allocation system treats it as fixed handler information, and after parsing it according to the default delimiter, it obtains a list of user identifiers, which is a specific job role. The task allocation module will assign the archiving task to all users under this role.

[0079] For example, in the medical field, in a hospital's consultation process, the "processor" field of the "pathology report retrieval" node does not begin with "[rules]" and is not a variable name. The task allocation system treats this as fixed processor information. Assuming that the string does not contain any delimiters but has email address identifiers, the task allocation system considers it as an email address identifier for a department. Through a predefined department-member mapping, it is converted into a list of user identifiers for all pathologists under that department, thereby completing the task allocation.

[0080] In summary, the logical process of the task allocation method based on rule-based dynamic configuration proposed in this embodiment of the invention is summarized as follows: Figure 5 As shown, the handler field is obtained from the configuration of the workflow node. First, it is determined whether the configuration field starts with the preset prefix "rules". If so, the corresponding dynamic rule is executed by calling the visual rule configuration component to obtain a list of user identifiers as handlers. If not, it is further checked whether there is a variable with the same name as the configuration field in the process runtime parameters. If it exists, the handler is extracted from the process variable. If it does not exist, the configuration field is directly used as a fixed value. Finally, the obtained result set is returned uniformly through the node handler processor to complete the allocation and creation of task nodes.

[0081] The method provided in this invention addresses time-sensitive scenarios such as financial credit approval and medical consultations. It centrally manages dynamic rules through a visual rule configuration component and uses a preset prefix as an explicit rule identifier. This overcomes problems such as rule fragmentation, priority conflicts, and coverage omissions caused by traditional rule engines. When organizational structures are adjusted or approval strategies change, maintenance personnel only need to modify the corresponding rules in the visual interface, eliminating the need to search and coordinate across multiple rule files. This reduces maintenance costs and the risk of rule conflicts. Furthermore, since the handler field of workflow nodes directly embeds the rule identifier, the execution process can be traced back to the specific rule. In the event of a handler mismatch, troubleshooting can quickly locate the target rule and its configuration change records, avoiding the inefficiency and uncertainty of full log retrieval. While ensuring flexibility, this method meets the requirements of financial risk control and clinical diagnosis for traceability and production stability, improving the overall reliability and intelligence of the system.

[0082] Furthermore, as Figure 1 In a specific implementation of the method, this embodiment of the invention provides a task allocation device based on rule-based dynamic configuration, such as... Figure 6 As shown, the device includes: a configuration module 601, an identification module 602, an extraction module 603, and an allocation module 604.

[0083] The configuration module 601 is used to configure at least one dynamic rule in the visual rule configuration component, and to assign a rule identifier with a preset prefix to each of the dynamic rules; The identification module 602 is used to obtain the handler field in the configuration of the workflow node when a workflow node is obtained, and to identify whether the handler field starts with the preset prefix. The extraction module 603 is used to extract a rule identifier from the processor field if it is determined that the processor field starts with the preset prefix, and to call the visual rule configuration component to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The allocation module 604 is used to call the visual rule configuration component to execute the target dynamic rule, use the list of user identifiers obtained after execution as the task handlers of the workflow nodes, and perform task allocation.

[0084] In a specific application scenario, the configuration module 601 is used to determine a preset visualization rule configuration component, in which multiple rule types are predefined, including role-based handler mapping rules, hierarchical relationship query rules, and multi-dimensional condition combination rules; receive rule configuration parameters, and determine multiple dynamic rules to be configured from the multiple rule types according to the rule configuration parameters; according to the rule configuration parameters, configure input parameters, execution logic, and return result structure for each of the multiple dynamic rules in the visualization rule configuration component, and assign a rule identifier to each dynamic rule with the preset prefix as the starting point, wherein the preset prefix is ​​an identifier in string form.

[0085] In specific application scenarios, the configuration module 601 is further used to initialize a client instance of the visual rule configuration component during the system startup phase, and establish a network connection with an external rule configuration center through the client instance. The rule configuration center is used to centrally store and manage the definition content of the at least one dynamic rule. After the client instance is initialized, it subscribes to the rule configuration center for change events of the configured dynamic rules. When a dynamic rule starting with the preset prefix needs to be executed, the workflow engine sends a rule execution request carrying the corresponding rule identifier to the rule configuration center through the client instance. The rule configuration center then finds the corresponding dynamic rule based on the rule identifier, executes it, and returns the execution result.

[0086] In specific application scenarios, the configuration module 601 is further configured to, in response to a rule addition instruction, obtain new configuration parameters for the dynamic rule to be added. These new configuration parameters include the target rule type, input parameter list, execution logic script, return result structure, and custom rule identifier of the dynamic rule to be added. The custom rule identifier begins with the preset prefix and is not duplicated with any existing rule identifier in the visual rule configuration component. Based on the target rule type, a corresponding rule template is determined in the visual rule configuration component. The input parameter list, execution logic script, and return result structure are written into the rule template according to the format requirements of the target rule type, and the custom rule identifier is bound to the identifier field of the rule template. In response to a rule deletion instruction, the module obtains the specified rule identifier of the dynamic rule to be deleted. It iterates through all configured dynamic rules in the visual rule configuration component, queries for rule entries matching the specified rule identifier, and, if a matching specified rule entry is found, removes the specified rule entry from the rule storage structure of the visual rule configuration component and releases the configuration resources occupied by the specified rule entry. If no specified rule entry is found, it returns a deletion failure indication.

[0087] In specific application scenarios, the device further includes: A construction module is used to respond to a workflow node creation request by obtaining multiple handler roles, hierarchical relationship rules, and multi-dimensional condition combination rules indicated by the workflow node creation request; constructing multiple role nodes according to the multiple handler roles; and organizing the multiple role nodes according to the hierarchical architecture between roles indicated by the hierarchical relationship rules and the multi-dimensional condition combination rules to generate a workflow diagram; determining the role nodes to be assigned tasks among the multiple role nodes as multiple user task nodes; and filling in the rule identifier in the handler attribute field of each user task node in the workflow diagram; exporting the workflow diagram with the rule identifier filled in as a workflow definition file; and deploying the workflow definition file to the workflow engine so that the workflow engine can parse the workflow definition file, obtain the workflow nodes, and identify the handler field.

[0088] In specific application scenarios, the building module is also used to add a node handler class to the code project. The node handler class implements a predetermined processor interface or is marked by a predetermined annotation, and the node handler class encapsulates the coordination logic of the handler acquisition strategy. When the workflow engine starts as an independent service, the workflow engine discovers and instantiates the node handler class through classpath scanning or dependency injection container, and loads the instantiated node handler class into the processor registry in memory, so that the node handler instance can be obtained from the processor registry by calling the workflow engine to realize the identification of the handler field.

[0089] In specific application scenarios, the allocation module 604 is further configured to, if it is determined that the handler field does not begin with the preset prefix, obtain the runtime variable context of the workflow node's process instance. The runtime variable context contains multiple sets of key-value pairs, where the key in each key-value pair is a variable name and the value is the corresponding variable content. The original string of the handler field is used as the key name to be matched, and a query is performed in the runtime variable context to determine if a variable name matching the key name exists. When the query determines that a variable name matching the key name exists, the variable value corresponding to the variable name is extracted from the runtime variable context, and the variable value is used as the task handler. The data type of the variable value is a single user identifier, a list of user identifiers, or an expression string that can be parsed into a set of user identifiers. When the query determines that no variable name matching the key name exists, fixed handler information is generated using the original string of the handler field, and the handler indicated by the fixed handler information is used as the task handler. The fixed handler information includes a username, job code, department identifier, or a multi-user identifier string connected by a separator.

[0090] The device provided in this invention addresses time-sensitive scenarios such as financial credit approval and medical consultations. It centrally manages dynamic rules through a visual rule configuration component and uses a preset prefix as an explicit rule identifier. This overcomes problems such as rule fragmentation, priority conflicts, and coverage omissions caused by traditional rule engines. When organizational structures are adjusted or approval strategies change, maintenance personnel only need to modify the corresponding rules in the visual interface, eliminating the need to search and coordinate across multiple rule files, thus reducing maintenance costs and rule conflict risks. Furthermore, since the handler field of workflow nodes directly embeds the rule identifier, the execution process can be traced back to the specific rule. In the event of a handler mismatch, troubleshooting can quickly locate the target rule and its configuration change records, avoiding the inefficiency and uncertainty of full log retrieval. While ensuring flexibility, it meets the requirements of financial risk control and clinical diagnosis for traceability and production stability, improving the overall reliability and intelligence of the system.

[0091] Specific limitations regarding the rule-based dynamic configuration task allocation device can be found in the limitations of the rule-based dynamic configuration task allocation method described above, and will not be repeated here. Each module in the aforementioned rule-based dynamic configuration task allocation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0092] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements server-side functions or steps based on a rule-based dynamic configuration task allocation method.

[0093] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 8As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements client-side functions or steps based on a rule-based dynamic configuration task allocation method.

[0094] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Configure at least one dynamic rule in the visual rule configuration component, and assign a rule identifier with a preset prefix to each dynamic rule; When a workflow node is obtained, the handler field is retrieved from the configuration of the workflow node, and it is identified whether the handler field starts with the preset prefix. If it is determined that the processor field begins with the preset prefix, then the rule identifier is extracted from the processor field, and the visual rule configuration component is called to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The visualization rule configuration component is invoked to execute the target dynamic rule, and the list of user identifiers obtained after execution is used as the task handlers of the workflow nodes, and tasks are assigned.

[0095] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Configure at least one dynamic rule in the visual rule configuration component, and assign a rule identifier with a preset prefix to each dynamic rule; When a workflow node is obtained, the handler field is retrieved from the configuration of the workflow node, and it is identified whether the handler field starts with the preset prefix. If it is determined that the processor field begins with the preset prefix, then the rule identifier is extracted from the processor field, and the visual rule configuration component is called to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The visualization rule configuration component is invoked to execute the target dynamic rule, and the list of user identifiers obtained after execution is used as the task handlers of the workflow nodes, and tasks are assigned.

[0096] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0097] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this invention are all information and data authorized by the user or fully authorized by all parties.

[0098] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0100] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0101] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A task allocation method based on rule-based dynamic configuration, characterized in that, include: Configure at least one dynamic rule in the visual rule configuration component, and assign a rule identifier with a preset prefix to each dynamic rule; When a workflow node is obtained, the handler field is retrieved from the configuration of the workflow node, and it is identified whether the handler field starts with the preset prefix. If it is determined that the processor field begins with the preset prefix, then the rule identifier is extracted from the processor field, and the visual rule configuration component is called to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The visualization rule configuration component is invoked to execute the target dynamic rule, and the list of user identifiers obtained after execution is used as the task handlers of the workflow nodes, and tasks are assigned.

2. The method according to claim 1, characterized in that, The step of configuring at least one dynamic rule in the visual rule configuration component, and assigning a rule identifier with a preset prefix to each dynamic rule, includes: A preset visualization rule configuration component is determined, and multiple rule types are predefined in the visualization rule configuration component. The rule types include role-based processor mapping rules, hierarchical relationship query rules, and multi-dimensional condition combination rules. Receive rule configuration parameters, and determine multiple dynamic rules to be configured from the various rule types according to the rule configuration parameters; According to the rule configuration parameters, the visual rule configuration component configures input parameters, execution logic, and return result structure for each of the multiple dynamic rules, and assigns a rule identifier to each dynamic rule with the preset prefix as the starting point, wherein the preset prefix is ​​an identifier in string form.

3. The method according to claim 2, characterized in that, The method further includes: During the system startup phase, a client instance of the visual rule configuration component is initialized, and a network connection is established with an external rule configuration center through the client instance. The rule configuration center is used to centrally store and manage the definition content of the at least one dynamic rule. After the client instance is initialized, it subscribes to the rule configuration center for change events of the configured dynamic rules. When a dynamic rule starting with the preset prefix needs to be executed, the workflow engine sends a rule execution request carrying the corresponding rule identifier to the rule configuration center through the client instance. The rule configuration center then finds the corresponding dynamic rule based on the rule identifier, executes it, and returns the execution result.

4. The method according to claim 2, characterized in that, The method further includes: In response to a rule addition command, the system obtains the new configuration parameters for the dynamic rule to be added. These parameters include the target rule type, input parameter list, execution logic script, return result structure, and custom rule identifier. The custom rule identifier begins with the preset prefix and is not duplicated with any existing rule identifier in the visual rule configuration component. Based on the target rule type, the system determines the corresponding rule template in the visual rule configuration component. The system then writes the input parameter list, execution logic script, and return result structure into the rule template according to the format requirements of the target rule type and binds the custom rule identifier to the identifier field of the rule template. In response to a rule deletion command, the system obtains the specified rule identifier of the dynamic rule to be deleted, traverses all configured dynamic rules in the visual rule configuration component, queries for rule entries that match the specified rule identifier, and removes the specified rule entry from the rule storage structure of the visual rule configuration component and releases the configuration resources occupied by the specified rule entry if a matching specified rule entry is found. If no specified rule entry is found, the system returns a deletion failure indication message.

5. The method according to claim 1, characterized in that, Before obtaining the handler field from the configuration of the workflow node when a workflow node is obtained, and identifying whether the handler field begins with the preset prefix, the method further includes: In response to a workflow node creation request, obtain multiple handler roles, hierarchical relationship rules, and multi-dimensional condition combination rules indicated by the workflow node creation request; Based on the multiple processing roles, multiple role nodes are constructed, and the multiple role nodes are organized according to the hierarchical architecture between roles indicated by the hierarchical relationship rules and the multi-dimensional condition combination rules to generate a workflow diagram. Among the multiple role nodes, the role node to be assigned a task is determined as multiple user task nodes, and in the workflow diagram, the rule identifier is filled in the handler attribute field of each user task node among the multiple user task nodes. The workflow diagram filled with the rule identifier is exported as a workflow definition file, and the workflow definition file is deployed to the workflow engine so that the workflow engine can be called to parse the workflow definition file, obtain the workflow nodes, and identify the processor field.

6. The method according to claim 5, characterized in that, The method further includes: Add a node handler class to the code project. The node handler class implements a predetermined processor interface or is marked by a predetermined annotation. The node handler class encapsulates the coordination logic of the handler acquisition strategy. When the workflow engine starts as an independent service, it is invoked to discover and instantiate the node handler class through classpath scanning or dependency injection container, and load the instantiated node handler class into the processor registry in memory, so that the node handler instance can be obtained from the processor registry by invoking the workflow engine, thereby realizing the identification of the handler field.

7. The method according to claim 1, characterized in that, When a workflow node is obtained, after retrieving the handler field from the workflow node's configuration and identifying whether the handler field begins with the preset prefix, the method further includes: If it is determined that the processor field does not start with the preset prefix, the runtime variable context of the workflow node's process instance is obtained. The runtime variable context contains multiple sets of key-value pairs, where the key in each set of key-value pairs is the variable name and the value is the corresponding variable content. The original string of the "processor" field is used as the key name to be matched, and a query is performed in the runtime variable context to see if there is a variable name that matches the key name to be matched. When the query determines that there is a variable name that matches the key name to be matched, the variable value corresponding to the variable name is extracted from the runtime variable context, and the variable value is used as the task handler. The data type of the variable value is a single user identifier, a list of user identifiers, or an expression string that can be parsed into a set of user identifiers. When the query determines that there is no variable name that matches the key name to be matched, the original string of the handler field is used to generate fixed handler information, and the handler indicated by the fixed handler information is used as the task handler. The fixed handler information includes username, job code, department identifier, or a multi-user identifier string connected by delimiters.

8. A task allocation device based on rule-based dynamic configuration, characterized in that, include: A configuration module is used to configure at least one dynamic rule in a visual rule configuration component, and to assign a rule identifier with a preset prefix to each dynamic rule; The identification module is used to obtain the handler field from the configuration of the workflow node when a workflow node is obtained, and to identify whether the handler field starts with the preset prefix. The extraction module is used to extract a rule identifier from the processor field if it is determined that the processor field starts with the preset prefix, and to call the visual rule configuration component to determine the target dynamic rule indicated by the rule identifier in the at least one dynamic rule; The allocation module is used to call the visual rule configuration component to execute the target dynamic rule, use the list of user identifiers obtained after execution as the task handlers of the workflow nodes, and perform task allocation.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images