Business process processing method and device based on multi-level tasks, equipment and medium

Abstract

The invention relates to the technical field of data processing, can be applied to business scenes of financial science and technology, medical treatment and health and the like, and discloses a business process processing method, device, equipment and medium based on multistage tasks. Creating a main task record and a detail task record and establishing an association relationship, updating the state of the detail task record, periodically scanning the main task record and judging whether the detail task record is completed or not, detecting a process triggering request and executing a preset business process or updating the state of the main task record according to a detection result. Whether the preposed verification task is needed or not is judged in a unified mode before the business object is generated, the state of each preposed task is tracked by means of the incidence relation between the main task record and the detailed task record, and the precondition of process execution is ensured to be accurately met in combination with a periodic scanning and process triggering detection mechanism; the accuracy of business process execution is improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a business process processing method, device, equipment and storage medium based on multi-level tasks. Background Art

[0002] In the field of information processing, particularly in business process management based on task state control and process triggering, existing technologies commonly suffer from complex task execution chains, uncertain process triggering timing, and confusing task state verification logic. As business processes continue to expand and refine, independent logical judgments for each type of pre-task within the system continue to accumulate, leading to code redundancy and reduced process maintainability. Furthermore, in multi-tasking concurrent scenarios, process node execution order can be disrupted, leading to data consistency risks or business process interruptions.

[0003] In the field of fintech business, especially in scenarios such as insurance underwriting and loan approval, there is often a need to rely on the completion of multiple pre-review tasks before triggering the subsequent contract generation, fund disbursement, or policy effectiveness process. For example, in the insurance underwriting process, it is usually necessary to complete multiple independent but critical verification tasks such as manual underwriting, facial recognition and double recording, and payment confirmation before formal underwriting. In the existing technology, a large amount of conditional judgment code is often embedded in the business process to verify the completion status of each task in turn. Since the completion time of these pre-tasks is uncertain and the callback sequence may be disordered, it is easy to cause confusion in process judgment, repeated state switching, or process erroneous triggering, thereby increasing the risk of underwriting process interruption, wrong signature or missed signature, seriously affecting system stability and business processing efficiency.

[0004] In the healthcare business field, especially in applications such as medical expense review, insurance claim pre-processing, and pre-admission assessment, similar pre-task process management needs also exist. For example, in the medical expense review scenario, it is often necessary to complete a series of independent pre-verification steps such as patient information verification, treatment project confirmation, and medical insurance eligibility review before the final expense approval. Existing systems usually manage these steps through scattered status judgment logic distributed in various business modules. However, due to the lack of unified task status tracking and centralized process triggering mechanisms, there is a large delay between task completion confirmation and approval process triggering, and even task status judgment errors, affecting expense review efficiency and compliance requirements. Summary of the Invention

[0005] The main purpose of the present invention is to provide a business process processing method, device, equipment and storage medium based on multi-level tasks, aiming to solve the technical problems in the existing technology that there is a lack of a unified mechanism for managing the pre-verification task status and process triggering conditions, resulting in confusion in task completion judgment, failure of process triggering and poor maintainability of business processes.

[0006] To achieve the above objectives, the present invention provides a business process processing method based on multi-level tasks, comprising:

[0007] Receive business initiation request;

[0008] Before generating a business object record, determining whether a pre-verification task record needs to be created based on the business initiation request;

[0009] If a pre-verification task record needs to be created, a main task record is created for the business object and set to an unfinished state;

[0010] Generate multiple detailed task records and set them to be executed, and establish the association between the main task record and the detailed task record;

[0011] Receive a task record completion event, and update the status of the detailed task record corresponding to the task record completion event to a completed status;

[0012] Periodically scan unfinished main task records to determine whether all detail task records associated with the unfinished main task records have been completed;

[0013] When all the detailed task records associated with the unfinished main task record are completed, check whether there is a process trigger request call record;

[0014] If there is a process trigger request call record, the preset business process is executed and the status of the main task record is updated;

[0015] If there is no process trigger request call record, the status of the main task record is updated to completed.

[0016] Furthermore, to achieve the above-mentioned purpose, the present invention provides a business process processing device based on multi-level tasks, comprising:

[0017] Request receiving module, used to receive service initiation requests;

[0018] A task determination module is used to determine whether it is necessary to create a pre-verification task record based on the business initiation request before generating a business object record;

[0019] The main task generation module is used to create a main task record for the business object and set it to an unfinished state if a pre-verification task record needs to be created;

[0020] The detailed task generation module is used to generate multiple detailed task records and set them to a pending state, and establish an association relationship between the main task record and the detailed task record;

[0021] A task completion processing module is used to receive a task record completion event and update the status of the detailed task record corresponding to the task record completion event to a completed status;

[0022] The status scanning module is used to periodically scan the unfinished main task records and determine whether all the detailed task records associated with the unfinished main task records have been completed;

[0023] The process trigger detection module is used to detect whether there is a process trigger request call record when all the detailed task records associated with the unfinished main task record are completed;

[0024] The process execution module is used to execute the preset business process and update the status of the main task record if there is a process trigger request call record;

[0025] The status update module is used to update the status of the main task record to completed if there is no process trigger request call record.

[0026] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a multi-level task-based business process processing program stored in the memory and capable of running on the processor. When the multi-level task-based business process processing program is executed by the processor, the steps of the multi-level task-based business process processing method as described above are implemented.

[0027] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a business process processing program based on a multi-level task is stored. When the business process processing program based on a multi-level task is executed by a processor, the steps of the business process processing method based on a multi-level task as described above are implemented.

[0028] Beneficial effects: The present invention relates to the field of data processing technology and can be applied to business scenarios such as financial technology and medical health. A business process processing method, device, equipment and medium based on multi-level tasks are disclosed, including: receiving a business initiation request, judging whether it is necessary to create a pre-verification task record based on the business initiation request before generating a business object record, if it is necessary to create a pre-verification task record, creating a main task record for the business object and setting it to an unfinished state, generating multiple detailed task records and setting them to a pending state and establishing an association relationship between the main task record and the detailed task record, receiving a task record completion event and updating the status of the detailed task record corresponding to the task record completion event to a completed state, periodically scanning the unfinished main task records and judging whether the detailed task records associated with the unfinished main task records are all completed, detecting whether there is a process trigger request call record when all the detailed task records associated with the unfinished main task records are completed, executing the preset business process and updating the status of the main task record if there is a process trigger request call record, and updating the status of the main task record to completed if there is no process trigger request call record. The present invention uniformly determines whether a pre-verification task is required before the business object is generated, uses the association between the main task record and the detailed task record to track the status of each pre-task, and combines periodic scanning with a process trigger detection mechanism to ensure that the prerequisites for process execution are accurately met, thereby avoiding the problems of process triggering errors or process confusion caused by the dispersion of task status judgment in the existing technology, and achieving improved accuracy in business process execution and reduced complexity in system maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0030] Figure 1 A schematic diagram of an application environment of a business process processing method based on multi-level tasks in one embodiment of the present invention;

[0031] Figure 2 This is a flowchart of an embodiment of a method for processing a business process based on multi-level tasks according to the present invention;

[0032] Figure 3 This is a functional module diagram of a preferred embodiment of a business process processing device based on multi-level tasks of the present invention;

[0033] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0034] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0035] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0036] The multi-level task-based business process processing method provided by the embodiment of the present invention can be applied in Figure 1 In an application environment, a user terminal communicates with a server terminal through a network. The server terminal can receive a business initiation request through the user terminal, and determine whether it is necessary to create a pre-verification task record based on the business initiation request before generating a business object record. If it is necessary to create a pre-verification task record, a main task record is created for the business object and set to an unfinished state, multiple detailed task records are generated and set to a pending state, and an association relationship between the main task record and the detailed task record is established. The server terminal receives a task record completion event and updates the status of the detailed task record corresponding to the task record completion event to a completed state. The server terminal periodically scans the unfinished main task records and determines whether the detailed task records associated with the unfinished main task records are all completed. When the detailed task records associated with the unfinished main task records are all completed, the server terminal detects whether there is a process trigger request call record. If there is a process trigger request call record, the server terminal executes the preset business process and updates the status of the main task record. If there is no process trigger request call record, the server terminal updates the status of the main task record to completed. The present invention uniformly determines whether a pre-verification task is required before a business object is generated, tracks the status of each pre-task by utilizing the association between the main task record and the detailed task record, and combines periodic scanning with a process trigger detection mechanism to ensure that the prerequisites for process execution are accurately met, thereby avoiding the problems of process triggering errors or process confusion caused by decentralized task status judgment in the prior art, thereby achieving improved accuracy in business process execution and reduced complexity in system maintenance. Among them, the user end can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. The server end can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0037] See also Figure 2 , Figure 2 This is a flowchart of an embodiment of a multi-level task-based business process processing method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0038] like Figure 2 As shown, the business process processing method based on multi-level tasks proposed by the present invention includes the following steps:

[0039] S10, receiving a service initiation request;

[0040] In this embodiment, receiving a service initiation request refers to the act of receiving information triggered by an external business system or user operation through a predefined request receiving interface during the operation of the business system. A service initiation request typically includes basic information such as the service number, service type, initiation time, operator identifier, and request context parameters. All received request data must be initially parsed and standardized according to a specific format to ensure that subsequent processes can be judged and processed based on a unified data structure. A service initiation request can originate from an external system API call, be triggered by an internal system event, or be submitted through a user interface for a service application. These scenarios include, but are not limited to, insurance applications, medical approval initiations, financial credit applications, and health record entry. The service initiation request reception process must support both asynchronous and synchronous reception modes. Asynchronous reception typically uses a message-based middleware to deliver service initiation events, ensuring high system availability and decoupling. Synchronous reception directly receives real-time requests via remote call protocols such as HTTP and gRPC. Upon receiving a service initiation request, the system must immediately perform parameter validation, including field integrity, parameter validity, and request idempotence, to prevent process errors caused by data anomalies. In practice, a request monitoring module can continuously monitor a designated port or message queue and automatically trigger parsing and verification operations upon detecting business request data that conforms to a predefined protocol format. This module must possess high concurrency processing capabilities to handle the surge in requests during peak business periods. It must also include exception capture and fault-tolerant mechanisms to ensure that business request data can be properly processed even in the presence of network jitter or format anomalies.

[0041] Receiving business initiation requests can be achieved by configuring a RESTful protocol-based receiving interface. During system deployment, a business request receiving endpoint should be set up at the unified access layer and strict request data specifications should be established. For example, each request should include a unique business serial number, business type identifier, initiation timestamp, and extended attribute fields. When a business initiation request arrives through the interface, the access layer first performs field validation and data parsing on the request body, storing structured request data that complies with the specifications in a request buffer. The request dispatch module then distributes the request to the business processing engine for further processing. To support high-concurrency environments, the receiving port can be bound to a high-availability load balancer and forwarded through distributed message queue middleware such as Kafka or RabbitMQ. This approach utilizes asynchronous pull and batch processing to improve request reception capabilities. Furthermore, to ensure the security of request reception, a unified authentication mechanism within the API gateway can be implemented during the reception phase to authenticate and verify each request, preventing unauthorized requests from being injected into the system. Depending on the application scenario, business initiation requests can also be prioritized. Upon receiving a request, the order in which requests are dispatched to the business processing engine is dynamically adjusted based on the priority rules, improving the responsiveness of critical business processes.

