A multi-scene task serial-parallel visual collaborative management method and system

Abstract

This application relates to a multi-scenario task serial parallel visualization collaborative management method and system. The method includes: responding to a task assignment instruction, defining a collaborative task data structure, and setting the status identifier to "to be decomposed." Responding to a decomposition operation triggered by the "to be decomposed" status, obtaining decomposition configuration information, generating and configuring a step flowchart data structure accordingly, and updating the task status to "to be filled in." Responding to the operation of the sub-item responsible person in the "to be filled in" status, obtaining the data objects to be filled in at each node. Based on the serial parallel type identifier of the nodes in the flowchart, dynamically controlling the filling permissions of the corresponding responsible person, and updating the node status according to the filled data. When all node statuses are "complete" and the closing conditions are met, obtaining a closing instruction, updating the task status to "closed," and archiving the flowchart data structure. This application achieves structured management and control of the entire lifecycle of complex tasks from initiation, decomposition, execution to archiving.

Description

Technical Field

[0001] This application relates to the field of digital collaborative management and control technology, and in particular to a method and system for multi-scenario task serial parallel visualization collaborative management. Background Technology

[0002] With the rapid development of high-end equipment manufacturing industries such as intelligent manufacturing of aerospace equipment, the complexity of product research and development and production processes is increasing, and cross-departmental and cross-professional collaborative operations have become the norm. The research and production of complex equipment often involves a massive number of task nodes and deep involvement of multiple levels of personnel. The logical dependencies between tasks are becoming increasingly complex, placing extremely high demands on the efficiency of collaborative work, the flexibility of process arrangement, and the transparency of process control. To ensure the smooth progress of projects, enterprises urgently need to use information technology to centrally and meticulously manage the initiation, transfer, execution, and delivery of collaborative tasks, ensuring information synchronization at each stage, controllable progress, and accurate deliverables.

[0003] However, most existing collaborative work relies on traditional communication methods for task distribution and feedback. This approach lacks a structured task data carrier and a unified workflow scheduling mechanism, making it difficult to track the status of tasks in real time and preventing task executors from accurately identifying pending tasks immediately. Furthermore, when faced with tasks involving multiple collaborators and complex logical dependencies, existing methods struggle to clearly define the boundaries of each participant's task content and the order of execution, easily leading to unclear responsibilities and buck-passing.

[0004] Furthermore, during long-cycle task execution, the lack of effective flow logic control and status verification mechanisms means that the connection between task nodes often relies on manual confirmation and subjective judgment. This not only easily leads to confusion and errors in the versions of deliverables such as attachments, but also frequently results in the omission or forgetting of near-delay or overdue tasks. Ultimately, this makes it difficult for collaborative tasks to form a clear closed loop, resulting in low efficiency in cross-departmental collaboration. This fails to meet the stringent requirements of intelligent manufacturing of complex equipment for full lifecycle management of collaborative tasks, flexible process orchestration, and transparent and traceable processes. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method and system for parallel visualization and collaborative management of multi-scenario task strings.

[0006] Firstly, this application provides a method for parallel, visual, and collaborative management of multi-scenario task strings, employing the following technical solution: A method for parallel, visual, and collaborative management of multi-scenario task strings, the method comprising: In response to a task assignment instruction, a data structure for a collaborative task is defined, which includes task configuration information and a task status identifier, and the task status identifier is set to a state to be decomposed. In response to the decomposition operation triggered when the task status is identified as pending decomposition, decomposition configuration information is obtained; wherein, the decomposition configuration information includes the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of the sub-item. The data structure for generating and configuring the step flowchart based on the decomposed configuration information is then updated to the pending data entry status. In response to the reporting operation of each sub-item responsible person when the task status is marked as pending, the reporting data object of each node is obtained; Based on the serial-parallel type identifier of each node in the flowchart, the reporting permissions of the person in charge of each sub-item are dynamically controlled, and the node status of the corresponding node in the flowchart is updated according to the reported data object. In response to the fact that the node status of all nodes in the flowchart of the steps is updated to the completed state and the closing trigger condition is met, a closing instruction is obtained; Based on the closing instruction, the task status identifier in the data structure of the collaborative task is updated to the closed state, and the data structure of the step flowchart is archived.

[0007] By adopting the above technical solutions, a collaborative task management mechanism based on information-driven and data-structured control was constructed. By defining a data structure carrying status identifiers and dynamically controlling the filling permissions according to the serial-parallel type identifier, the technical problems of unclear task boundaries, untraceable status, chaotic attachment versions, and uncontrolled flow logic in traditional email collaboration were solved. Visual closed-loop control of the entire lifecycle from task initiation to archiving was realized. It not only prevented overdue omissions through precise message push and permission verification, but also allowed subsequent nodes to intervene in the filling in advance through flexible serial-parallel flow logic, shortening the processing cycle of complex collaborative tasks and improving the efficiency and delivery quality of cross-departmental collaborative operations.

[0008] Optionally, in response to a task deployment instruction, defining a data structure for a collaborative task that includes task configuration information and a task status identifier, and setting the task status identifier to a state to be decomposed, includes the following steps: Parse the task deployment instruction to obtain task configuration information; Generate a globally unique collaborative task identifier, and initialize the data structure of the collaborative task based on the collaborative task identifier; wherein, the data structure includes a task configuration field and a task status identifier; Write the task configuration information into the task configuration field, and set the task status identifier to the pending decomposition state.

[0009] By adopting the above technical solution, collaborative tasks are transformed from disordered email communication to structured data-driven processes. Comprehensive task configuration information and fine-grained attachment permission configurations are obtained by parsing instructions. Configuration and status fields are strictly separated in the data structure created during initialization, decoupling the static attributes and dynamic flow logic of tasks. At the same time, by using globally unique collaborative task identifiers and the setting of decomposition status, a solid data foundation is laid for subsequent accurate information push and parallel flow control based on caching and message middleware. This fundamentally eliminates the problems of unclear task boundaries, uncontrolled attachment versions, and chaotic flow instructions in traditional methods.

[0010] Optionally, the task assignment instruction may also include attachment files and attachment permission configuration data. The attachment permission configuration data is used to control the preview and editing permissions of the attachment files when the person in charge of the sub-item performs the data entry operation.

[0011] Through the above mechanism, the attachment permission configuration data can precisely control the access scope of attachment files throughout the entire task lifecycle, avoiding uncontrollable attachment versions or accidental data modification due to permission confusion, thereby ensuring the integrity and consistency of the output data in collaborative tasks.

[0012] Optionally, the step of generating and configuring the data structure of the step flowchart based on the decomposed configuration information, and updating the task status identifier to the pending status, includes: Parse the decomposed configuration information to obtain the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of each sub-item; Based on the obtained node attributes, serial-parallel type identifiers and corresponding relationships, the data structure of the step flowchart is generated; wherein, the data structure of the step flowchart includes node identifiers of multiple task nodes, sequential number of each node, serial-parallel type identifier of each node, sub-item responsible person identifier corresponding to each node, and directed edge data used to characterize the flow logic between each node. The data structure of the flowchart of the steps is associated and stored with the data structure of the collaborative task; Update the task status identifier in the data structure of the collaborative task from the state to be decomposed to the state to be filled in.

[0013] By adopting the above technical solutions, a precise structured mapping of collaborative tasks from macro-level description to micro-level execution is achieved. By parsing and decomposing configuration information and generating a step flowchart data structure containing node attributes, directed edges, and serial / parallel identifiers, the complex business flow logic is transformed into a topological model that can be rigorously computed by a computer. This eliminates the problems of ambiguous task boundaries and chaotic flow instructions in traditional email methods. At the same time, by associating the flowchart with collaborative tasks and driving the update of state identifiers, a state machine-based information-driven mechanism is constructed, ensuring seamless connection and accurate message push from task planning to execution, and improving the efficiency and process controllability of cross-departmental collaborative operations.

[0014] Optionally, after updating the task status identifier in the data structure of the collaborative task from the state to be decomposed to the state to be filled in, the method further includes: Based on the data structure of the stored flowchart of the steps, obtain the sub-item responsible person identifier corresponding to each node; Obtain the collaborative task identifier from the data structure of the collaborative task; Using a message middleware, a reporting notification message is generated based on the collaborative task identifier, the sub-item leader identifier corresponding to each node, and the node identifier; The notification message is pushed to the message queue of the corresponding sub-item manager to trigger the sub-item manager to perform the data entry operation.