[0042] Example: In the healthcare field, receiving business initiation requests can be applied to the patient hospitalization approval process. When a new hospitalization application is submitted to the hospital information system, the system receives the hospitalization application initiation request in real time, parses key parameters such as patient identity information, condition description, and application time, and ensures that the hospitalization approval business chain can trigger the generation and execution of related review tasks based on complete application data.

[0043] In the financial field, receiving business initiation requests can be applied to credit application scenarios. When a customer submits a loan application form through an online credit platform, the system receives and parses the loan application request through a unified access layer, including the borrower's basic information, application amount, repayment method and other data. The subsequent credit approval process generates pre-verification tasks and conducts credit assessment operations based on this.

[0044] This embodiment can achieve unified management and efficient access to business trigger sources by receiving business initiation requests and performing standardized parsing and structured processing on the request content, ensuring that the subsequent generation of main task records and detailed task records is based on a consistent and reliable data foundation, avoiding process processing confusion caused by heterogeneous, missing or abnormal request data, thereby improving the stability and accuracy of the overall business process.

[0045] S20, before generating the business object record, determining whether it is necessary to create a pre-verification task record based on the business initiation request;

[0046] In this embodiment, before generating a business object record, it is determined whether a pre-verification task record needs to be created based on the business initiation request, which involves performing task dependency determination in advance during the business process initialization phase to ensure smooth progress of subsequent processes.

[0047] Business object records typically refer to data entities in business systems used to persist essential business process information, such as insurance application records in insurance systems, hospitalization application records in medical approval systems, and loan application records in financial credit systems. A business initiation request contains all the preliminary information required to initiate a business action. Based on the business initiation request, it can be inferred whether there are specific tasks that must be completed beforehand.

[0048] A pre-verification task record is a control information unit that indicates specific tasks that must be completed before a business object record is officially generated. Examples include personnel verification, payment, dual-recording, health assessment, and identity verification. The need to create a pre-verification task record is determined by analyzing characteristic parameters in the business initiation request. These parameters may include business type code, customer risk level, product risk attributes, and regional compliance requirements. These parameters collectively determine whether the current business scenario meets the triggering conditions for generating a pre-verification task.

[0049] During actual execution, the system first extracts the entire set of characteristic parameters from the business initiation request, and determines which detailed task types are required verification tasks in this business type scenario by matching the predefined task type mapping rule table. The mapping rule table can be dynamically maintained through the rule engine, supporting configuration-based management operations such as adding, modifying, enabling, and disabling, thereby adapting to task verification requirements at different times, in different regions, and under different policies. When the parsed characteristic parameter set meets the triggering conditions in the mapping rule, the system generates a judgment signal to create a pre-verification task record. Subsequently, based on the judgment result, the main task record and the detailed task record link will be prioritized before the business object record is generated.

[0050] A feature parameter parser component can be added to the request processing module. This parser component is initiated after the business initiation request is received and initially validated, automatically extracting the feature parameter fields contained in the request body. The feature parameter set extracted by the parser is passed as input to the task creation decision engine. The decision engine performs a matching query based on the currently configured task type mapping table, retrieving a set of all pre-verification task types that meet the criteria. If one or more pre-verification task types meet the matching criteria, a task creation decision result is generated, along with a list of pre-verification task types to be created. In implementation, the task type mapping table can adopt a hierarchical dictionary structure, with the first-level index representing the business type code, the second-level index representing the feature parameter combination rules, and the third-level node representing the detailed task type set. This structure efficiently supports rapid retrieval and maintenance under complex conditions. To adapt to the differences in features across different business scenarios, a dynamic decision engine based on rule expressions can be introduced, such as using SpEL expressions or the Drools rule engine, to adjust the feature parameter-to-task type mapping rules in real time without restarting the system. To enhance system flexibility and scalability, the structure of feature parameter collections should support extended attribute mechanisms, such as using lists of key-value pairs or nested objects. This ensures that even future additions of new business parameters can be seamlessly integrated into the judgment process. After the judgment is completed, regardless of whether a pre-verification task record is generated, the judgment result should be returned in a standardized structure for subsequent use, avoiding processing logic ambiguity caused by inconsistent data parsing.

[0051] Example: In the healthcare field, when a medical institution's information system receives a patient's hospitalization application request, the system can determine whether specific medical insurance eligibility verification tasks or hospital infection screening tasks need to be completed before hospitalization is accepted based on characteristic parameters such as the patient's age, disease classification, and medical insurance type in the hospitalization application form. If necessary, the system will automatically create the corresponding pre-verification task and suspend the delivery of the hospitalization document to ensure that all necessary verification actions are completed before formal acceptance.

[0052] In the financial field, when a credit management system receives a customer's loan application request, the system can dynamically determine whether it is necessary to create a large-scale credit review task or a special approval process task before the loan application is accepted based on characteristic parameters such as the customer's credit rating, application amount, and loan product type in the application form, thereby completing early prevention and control of high-risk factors before the loan application form is generated.

[0053] This embodiment can realize dynamic perception and intelligent decision-making of the predecessor task link in the process initialization stage by judging whether it is necessary to create a predecessor verification task record based on the business initiation request before generating the business object record, avoiding the problems of manual hard-coded judgment, logical dispersion, and redundant expansion in traditional systems, ensuring that the dependent tasks before the business object is generated have a complete verification path, fundamentally improving the consistency, controllability and scalability of the process, reducing the risk of abnormal interruption of subsequent processes due to omission of predecessor tasks, and laying a data foundation for asynchronous concurrent processing and dynamic process orchestration.

[0054] S30, if a pre-verification task record needs to be created, a main task record is created for the business object and set to an unfinished state;

[0055] In this embodiment, if a pre-verification task record is required, a master task record is created for the business object and set to an uncompleted state. This means that after confirming that the necessary pre-verification requirements exist in the business initiation request, a separate master task record is generated for this business operation to uniformly manage the status and process control of all subsequent detailed tasks. A business object is typically the core data carrier of an independent business transaction, such as a policy object in insurance, a hospitalization application object in healthcare, or a loan approval object in finance. A master task record is a task control entity generated around a business object. It carries out the lifecycle management of the entire chain of pre-tasks, including initialization, progress tracking, status changes, and exception handling. Creating a master task record means writing a new task master table record to the data persistence system, which includes at least, but not limited to, fields such as the master task unique identifier, the associated business object number, the master task type code, the current processing status, the task creation time, and the task update time. The master task unique identifier can be generated using a globally unique numbering strategy, such as those based on UUIDs, snowflake algorithms, or distributed ID generators, to ensure the uniqueness and traceability of task data. The associated business object number points to the specific business object being processed, ensuring that the main task record is bound to the business process.

[0056] When the main task record is created, its current processing status needs to be initialized to an unfinished state. The unfinished state indicates that the main task has not yet met the release conditions, and there are still detailed tasks to be processed or verification actions that are not completed. Commonly used status field values can be defined as "pending", "init", "in_progress", etc. The unfinished status setting is not only the basis for task lifecycle management, but also the core basis for determining whether to continue to promote the implementation of business objects in subsequent process control. To ensure the consistency and accuracy of status identification, the system should force the writing of the status field when creating the main task record and set the necessary field integrity constraints in the data model to avoid business logic execution exceptions due to the omission of the status field.

[0057] A main task record creator component can be implemented within the task management module. This component is triggered upon receiving a signal indicating the need to create a pre-verification task record. The main task record creator calls a distributed ID generator to generate a new main task unique identifier. It then constructs a main task record object, populating it with the associated business object number, the main task type code, and the current system timestamp as the creation time. The default status is set to "Incomplete." The task type code can be automatically assigned based on the business object's business type. For example, the main task type code generated for a medical hospitalization application might be "HOSPITAL_ADMISSION_PRECHECK," while the main task type code generated for a financial loan application might be "LOAN_CREDIT_AUDIT." At the data writing layer, main task record objects can be persisted to the task master table using an ORM framework (such as Hibernate or MyBatis), or directly executed using standard SQL insert statements. To improve processing efficiency and fault tolerance, an asynchronous write mechanism can be adopted, using message queue middleware such as Kafka or RabbitMQ to distribute write commands and batch processing on the data persistence server. To prevent duplicate task creation, you can query the existing main task record set based on the business object ID before creating a task. New tasks are only allowed when no historical main task records in an unfinished state are found, ensuring the idempotence of task creation.

[0058] Master task records can include auxiliary control parameters such as task priority fields and task processing strategy fields, facilitating differentiated management based on task urgency or processing requirements. Furthermore, master task record objects can be configured with event publishing functionality to automatically publish a master task creation event upon successful record creation, allowing other microservice modules, such as task allocation and process orchestration, to perceive this event in real time and trigger subsequent actions.

[0059] Example: In a healthcare business scenario, when a patient submits an admission application, the system pre-determines that medical insurance eligibility review and infectious disease screening are required. The system immediately generates a master task record. The master task unique identifier is "HOSPITAL_TASK_202408001," the associated business object number is the patient's admission application number, the master task type code is "HOSPITAL_ADMISSION_PRECHECK," and the current status is set to Incomplete. Once this master task record is created, it can be tracked throughout the process through the Task Center of the inpatient management system. Once all pre-check tasks are completed, the master task status is updated to Completed.

[0060] In a fintech business scenario, when a customer initiates a high-value loan application, the system analyzes characteristic parameters and determines that a credit review and large-amount credit approval task is required. The system immediately generates a master task record with the unique ID "LOAN_TASK_202408123," associated with the loan application number, and the master task type code set to "LOAN_CREDIT_AUDIT." The current processing status is initialized to incomplete. The loan business management platform uses this master task record to monitor the completion status of each detailed task in real time, ensuring that the loan approval process is not advanced prematurely until all risk control requirements are met.

[0061] This embodiment creates a main task record for the business object and initializes it to an unfinished state immediately after determining that a pre-verification task record needs to be created. This allows all pre-tasks to be unified and managed in a structured and standardized manner, avoiding the problems of scattered task logic, lack of unified identification, and uncontrollable status in traditional systems. It achieves global visibility of the task chain, unified progress tracking, and rapid location of anomalies, significantly improving the stability and flexibility of the business process and providing a solid data foundation for subsequent detailed task generation, state change monitoring, and process flow decision-making.

[0062] S40, generating multiple detailed task records and setting them to a pending state, and establishing an association relationship between the main task record and the detailed task record;

[0063] In this embodiment, multiple detailed task records are generated and set to a pending state, and an association relationship is established between the main task record and the detailed task record. This means that after the main task record is initialized, the system dynamically generates a set of specific subtasks based on the main task type and its business context. Each subtask is independently stored and managed in the form of a detailed task record, and a one-to-many data association is established with the parent main task. Detailed task records refer to more fine-grained executable task units formed by splitting the main task. For example, in the medical and health field, medical insurance eligibility verification, infectious disease screening, basic vital signs measurement, etc. need to be completed before hospitalization. Each examination can be mapped to an independent detailed task record. In the financial technology business field, credit assessment, anti-fraud detection, repayment ability calculation, etc. are required before loan approval. Each verification action can also generate an independent detailed task.

[0064] During the generation process, the main task type code stored in the main task record must first be parsed. The main task type code is a standardized string that identifies the category of the current main task, such as "INSURANCE_APPLICATION_PRECHECK" and "HOSPITAL_ADMISSION_VERIFICATION." The main task type code can be used as a query condition to access the predefined task type mapping table. The mapping table is a data structure that stores the standard correspondence between main tasks and detailed tasks. Using the main task type as an index, it can retrieve the set of detailed task types that should be derived from the current main task. A detailed task type set is a combination of multiple detailed task type codes, each of which uniquely corresponds to a standardized task classification.

[0065] After obtaining the set of detailed task types, the detailed task parameter sets corresponding to each detailed task type need to be generated based on the business context parameter set recorded in the main task. The business context parameter set is typically extracted from the business object and includes, but is not limited to, the business number, user ID, product information, service request content, etc., and is used to populate personalized initial parameters for each detailed task. For example, in healthcare scenarios, patient age and insurance type will influence screening item selection; in financial scenarios, loan amount and purpose of borrowing will influence credit verification dimensions.

[0066] Based on the set of detailed task types and the corresponding set of detailed task parameters, the system can construct a set of detailed task records. Each detailed task record includes but is not limited to the detailed task unique identifier, the associated main task identifier, the detailed task type code, the detailed task initialization parameters, and the detailed task current status field. The detailed task unique identifier can be guaranteed to be globally unique through an independent ID generation strategy, such as generated through a UUID or distributed ID algorithm. When each detailed task record is created, its status field needs to be initialized to the pending state. The pending state indicates that the detailed task has not yet been completed and still needs to be processed by the system or manually. The status value can be uniformly set to standard values such as "pending" and "waiting".

[0067] To establish a relationship between master task records and detail task records, a master task foreign key identifier must be added to each detail task record. The master task foreign key identifier points to the unique identifier field of the corresponding master task record. Foreign key constraints are typically configured at the database level to ensure that detail task records belong to a specific master task record, forming a clear master-slave structure. In terms of data modeling, it's recommended to set a "master_task_id" field in the detail task table and establish a one-to-many relationship with the "task_id" field in the master task table. This allows for quick retrieval of all associated detail tasks based on the master task during subsequent process control, task progress statistics, and exception handling.

[0068] A detailed task batch generator can be designed in the task generation module. The detailed task batch generator receives the main task record instance and the business context parameter set as input, performs main task type code parsing, accesses the task type mapping table, and retrieves the corresponding detailed task type set. Then, for each detailed task type code, an initial parameter set is dynamically constructed based on the business context parameters, and detailed task objects are instantiated based on a unified task template. When a detailed task object is generated, it should automatically assign a unique identifier for the detailed task, fill in the detailed task type code, business initial parameters, and current status fields as pending, and bind the main task foreign key identifier.

[0069] During the data persistence phase, you can use a batch insert strategy to write a collection of detailed task records to the database all at once, reducing database connection overhead and improving write performance. Batch writes can be accomplished by committing transactions in batches using the ORM framework or using the BULK INSERT command natively supported by high-performance databases. To ensure data consistency during the insert process, you can set uniqueness validation rules for the master task ID and detail task unique ID fields to avoid data conflicts caused by concurrent inserts.

[0070] If business requirements require complex detailed task dependencies, you can add parent-child relationship fields to detailed task records. For example, use the "parent_task_id" field to mark the task dependency order, forming a chain of constraints between detailed tasks. Furthermore, in certain scenarios, you can set different processing priorities, timeouts, and retry policies for different types of detailed tasks, flexibly supporting diverse task execution strategies through extended fields.

[0071] Example: In a healthcare data processing scenario, when a patient submits a surgery appointment, the system retrieves the required detailed task types based on the primary task type code "HOSPITAL_SURGERY_PRECHECK": preoperative blood work, preoperative imaging, and preoperative risk assessment. Based on the patient's baseline information, the system generates personalized parameters for each detailed task, such as a list of test items, imaging sites, and a description of medical history. It then creates three detailed task records, all initialized to a pending state. The unique identifier of the primary task record acts as a foreign key to link the three detailed task records, ensuring that each preoperative preparation step can be individually monitored.

[0072] In a FinTech business scenario, for a mortgage loan application worth 500,000 yuan, the system generates a set of detailed tasks based on the main task type code "LOAN_COLLATERAL_REVIEW," including three tasks: property appraisal, mortgage verification, and lender credit review. Each task generates unique parameters based on the property information, identity information, and credit history provided in the loan application form. These parameters are then persisted independently as detailed task records and all are set to a pending state. The main task record ID acts as a foreign key to link the three detailed task records, ensuring process control and data isolation during the pre-review phase of the loan approval process.

[0073] This embodiment parses the main task type code, queries the predefined task type mapping table, and dynamically generates multiple detailed task records based on business context parameters and initializes them to a pending state. This allows for standardized splitting and personalized configuration of pre-verification tasks, ensuring that each required pre-verification task has independent tracking and independent execution capabilities in the data structure. At the same time, by establishing a one-to-many association between the main task record and the detailed task record, a task management system with a clear structure and a logical closed loop is formed. This structured task splitting and association mechanism significantly improves the controllability and maintainability of pre-verification tasks in complex business processes, and reduces the risk of process blockage and data errors caused by task chain confusion.

[0074] S50, receiving a task record completion event, and updating the status of the detailed task record corresponding to the task record completion event to a completed status;

[0075] In this embodiment, receiving a task record completion event and updating the status of the detailed task record corresponding to the task record completion event to a completed state means that during the execution of the business process, the system receives task completion feedback information in real time, performs a status update operation on the detailed task record that matches the feedback information, and switches it from a pending state to a completed state to ensure the dynamic synchronization of the task link and the continuity of the process. A task record completion event refers to a task completion notification generated by an external system, an internal sub-module, or a manual operation node, and is usually delivered in the form of an event message, an interface callback, a database status change, a message middleware push, etc. Receiving a task record completion event means that the business process management system captures these task completion signals in real time through a pre-registered listening mechanism or an interface service receiving mechanism.

[0076] Task record completion events typically carry key identification information, including the business object number, detailed task type code, task execution result identifier, completion timestamp, and authentication signature. The business object number is used to locate the target master task record, the detailed task type code is used to accurately match the target detailed task record, and the task execution result identifier is used to confirm the legitimacy of the task execution and the status of the result. Parsing task record completion events involves extracting the aforementioned key fields from the received raw message data and performing processing such as format parsing, content verification, and field standardization to provide basic data for subsequent database queries and updates.

[0077] Updating the status field of a detailed task record to completed status involves retrieving the corresponding detailed task record from the database using the parsed business object ID and detailed task type code. Assuming the task execution result meets the legality requirements, the status field value of the detailed task record is changed from pending to completed. Status fields are typically managed using standard enumeration values, with pending status defined as "pending" and completed as "completed." Status changes require not only updating the field value but also recording audit information such as the change time, change source, and version number to ensure traceability of status transitions.

[0078] To ensure data consistency and concurrency control, the target detailed task record must be locked before executing a status update. Row-level locking, pessimistic locking, or optimistic locking strategies must be employed to prevent issues such as dirty writes, duplicate updates, and data loss in high-concurrency environments. After the update is complete, the lock resources must be released and the transaction committed to ensure synchronization between the master task and the detailed task chain in the database. Furthermore, to prevent forged completion events or illegal status updates, the system can verify the signature of the task execution result in the task record completion event, using symmetric or asymmetric encryption mechanisms to verify the legitimacy and integrity of the message source.

[0079] By integrating with messaging middleware, you can achieve real-time reception of task completion events, register and listen on the topic channel corresponding to the main task type code, and use a high-performance consumer group model to concurrently process batches of arriving event messages. The message consumption module can use an automatic confirmation mechanism, immediately marking the message as completed after successful consumption and automatically retrying after failure.

[0080] When parsing task completion events, a unified message parser module supports parsing event messages in various formats, such as JSON, XML, and Protocol Buffers. After parsing, a standardized task completion event object is generated. The parsed business object number and the detailed task type code are used as a joint primary key to perform a database query and locate the corresponding detailed task record. If multiple records are found, further refine the filter based on the task's unique identifier to ensure a unique match.

[0081] Before executing a status update, you can use the database transaction mechanism and the SELECT FOR UPDATE statement to apply a row-level lock to the target detailed task record. Other transactions are prohibited from modifying the record during the lock. When verifying the signature of the task execution result, you can use a standard signature algorithm such as RSA-SHA256 or HMAC-SHA256 based on the task key information stored within the system. Only task completion events that pass the signature verification are allowed to update the status. After the status update is completed, the completion time field of the detailed task record should be assigned to the current system time, the completion version field should be incremented by one, and the audit log should be updated.

[0082] Example: In the healthcare sector, when a patient completes a preoperative blood test, the hospital's laboratory system generates a task completion event containing the patient's business object number, the detailed task type code "PRE_SURGERY_BLOOD_TEST," and the signature of the test completion result. Upon receiving this event, the system parses the business object number, retrieves the corresponding preoperative preparation main task record and its associated detailed task records, identifies the target detailed task, and, upon signature verification, updates the detailed task record's status to Completed and records the completion time, ensuring the preoperative preparation process can proceed.

[0083] In the fintech sector, when a loan applicant completes the anti-fraud review, the anti-fraud system pushes a task completion event, including the loan transaction number, the detailed task type code "FRAUD_CHECK," and the review result signature. Upon receiving the event, the process management system extracts the transaction number to query the corresponding loan approval main task and anti-fraud detailed task, locates the target record, verifies the signature, and updates the detailed task status to completed if approved, allowing the loan approval process to proceed to the next step, such as credit verification or credit limit assessment.

[0084] This embodiment ensures that the processing progress of the pre-verification task is synchronized with the main task link by receiving the task record completion event and parsing the matching detailed task record in real time and updating the status, thereby improving the accuracy and timeliness of the business process. Based on the lock mechanism and signature verification mechanism, it can effectively prevent abnormal problems such as duplicate completion, forged completion, and concurrency conflicts, and ensure the reliability and traceability of task execution results. Overall, it significantly optimizes the real-time and security of pre-task status management in complex processes, providing a solid data foundation for subsequent process flow.

[0085] S60, periodically scanning unfinished main task records to determine whether all detailed task records associated with the unfinished main task records are completed;

[0086] In this embodiment, the periodic scanning of unfinished main task records to determine whether all the detailed task records associated with the unfinished main task records have been completed means that during the execution of the business process, the system automatically triggers the scanning action at preset time intervals through the set timer scheduling mechanism, filters out the main task records in the current database that are in an unfinished state, and analyzes the execution status of the detailed task records attached to each main task record based on the association relationship between these main task records to determine whether all are completed. Periodic scanning is an automated operation method based on time triggering, usually implemented by a timer component, a job scheduler, or an event polling module. For example, a timed task framework set by a Cron expression can be used, or a polling scanning mechanism can be used.

[0087] An unfinished main task record refers to a main task data instance whose current status field has not reached the completed standard value. This status can be uniformly defined by the business process control module. Common status values include unfinished, in progress, and pending verification. Filtering unfinished main task records is usually based on the status field of the main task table in the database. Efficient filtering is performed by constructing WHERE conditions to avoid performance bottlenecks caused by full table scans. Paging scan parameters refer to a set of parameters that limit the amount of data processed each time and the starting position of processing during scanning. Commonly used paging parameters include page number, number of records per page, offset, etc. The introduction of a paging mechanism can effectively control the resource consumption of a single scanning task and prevent the system from being overloaded.