[0015] By adopting the above technical solution, an automated flow-driven mechanism based on a step flowchart data structure and message middleware was constructed. By parsing the flowchart data to extract personnel and task identifiers, and using the message middleware to generate accurately routed filling notification messages to push to individual queues, this replaces the inefficient mode of traditional manual email forwarding and verbal reminders. It achieves a seamless closed loop between task status changes and personnel action triggering, ensuring that executors can lock onto pending items in complex tasks across multiple scenarios as soon as possible, eliminating omissions and delays in task information, and improving the real-time performance and controllability of cross-departmental collaborative operations.

[0016] Optionally, the steps of dynamically controlling the reporting permissions of the person in charge of each sub-item corresponding to each node based on the serial-parallel type identifier of each node in the step flowchart, and updating the node status of the corresponding node in the step flowchart according to the reported data object, include: In response to the data entry operation of the current node, the data entry object is obtained and stored as temporary data of the current node; From the data structure of the flowchart, obtain the serial-parallel type identifier of the current node, and obtain the node status of all predecessor nodes corresponding to the current node; Based on the obtained serial-parallel type identifier of the current node and the node status of all predecessor nodes, determine whether it is allowed to set the node status of the current node to the completed state. If so, update the node status of the current node to the completed state and mark the temporary data as final data; If not, the node status of the current node is updated to a temporary saved state, and the temporary data is allowed to be overwritten by subsequent data entry operations.

[0017] By adopting the above technical solution, precise and automated control of complex serial-parallel flow logic in collaborative tasks is achieved. By extracting the serial-parallel type identifier of the current node and performing joint verification with the status of the predecessor node, the system dynamically intervenes in the transition of the node status from temporary storage to completion. This allows the person in charge of each sub-item to fill in the information in advance in the preliminary stage to shorten the overall cycle. At the same time, the system eliminates the chaotic phenomenon of parallel tasks being transferred before they are complete by strictly judging the completion permissions. This solves the problems of unclear task boundaries and uncontrolled flow status under traditional email collaboration, and improves the execution efficiency and data compliance of multi-scenario collaborative tasks.

[0018] Optionally, the step of updating the task status identifier in the data structure of the collaborative task to a closed state based on the closing instruction, and archiving the data structure of the step flowchart, includes: Parse the shutdown command to obtain the identifier of the collaborative task to be shut down; Based on the acquired collaborative task identifier, the data structure of the collaborative task and the data structure of the associated storage step flowchart are read from the storage system; Obtain the node status data of all nodes from the data structure of the read flowchart, and verify that the node status of all nodes is complete. If the verification passes, the task status identifier in the data structure of the collaborative task will be updated to the closed state, and a closed timestamp will be generated and added to the data structure of the collaborative task. Generate an archive identifier, and based on the archive identifier, mark the data structure of the step flowchart and the data structure of the collaborative task as immutable archive objects, and store the marked immutable archive objects in the archive storage space.

[0019] By adopting the above technical solutions, closed-loop management of the entire lifecycle of collaborative tasks from initiation to closure is achieved. Rigorous node status verification eliminates the loophole of closing tasks before completion. Status updates and timestamps solidify the task's termination node. Immutable archiving ensures the integrity and traceability of process data. This solves the problems of tasks not being able to close the loop, data being easily lost, and subsequent statistics not being possible under traditional collaborative methods, thereby improving the compliance of enterprise-level project management and the value of data assets.

[0020] Secondly, this application provides a multi-scenario task serial parallel visualization collaborative management system, which adopts the following technical solution: A multi-scenario task serial parallel visualization collaborative management system, the system comprising: The collaborative task initiation module is used to respond to the task deployment instruction, define the data structure of the collaborative task containing task configuration information and task status identifier, and set the task status identifier to a state to be decomposed. The collaborative task decomposition module is used to respond to the decomposition operation triggered when the task status is identified as pending decomposition, and to obtain decomposition configuration information; wherein, the decomposition configuration information includes the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of the sub-item. The step flow generation module is used to generate and configure the data structure of the step flow diagram based on the decomposed configuration information, and update the task status identifier to the pending state. The collaborative task reporting module responds to the reporting operations of each sub-item leader when the task status is marked as pending reporting, and obtains the reporting data objects of each node. The data entry permission control module is used to dynamically control the data entry permission of the person in charge of each sub-item corresponding to each node based on the serial-parallel type identifier of each node in the step flowchart, and update the node status of the corresponding node in the step flowchart according to the data entry object. The task closure trigger module is used to obtain a closure command in response to the fact that the node status of all nodes in the process flowchart is updated to the completed state and the closure trigger condition is met. The collaborative task closing module is used to update the task status identifier in the collaborative task's data structure to a closed state based on the closing instruction, and to archive the data structure of the step flowchart.

[0021] Thirdly, this application provides a computer device, which adopts the following technical solution: A computer device includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform the steps of the method as described in the first aspect.

[0022] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect. Attached Figure Description

[0023] Figure 1 This is a first flowchart of a multi-scenario task string parallel visualization collaborative management method according to one embodiment of this application.

[0024] Figure 2 This is a second flowchart illustrating a multi-scenario task string parallel visualization collaborative management method according to one embodiment of this application.

[0025] Figure 3 This is a schematic diagram of the third process of a multi-scenario task string parallel visualization collaborative management method according to one embodiment of this application.

[0026] Figure 4 This is a schematic diagram of the fourth process of a multi-scenario task serial parallel visualization collaborative management method according to one embodiment of this application.

[0027] Figure 5 This is a schematic diagram of the fifth process of a multi-scenario task serial parallel visualization collaborative management method according to one embodiment of this application.

[0028] Figure 6 This is a schematic diagram of the sixth process of a multi-scenario task serial parallel visualization collaborative management method according to one embodiment of this application. Detailed Implementation

[0029] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-6 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0030] This application discloses a method for parallel visualization and collaborative management of multi-scenario task strings.

[0031] Reference Figure 1 A multi-scenario task string parallel visualization collaborative management method, specifically including: Step S101: In response to the task deployment instruction, define a data structure for the collaborative task that includes task configuration information and task status identifier, and set the task status identifier to a state to be decomposed. The task assignment instruction is triggered by the task assigner on the system front end based on business needs. After the system responds to the instruction, it creates a collaborative task instance on the back end. This instance exists in the form of a data structure, which contains task configuration information such as task description, main person in charge, sub-item person in charge, attachment files and their permission configuration. At the same time, a task status identifier is assigned to this data structure to represent the current life cycle stage of the collaborative task. It is set to the pending decomposition state during initialization to drive the execution of subsequent decomposition steps.

[0032] Specifically, by abstracting collaborative tasks into a data structure containing configuration information and status identifiers, the flow of tasks is freed from the traditional discrete communication mode of email. Instead, the system uniformly schedules tasks based on status identifiers. The setting of the status to be decomposed also clarifies the current business boundary of the task, ensuring that the task will not enter the filling process before it is effectively decomposed.

[0033] For example, in the intelligent manufacturing scenario of aviation equipment, the chief engineer of the project initiates a collaborative task for wing assembly. After receiving the instruction, the system generates the data structure of the task, records the overall description of the wing assembly and the designated person in charge of final assembly, and sets the status flag to be decomposed, waiting for the person in charge of final assembly to carry out the subsequent disassembly.

[0034] Step S102: In response to the decomposition operation triggered when the task status is identified as pending decomposition, obtain decomposition configuration information; wherein, the decomposition configuration information includes the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of the sub-item. Specifically, when the system detects that the task status of a collaborative task is marked as pending decomposition, it pushes a decomposition instruction to the main person in charge. The main person in charge then breaks down the macro-level task accordingly. The system obtains the decomposition configuration information input by the main person in charge. This information defines the micro-structure of task execution in detail. The node attributes of the task node define the business requirements of the node. The serial / parallel type identifier is dynamically marked according to the number of corresponding sub-item persons in charge. If a node is executed by only a single person in charge, it is marked as serial. If multiple people need to execute it together, it is marked as parallel. At the same time, a precise binding relationship between nodes and personnel is established.

[0035] In this embodiment of the application, obtaining the decomposed configuration information is the core step in establishing the task flow topology. By clarifying the correspondence between serial and parallel type identifiers and personnel, the task content boundaries of each sub-item leader are clearly defined from the data level, fundamentally eliminating the problem of unclear task boundaries and shirking responsibility in multi-person collaborative tasks.

[0036] For example, the final assembly manager breaks down the wing assembly task into two nodes: skin riveting and frame welding. Skin riveting is handled by a single person and is designated as a serial node, while frame welding is handled by three people and is designated as a parallel node. The system records these decomposed configuration information in a structured manner.