[0088] After obtaining the set of uncompleted master task records, the system traverses each master task record instance and, based on the master task record's unique identifier, queries the associated detail task record set. A detail task record set is a collection of data logically linked through foreign keys or associated fields. This allows for faster retrieval through indexing during queries. Counting the number of uncompleted detail tasks involves performing an aggregate analysis of the status field for each master task record's associated detail task set, calculating the number of detail task records whose status is not completed. The uncompleted count can be achieved using the SQL aggregate function COUNT combined with conditional filtering to ensure accurate results.

[0089] The logic for determining whether all tasks are complete based on statistical results means that when the number of uncompleted tasks reaches zero, all detail tasks associated with the master task record are considered completed and can proceed to the next stage of the process. When the number of uncompleted tasks exceeds zero, it indicates that there are still detail tasks that are unfinished and need to continue waiting without updating the status. This judgment logic directly influences whether the subsequent process execution is triggered or the current pending status is maintained, and plays a decisive role.

[0090] Periodic scanning can be implemented by introducing a scheduled task framework. For example, Quartz Scheduler can be used to schedule scans every minute, every five minutes, or every hour. Once the scheduled task is started, the number of queries per page and the starting page number are configured based on the paging scan parameters. The paging query conditions are then constructed, and the database is filtered to select the set of main task records with an uncompleted status field. Index-optimized SELECT queries are then used to improve retrieval performance.

[0091] When traversing a collection of master task records, you can use multi-threaded parallel processing to improve the processing speed of large amounts of data. For each master task record instance, use the master task identifier field as a foreign key query condition to retrieve all detail task records associated with that master task from the detail task record table. Limit the query to only those whose status field is not "Completed" to reduce the data volume and improve the efficiency of the query.

[0092] When counting uncompleted detail tasks, you can directly use COUNT aggregation calculations on the database side to avoid pulling all detail records to the application layer, reducing network transmission and memory consumption. After each count, the number of uncompleted tasks is determined. If the result is zero, the current main task record is marked as a detail task completion trigger and added to the list of tasks available for subsequent processing. If the result is not zero, the current main task is recorded as unfinished and subsequent processing is skipped.

[0093] Example: In the healthcare business field, when a hospital prepares for a major surgical operation, the preoperative examination tasks involved include blood tests, imaging examinations, electrocardiogram analysis, etc. The hospital information system uses a set timed scanning task to scan the unfinished preoperative preparation main task records every five minutes. By checking the completion status of each preoperative detailed task one by one, if it is found that all examination results have been returned and passed the verification, the preoperative preparation main task will be automatically marked as ready to enter the preoperative review stage.

[0094] In the field of financial technology, when an insurance company conducts pre-insurance approval for a large group insurance contract, it involves multiple pre-tasks such as financial due diligence, policyholder qualification review, and risk rating assessment. The backend system periodically scans the unfinished insurance approval main task records through paging, counts and analyzes the status of each pre-approval detailed task. When it detects that all pre-tasks have been completed and meet the requirements, the system automatically switches the main task status to the issuable status and pushes it to the subsequent underwriting processing process to ensure the smooth progress of the entire approval process.

[0095] This embodiment periodically scans unfinished main task records and determines whether all associated detailed task records are complete. This allows for real-time monitoring and dynamic management of the status of the chain of preceding tasks in complex business processes, ensuring that subsequent business processes are accurately triggered after all preceding tasks are completed, thereby improving the accuracy and timeliness of process management. Based on a paging scanning and incremental judgment mechanism, it can effectively control system resource consumption, adapt to the stable operation requirements of large-scale concurrent business scenarios, and significantly reduce the risk of process blockage, data anomalies, or service anomalies caused by asynchronous task chains.

[0096] S70, when all the detailed task records associated with the unfinished main task record are completed, detecting whether there is a process trigger request call record;

[0097] In this embodiment, when all the detailed task records associated with the unfinished main task record are completed, it is detected whether there is a process trigger request call record, which means that after the system determines that the status of all detailed task records under a specific main task record are completed, it further verifies whether there is a process request triggered for the business object to determine whether it is safe to enter the subsequent business process execution stage. The main task record refers to a record data instance used to manage the status of a group of pre-verification tasks in the business process, and establishes a one-to-one or one-to-many logical association relationship with the business object number through the primary key field. The detailed task record refers to a specific subtask instance allocated within the control range of the main task. Each detailed task record contains its own status, type and main task identification information.

[0098] Process trigger request call records refer to request log data registered in a business process management system or external business system. They identify action requests initiated by a business object to execute a process. To detect the existence of process trigger request call records, use the business object ID as the query condition and search the process call log table or request message table to confirm whether there are any successfully registered process trigger requests that are either unprocessed or in the processing state.

[0099] To ensure the accuracy and real-time nature of detection operations, detection actions should be executed immediately after the detailed confirmation task is completed to avoid misjudgment due to subsequent data changes. When querying process trigger request call records, the search scope should be limited to request records generated within the current business processing session or operation cycle to prevent historical request records from affecting the current processing logic. Typically, the business object number is combined with the timestamp or status field as a combined filtering condition to ensure that only valid process trigger request call records are hit.

[0100] Existence detection usually adopts counting query method, that is, retrieving the number of process trigger requests that meet the conditions. When the number is greater than zero, it is determined that there is a valid process trigger request; when the number is equal to zero, it is determined that there is no process trigger request.

[0101] This embodiment promptly detects the presence of process trigger request invocation records when all detailed task records associated with the main task record are completed. This allows precise control of the timing of subsequent business process initiation, avoiding process interruptions due to missed triggers and system anomalies caused by incorrect process execution without triggers. Combining transaction consistency control with high-performance query optimization strategies improves system processing efficiency while ensuring data accuracy, enhancing the automation and stability of the entire business process and significantly reducing the risk of operational errors caused by manual intervention or system anomalies.

[0102] S80: If there is a process trigger request call record, execute the preset business process and update the status of the main task record;

[0103] In this embodiment, if a process trigger request call record exists, the preset business process is executed and the status of the main task record is updated. This means that after detecting the valid existence of a process trigger request call record associated with the current business object number, the corresponding business processing logic is automatically executed according to the pre-defined process specification, and the status field of the main task record is synchronously updated based on the execution results after the process execution is completed. The process trigger request call record contains the initiator information of the trigger instruction, the business object number, the trigger type, and a set of specific business parameters that may be included. It usually serves as an intermediary carrier for process linkage between cross-modules and cross-systems.

[0104] Executing a pre-set business process involves selecting a corresponding process template from the system's pre-set process template library based on the business scenario identified in the trigger request call record. This process then completes the process call and data interaction with the target business system or module according to the execution node sequence, call interface path, parameter mapping rules, and other information defined in the process template. The execution process includes building a standardized request data packet, submitting it to the target system's designated interface, waiting for the process execution response, and recording the process execution log.

[0105] Updating the status of the main task record means updating the value of the status field in the data table of the main task record according to the status indication in the response result or the business processing feedback information after the process execution is completed and the response result is obtained. For example, it can be updated to the process triggered status, process execution completed status, or process execution exception status, etc., to ensure that the main task record can accurately reflect the latest stage of the business processing and support subsequent status judgment and system decision-making operations.

[0106] After detecting a process trigger request call record, the system first parses the caller system ID, request type, and business object number in the request record. The standardized process template corresponding to the caller system ID and request type is then retrieved from the system's internal process configuration management module. The system then extracts the key business parameter set stored in the master task record and, based on parameter mapping rules, injects these business parameters into the standardized process template, dynamically generating business process request data that complies with the interface specification.

[0107] After generating the request data, the business process request is submitted by calling the process execution interface of the target business system, and a reasonable timeout control and retry mechanism is set to adapt to different network or system environments. When the response of the target business system is received, the response result is parsed. If the response status code indicates success, such as HTTP status code 200 or a custom success code of the business system, the status field of the main task record is updated to the process triggered or process execution successful status; if the response result indicates that the execution failed, such as returning a 4xx, 5xx series error or a business logic failure code, the preset rules can be used to decide whether to re-trigger, record an exception log, or keep the main task record in the pending trigger state.

[0108] In actual deployments, independent transaction boundaries can be configured for process execution actions to ensure that even if process execution fails, the consistency of existing data in the main task record will not be affected. At the same time, asynchronous execution mechanisms can be introduced. For example, using a message queue to enqueue process call requests into an asynchronous processing queue, where they are consumed and processed by a dedicated process execution module. This avoids blocking the main thread and improves overall system throughput.

[0109] This embodiment can achieve cross-module and cross-system process automation connection by automatically executing the preset business process and updating the status of the main task record when the existence of the process trigger request call record is detected, greatly improving the consistency and accuracy of business flow. Dynamically assembling request messages in combination with standardized process templates can adapt to diverse business scenario requirements and enhance the flexibility and scalability of the system. The main task record status is synchronously updated by the success or failure of the process execution, which can accurately reflect the evolution of the task life cycle, reduce business risks caused by manual intervention or status errors, and improve the robustness and maintenance efficiency of the overall system.

[0110] S90: If there is no process trigger request call record, the status of the main task record is updated to completed.

[0111] In this embodiment, if there is no process trigger request call record, the status of the main task record is updated to completed, which means that after the completion check of the associated detailed task records for the currently unfinished main task record is performed, if the system further detects that the process trigger request call record for the main task record does not exist or is invalid, the data status field of the main task record is directly marked as completed, indicating that the business processing link corresponding to the main task record has naturally ended and no longer needs to rely on other process nodes for further processing. The process trigger request call record mainly plays the intermediary role of triggering subsequent business processes across modules or systems. If it is missing, it means that the main task only needs to be closed-loop processed within the current module.

[0112] Updating the status of the main task record to "Completed" requires ensuring the atomicity and consistency of database transactions to avoid inconsistencies or update failures caused by concurrent access or interruptions during the status update process. The status field of the main task record is typically defined as a finite set of states, including values such as "Incomplete," "Process Triggered," "Process Successfully Executed," "Process Execution Exception," and "Completed." The "Completed" state plays a crucial role in signaling the completion of the task's closed-loop.

[0113] After the update action is completed, the status change history can be recorded in the task log module according to business needs to ensure that the life cycle evolution trajectory of each main task record can be fully traced during subsequent system audits, exception troubleshooting or data backtracking.

[0114] You can periodically scan uncompleted master task records and check whether all associated detail task records are complete. You can then proceed with checking process trigger request call records. If no valid associated process trigger request call records are found, the status update process is initiated. First, a row-level lock is applied to the master task record to prevent concurrency conflicts. Then, the status field is updated from incomplete to completed, and the database transaction is committed.

[0115] In practical applications, the task state machine module can centrally manage state update logic. This module automatically derives the next state change path based on the current task state and detected contextual conditions. If the path is determined to be completed, it calls the database update interface to execute the state change. To enhance system robustness, pre-update verification can be introduced, such as re-verifying that detailed task records are indeed fully completed to avoid state misjudgments caused by asynchronous delays in intermediate data.

[0116] To improve operational efficiency and avoid table locking issues, you can batch process eligible main task records and submit status update operations in a single transaction. This can effectively reduce database pressure and improve system throughput, especially in high-concurrency task processing scenarios.

[0117] This embodiment directly updates the main task record status to completed when no process trigger request call record is detected. This effectively avoids the problem of long-term suspension of the main task due to the missing process trigger link, ensures that the task lifecycle in the task management system can be naturally closed, and thus improves the data consistency and business flow efficiency of the entire system. Synchronous recording of status change logs further enhances the traceability and exception troubleshooting capabilities of the task processing process, and enhances the maintainability and transparency of the system.

[0118] The present invention relates to the field of data processing technology and can be applied to business scenarios such as financial technology and medical health. A business process processing method, device, equipment and medium based on multi-level tasks are disclosed, including: receiving a business initiation request, judging whether it is necessary to create a pre-verification task record based on the business initiation request before generating a business object record, if it is necessary to create a pre-verification task record, creating a main task record for the business object and setting it to an unfinished state, generating multiple detailed task records and setting them to a pending state and establishing an association relationship between the main task record and the detailed task record, receiving a task record completion event and updating the state of the detailed task record corresponding to the task record completion event to a completed state, periodically scanning the unfinished main task records and judging whether the detailed task records associated with the unfinished main task records are all completed, detecting whether there is a process trigger request call record when all the detailed task records associated with the unfinished main task records are completed, executing a preset business process and updating the state of the main task record if there is a process trigger request call record, and updating the state of the main task record to completed if there is no process trigger request call record. The present invention uniformly determines whether a pre-verification task is required before the business object is generated, uses the association between the main task record and the detailed task record to track the status of each pre-task, and combines periodic scanning with a process trigger detection mechanism to ensure that the prerequisites for process execution are accurately met, thereby avoiding the problems of process triggering errors or process confusion caused by the dispersion of task status judgment in the existing technology, and achieving improved accuracy in business process execution and reduced complexity in system maintenance.

[0119] In one embodiment, the above step S40 includes:

[0120] S401, parsing the main task type code stored in the main task record;

[0121] S402, querying a predefined task type mapping relationship table to obtain a set of detailed task types associated with the main task type code;

[0122] S403, generating a detailed task parameter set corresponding to each detailed task type according to the business context parameter set of the main task record;

[0123] S404: Creating a detailed task record set based on the detailed task type set and the corresponding detailed task parameter set;

[0124] S405, initializing the status field of each detailed task record in the detailed task record set to a pending state;

[0125] S406: Add a main task foreign key identifier to each detailed task record in the database to establish an association relationship with the main task record.

[0126] In this embodiment, multiple detailed task records are generated and set to a pending state, and an association relationship is established between the main task record and the detailed task record. This first involves parsing the main task type code stored in the main task record. The main task type code, as a core parameter for distinguishing main task categories in different business flow scenarios, is typically encoded using a unified format standard in business systems. For example, a hierarchical encoding method consisting of a business area plus a subtask type, such as INSURANCE_AUDIT or MEDICAL_DISCHARGE verification, is used. The parsing operation extracts the type code data used for subsequent task type matching by reading the corresponding field value in the main task record instance.

[0127] After parsing the main task type code, the predefined task type mapping table is queried to obtain the set of detailed task types associated with the main task type code. The task type mapping table is a preconfigured data structure that stores the correspondence between main task types and their subordinate detailed task types. This query can dynamically determine which specific detailed tasks should be generated for the current main task type. For example, the main insurance application task may correspond to manual underwriting tasks, payment confirmation tasks, and dual-recording tasks. The main medical discharge task may correspond to discharge order verification and medical insurance settlement review tasks.

[0128] Then, based on the business context parameter set of the master task record, a detailed task parameter set corresponding to each detailed task type is generated. The business context parameter set is typically stored when the master task record is created and contains key attributes related to the current business object, such as the policy number, customer ID, product type, and disease diagnosis results. Based on the parameter requirements of different detailed task types, the corresponding detailed task parameter set is extracted or combined from the business context to support the personalized execution logic of the detailed task record.

[0129] Create a set of detailed task records based on a set of detailed task types and their corresponding set of detailed task parameters. This creation process involves traversing the set of detailed task types, dynamically generating a detailed task record instance for each detailed task type, and encapsulating the corresponding detailed task parameter set into the record structure to enable independent configuration and management of different detailed tasks.

[0130] Initialize the status field of each detailed task record in the detailed task record set to the pending state. The pending state, as the starting point of the detailed task lifecycle, indicates that the task has been configured and meets the execution conditions, but actual processing has not yet begun. It is usually defined as one of the system's standard task states, such as pending, executing, completed, or failed, a fixed enumeration value in the state set.

[0131] Add a master task foreign key identifier to each detail task record in the database to establish a relationship with the master task record. The master task foreign key identifier is used to implement integrity constraints between master and subtask records. Typically, this is done by setting the foreign key field in the detail task table to point to the primary key field in the master task table. This ensures that each detail task record can be accurately traced back to its corresponding master task record, allowing subsequent scanning, statistics, status synchronization, and other operations to accurately process the associated relationship.

[0132] This embodiment realizes the data closed loop and status synchronization between main and subtasks by parsing the main task type code, querying the task type mapping relationship table, generating a detailed task parameter set based on context parameters, creating detailed task records and establishing an association relationship with the main task record. It can ensure that during the business flow process, all necessary verification and pre-processing tasks are fully listed, automatically generated and uniformly incorporated into the system scheduling management system, significantly reducing the need for manual intervention, improving the consistency and automation level of business processing, and enhancing the scalability and maintainability of the overall business system.

[0133] In one embodiment, the above step S20 includes:

[0134] S201, parsing the characteristic parameter code in the service initiation request, and extracting the characteristic parameter value set in the service initiation request;

[0135] S202, querying a predefined task type table to obtain a set of candidate task types associated with the feature parameter code;

[0136] S203, determining a necessity weight value of each candidate task type in the candidate task type set according to the feature parameter value set;

[0137] S204: When there is a candidate task type whose necessity weight value exceeds a preset weight threshold, it is determined that a pre-verification task record needs to be created.

[0138] In this embodiment, before generating a business object record, it is determined whether a pre-verification task record needs to be created based on the business initiation request, including first parsing the characteristic parameter code in the business initiation request and extracting the characteristic parameter value set in the business initiation request. The characteristic parameter code is a core identifier used to distinguish the type of business request. A multi-level encoding rule can be used, such as a composite structure consisting of an industry identifier plus a specific business type, such as HEALTH_CLAIM or FINANCE_LOAN_APPLY, to quickly identify the domain to which the business request belongs. The parsing action is usually completed by parsing the standard fields in the request message body, such as reading fixed key-value pairs in the JSON format, or parsing the tag field in the structured message body.

[0139] Extracting the characteristic parameter value set from a service initiation request involves extracting all basic attributes associated with the current service decision logic to form a parameter set to be processed. This parameter set may include, but is not limited to, business details such as customer age, product type, insurance amount, diagnosis code, and application amount. The extraction of parameter value sets is typically performed through matching and filtering in the request field mapping table to prevent irrelevant data from being included in the subsequent decision process.

[0140] Based on the extracted feature parameter code, the predefined task type table is queried to obtain a set of candidate task types associated with the feature parameter code. The predefined task type table is a static or dynamically updated data table pre-configured by the system. It contains all the prerequisite tasks that may be required for a specific business type. The task type set can be divided into required and optional tasks based on business complexity. For example, in the insurance field, the feature parameter code INSURANCE_APPLY may correspond to multiple task types, such as manual underwriting, facial recognition dual recording, and payment verification.

[0141] Based on the extracted feature parameter values, a necessity weight is determined for each candidate task type in the candidate task type set. Necessity weights are metrics that quantify the importance of different tasks based on the current business context. They are typically generated using a combination of a rule engine, decision tree, or weighting model. The importance of each task type varies depending on different business attributes. For example, high-insurance applications require a higher-priority human review task, while low-insurance applications may require a lower-priority human review task.

[0142] When a candidate task type has a necessity weight exceeding a preset weight threshold, a pre-verification task record is generated. This threshold is typically configured by the system and represents the minimum necessity requirement for a task to be triggered. Only when a task's weight exceeds this threshold will it be included in the subsequent generation and tracking system, thus avoiding redundant processes and wasted resources caused by low-importance tasks.

[0143] This embodiment parses the characteristic parameter codes and parameter value sets of the business initiation request, dynamically queries the predefined task type table and calculates the necessity weight value based on the actual business context, so as to accurately determine whether it is necessary to generate a pre-verification task before the business object is created. It can effectively avoid the generation of redundant tasks, improve system resource utilization, enhance the flexibility and accuracy of business flow, and ensure the timely coverage of necessary tasks in high-risk scenarios, thereby enhancing the intelligence and controllability of the overall business process.

[0144] In one embodiment, the above step S50 includes:

[0145] S501, registering and monitoring the topic channel associated with the main task type code in the message middleware;

[0146] S502, parsing the message body content of the task record completion event in the subject channel to obtain the business object number and detailed task type code;

[0147] S503: querying a database according to the business object number to obtain a corresponding main task record instance and an associated detailed task record set;

[0148] S504: Perform a row-level lock acquisition operation on the target detailed task record in the detailed task record set that is in a pending state;

[0149] S505, verifying whether the task execution result signature in the task record completion event is consistent with the security verification key of the main task record instance;

[0150] S506, when the verification is consistent, the status field of the target detailed task record is updated to the completed status and the database transaction is committed;

[0151] S507, when the verification is inconsistent, discarding the task record completion event and generating a security audit log;

[0152] S508: Release the row-level lock resource of the target detailed task record.

[0153] In this embodiment, receiving a task record completion event and updating the status of the detailed task record to a completed state includes first registering a monitoring topic channel associated with the main task type code in the message middleware. The topic channel refers to the message publishing and subscription path divided by the business classification dimension in the message middleware. The main task type code serves as the binding identifier of the topic channel to ensure that different types of business events can flow independently in different message channels. The registration and monitoring process is generally implemented through the subscription API interface. The consumer node registers the monitoring callback function according to the configured topic channel name, thereby asynchronously receiving the target event data.

[0154] Parse the message body of the task completion event in the subject channel to obtain the business object number and detailed task type code. The message body is typically encapsulated in a structured format (such as JSON or Protocol Buffers). Parsing involves extracting fields from the message content and restoring the data structure. The business object number corresponds to the external association identifier of the main task record and is used to locate the specific main task instance in the database. The detailed task type code is used to match specific detailed task records to ensure accurate event attribution.

[0155] Query the database based on the business object ID to retrieve the corresponding master task record instance and its associated detail task record set. Database queries typically utilize transactional consistency control, retrieving the primary key ID in the master task table based on the business object ID and simultaneously retrieving the detail task record set through foreign key associations. The detail task record set is typically filtered by the master task ID and further matched by the task type code to ensure accurate location of the target task record.

[0156] Acquire a row-level lock on the target detail task record in the detail task record set that is in the pending state. Row-level locking is a fine-grained concurrency control mechanism that prevents other transactions from updating or reading the record while the task status is changing, ensuring data consistency. Row-level locking can be achieved through explicit locking statements such as SELECT...FOR UPDATE or implicitly through the database's optimistic locking policy.