[0037] Step S103: Generate and configure the data structure of the step flowchart based on the decomposed configuration information, and update the task status identifier to the pending data entry status. Based on the obtained decomposition configuration information, the system automatically maps and generates a step flowchart data structure at the underlying level. This data structure connects the attributes, serial / parallel types, and personnel correspondences of each task node in a topological manner to form a flow path that can be parsed by a computer. At the same time, the task status identifier in the collaborative task data structure is updated from the pending decomposition status to the pending reporting status, marking the transition of the task from the planning stage to the execution stage.

[0038] Specifically, the generation of the step flowchart data structure makes the execution logic of the task visible and traceable by the program. The update of the status identifier serves as an information-driven signal, triggering the system to accurately push the filling instructions to all sub-item managers through the caching middleware and message components, enabling relevant personnel to lock the pending tasks as soon as possible.

[0039] For example, based on the aforementioned decomposition configuration, the system generates a step flowchart data structure containing the sequence of skin riveting and skeleton welding, and changes the task status to pending data entry. At this time, the message component pushes a data entry notification to the personnel responsible for skin riveting.

[0040] Step S104: In response to the filling operation of each sub-item person in charge when the task status is marked as pending, obtain the filling data object of each node. In the pending data entry state, the person in charge of each sub-item performs the data entry operation through the front-end interface, including submitting text descriptions, online editing of attachments, and completion percentages. The system receives these inputs and encapsulates them into data entry objects corresponding to each task node. These data objects are the core carriers reflecting the progress of task execution.

[0041] In this embodiment of the application, the acquisition of the data object supports two processing modes: temporary storage and data entry completion. Regardless of the storage method used, the system can track and monitor the overall execution status of the current task in real time based on the completion ratio parameter in the data object, thus avoiding the omission or forgetting of long-cycle tasks.

[0042] For example, when a worker responsible for skin riveting uploads a riveting process record file and fills in the progress in the system, the system encapsulates these texts and attachments into a data object for that node. Even if it is only temporarily saved, the system can still record the current completion rate based on this.

[0043] Step S105: Based on the serial-parallel type identifier of each node in the step flowchart, dynamically control the filling permissions of the person in charge of each sub-item corresponding to each node, and update the node status of the corresponding node in the step flowchart according to the filling data object. The system uses the pre-defined serial-parallel type identifier in the flowchart data structure to rigorously and dynamically intervene in the filling permissions during the workflow. Different unlocking logic is set for different serial-parallel combinations of nodes before and after. When the system obtains the filling data object submitted by the person in charge of the sub-item, it updates the node status of the corresponding node according to its operation type and permission control logic. If it is a temporary save, the current status is maintained. If the filling is completed and meets the workflow conditions, the node status is advanced.

[0044] Specifically, this dynamic control logic rigorously covers four relationships: preceding-parallel, preceding-parallel, preceding-parallel-following, and preceding-parallel-following. For example, when the preceding node is a parallel node, as long as one person completes the data entry, the subsequent node's data entry permission is unlocked, allowing early intervention. However, the subsequent node's completion permission is only unlocked after all members of the preceding parallel nodes have completed the data entry, thereby maximizing collaborative efficiency while ensuring process rules.

[0045] For example, when a welder in the parallel node of skeleton welding completes the data entry first, the system dynamically unlocks the data entry permission for subsequent inspection nodes, allowing inspectors to intervene in advance to temporarily save the data, but prohibiting them from clicking "complete data entry". Only when all welders in the skeleton welding node have submitted the data entry object will the inspection node be granted completion permission.

[0046] Step S106: In response to the fact that the node status of all nodes in the step flowchart is updated to the completed state and the closing trigger condition is met, obtain the closing instruction; Throughout the entire data entry process, the system continuously monitors the status of each node in the flowchart data structure. When it is determined that all task nodes have been updated to the completed state and the overall completion rate has reached the set threshold and other closing trigger conditions, the system opens the closing operation entry to the task assigner and receives the closing command issued by the assigner.

[0047] Specifically, the setting of the closing trigger condition ensures the rigor of the task closure. The system automatically verifies the overall completion of the task by traversing the node status identifiers in the flowchart data structure. Only when all underlying nodes have been filled in without omission is the final closure operation allowed, thus avoiding missing deliverables or version errors.

[0048] For example, when the status of skin riveting, frame welding and subsequent inspection nodes all change to "complete" and the completion rate is displayed as 100%, the system determines that the closure trigger condition is met, and the project chief engineer can then trigger the closure command in the system.

[0049] Step S107: Based on the closing instruction, update the task status identifier in the collaborative task's data structure to the closed state, and archive the data structure of the step flowchart.

[0050] The system parses the shutdown command, updates the task status identifier in the collaborative task data structure to the closed state, completely terminates the task's lifecycle, and transfers the step flowchart data structure and all associated data objects to the archive storage area to form the final project asset.

[0051] Specifically, updating the status identifier cuts off the message push and status change mechanism of the task at the system level, while the archiving operation ensures that all text and attachment data throughout the entire lifecycle of the collaborative task can be permanently traced and queried, thus achieving the control requirements of transparent and traceable process.

[0052] For example, after the project chief engineer clicks "close," the status of the wing assembly task is set to "closed," and all flowcharts and process attachments are packaged and archived to the database. If a review is needed later, the archived data can be retrieved at any time through the query module.

[0053] The above implementation constructs a collaborative task management mechanism based on information-driven and data-structured control. By defining a data structure carrying status identifiers and dynamically controlling the filling permissions according to the serial-parallel type identifier, it solves the technical problems of unclear task boundaries, untraceable status, chaotic attachment versions, and uncontrolled flow logic in traditional email collaboration. It realizes visualized closed-loop control of the entire lifecycle from task initiation to archiving. It not only eliminates overdue omissions through precise message push and permission verification, but also allows subsequent nodes to intervene in the filling in advance through flexible serial-parallel flow logic, shortening the processing cycle of complex collaborative tasks and improving the efficiency and delivery quality of cross-departmental collaborative operations.

[0054] Reference Figure 2 As one implementation of step S101, in response to a task deployment instruction, defining a data structure for a collaborative task that includes task configuration information and a task status identifier, and setting the task status identifier to a state to be decomposed includes the following steps: Step S201: Parse the task deployment instruction and obtain the task configuration information; The task configuration information includes task description data, main person in charge identification, task resolution time, and attachment files and corresponding read / write permission configurations. Specifically, the system receives and parses the task assignment instructions triggered by the task assigner at the front end, extracts the key task configuration information required to build the collaborative task, and this information constitutes the metadata foundation for task execution. The task description data defines the scope of business requirements for the collaborative task, the main person in charge identifies the core personnel responsible for breaking down and coordinating the task, the task resolution node time sets the time boundary for the task to be used for subsequent overdue warning calculations, and the attachment files and their read / write permission configurations provide the rule basis for version control and online editing permissions of the products in the multi-person collaboration process.

[0055] For example, in complex collaborative scenarios such as intelligent manufacturing of aerospace equipment, tasks are often accompanied by a large number of design documents or process documents. By obtaining the read and write permission configuration of the attachment files during the instruction parsing stage, the system can lock the access and modification rules of each attachment in advance at the underlying data level, avoiding the problem of delivery version confusion or unauthorized modification during subsequent multi-node flow. At the same time, the extraction of the main person in charge's identifier ensures accurate assignment after the task scope is determined, without the need to repeatedly confirm the recipient through traditional emails.

[0056] For example, when the chief engineer of a project initiates a collaborative task for wing assembly, the system parses the instructions submitted and obtains task description data including "complete the wing assembly process compilation", the main person in charge of "final assembly engineer", the task resolution deadline of "the 30th of this month", as well as the attached "wing design drawing.docx" file and its read and write permission configuration of "allow online preview, allow online editing, and prohibit overwriting".

[0057] Step S202: Generate a globally unique collaborative task identifier, and initialize the collaborative task data structure based on the collaborative task identifier; wherein, the data structure includes a task configuration field and a task status identifier; The system assigns a globally unique collaborative task identifier to the currently received collaborative task according to the preset identifier generation rules. This identifier serves as a unique index for the task throughout its entire lifecycle. Subsequently, the system initializes and creates a collaborative task data structure based on this identifier in memory or the persistent layer. This data structure is designed to contain two core logical areas: a task configuration field and a task status identifier, which are used to carry the static attributes and dynamic flow status of the task, respectively.