[0157] Verify that the signature of the task execution result in the task record completion event is consistent with the security verification key of the primary task record instance. The task execution result signature is a cryptographic proof of the validity of the task completion, typically generated using symmetric or asymmetric encryption. The security verification key is stored in the primary task record and serves as the basis for verification. The verification operation compares the decrypted signature value with the expected verification value to ensure the authenticity of the completion event and prevent forged data from interfering with the task flow.

[0158] When verification is consistent, the status field of the target detailed task record is updated to Completed and the database transaction is committed. Update operations are typically performed within a transaction context that holds a row-level lock. Modifying the status field of the detailed task record and immediately committing the transaction ensures the atomicity and immediate effectiveness of the status change.

[0159] If the verification is inconsistent, the task is discarded, the completion event is recorded, and a security audit log is generated. Discarding means that the current event is not included in the main process and continued execution. A security audit log is generated to record the exception, including information such as the exception source, timestamp, and the involved business number, to facilitate subsequent analysis and accountability.

[0160] Release the row-level lock resources of the target detail task record. The release operation is automatically triggered after the transaction is committed or rolled back, or explicitly released in the program to ensure that database connection resources are recovered and prevent resource leakage and deadlock risks.

[0161] This embodiment effectively implements the security and reliability control of task status updates by registering and monitoring the subject channel corresponding to the main task type code, accurately parsing the content of the task completion event, applying row-level locks to ensure data consistency, verifying the legitimacy of the task execution result signature, and conditionally updating the detailed task status or recording the abnormal audit log based on the verification result. It can prevent data tampering and illegal state jumps, and at the same time ensure the transaction integrity and resource management stability of the system in a high-concurrency processing environment, significantly improving the robustness and maintainability of business processes.

[0162] In one embodiment, the above step S60 includes:

[0163] S601, initializing paging scanning parameters;

[0164] S602, obtaining a set of unfinished main task records from a database by page based on the page scanning parameters;

[0165] S603, traversing each main task record entry in the uncompleted main task record set;

[0166] S604: Query the associated detailed task record set according to the unique identifier of the main task record entry;

[0167] S605, counting the number of detailed task records in the detailed task record set that are in an unfinished state;

[0168] S606: When the unfinished quantity is zero, it is determined that all the associated detailed task records are completed.

[0169] In this embodiment, the unfinished main task records are periodically scanned and it is determined whether all the associated detailed task records are completed. The paging scanning parameters are first initialized. The paging scanning parameters are used to control the starting position of the database query and the amount of data for a single query, including the paging size parameter and the starting index parameter. The setting of the paging scanning parameters can be dynamically adjusted according to the business volume, system load and database responsiveness. The paging control is used to achieve batch-by-batch pulling of the unfinished main task record set, avoiding memory overflow or database pressure surge caused by querying a large amount of data at one time.

[0170] Based on the paging scan parameters, a collection of uncompleted main task records is retrieved from the database in pages. Uncompleted main task records are those whose current status field is not marked as completed or whose process is not triggered. This is achieved through database conditional filtering. Paging retrieval typically combines query conditions, sorting rules, and offset control to achieve page-by-page retrieval, ensuring query stability and system responsiveness in large data environments.

[0171] Traverse each main task record entry in the uncompleted main task record set and process them one by one. This step uses a loop control structure to analyze each main task record one by one, ensuring that even in paginated query scenarios, each uncompleted main task record can be processed step by step. A main task record entry refers to a single record in the paginated query results and contains key information such as the main task type code, the main task unique identifier, and the current status field.

[0172] Query the associated detail task records based on the unique identifier of a master task record. The unique identifier is typically the primary key field of the master task record in the database. This field is used as a foreign key query condition to retrieve all associated detail task records. The detail task record set is dynamically retrieved using established primary and foreign key relationships to ensure data consistency and accuracy.

[0173] Counts the number of uncompleted detail task records in the detail task record set. Uncompleted detail task records are those that haven't yet been marked as completed. The statistics operation filters the detail task record set and calculates the number of values, reflecting the overall progress of the main task. The statistics method can be based on in-memory set operations or database grouping and aggregation functions to improve processing efficiency.

[0174] When the uncompleted quantity reaches zero, all associated detail task records are considered complete. This determination is a logical decision based on statistical results. A zero uncompleted quantity indicates that all detail task records under the master task have been completed, and no more details remain to be executed. This provides a basis for subsequent triggering of process execution or status updates. This determination is completed instantly during the traversal process, ensuring the real-time and accurate processing results.

[0175] You can configure a scheduled task in the backend scheduling module to trigger periodic scans at fixed intervals. When initializing paging scan parameters, the paging size is dynamically set based on system load, typically between 100 and 1000 records, with the starting index incremented each time. You can use paging query statements optimized for database indexes, restricting the selection of uncompleted master task records by conditional fields, and sorting by primary key or creation time to maintain a deterministic processing order.

[0176] After paging through the collection of uncompleted main task records, you can traverse each main task record entry one by one. For each main task record, you can query the corresponding detailed task record set based on its primary key ID, filter out detailed task records with an uncompleted status, and count the number. You can add conditional filtering during the query, such as directly counting the number of uncompleted tasks in the SQL query to reduce memory computing load. When the count result is zero, you can record the main task record in memory as a candidate for the fully completed status, for subsequent batch status updates or process trigger judgment.

[0177] Data from different paging batches can be processed through an asynchronous thread pool or concurrent batch processing framework to improve overall scanning and judgment efficiency. Timeout mechanisms and exception fallback strategies can also be configured to prevent a single scan from blocking the overall task flow. Scan progress can be recorded promptly after processing a batch of paging data, ensuring that in the event of a system failure or interruption, the scan can be resumed from the last scan position without having to rescan the processed portion.

[0178] This embodiment can effectively control database access load and memory usage by initializing paging scan parameters and obtaining a set of unfinished main task records by paging, thus avoiding system performance degradation caused by large-scale queries. By traversing each main task record entry and querying the associated detailed task record set based on the unique identifier, refined monitoring of the main task execution status is achieved. By counting the number of unfinished tasks in the detailed task record set and instantly determining whether all are completed, the system can grasp the completion status of business process nodes in real time, thereby supporting subsequent process triggering or status update decisions.

[0179] In one embodiment, the above step S80 includes:

[0180] S801: If a process trigger request call record exists, query the caller system identifier of the process trigger request call record, and query the database to obtain the corresponding main task record instance based on the business object number in the process trigger request call record;

[0181] S802, matching a standardized request message template of a preset business process according to the caller system identifier;

[0182] S803, extracting a set of key business parameters of the main task record instance;

[0183] S804, injecting the key business parameter set into the standardized request message template to generate a target business process request message;

[0184] S805, calling the process execution interface of the target business system corresponding to the calling system identifier, and submitting the target business process request message to the target business system;

[0185] S806, receiving the business process execution result returned by the target business system;

[0186] S807, when the business process execution result includes a success status code, updating the status of the main task record instance to a process triggered status;

[0187] S808: When the business process execution result includes a failure status code, a process trigger exception log is generated and the status of the main task record instance is kept unchanged.

[0188] In this embodiment, after detecting the existence of a process trigger request call record, it is first necessary to query the caller system identifier contained in the process trigger request call record, and query the database to obtain the corresponding main task record instance based on the business object number in the process trigger request call record. The caller system identifier is the identification information used to identify the external or internal business system that initiated this process trigger request. For example, in the medical and health business, it may be an inspection management system, and in the financial technology business, it may be a loan approval system. The business object number is used to uniquely locate a specific business object, such as a policy number, order number, or patient number. The main task record instance associated with it can be accurately obtained through database query, including the task type, current status, and associated system information.

[0189] Standardized request message templates are matched to preset business processes based on the caller's system identifier. Standardized request message templates are predefined interface call formats for different target business systems, including interface addresses, request field structures, parameter mapping rules, etc. By matching the templates, the generated process request message can be ensured to meet the receiving specifications of the target business system, avoiding call failures due to format inconsistencies.

[0190] Extract a set of key business parameters from the main task record instance. These key business parameters include, but are not limited to, basic attributes of the business object, summary of task processing results, and associated entity identifiers. This extraction operation is typically performed based on database field mapping rules, organizing the structured information in the main task record instance into a set of parameters to be injected into the message template.

[0191] Inject a set of key business parameters into a standardized request message template to generate a target business process request message. This injection process requires filling in key parameters one by one according to the field names and positions defined in the template. Field format conversions, such as timestamp format, amount precision adjustment, and identifier encoding conversion, must be performed as required by the target system. The generated target business process request message must comply with the target system's data reception specifications to ensure successful invocation of subsequent process execution interfaces.

[0192] Call the process execution interface of the target business system corresponding to the calling system identifier and submit the target business process request message to the target business system. The process execution interface is the standard operation entry point provided by the target business system to the outside world. The submission message is usually completed through various communication methods such as HTTP POST, gRPC, and message queue push. The submission process must include authentication information such as signature parameters, token authentication, or two-way TLS encryption to ensure the security and integrity of the data transmission process.

[0193] Receive the business process execution results returned by the target business system. These results typically include a status code, processing description, exception notifications, or follow-up action suggestions. The status code is the core basis for determining whether the process execution is successful. For example, 200 indicates success, while 400 or 500 indicate an exception. When receiving the response, format parsing and field extraction are required to ensure that the information returned by the target system is correctly understood.

[0194] When the business process execution result contains a success status code, the status of the main task record instance is updated to the process triggered status, indicating that the main task has been successfully pushed to the next processing link and will not be triggered again in the future. When the business process execution result contains a failure status code, a process trigger exception log is generated and the status of the main task record instance remains unchanged. The exception log must record in detail the input parameters of the trigger request, the caller identifier, the exception information returned by the interface, etc., for subsequent manual verification or automatic retry mechanism use. At the same time, keeping the main task record status unchanged can prevent the system from incorrectly advancing subsequent processes.

[0195] This embodiment achieves flexible adaptation to different target business systems by matching a standardized request message template based on the caller's system identifier and automatically injecting key business parameters into the main task record instance, ensuring that the process execution interface call complies with the protocol requirements of each system. By automatically identifying and processing the success and failure status of business process execution results, the system can promptly advance the main task status update when successful, and accurately record the exception without advancing the status when failed, thus avoiding the risk of abnormal process advancement due to interface anomalies.

[0196] In one embodiment, after the above step S70, the method further includes:

[0197] S8001, parsing the business object number in the process trigger request;

[0198] S8002, query the database according to the business object number to obtain the corresponding main task record;

[0199] S8003, checking whether the status field of the main task record meets the preset process triggering condition;

[0200] S8004, when the status field is in the completed state, a process blocking alarm log is generated and the current process trigger request is terminated;

[0201] S8005, when the status field is in an unfinished state, a process release instruction is generated and the preset business process is allowed to be executed;

[0202] S8006: Write the process blocking alarm log or process release instruction into the process operation record table.

[0203] In this embodiment, once all detail task records associated with an unfinished main task record have been completed and a process trigger request call record has been detected, the business object number in the process trigger request must first be parsed. The business object number uniquely identifies business data within the system. In the financial sector, this could be a loan number, or in the healthcare sector, a hospital admission application number. This number must be extracted when parsing the process trigger request to ensure uniqueness and accuracy in subsequent database searches.

[0204] Query the database based on the parsed business object ID to retrieve the corresponding primary task record. Database queries are typically based on a one-to-one relationship between the business object ID and the primary task record. The query results should include key information such as the primary task's status field, task type, creation time, and associated detailed task statistics. This precise search ensures that subsequent process decisions are based on the latest status data.

[0205] Check whether the status field of the main task record meets the preset process trigger conditions. Preset process trigger conditions are status determination criteria set by the system during the business rule definition phase. Typically, status fields include unfinished, completed, and abnormal. The judgment logic requires that subsequent processes be allowed to proceed only when the main task record is in a specific triggerable state, ensuring business correctness and data consistency in the process.

[0206] When the status field of the main task record indicates "Completed," a process blocking alarm log is generated and the current process trigger request is terminated. The process blocking alarm log records detailed information about the abnormal trigger request, including request time, business object ID, main task status, call source identifier, and blocking reason, facilitating subsequent audits and problem tracing. Terminating a process trigger request discontinues any further process advancement operations, thus avoiding duplicate processing, status conflicts, or data anomalies caused by a completed process.

[0207] When the status field of the main task record indicates "Incomplete," a process release instruction is generated, allowing the pre-set business process to execute. This process release instruction is used to internally confirm that the process trigger request is legitimate, allowing the pre-set business operation to proceed, such as submitting a credit grant, completing a hospital admission, or activating an insurance policy. The release instruction should include information such as the business object number, trigger time, and pre-set process identifier to ensure that subsequent processing steps can correctly identify and respond to it.

[0208] Log process blocking alerts or process release instructions into the process operation record table. As a crucial infrastructure for system auditing and tracking, the process operation record table records the results of every process trigger request, whether it's a release or a block, and stores them in a database. Fields in the record table typically include information such as the operation time, operation type, business object number, processing result, operator system ID, and additional notes. This continuous data accumulation can be used for process operation monitoring, anomaly detection, audit compliance checks, and process optimization analysis.

[0209] After receiving a process trigger request call record and confirming the completion of the master task's detailed tasks, the process trigger request can be automatically parsed to extract the business object ID field. Based on the business object ID, the master task database table can be queried using a unique index to obtain the master task record instance and its latest status field value.

[0210] After querying the main task record, you can read the status field and compare it based on the system's predefined trigger condition list. When the comparison result is completed, call the log generation module to assemble the process blocking alarm log content, and interrupt the current process trigger operation through the abnormal process management module, release the occupied resources and return the blocking result.

[0211] When the status field is in an unfinished state, the process management module can be called to generate a process release instruction. The instruction content contains field information such as the business object number, current processing time, target business process number, etc., and then the process release instruction is pushed to the process execution module to continue subsequent operations.

[0212] Through database transaction control, both blocking logs and release instructions can be uniformly and persistently stored in the process operation record table. The table design supports high-concurrency writing and index optimization to ensure the real-time and reliability of write operations.

[0213] A field structure extension mechanism for the operation record table can be set up in the implementation. When more process audit information needs to be recorded later, extended fields such as device information, IP address, interface time, etc. can be dynamically added to improve the precision and usability of audit tracking.

[0214] Example: In the fintech business domain, for loan approval and disbursement, the system first receives a loan disbursement process trigger request from the loan application system. Before generating a disbursement business object record, it parses the feature parameter codes in the process initiation request, such as loan product type, application amount range, and customer credit rating category, and extracts a set of feature parameter values. Based on a predefined task type table, the system matches the required pre-verification task types, such as manual review of large loans, anti-fraud verification, and supplementary credit inquiry. It calculates the necessity weight for each task and determines the need to create a pre-verification task record if a task type's weight exceeds a preset threshold. In cases where a pre-verification task is required, the system creates a master task record for the current loan business object and sets it to an uncompleted state. The master task record is associated with key information such as the loan number, customer ID, and application time. The system then parses the master task type code in the master task record and retrieves the associated detailed task type set by querying the task type mapping table. Based on the loan application's business context parameters, such as the loan amount, collateral method, and customer region, the system dynamically generates a corresponding set of detailed task parameters for each detailed task type. For example, large-value review tasks are associated with approval limit parameters, while credit inquiry tasks are associated with customer identity parameters. The system then creates multiple detailed task records, initializes their status fields to pending, and adds a master-task foreign key identifier to each detailed task record to ensure accurate database storage of master-detail relationships. During loan execution, the system registers a listener on the message middleware topic channel associated with the loan review task type code. Upon receiving a manual review completion event or a credit inquiry completion event, the system parses the message body to extract the loan number and detailed task type code. It then queries the database to locate the corresponding master task record instance and its associated set of detailed task records, locks the target detailed task record, and performs signature verification to verify the authenticity and integrity of the task result. If signature verification passes, the system updates the detailed task record status to completed and commits the database transaction. If verification fails, the invalid event is discarded, a security audit log is generated, and row-level lock resources are released to ensure data consistency and security. The system scans the set of unfinished main task records as a periodic task, retrieving data page by page using a paged scanning method. When traversing each main task record entry, the system queries its associated set of detailed task records based on the unique identifier of the main task record, and counts the number of detailed task records with an unfinished status. When the statistical result is zero, the system determines that all detailed tasks under the main task record have been completed and enters the process trigger detection phase. After detecting that all detailed tasks have been completed, the system checks whether there is a process trigger request call record for the loan number. If a process trigger request call record exists, the system parses the loan number carried in the request and queries the main task record to check whether the status field of the main task record meets the preset process trigger conditions.If the status is Completed, the system generates a process blocking alarm log and aborts the process trigger request. If the status is Incomplete, the system generates a process release instruction, allows subsequent business processes to execute, and records the processing progress in the process operation record table. If the process release instruction is effective, the system matches the caller's system identifier with the standardized request message template of the loan disbursement management system. It extracts key business parameters from the main task record, such as basic loan information, customer fund account information, loan amount, and approval result, and injects them into the message template to generate a loan disbursement request message. Subsequently, the process execution interface of the loan fund management system is called to submit the loan disbursement request and receive the business process execution result. If a success status code is returned, the status of the main task record instance is updated to the process triggered state. If a failure status code is returned, a process trigger exception log is generated and the main task status remains unchanged, ensuring the accuracy and controllability of the loan disbursement process at the execution level.

[0215] In the healthcare sector, for the patient admission management process, the system receives an admission process trigger request initiated by the hospital's outpatient registration system. Before generating an admission business object record, it parses the patient's admission application information to extract characteristic parameter codes, such as the patient's disease classification code, payment method type, and whether the patient is critically ill. It also extracts a set of characteristic parameter values. The system then matches a set of pre-verification task types that require completion based on a predefined task type table, such as insurance information confirmation, admission deposit payment, and pre-admission imaging. Based on the necessity weight, it determines whether a pre-verification task record is necessary. When a pre-verification task is required, the system creates a master task record for the patient's admission application and initializes it to an uncompleted state. The master task record stores basic information such as the patient ID, application time, target department, and insurance type. Based on the master task type code, the system then queries the set of detailed task types and generates the required parameter sets for each detailed task based on the patient's medical history. For example, the deposit payment task is associated with the deposit amount parameter, and the insurance confirmation task is associated with the insurance policy number. The system then creates a batch of detailed task records, sets their initial status to pending, and adds a foreign key relationship with the master task record. Before a patient is admitted, the system registers and listens to a message middleware topic related to admission approval. Upon completion of detailed tasks such as a successful deposit payment, insurance document verification, and successful upload of imaging studies, the system parses the message body to extract the patient ID and detailed task type code. The system then queries the database to lock the corresponding detailed task record and performs signature verification. Upon successful verification, the detailed task record status is updated to Completed. If verification fails, an exception log is generated and the message is ignored, leaving the task status unchanged. The system periodically scans all uncompleted main task records, checking the completion status of each detailed task under each main task. If all detailed tasks are completed, the system further checks for an admission process trigger request. If so, it parses the patient ID in the request, queries the main task record, and verifies its status. If the patient has canceled their admission or has already been admitted (completed), a process block warning log is generated, terminating subsequent operations. If the patient's status is uncompleted and there are no pending detailed tasks, a process release instruction is generated, pushing the patient information to the inpatient system to continue with the admission registration process, and logging the release operation log. If the process is released, the system matches the caller's system ID with the standardized interface template of the inpatient registration system. It extracts basic patient information, admission application parameters, department assignment results, and other information, populates the information into a standardized admission registration message, and calls the inpatient system interface. If the inpatient system returns a successful registration result, the main task record is updated to indicate that the process has been triggered. If the registration fails, an exception log is generated and the current status is maintained for subsequent processing.

[0216] This embodiment can accurately verify whether the current main task meets the triggering conditions before the process is executed by parsing the business object number and querying the main task record status field before the process is triggered, effectively avoiding the problem of repeated process execution due to the completion of the main task. By generating a process blocking alarm log and terminating the process when the status is completed, the rigor of data processing and the consistency of the system are guaranteed. By generating a process release instruction and allowing the continuation of the business process when the status is incomplete, the timeliness and correctness of the process advancement are ensured. By uniformly writing the blocking or release operations into the process operation record table, the traceability and audit compliance of the entire process trigger processing chain are achieved, which significantly improves the stability, maintainability and process control accuracy of the system.

[0217] In one embodiment, a business process processing device based on multi-level tasks is provided, and the business process processing device based on multi-level tasks corresponds one-to-one to the business process processing method based on multi-level tasks in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of a multi-level task-based business process processing device according to the present invention. It includes a request receiving module 10, a task determination module 20, a main task generation module 30, a detailed task generation module 40, a task completion processing module 50, a status scanning module 60, a process trigger detection module 70, a process execution module 80, and a status update module 90. Each functional module is described in detail below:

[0218] A request receiving module 10 is used to receive a service initiation request;

[0219] The task determination module 20 is used to determine whether it is necessary to create a pre-verification task record based on the business initiation request before generating the business object record;

[0220] The main task generation module 30 is used to create a main task record for the business object and set it to an unfinished state if a pre-verification task record needs to be created;

[0221] The detailed task generation module 40 is used to generate multiple detailed task records and set them to a pending state, and establish an association relationship between the main task record and the detailed task record;

[0222] The task completion processing module 50 is used to receive a task record completion event and update the status of the detailed task record corresponding to the task record completion event to a completed status;

[0223] The status scanning module 60 is used to periodically scan the unfinished main task records and determine whether the detailed task records associated with the unfinished main task records are all completed;

[0224] A process trigger detection module 70 is used to detect whether there is a process trigger request call record when all the detailed task records associated with the unfinished main task record are completed;

[0225] The process execution module 80 is used to execute the preset business process and update the status of the main task record if there is a process trigger request call record;

[0226] The status updating module 90 is configured to update the status of the main task record to completed if there is no process trigger request call record.

[0227] In one embodiment, the detailed task generation module 40 is specifically configured to:

[0228] Parse the main task type code stored in the main task record;

[0229] Query a predefined task type mapping relationship table to obtain a set of detailed task types associated with the main task type code;

[0230] Generate a detailed task parameter set corresponding to each detailed task type according to the business context parameter set of the main task record;

[0231] Creating a detailed task record set based on the detailed task type set and the corresponding detailed task parameter set;

[0232] Initialize the status field of each detailed task record in the detailed task record set to a pending state;