[0058] Specifically, the generation of a globally unique identifier ensures that various notifications and data entries can be accurately matched to the corresponding task instances during the transmission of the distributed system architecture and message middleware. Dividing the data structure into two independent fields, configuration and status, decouples business data from process control data. This allows the system to drive the process engine by independently reading the task status identifier when performing task flow and access control, without having to parse complex configuration information, thus improving the system's response speed and robustness.

[0059] For example, the system uses the snowflake algorithm to generate an 18-bit number string as the collaborative task identifier "202310241234567890", and creates a record for this identifier in the database, constructing a data structure containing two fields, "TaskConfig" and "TaskStatus", as the underlying storage entity for this collaborative task.

[0060] Step S203: Write the task configuration information into the task configuration field and set the task status identifier to the pending decomposition state.

[0061] The system serializes or formats the task configuration information obtained from the aforementioned parsing and persists it to the task configuration field of the newly created collaborative task data structure. At the same time, it initializes the task status identifier with an enumeration value or status code representing the state to be decomposed, thereby completing the instantiation and construction of the collaborative task and enabling it to officially enter the system's pipeline.

[0062] Specifically, setting the task status to "to be decomposed" is the key starting point for the system to realize information-driven flow. On the one hand, this status restricts the current task to only be decomposed and cannot be directly filled in. On the other hand, as a trigger signal, in conjunction with the caching middleware and message component, the system can accurately push the to-do decomposition notification to the main person in charge based on this status, guide the task to the next stage, and completely eliminate the situation of task omission and forgetting under the traditional email method.

[0063] For example, the system packages the task description of "Complete the wing assembly process compilation", the "final assembly engineer" identifier, "30th of this month" and the attachment permission configuration into the "TaskConfig" field, and sets the value of the "TaskStatus" field to "Pending_Decomposition" (representing pending decomposition). Subsequently, the system detects this status change and triggers the message component to push a message reminder to the final assembly engineer's terminal that "You have a new collaborative task that needs to be decomposed".

[0064] The above implementation transforms collaborative tasks from disordered email communication to structured data-driven processes. By parsing instructions, it obtains comprehensive task configuration information and fine-grained attachment permission configuration. In the data structure created during initialization, configuration and status fields are strictly separated, decoupling the static attributes and dynamic flow logic of the task. At the same time, by using globally unique collaborative task identifiers and the setting of decomposition status, it lays a solid data foundation for subsequent accurate information push and parallel flow control based on caching and message middleware. This fundamentally eliminates the problems of unclear task boundaries, uncontrolled attachment versions, and chaotic flow instructions in traditional methods.

[0065] As one implementation of the task assignment instruction, the task assignment instruction also includes attachment files and attachment permission configuration data. The attachment permission configuration data is used to control the preview and editing permissions of the attachment files when the person in charge of the sub-item performs the filling operation.

[0066] In addition to basic task description information, the task assignment instruction also includes attachment file data and its corresponding attachment permission configuration data. The attachment permission configuration data is stored and associated with the collaborative task's data structure, and is used to define the types of operation permissions granted to each sub-project leader for the attachment files during subsequent task workflow.

[0067] Specifically, the attachment permission configuration data includes at least preview permission identifiers and edit permission identifiers, which indicate whether the sub-project leader is allowed to preview or edit the attachment file online when performing the data entry operation. After receiving the task assignment instruction, the system uploads the attachment file to the file storage server and records the attachment permission configuration data and the storage path of the attachment file in the collaborative task's data structure. When any sub-project leader initiates an access request to the attachment file through the client, the system first reads the attachment permission configuration data from the collaborative task's data structure, and then dynamically controls the enabling or disabling of the preview and edit permissions based on the matching relationship between the current sub-project leader's identity identifier and the attachment permission configuration data.

[0068] Through the above mechanism, the attachment permission configuration data can precisely control the access scope of attachment files throughout the entire task lifecycle, avoiding uncontrollable attachment versions or accidental data modification due to permission confusion, thereby ensuring the integrity and consistency of the output data in collaborative tasks.

[0069] Reference Figure 3 As one implementation of step S103, the step of generating and configuring the data structure of the step flowchart based on the decomposed configuration information, and updating the task status identifier to the pending state, includes: Step S301: Parse and decompose the configuration information to obtain the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of each sub-item. Among them, the decomposed configuration information is the structured data input into the system by the main person in charge after breaking down the macro-level collaborative tasks into business operations. The system extracts the key elements used to build the underlying execution logic by parsing this information. The node attributes of the task node define the business requirements and execution content of the node. The serial and parallel type identifier is dynamically marked according to the number of corresponding sub-item persons in charge. If the node is executed by only a single person in charge, it is marked as serial. If it needs to be executed by multiple people, it is marked as parallel. The correspondence between nodes and sub-item persons in charge establishes a precise binding between personnel and tasks.

[0070] For example, in complex collaborative scenarios such as intelligent manufacturing of aerospace equipment, the ambiguity of task boundaries often leads to buck-passing. By extracting the above-mentioned node attributes and their corresponding personnel, the system clearly delineates the task content boundaries of each sub-item's responsible person from a data perspective. At the same time, the acquisition of serial and parallel type identifiers provides the core rule basis for dynamic permission control and state machine judgment during subsequent process flow, ensuring that the task flow logic is based on evidence.

[0071] For example, the final assembly manager breaks down the wing assembly task into two nodes: skin riveting and frame welding. After the system analyzes the data, it finds that the skin riveting node has the attribute "process preparation", corresponds to a single person in charge, and is identified as serial in the serial-parallel type. The frame welding node has the attribute "welding implementation", corresponds to three people, and is identified as parallel in the serial-parallel type. The system extracts these elements for use in the subsequent flowchart generation.

[0072] Step S302: Based on the obtained node attributes, serial-parallel type identifiers and corresponding relationships, generate the data structure of the step flowchart; wherein, the data structure of the step flowchart includes the node identifiers of multiple task nodes, the sequential number of each node, the serial-parallel type identifier of each node, the sub-item responsible person identifier corresponding to each node, and directed edge data used to represent the flow logic between each node. Specifically, the system maps the aforementioned discrete configuration elements into a computer-parseable graph theory data structure. Node identifiers and sequence numbers establish the time and logical order of task execution. Serial / parallel type identifiers and sub-item responsible person identifiers are encapsulated as the core attributes of nodes, while directed edge data clarifies the predecessor and successor dependencies between nodes through pointing relationships, together constructing a complete step flowchart data structure.

[0073] In this embodiment of the application, the generation of this graph data structure is the foundation for realizing visual collaboration and process control. The directed edge data not only defines the top-down flow path of tasks, but also forms a rigorous flow judgment engine in conjunction with the serial and parallel type identifiers, enabling the system to accurately calculate the nodes that should be activated and the personnel that should be authorized based on this data structure, completely replacing the traditional disordered flow mode of emails.

[0074] For example, the system assigns globally unique node identifiers to skin riveting nodes and skeleton welding nodes, and assigns incremental sequence numbers according to the execution order. At the same time, it generates a directed edge data from the skin riveting node to the skeleton welding node, representing the preconditions in the flow logic. Then, it serializes this information into a step flowchart data structure for persistent storage.

[0075] Step S303: Associate and store the data structure of the step flowchart with the data structure of the collaborative task; The collaborative task data structure records task configuration information and status, while the step flowchart data structure serves as the topological carrier for micro-execution. The two need to establish a mapping relationship from macro to micro through associated storage, so that the system can quickly index the corresponding execution path graph through the main data structure when processing task flow.

[0076] Specifically, the implementation of associated storage can be either serializing the data structure of the step flowchart into a string and then directly embedding it in a specific field of the collaborative task data structure, or storing the data structure of the step flowchart independently in the process library and writing the storage address pointer of the flowchart into the collaborative task data structure. This associated design ensures the decoupling and consistency between business data and process data.

[0077] For example, the system serializes the generated wing assembly step flowchart data structure and binds it to the reserved step flowchart field in the wing assembly collaborative task data structure, or stores the flowchart in an independent graph database and writes its primary key into the collaborative task record to ensure that the execution path can be accurately retrieved during subsequent queries and workflows.

[0078] Step S304: Update the task status identifier in the collaborative task's data structure from the pending decomposition state to the pending data entry state.

[0079] Among them, the task status identifier is the core signal that drives the system message push and the operation of the process engine. When the data structure of the step flowchart is successfully generated and associated, the task has completed the planning stage. The system will change the task status identifier in the collaborative task data structure from the pending decomposition state to the pending filling state, which marks the task officially entering the execution and filling stage.

[0080] Specifically, the update of this status identifier cuts off the triggering conditions of the decomposition operation at the underlying level, while activating the filling permission control logic. After the system detects this status change, it will automatically read the sub-item responsible person identifier of the first node in the step flowchart data structure, and use the message middleware to accurately push the filling instruction to it, realizing seamless connection and information-driven operation from task planning to task execution.

[0081] For example, after the flowchart of the wing assembly task is generated, the system updates the task status identifier from "to be decomposed" to "to be filled in". This status update triggers the message component to push a to-do notification to the person in charge of skin riveting at the first node of the flowchart, reminding them to log in to the system to fill in the information.

[0082] The above implementation achieves a precise structured mapping of collaborative tasks from macro-level description to micro-level execution. By parsing and decomposing configuration information and generating a step flowchart data structure containing node attributes, directed edges, and serial / parallel identifiers, the complex business flow logic is transformed into a topological model that can be rigorously computed by a computer. This eliminates the problems of ambiguous task boundaries and chaotic flow instructions found in traditional email methods. At the same time, by associating the flowchart with collaborative tasks and driving the update of state identifiers, a state machine-based information-driven mechanism is constructed, ensuring seamless connection and accurate message push from task planning to execution, and improving the efficiency and process controllability of cross-departmental collaborative operations.

[0083] Reference Figure 4 As one implementation method of a multi-scenario task serial parallel visualization collaborative management method, after updating the task status identifier in the collaborative task data structure from the pending decomposition state to the pending reporting state, it also includes: Step S401: Based on the data structure of the associated stored step flowchart, obtain the sub-item responsible person identifier for each node; In this process, after updating the task status identifier of the collaborative task to the pending status, the system immediately retrieves the data structure of the associated storage step flowchart from the underlying storage, and traverses the node configuration information in the data structure to extract the sub-item leader identifier bound to each task node. The sub-item leader identifier is a unique personnel index pre-assigned by the system, which is used to accurately locate the task execution subject when distributing messages.

[0084] Specifically, obtaining the identifier of the person in charge of each sub-item is a prerequisite for achieving information-driven and precise targeted assignment. The data structure of the step flowchart not only records the serial and parallel topology relationship of the nodes, but also solidifies the binding relationship between personnel and nodes. By parsing this data structure, the system can clearly know which node should be executed by whom, thereby providing a precise addressing basis for subsequent message routing, and completely avoiding the problems of ambiguous task distribution objects and the inability of the recipient to lock the pending tasks in time under traditional communication methods.

[0085] For example, in the collaborative task of assembling aircraft wings, the system reads the riveting worker identifiers bound to the "skin riveting" node and the three welder identifiers bound to the "skeleton welding" node from the generated step flowchart data structure, and extracts these personnel identifiers as the target address pool for message push.

[0086] Step S402: Obtain the collaborative task identifier from the collaborative task's data structure; The system synchronously reads the globally unique collaborative task identifier from the collaborative task's data structure. This identifier is generated when responding to the task deployment instruction and is used to uniquely represent the current collaborative task instance throughout the entire system lifecycle.

[0087] Specifically, obtaining the collaborative task identifier is to provide a traceability anchor for the task context when generating notification messages. Since there may be hundreds or thousands of collaborative tasks in the pending data entry state in an enterprise system, it is impossible to distinguish the specific task to which the message belongs based solely on the personnel identifier. Combining the collaborative task identifier with the personnel identifier is necessary to ensure that the pushed message accurately points to the specific task instance and prevent message streaming or context loss.

[0088] For example, the system reads the collaborative task identifier "Task_20231024_001" of the current wing assembly task and prepares to combine this identifier with the previously acquired riveting worker identifier to indicate that the following notification is specifically issued for this wing assembly task and not for other parallel tasks.

[0089] Step S403: Using message middleware, generate a data entry notification message based on the collaborative task identifier, the sub-item responsible person identifier for each node, and the node identifier. The system uses the acquired collaborative task identifier, sub-item leader identifier, and corresponding node identifier as message construction parameters, calls the application programming interface of the message middleware, and encapsulates these parameters into a structured reporting notification message. The message middleware, as an independent message bus in the system, is responsible for converting business logic into a standard message protocol format.

[0090] In this embodiment, a message middleware is used to generate a data entry notification message, thereby decoupling business processing from message distribution. The data entry notification message carries not only a collaborative task identifier pointing to a specific task, but also a node identifier pointing to a specific execution step. This makes the message not just a simple reminder, but an instruction carrier containing precise routing information. This middleware-based event-driven mechanism replaces the tedious operation of manually searching for historical emails and forwarding notifications in traditional email, ensuring the timeliness and accuracy of the flow instructions.

[0091] For example, the system uses the RabbitMQ message component to encapsulate the collaborative task identifier "Task_20231024_001", the riveting worker's employee number, and the "skin riveting" node identifier into a JSON format reporting notification message. This message clearly specifies the recipient and the specific location of the pending task.

[0092] Step S404: Push the filling notification message to the message queue identified by the corresponding sub-item leader to trigger the sub-item leader to perform the filling operation.

[0093] The message middleware routes and delivers the message to the dedicated message queue corresponding to the sub-item responsible person carried in the filling notification message. When the sub-item responsible person logs into the enterprise portal website or collaborative management system, the system listens to the message queue and obtains the filling notification message, and then displays the to-do reminder on the front-end interface, thereby triggering the sub-item responsible person to enter the filling operation process.

[0094] Specifically, pushing the reporting notification message to the message queue is the final step in implementing the information-driven mechanism. The message queue has the ability to process asynchronously and smooth out peaks and valleys, ensuring that no matter how high the system concurrency is, the reporting instructions can reliably and quickly reach the client of the person in charge of the sub-project. The person in charge of the sub-project does not need to actively check emails or inquire about progress. They can quickly lock the task and enter the reporting module simply by looking at the to-do link that pops up automatically by the system. This fundamentally solves the problem of omissions and forgettings caused by the inability to remind people of the deadline in long-cycle tasks, and greatly improves the response speed of cross-departmental collaboration.

[0095] For example, RabbitMQ pushes the wing assembly reporting notification message to the riveting worker's message queue. After the riveting worker logs into the system, the system displays the task through a flashing button or pop-up window. The worker clicks the task link and is directly redirected to the reporting interface of the "skin riveting" node to start the reporting operation.

[0096] In the above implementation, an automated flow-driven mechanism based on a step flowchart data structure and message middleware was constructed. By parsing the flowchart data to extract personnel and task identifiers, and using message middleware to generate precise routing notification messages to push to individual queues, this replaces the inefficient mode of traditional manual email forwarding and verbal reminders. It achieves a seamless closed loop between task status changes and personnel action triggering, ensuring that executors can lock onto pending items in complex tasks across multiple scenarios as soon as possible, eliminating omissions and delays in task information, and improving the real-time performance and controllability of cross-departmental collaborative operations.

[0097] Reference Figure 5As one implementation of step S105, the steps of dynamically controlling the reporting permissions of the person in charge of each sub-item corresponding to each node based on the serial-parallel type identifier of each node in the step flowchart, and updating the node status of the corresponding node in the step flowchart according to the reported data object, include: Step S501: In response to the data entry operation on the current node, obtain the data entry object and store the obtained data entry object as temporary data of the current node; The system receives the data entry operation submitted by the person in charge of the sub-item on the client, extracts the data entry data objects such as text content, attachment files and completion rate contained in the operation, and temporarily stores the obtained data entry data objects as temporary data of the current node in the storage layer. At this time, the business status of the data has not been fixed, and subsequent modification and overwriting are allowed.

[0098] Specifically, storing the data objects as temporary data is the basis for achieving dual-state control of "temporary storage" and "data entry completion" in collaborative tasks. This ensures that the phased work results of the sub-project leader will not be lost when the process flow conditions are not fully met, and at the same time, it does not cause substantial flow blockage or submission commitment to downstream nodes, thus achieving decoupling between data storage and process status.

[0099] For example, in the task of assembling an aircraft wing, the person in charge of the sub-project responsible for the frame welding uploaded the welding process record. The system first stores the record as temporary data in the temporary storage area of ​​the current node, waiting for the subsequent process logic to verify and decide whether to solidify it.