[0233] Add a main task foreign key identifier to each detailed task record in the database to establish an association relationship with the main task record.

[0234] In one embodiment, the task determination module 20 is specifically configured to:

[0235] Parsing the characteristic parameter code in the service initiation request and extracting the characteristic parameter value set in the service initiation request;

[0236] Querying a predefined task type table to obtain a set of candidate task types associated with the feature parameter code;

[0237] Determining a necessity weight value for each candidate task type in the candidate task type set according to the feature parameter value set;

[0238] When there is a candidate task type whose necessity weight value exceeds a preset weight threshold, it is determined that a pre-verification task record needs to be created.

[0239] In one embodiment, the task completion processing module 50 is specifically configured to:

[0240] Register and monitor the topic channel associated with the main task type code in the message middleware;

[0241] Parse the message body content of the task record completion event in the subject channel to obtain the business object number and detailed task type code;

[0242] Querying the database according to the business object number to obtain the corresponding main task record instance and the associated detailed task record set;

[0243] Performing a row-level lock acquisition operation on a target detailed task record in the detailed task record set whose status is to be executed;

[0244] Verify whether the task execution result signature in the task record completion event is consistent with the security verification key of the main task record instance;

[0245] When the verification is consistent, the status field of the target detailed task record is updated to the completed status and the database transaction is submitted;

[0246] When the verification is inconsistent, the task record completion event is discarded and a security audit log is generated;

[0247] Release the row-level lock resources of the target detail task record.

[0248] In one embodiment, the status scanning module 60 is specifically configured to:

[0249] Initialize paging scanning parameters;

[0250] Obtaining a set of unfinished main task records from the database in pages based on the page scanning parameters;

[0251] Traversing each main task record entry in the uncompleted main task record set;

[0252] Querying the associated detailed task record set according to the unique identifier of the main task record entry;

[0253] Counting the number of unfinished detail task records in the detail task record set;

[0254] When the unfinished quantity is zero, it is determined that all the associated detailed task records are completed.

[0255] In one embodiment, the process execution module 80 is specifically configured to:

[0256] If there is a process trigger request call record, query the caller system identifier of the process trigger request call record, and query the database to obtain the corresponding main task record instance according to the business object number in the process trigger request call record;

[0257] Matching a standardized request message template of a preset business process according to the caller system identifier;

[0258] Extracting a set of key business parameters of the main task record instance;

[0259] Injecting the key business parameter set into the standardized request message template to generate a target business process request message;

[0260] Calling the process execution interface of the target business system corresponding to the calling system identifier, and submitting the target business process request message to the target business system;

[0261] Receive the business process execution result returned by the target business system;

[0262] When the business process execution result includes a success status code, the status of the main task record instance is updated to the process triggered status;

[0263] When the business process execution result includes a failure status code, a process trigger exception log is generated and the status of the main task record instance is kept unchanged.

[0264] In one embodiment, the process trigger detection module 70 is specifically configured to:

[0265] Parse the business object ID in the process trigger request;

[0266] Query the database according to the business object number to obtain the corresponding main task record;

[0267] Check whether the status field of the main task record meets the preset process trigger condition;

[0268] When the status field is in the completed state, a process blocking alarm log is generated and the current process trigger request is terminated;

[0269] When the status field is in an unfinished state, a process release instruction is generated and the preset business process is allowed to be executed;

[0270] The process blocking alarm log or process release instruction is written into the process operation record table.

[0271] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the service side of a business process processing method based on multi-level tasks.

[0272] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a business process processing method based on multi-level tasks.

[0273] 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. When the processor executes the computer program, the following steps are performed:

[0274] Receive business initiation request;

[0275] Before generating a business object record, determining whether a pre-verification task record needs to be created based on the business initiation request;

[0276] If a pre-verification task record needs to be created, a main task record is created for the business object and set to an unfinished state;

[0277] Generate multiple detailed task records and set them to be executed, and establish the association between the main task record and the detailed task record;

[0278] Receive a task record completion event, and update the status of the detailed task record corresponding to the task record completion event to a completed status;

[0279] Periodically scan unfinished main task records to determine whether all detail task records associated with the unfinished main task records have been completed;

[0280] When all the detailed task records associated with the unfinished main task record are completed, check whether there is a process trigger request call record;

[0281] If there is a process trigger request call record, the preset business process is executed and the status of the main task record is updated;

[0282] If there is no process trigger request call record, the status of the main task record is updated to completed.

[0283] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0284] Receive business initiation request;

[0285] Before generating a business object record, determining whether a pre-verification task record needs to be created based on the business initiation request;

[0286] If a pre-verification task record needs to be created, a main task record is created for the business object and set to an unfinished state;

[0287] Generate multiple detailed task records and set them to be executed, and establish the association between the main task record and the detailed task record;

[0288] Receive a task record completion event, and update the status of the detailed task record corresponding to the task record completion event to a completed status;

[0289] Periodically scan unfinished main task records to determine whether all detail task records associated with the unfinished main task records have been completed;

[0290] When all the detailed task records associated with the unfinished main task record are completed, check whether there is a process trigger request call record;

[0291] If there is a process trigger request call record, the preset business process is executed and the status of the main task record is updated;

[0292] If there is no process trigger request call record, the status of the main task record is updated to completed.

[0293] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0294] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application 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), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0295] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by 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.

[0296] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A business process processing method based on multi-level tasks, characterized in that: The following steps are involved: Receive business initiation request; Before generating a business object record, determining whether a pre-verification task record needs to be created based on the business initiation request; If a pre-verification task record needs to be created, a main task record is created for the business object and set to an unfinished state; Generate multiple detailed task records and set them to be executed, and establish the association between the main task record and the detailed task record; Receive a task record completion event, and update the status of the detailed task record corresponding to the task record completion event to a completed status; Periodically scan unfinished main task records to determine whether all detail task records associated with the unfinished main task records have been completed; When all the detailed task records associated with the unfinished main task record are completed, check whether there is a process trigger request call record; If there is a process trigger request call record, the preset business process is executed and the status of the main task record is updated; If there is no process trigger request call record, the status of the main task record is updated to completed.

2. The multi-level task-based business process processing method according to claim 1, characterized in that: Generate multiple detailed task records and set them to pending status, and establish an association between the main task record and the detailed task records, including: Parse the main task type code stored in the main task record; Query a predefined task type mapping relationship table to obtain a set of detailed task types associated with the main task type code; Generate a detailed task parameter set corresponding to each detailed task type according to the business context parameter set of the main task record; Creating a detailed task record set based on the detailed task type set and the corresponding detailed task parameter set; Initialize the status field of each detailed task record in the detailed task record set to a pending state; Add a main task foreign key identifier to each detailed task record in the database to establish an association relationship with the main task record.

3. The multi-level task-based business process processing method according to claim 1, characterized in that: Before generating a business object record, determining whether a pre-verification task record needs to be created based on the business initiation request includes: Parsing the characteristic parameter code in the service initiation request and extracting the characteristic parameter value set in the service initiation request; Querying a predefined task type table to obtain a set of candidate task types associated with the feature parameter code; Determining a necessity weight value for each candidate task type in the candidate task type set according to the feature parameter value set; When there is a candidate task type whose necessity weight value exceeds a preset weight threshold, it is determined that a pre-verification task record needs to be created.

4. The multi-level task-based business process processing method according to claim 1, characterized in that: Receiving a task record completion event and updating the status of the detailed task record corresponding to the task record completion event to a completed status, including: Register and monitor the topic channel associated with the main task type code in the message middleware; Parse the message body content of the task record completion event in the subject channel to obtain the business object number and detailed task type code; Querying the database according to the business object number to obtain the corresponding main task record instance and the associated detailed task record set; Performing a row-level lock acquisition operation on a target detailed task record in the detailed task record set whose status is to be executed; Verify whether the task execution result signature in the task record completion event is consistent with the security verification key of the main task record instance; When the verification is consistent, the status field of the target detailed task record is updated to the completed status and the database transaction is submitted; When the verification is inconsistent, the task record completion event is discarded and a security audit log is generated; Release the row-level lock resources of the target detail task record.

5. The multi-level task-based business process processing method according to claim 1, characterized in that: Periodically scan unfinished main task records to determine whether all detail task records associated with the unfinished main task records have been completed, including: Initialize paging scanning parameters; Obtaining a set of unfinished main task records from the database in pages based on the page scanning parameters; Traversing each main task record entry in the uncompleted main task record set; Querying the associated detailed task record set according to the unique identifier of the main task record entry; Counting the number of unfinished detail task records in the detail task record set; When the unfinished quantity is zero, it is determined that all the associated detailed task records are completed.

6. The multi-level task-based business process processing method according to claim 1, characterized in that: If there is a process trigger request call record, the preset business process is executed and the status of the main task record is updated, including: If there is a process trigger request call record, query the caller system identifier of the process trigger request call record, and query the database to obtain the corresponding main task record instance according to the business object number in the process trigger request call record; Matching a standardized request message template of a preset business process according to the caller system identifier; Extracting a set of key business parameters of the main task record instance; Inject the key business parameter set into the standardized request message template to generate Target business process request message; Calling the process execution interface of the target business system corresponding to the calling system identifier, and submitting the target business process request message to the target business system; Receive the business process execution result returned by the target business system; When the business process execution result includes a success status code, the status of the main task record instance is updated to the process triggered status; When the business process execution result includes a failure status code, a process trigger exception log is generated and the status of the main task record instance is kept unchanged.

7. The multi-level task-based business process processing method according to claim 1, characterized in that: When all the detailed task records associated with the unfinished main task record are completed, after checking whether there is a process trigger request call record, the following is also included: Parse the business object ID in the process trigger request; Query the database according to the business object number to obtain the corresponding main task record; Check whether the status field of the main task record meets the preset process trigger condition; When the status field is in the completed state, a process blocking alarm log is generated and the current process trigger request is terminated; When the status field is in an unfinished state, a process release instruction is generated and the preset business process is allowed to be executed; The process blocking alarm log or process release instruction is written into the process operation record table.

8. A business process processing device based on multi-level tasks, characterized in that: The multi-level task-based business process processing device includes: Request receiving module, used to receive service initiation requests; A task determination module is used to determine whether it is necessary to create a pre-verification task record based on the business initiation request before generating a business object record; The main task generation module is used to create a main task record for the business object and set it to an unfinished state if a pre-verification task record needs to be created; The detailed task generation module is used to generate multiple detailed task records and set them to a pending state, and establish an association relationship between the main task record and the detailed task record; A task completion processing module is used to receive a task record completion event and update the status of the detailed task record corresponding to the task record completion event to a completed status; The status scanning module is used to periodically scan the unfinished main task records and determine whether all the detailed task records associated with the unfinished main task records have been completed; The process trigger detection module is used to detect whether there is a process trigger request call record when all the detailed task records associated with the unfinished main task record are completed; The process execution module is used to execute the preset business process and update the status of the main task record if there is a process trigger request call record; The status update module is used to update the status of the main task record to completed if there is no process trigger request call record.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a multi-level task-based business process processing program stored in the memory and capable of running on the processor. When the multi-level task-based business process processing program is executed by the processor, the steps of the multi-level task-based business process processing method as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a multi-level task-based business process processing program, which, when executed by a processor, implements the steps of the multi-level task-based business process processing method according to any one of claims 1 to 7.

Images