[0100] Step S502: Obtain the serial-parallel type identifier of the current node and the node status of all predecessor nodes corresponding to the current node from the data structure of the flowchart. The system retrieves the serial-parallel type identifier of the current node from the generated step flowchart data structure to determine its execution mode. At the same time, it searches backward along the directed edge data to retrieve all predecessor nodes pointing to the current node and reads the current node state of these predecessor nodes as a prerequisite for flow control.

[0101] In this embodiment, obtaining the serial-parallel type identifier is to distinguish whether the current node is handled serially by a single person or collaboratively by multiple people. Obtaining the predecessor node status is to verify whether the current node has been activated and has the logical prerequisites for completion. This data extraction method combines the static topology of the flowchart with the dynamic execution state, providing complete data support for subsequent state machine determination.

[0102] For example, the system finds that the current "skeleton welding" node is identified as parallel in terms of its serial-parallel type, and at the same time finds that the node status of its predecessor node "skin riveting" is completed, thus obtaining the core parameters for determining whether the current node can be completed.

[0103] Step S503: Based on the obtained serial-parallel type identifier of the current node and the node status of all predecessor nodes, determine whether it is allowed to set the node status of the current node to the completed state. If yes, proceed to step S504; otherwise, proceed to step S505. The system performs logical checks based on preset serial-parallel flow rules, combined with the execution mode of the current node and the completion status of the predecessor node, to determine whether the current node has closed-loop conditions. If the predecessor node has incomplete items or the current node is in a parallel state and not all items have been completed, the setting of the completion state is rejected.

[0104] Specifically, this judgment logic is the core of solving the problems of blurred boundaries and chaotic flow in multi-person collaborative tasks. If the current node is serial and all predecessors have completed, it has the conditions for completion. If the current node is parallel, even if all predecessors have completed, only the intermediate state is allowed and the completed state is not allowed before all members in the parallel group have completed. This fundamentally avoids the risk that some people have not completed the task in the parallel process but the overall process has been skipped.

[0105] For example, if the predecessor node "skin riveting" has been completed, but the current "skeleton welding" is a parallel node and only one of the three people has submitted it, the system will make a comprehensive judgment based on the parallel identifier and the predecessor status, and will not allow the node to be set to the completed state, thereby restricting abnormal flow of the process.

[0106] Step S504: Update the node status of the current node to the completed state and mark the temporary data as the final data; Specifically, when the system determines that the current node meets all the prerequisite flow and parallel logic conditions, it changes the node state value of the current node to the completed state, and at the same time promotes the previously stored temporary data to the final data that cannot be arbitrarily overwritten, thus completing the solidification of data and the advancement of state.

[0107] In this embodiment, updating the status to completion and marking temporary data as final data are synchronous atomic operations, ensuring data consistency. Marking the final data means that the current node's data has been recognized by the system and will serve as the data basis for subsequent node transfer and write-back. It also provides an event source for the message middleware to trigger the data filling notification of downstream nodes.

[0108] For example, when all three responsible persons of the "skeleton welding" parallel node have completed the data entry, the system determines that completion is allowed, updates the node status to complete, and solidifies the welding data submitted by the three persons into the final data. Subsequently, the message component is triggered to push the data entry notification to the subsequent inspection nodes.

[0109] Step S505: Update the node status of the current node to a temporary saved state, and ensure that the temporary data can be overwritten by subsequent data entry operations.

[0110] Specifically, when the system determines that the current node does not meet the closed-loop condition because the predecessor node has not been fully completed or the parallel node has not been fully completed, the node status of the current node is set to a temporary saved state, and the read and write attributes of the temporary data are kept open, allowing the sub-project leader to continue to modify or overwrite it later.

[0111] Specifically, this control mechanism, which does not allow completion but allows temporary saving, enables the person in charge of the sub-item to intervene in the form filling before the preceding work is fully completed, which greatly shortens the processing cycle of collaborative tasks. At the same time, by ensuring the effectiveness of the prohibited completion status, the rigor of the process rules is ensured, and the problems of unauthorized closed loops or data transfer before completeness are eliminated are prevented.

[0112] For example, in the "skeleton welding" parallel node, if only one person submits while others do not, the system determines that completion is not allowed and sets the status to temporary. The data of the person in charge is retained as temporary data and can be overwritten and modified by that person later. Although the next node receives the workflow reminder, it can only be temporarily saved and cannot be completed until all members of this parallel node complete the task.

[0113] The above implementation achieves precise and automated control over the complex serial-parallel flow logic in collaborative tasks. By extracting the serial-parallel type identifier of the current node and performing joint verification with the status of the predecessor node, it dynamically intervenes in the transition of the node status from temporary storage to completion. This allows the person in charge of each sub-item to fill in the information in advance in the preliminary stage to shorten the overall cycle. At the same time, it eliminates the chaotic phenomenon of parallel tasks being transferred before they are complete by strictly judging the completion permissions. It solves the problems of unclear task boundaries and uncontrolled flow status under traditional email collaboration, and improves the execution efficiency and data compliance of multi-scenario collaborative tasks.

[0114] In some embodiments of this application, the step of determining whether to allow setting the current node's node state to a completed state based on the obtained serial-parallel type identifier of the current node and the node states of all predecessor nodes includes: If the serial-parallel type identifier of the predecessor node is a serial identifier, and the serial-parallel type identifier of the current node is a serial identifier, then it is determined that after the node state of the predecessor node is updated to the completed state, it is permissible to set the node state of the current node to the completed state. If the serial-parallel type identifier of the predecessor node is serial and the serial-parallel type identifier of the current node is parallel, then after the node status of the predecessor node is updated to the completed state, each sub-item leader in the sub-item leader list corresponding to the current node is given the reporting permission, and after all the node statuses corresponding to the sub-item leaders in the sub-item leader list are updated to the completed state, it is allowed to set the node status of the current node to the completed state. If the serial-parallel type identifier of the predecessor node is parallel, and the serial-parallel type identifier of the current node is serial, then after determining that the node status of any sub-item leader in the sub-item leader list corresponding to the predecessor node is updated to the completed status, the single sub-item leader in the sub-item leader list corresponding to the current node is granted the reporting permission, and after determining that the node status of all sub-item leaders in the sub-item leader list corresponding to the predecessor node is updated to the completed status, the node status of the current node is allowed to be set to the completed status. If the serial-parallel type identifier of the predecessor node is a parallel identifier, and the serial-parallel type identifier of the current node is a parallel identifier, then after determining that the node status corresponding to any sub-item leader in the sub-item leader list corresponding to the predecessor node is updated to the completed status, each sub-item leader in the sub-item leader list corresponding to the current node is granted the reporting permission. After determining that the node status corresponding to all sub-item leaders in both the sub-item leader list of the predecessor node and the sub-item leader list of the current node is updated to the completed status, the node status of the current node is allowed to be set to the completed status.

[0115] Reference Figure 6 As one implementation of step S107, the steps of updating the task status identifier in the collaborative task's data structure to a closed state based on the closing instruction, and archiving the data structure of the step flowchart, include: Step S601: Parse the shutdown command and obtain the identifier of the collaborative task to be shut down; When the system receives a shutdown command triggered by the task assigner, it parses the command to extract the identifier of the collaborative task to be shut down. The collaborative task identifier is a globally unique identifier generated by the system when the task is initiated. It is used to accurately locate the instance and related data of the collaborative task in the storage system and avoid the shutdown operation from mistakenly pointing to other tasks.

[0116] Specifically, obtaining the collaborative task identifier by parsing the shutdown command is a prerequisite for ensuring the security and accuracy of the closed-loop operation of the task. Based on this identifier, the system restricts all subsequent verification and status change operations to a specific data domain to prevent cross-task data interference.

[0117] For example, when the project chief engineer clicks the close task button in the system, the front end sends a close command carrying the unique number of the task. The system parses the number and clarifies that the task to be handled is the wing assembly collaborative task, rather than other tasks carried out in parallel.

[0118] Step S602: Based on the obtained collaborative task identifier, read the data structure of the collaborative task and the data structure of the associated storage flowchart from the storage system; The system uses the acquired collaborative task identifier as an index key to retrieve and read the data structure of the collaborative task from the persistent storage system or caching middleware. At the same time, it reads the data structure of the step flowchart bound to it based on the association relationship. The data structure of the collaborative task carries the task configuration information and macro state, while the data structure of the step flowchart records the micro topology of task execution and the detailed state of each node.

[0119] In this embodiment of the application, reading these two data structures is the basis for performing the shutdown verification, because the shutdown condition of the collaborative task involves not only its macro state, but also the micro execution status of each node inside it. Reading both into memory together facilitates subsequent logical verification and batch status updates, ensuring the real-time performance and consistency of the data during verification.

[0120] For example, based on the collaborative task identifier of the wing assembly task, the system reads the task configuration field and task status identifier of the task from the database, and at the same time reads the associated stored step flowchart data structure containing nodes such as skin riveting and frame welding, to prepare data for subsequent verification of whether all nodes have been filled in.

[0121] Step S603: Obtain the node status data of all nodes from the data structure of the read step flowchart; Step S604: Verify whether the node status of all obtained nodes is in the completed state; if yes, proceed to step S605; if no, determine that the closing condition is not met.

[0122] The system iterates through all task nodes in the data structure of the flowchart, extracts the node status data of each node, and verifies whether these status data all point to the completed state. The verification is only passed when all nodes are in the completed state without exception; otherwise, the closing condition is not met.

[0123] Specifically, this verification logic is the core constraint for forming a clear closed loop in collaborative tasks. It strictly corresponds to the condition that all nodes must be fully reported before a collaborative task can be closed, eliminating the risk of closing the entire task if some nodes are not completed. This ensures the integrity of the deliverables and the rigor of the process, and solves the problem that tasks cannot form a clear closed loop under traditional methods.

[0124] For example, the system iterates through the flowchart of the wing assembly task steps, checks that the skin riveting node status is completed, the frame welding node status is completed, and the final inspection node status is also completed. After confirming that all node statuses are completed, the system determines that the verification is passed. If any step is found to be incomplete, the system refuses to execute and closes the process.

[0125] Step S605: Update the task status identifier in the collaborative task's data structure to the closed state, and generate a closed timestamp to add to the collaborative task's data structure; Once the completion status verification of all nodes is passed, the system changes the task status identifier in the collaborative task's data structure from pending or other intermediate status to closed status. At the same time, it generates a closing timestamp that records the current system time and writes this timestamp as metadata into the collaborative task's data structure, marking the end of the task's lifecycle.

[0126] In this embodiment, updating the task status identifier cuts off the possibility of the task continuing to flow and be filled in at the underlying level, while disabling the addition of timestamps provides a time certificate of the termination node for the full life cycle tracking of the task, which facilitates subsequent statistical calculation and audit review of the task execution cycle.

[0127] For example, the system assigns the task status identifier of the wing assembly task to an enumerated value that is closed, and obtains the current system time to generate a closing timestamp and writes it into the data structure. At this point, the task is officially completed in the system, and all pending reminders are canceled.

[0128] Step S606: Generate an archive identifier, mark the data structure of the step flowchart and the data structure of the collaborative task as immutable archive objects based on the archive identifier, and store the marked immutable archive objects in the archive storage space.

[0129] The system generates a unique archive identifier, packages the data structure of the collaborative task and the data structure of the step flowchart, and marks them as immutable archive objects. Immutable archive objects mean that the data is in a read-only state and cannot be tampered with by any subsequent operations. The marked data is then transferred to an archive storage space specifically for long-term preservation.

[0130] Specifically, the archiving process enables transparent traceability and long-term retention of process data. It ensures the originality and non-repudiation of archived data through immutable tags, and solves the problems of task information not being shared and synchronized in real time, process data being easily lost and version confusion under the traditional email method. It also supports subsequent multi-dimensional statistics of tasks and reuse of experience.

[0131] For example, the system generates an archive number for the wing assembly task, packages all the data entry records, attachment metadata, and flow diagrams for the task into an unmodifiable archive object, and stores it in the historical archive library. If it is necessary to review the time consumption and handover of the wing assembly later, read-only data can be retrieved directly from the archive space for analysis.

[0132] The above implementation achieves closed-loop management of the entire lifecycle of collaborative tasks from initiation to closure. Rigorous node status verification eliminates the loophole of closing tasks before completion. Status updates and timestamps solidify the task's termination node. Immutable archiving ensures the integrity and traceability of process data. It solves the problems of tasks not being able to close the loop, data being easily lost, and subsequent statistics not being possible in traditional collaborative methods, thereby improving the compliance of enterprise-level project management and the value of data assets.

[0133] As a further implementation of this application, in response to the approval instruction when the flowchart is in any node state, an approval data structure is generated and stored on the specified task node in the flowchart; and the approval content in the approval data structure is pushed to the sub-item manager corresponding to the specified task node.

[0134] During the execution of collaborative tasks, the task assigner needs to track and monitor the information filled in by the sub-item responsible persons. When an error is found or guidance is needed, an instruction is triggered. The system responds to the instruction by generating and persistently storing an instruction data structure containing the instruction in the data structure of the specified task node. Then, based on the sub-item responsible person's identifier bound to the node, the instruction content is accurately pushed to the corresponding personnel.

[0135] In the above implementation, by generating and storing the approval data structure at the designated nodes of the flowchart, a strong binding between process guidance and specific task nodes is achieved, ensuring that the approval opinions do not deviate from the business context. At the same time, the message push mechanism is used to remind the sub-item leaders in real time, so that they can obtain the correct processing direction as soon as possible, avoid potential risks and errors in filling, effectively improve the first-time processing completion rate and shorten the task processing cycle, and avoid deviation from the work.

[0136] As a further implementation of this application, in response to a return instruction when the task status is marked as pending data entry, the node identifier of the problem node specified by the return instruction is obtained; the node status corresponding to the problem node in the data structure of the step flowchart is reset to pending data entry; the data objects generated in all subsequent nodes after the problem node in the step flowchart are serialized and stored in the cache; when the node status corresponding to the problem node is updated to the data entry completed status, the stored data objects are read from the cache and deserialized, and written back to the corresponding subsequent node so that the sub-item responsible person of the subsequent node can continue to edit them.

[0137] When a node that has already been processed needs to be reprocessed due to an error, the system obtains the identifier of the problematic node from the rollback instruction and rolls back the status of the node to the pending state to allow re-entry. At the same time, in order to prevent the loss or invalidation of data in subsequent nodes, the data objects of subsequent nodes are serialized and cached. When the problematic node is corrected and processed again, the cached data is deserialized and written back to the subsequent nodes.

[0138] In the above implementation, this rollback and write-back mechanism fundamentally solves the problem of all subsequent work being rendered useless due to errors in preceding nodes in the traditional model. It protects the effective work results of subsequent nodes through serialization caching and automatically restores the site after the preceding problem is resolved. The person in charge of the sub-item can continue to edit based on the write-back content, which improves the efficiency of data entry and the fault tolerance of the system.

[0139] As a further implementation of this application, in response to a re-division instruction when the task status identifier is in the pending state, re-division configuration data is obtained, and the data structure of the step flowchart is updated according to the re-division configuration data; the task status identifier is reset to the pending decomposition state to re-trigger the decomposition operation.

[0140] When business changes occur during task execution, the main person in charge triggers a re-decomposition instruction. The system obtains re-decomposition configuration data containing new node attributes, serial-parallel relationships, and personnel correspondences. Based on this, the data structure of the step flowchart is reconstructed, and the task status is rolled back to the pending decomposition state, so that the system re-executes the initialization of the flow logic according to the new decomposition configuration.

[0141] In the above implementation, the solution provides the ability to flexibly orchestrate collaborative task processes. By reconfiguring the data structure of the underlying step flowchart directly, it ensures that the task flow topology can be dynamically adjusted according to business needs. The rollback of status indicators and the re-triggering of decomposition operations ensure the re-adaptation of serial and parallel permission control and message push logic under the new process, thus meeting the flexible change requirements in complex collaborative scenarios.

[0142] As a further implementation of this application, in response to a query request, the task status identifier in the data structure of the collaborative task is obtained, and monitoring data for visually displaying the execution progress of the collaborative task is generated and output according to the data structure of the step flowchart.

[0143] Upon receiving a query request, the system extracts macroscopic task status identifiers from the collaborative task's data structure and deeply analyzes the data structure of the step flowchart. It then maps the serial / parallel attributes, completion status, and flow path of each node into front-end renderable visual monitoring data and outputs it.

[0144] In the above implementation, by transforming the underlying graph data structure into a visualized step flowchart monitoring data, the execution progress of the collaborative task throughout its entire lifecycle becomes transparent and traceable. Managers can clearly and explicitly grasp the execution status of each step, thereby enabling them to promptly identify potential overdue risk factors and proactively make adjustments and interventions. This avoids the serious consequences of passive overdue processes for enterprises and meets the stringent requirements of high-end equipment intelligent manufacturing for transparent process control.

[0145] This application also discloses a multi-scenario task string parallel visualization collaborative management system.

[0146] A multi-scenario task serial parallel visualization collaborative management system, specifically including: The collaborative task initiation module is used to respond to task assignment instructions, define the data structure of collaborative tasks that include task configuration information and task status identifiers, and set the task status identifiers to the state of pending decomposition. The collaborative task decomposition module is used to respond to the decomposition operation triggered when the task status is marked as pending decomposition and obtain decomposition configuration information. The decomposition configuration information includes the node attributes of multiple task nodes, the serial / parallel type identifier of each node, and the correspondence between each node and the person in charge of the sub-item. The step flow generation module is used to generate and configure the data structure of the step flow diagram based on the decomposed configuration information, and update the task status identifier to the pending data entry status. The collaborative task reporting module is used to respond to the reporting operations of each sub-item leader when the task status is marked as pending reporting, and to obtain the reporting data objects of each node. The data entry permission control module is used to dynamically control the data entry permissions of the person in charge of each sub-item at each node based on the serial-parallel type identifier of each node in the step flowchart, and update the node status of the corresponding node in the step flowchart according to the data entry object. The task closure trigger module is used to obtain a closure command when the node status of all nodes in the step flowchart is updated to the completed state and the closure trigger condition is met. The collaborative task closure module is used to update the task status identifier in the collaborative task's data structure to the closed state based on the closure command, and to archive the data structure of the step flowchart.

[0147] The multi-scenario task serial parallel visualization collaborative management system of this application embodiment can implement any of the above methods, and the specific working process of each module in the system can refer to the corresponding process in the above method embodiment.

[0148] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0149] This application also discloses a computer device.

[0150] Computer equipment, including memory, processor, and computer program stored in memory and executable on the processor, wherein the processor executes the computer program to implement a multi-scenario task string parallel visualization collaborative management method as described above.

[0151] This application also discloses a computer-readable storage medium.

[0152] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above in any of the methods of a multi-scenario task string parallel visualization collaborative management method.

[0153] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0154] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for parallel, visual, and collaborative management of multi-scenario task strings, characterized in that, The method includes: In response to a task assignment instruction, a data structure for a collaborative task is defined, which includes task configuration information and a task status identifier, and the task status identifier is set to a state to be decomposed. In response to the decomposition operation triggered when the task status is identified as pending decomposition, decomposition configuration information is obtained; wherein, the decomposition configuration information includes the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of the sub-item. The data structure for generating and configuring the step flowchart based on the decomposed configuration information is then updated to the pending data entry status. In response to the reporting operation of each sub-item responsible person when the task status is marked as pending, the reporting data object of each node is obtained; Based on the serial-parallel type identifier of each node in the flowchart, the reporting permissions of the person in charge of each sub-item are dynamically controlled, and the node status of the corresponding node in the flowchart is updated according to the reported data object. In response to the fact that the node status of all nodes in the flowchart of the steps is updated to the completed state and the closing trigger condition is met, a closing instruction is obtained; Based on the closing instruction, the task status identifier in the data structure of the collaborative task is updated to the closed state, and the data structure of the step flowchart is archived.

2. The multi-scenario task serial parallel visualization collaborative management method according to claim 1, characterized in that, The steps of defining a data structure for a collaborative task that includes task configuration information and a task status identifier in response to a task assignment instruction, and setting the task status identifier to a state to be decomposed, include: Parse the task deployment instruction to obtain task configuration information; Generate a globally unique collaborative task identifier, and initialize the data structure of the collaborative task based on the collaborative task identifier; wherein, the data structure includes a task configuration field and a task status identifier; Write the task configuration information into the task configuration field, and set the task status identifier to the pending decomposition state.

3. The multi-scenario task serial parallel visual collaborative management method according to claim 2, characterized in that, The task assignment instruction also includes attachment files and attachment permission configuration data. The attachment permission configuration data is used to control the preview and editing permissions of the attachment files when the person in charge of the sub-item performs the filling operation.

4. The multi-scenario task serial parallel visual collaborative management method according to claim 1, characterized in that, The steps of generating and configuring the flowchart data structure based on the decomposed configuration information, and updating the task status identifier to the pending data entry status, include: Parse the decomposed configuration information to obtain the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of each sub-item; Based on the obtained node attributes, serial-parallel type identifiers and corresponding relationships, the data structure of the step flowchart is generated; wherein, the data structure of the step flowchart includes node identifiers of multiple task nodes, sequential number of each node, serial-parallel type identifier of each node, sub-item responsible person identifier corresponding to each node, and directed edge data used to characterize the flow logic between each node. The data structure of the flowchart of the steps is associated and stored with the data structure of the collaborative task; Update the task status identifier in the data structure of the collaborative task from the state to be decomposed to the state to be filled in.

5. The multi-scenario task serial parallel visualization collaborative management method according to claim 4, characterized in that, After updating the task status identifier in the data structure of the collaborative task from the state to be decomposed to the state to be filled, the method further includes: Based on the data structure of the stored flowchart of the steps, obtain the sub-item responsible person identifier corresponding to each node; Obtain the collaborative task identifier from the data structure of the collaborative task; Using a message middleware, a reporting notification message is generated based on the collaborative task identifier, the sub-item leader identifier corresponding to each node, and the node identifier; The notification message is pushed to the message queue of the corresponding sub-item manager to trigger the sub-item manager to perform the data entry operation.

6. The multi-scenario task serial parallel visualization collaborative management method according to claim 4, characterized in that, The steps of dynamically controlling the reporting permissions of the person in charge of each sub-item corresponding to each node based on the serial / parallel type identifier of each node in the flowchart, and updating the node status of the corresponding node in the flowchart according to the reported data object, include: In response to the data entry operation of the current node, the data entry object is obtained and stored as temporary data of the current node; From the data structure of the flowchart, obtain the serial-parallel type identifier of the current node, and obtain the node status of all predecessor nodes corresponding to the current node; Based on the obtained serial-parallel type identifier of the current node and the node status of all predecessor nodes, determine whether it is allowed to set the node status of the current node to the completed state. If so, update the node status of the current node to the completed state and mark the temporary data as final data; If not, the node status of the current node is updated to a temporary saved state, and the temporary data is allowed to be overwritten by subsequent data entry operations.

7. A multi-scenario task serial parallel visualization collaborative management method according to any one of claims 1 to 6, characterized in that, The steps of updating the task status identifier in the data structure of the collaborative task to the closed state based on the closed instruction, and archiving the data structure of the flowchart, include: Parse the shutdown command to obtain the identifier of the collaborative task to be shut down; Based on the acquired collaborative task identifier, the data structure of the collaborative task and the data structure of the associated storage step flowchart are read from the storage system; Obtain the node status data of all nodes from the data structure of the read flowchart, and verify that the node status of all nodes is complete. If the verification passes, the task status identifier in the data structure of the collaborative task will be updated to the closed state, and a closed timestamp will be generated and added to the data structure of the collaborative task. Generate an archive identifier, and based on the archive identifier, mark the data structure of the step flowchart and the data structure of the collaborative task as immutable archive objects, and store the marked immutable archive objects in the archive storage space.

8. A multi-scenario task serial parallel visual collaborative management system, characterized in that, The system includes: The collaborative task initiation module is used to respond to the task deployment instruction, define the data structure of the collaborative task containing task configuration information and task status identifier, and set the task status identifier to a state to be decomposed. The collaborative task decomposition module is used to respond to the decomposition operation triggered when the task status is identified as pending decomposition, and to obtain decomposition configuration information; wherein, the decomposition configuration information includes the node attributes of multiple task nodes, the serial-parallel type identifier of each node, and the correspondence between each node and the person in charge of the sub-item. The step flow generation module is used to generate and configure the data structure of the step flow diagram based on the decomposed configuration information, and update the task status identifier to the pending state. The collaborative task reporting module responds to the reporting operations of each sub-item leader when the task status is marked as pending reporting, and obtains the reporting data objects of each node. The data entry permission control module is used to dynamically control the data entry permission of the person in charge of each sub-item corresponding to each node based on the serial-parallel type identifier of each node in the step flowchart, and update the node status of the corresponding node in the step flowchart according to the data entry object. The task closure trigger module is used to obtain a closure command in response to the fact that the node status of all nodes in the process flowchart is updated to the completed state and the closure trigger condition is met. The collaborative task closing module is used to update the task status identifier in the collaborative task's data structure to a closed state based on the closing instruction, and to archive the data structure of the step flowchart.

9. A computer device, characterized in that: The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 7.

Images