Department-province collaborative data processing method based on Flowable engine

Abstract

The invention particularly relates to a Department and Province collaborative data processing method based on a Flowable engine. The method comprises the following steps: receiving a task construction order, assigning roles according to authority, and pushing notifications; data is extracted according to a multi-dimensional rule, a template generation instruction is loaded, and online debugging can be carried out; performing automatic pre-check and manual re-check, and determining the process trend according to the result; a protocol issuing instruction is converted, the state is tracked in real time, and a timeout mechanism is set; and analyzing a returned result, verifying compliance, encrypting and archiving, and if the result is abnormal, creating a sub-work order for manual processing. According to the Department collaborative data processing method based on the Flowable engine, full-link automatic management is achieved, the equipment adaptation problem is solved, the interaction efficiency is guaranteed, the overall efficiency and quality of Department data interaction are remarkably improved, and the method has wide industry application prospects and extremely high popularization value.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for collaborative data processing between ministries and provinces based on the Flowable engine. Background Technology

[0002] In the field of data exchange with ministries and provinces, current technologies face many core challenges that urgently need to be addressed:

[0003] First, the process is fragmented. Key steps such as receiving tasks from ministries and provinces, processing work orders, and issuing equipment instructions lack the support of a unified process engine, relying excessively on manual operations for coordination, which makes it difficult to control task progress. If there is a break in the data verification process between ministries and provinces, it will directly cause a significant increase in task time, up to 40%.

[0004] Secondly, there is the challenge of adapting to devices from multiple vendors. Given the significant differences in instruction formats between devices from different vendors (such as Huawei, ZTE, and Ericsson), including variations in CLI instruction syntax and parameter order, the traditional hard-coding approach necessitates developing separate adaptation modules for each device. This not only results in high maintenance costs but also greatly increases the risk of errors.

[0005] Third, the interface collaboration efficiency is low. The provincial and ministerial interfaces and the Equipment Management Interface (OMC) operate independently, failing to establish a standardized interaction mechanism. In daily operation, situations frequently arise where commands are successfully issued but feedback is delayed, or there are format compatibility issues, severely affecting the smoothness and timeliness of data interaction.

[0006] Fourth, personnel collaboration falls into disarray. The allocation of tasks between processors and reviewers relies primarily on manual designation, lacking a scientifically sound and automated allocation mechanism. This approach easily leads to frequent task backlogs or unreasonable situations such as misaligned permissions. If reviewers fail to fulfill their responsibilities in a timely manner, work orders will be delayed beyond their time limit, severely slowing down the overall work progress.

[0007] In summary, existing solutions have failed to construct a complete solution system centered on a process engine, thus making it difficult to fully meet the stringent requirements of efficiency, standardization, and traceability for data exchange between ministries and provinces. Although some units have begun to introduce process management tools to optimize data production processes, these tools are limited by their functionalities and cannot fully meet the complex characteristics of data production at the ministry-province interface, making it difficult to achieve full automation and standardization of the data production process.

[0008] Based on the above, this invention proposes a method for collaborative data processing between ministries and provinces based on the Flowable engine. Summary of the Invention

[0009] To overcome the shortcomings of existing technologies, this invention provides a simple and efficient method for collaborative data processing between ministries and provinces based on the Flowable engine.

[0010] This invention is achieved through the following technical solution:

[0011] A method for collaborative data processing between ministries and provinces based on the Flowable engine includes the following steps:

[0012] Step S1: Access to Ministry / Province Tasks and Initialization of Work Orders

[0013] Step S1.1, Interface Connection

[0014] Establish a data exchange channel between the Ministry and the provinces via a RESTful API to receive task packages containing the Ministry and provincial task IDs, data standards, equipment manufacturer lists, and processing time limits.

[0015] Step S1.2: Work Order Creation

[0016] After receiving the task parameters, a corresponding work order instance is created in the Flowable engine, bound to the department / province task ID, a unique work order number associated with the department / province task ID is generated synchronously, and the preset BPMN2.0 process template is activated.

[0017] Step S1.3, Role Assignment

[0018] Based on the role-permission mapping relationship in the organization's permission configuration library, the system intelligently matches the combination of handler and approver according to the task type, supporting both single-person independent processing and single-person processing paired with two people.

[0019] Step S1.4, Notification Push

[0020] Using the RabbitMQ message middleware, notification information containing a work order link is sent to the relevant handler via SMS, email, or in-site message;

[0021] Step S2: Multi-dimensional data audit and instruction generation

[0022] Step S2.1, Standard Extraction

[0023] The handler extracts the audit rules through the front-end work order interface, including:

[0024] Basic validation rules include standard field length, data format, and value range.

[0025] Business logic rules include data correlation, timing constraints, and vendor-defined specifications.

[0026] Device adaptation rules: including instruction parameter mapping table and execution end character matching rules;

[0027] Step S2.2, Template Loading

[0028] Based on the equipment manufacturer identifier in the work order, the corresponding instruction template is dynamically loaded from the built-in multi-vendor equipment instruction configuration library;

[0029] Step S2.3, Smart Fill

[0030] The template engine is used to inject audit data that conforms to the audit rules into the instruction template, generate device-specific instructions, and synchronize the associated work order version number for traceability.

[0031] Step S2.4, Online Debugging

[0032] It provides a visual editing environment for users to adjust instructions in real time to ensure they meet actual needs;

[0033] Step S3: Hierarchical Instruction Audit and Process Control

[0034] Step S3.1, Automated Pre-inspection

[0035] Use a regular expression engine to verify the compliance of command syntax;

[0036] Verify the completeness of required fields based on the parameter mapping table;

[0037] In step S3.1, an OMC interface simulator is introduced to perform pre-execution testing and conduct preliminary risk screening.

[0038] Step S3.2, Manual review

[0039] The auditor obtains the audit instructions from the Flowable task node and views the original text of the instructions, the audit rule matching results, and the device adaptation suggestions.

[0040] If the reviewer approves, the instruction issuance stage begins;

[0041] If the reviewer rejects the application, it will be returned to the designated stage with suggested modifications.

[0042] In step S3.2, the Flowable engine intelligently executes process branch decisions based on the review results;

[0043] If the reviewer approves, the process proceeds directly to the instruction issuance and execution node.

[0044] If the instruction is rejected, the rollback logic is triggered, and the work order is automatically and accurately rolled back to the nearest editable node according to preset rules.

[0045] In step S3.2, if the instruction is rejected, the rollback logic is triggered, and the work order is automatically rolled back to the initial stage of instruction generation or the key stage of data auditing according to preset rules.

[0046] Step S4: Issuance of commands and status tracking for multiple vendor devices

[0047] Step S4.1, Protocol Conversion

[0048] By loading the manufacturer's dedicated OMC interface through the OMC interface gateway, standardized commands are converted into a specified format that the device can recognize, thereby realizing protocol conversion and secure invocation of device commands;

[0049] Step S4.2, Execution Tracing

[0050] Start an independent execution status monitoring thread to determine the instruction execution status in real time based on the execution end markers pre-defined in the instruction configuration library of multiple vendors' devices;

[0051] In step S4.2, the multi-vendor device instruction configuration library stores instruction templates, parameter mapping relationships, execution end symbols, and OMC interface parameters for each vendor's devices;

[0052] Execution termination markers include, but are not limited to, specific strings, status codes, and heartbeat signals.

[0053] Step S4.3, Timeout Management

[0054] Configure a multi-level timeout mechanism. When a timeout event occurs, the corresponding mechanism will be automatically triggered to generate an exception work order and notify the operations and maintenance supervisor for intervention, effectively avoiding disorderly backlog and delays of tasks.

[0055] In step S4.3, the multi-level timeout mechanism is 5 minutes for the first-level warning duration, 10 minutes for the second-level warning duration, and 15 minutes for the forced termination duration.

[0056] Step S5: Result Processing and Closed-Loop Archiving

[0057] Step S5.1, Data Analysis

[0058] After the device execution result is returned via the OMC interface, the returned result is disassembled according to the manufacturer's protocol standard, and the result data is standardized and parsed according to the specific requirements of the manufacturer's protocol to extract core metadata;

[0059] Step S5.2, Compliance Verification

[0060] The parsed data is compared with the audit standards preset in the work order to verify its compliance.

[0061] After the reviewer confirms that the results are correct, the entire process data of the work order is fully encrypted and compressed, and stored in a distributed storage system according to the rule of "Ministry and Province Task ID + Timestamp". The work order status is updated synchronously through the Ministry and Province callback interface, and result summary information is attached to achieve a complete closed loop of data interaction.

[0062] If any abnormal situation occurs, the exception handling process will be triggered, the corresponding exception handling sub-work order will be automatically created, and relevant personnel will be notified in a timely manner to handle the situation manually, so as to ensure the rigor of the entire process and the reliability of the data.

[0063] A ministerial-provincial collaborative data processing system based on the Flowable engine, used to implement the above method, includes:

[0064] Ministry-Province Interaction Layer: Includes task receiving interface and result feedback interface, responsible for implementing task access and result feedback through standardized interfaces, and supports multi-protocol adaptation;

[0065] The Flowable engine core layer includes a process definition repository, a dynamic task scheduler, a process instance manager, and a historical process tracer, which are responsible for managing process definitions, instance lifecycles, and historical traceability.

[0066] Business processing layer: includes work order instance generator and process node controller, responsible for the creation, management and monitoring of process node status of work orders;

[0067] Multi-vendor device adaptation platform: including command configuration center and OMC interface gateway. The command configuration center is used to manage device command templates and version control, and the OMC interface gateway is used to realize command protocol conversion and secure invocation.

[0068] Support layer: Includes data storage layer, organization permission configuration library and monitoring management module, responsible for providing basic services, including organization permissions, data storage and monitoring management;

[0069] Data storage layer: includes the main database and historical archive repository;

[0070] The main database includes an organization permission configuration library and a multi-vendor device instruction configuration library, which are used to store work order instances, process logs and device configuration data.

[0071] The historical archive is used to store data on completed work orders;

[0072] Monitoring and management module: includes process dashboard and operation audit log, used to display work order progress and record user operations in real time.

[0073] A departmental-provincial collaborative data processing device based on the Flowable engine includes a memory and a processor; the memory is used to store a computer program, and the processor is used to execute the computer program to implement the above-described method steps.

[0074] A readable storage medium storing a computer program that, when executed by a processor, implements the above-described method steps.

[0075] The beneficial effects of this invention are: the Flowable engine-based method for collaborative data processing between ministries and provinces realizes full-link automated management, solves the problem of device compatibility, ensures interaction efficiency, significantly improves the overall efficiency and quality of data interaction between ministries and provinces, and has broad industry application prospects and extremely high promotion value. Attached Figure Description

[0076] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0077] Figure 1 This is a schematic diagram of the departmental-provincial collaborative data processing system architecture based on the Flowable engine of this invention.

[0078] Figure 2 This is a schematic diagram of the work order processing flow of the present invention. Detailed Implementation

[0079] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions in the embodiments of this invention will be clearly and completely described below in conjunction with the embodiments of this invention. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0080] This ministerial-provincial collaborative data processing method based on the Flowable engine includes the following steps:

[0081] Step S1: Access to Ministry / Province Tasks and Initialization of Work Orders

[0082] Step S1.1, Interface Connection

[0083] Establish a data exchange channel between the Ministry and the provinces via a RESTful API to receive task packages containing the Ministry and provincial task IDs, data standards, equipment manufacturer lists, and processing time limits.

[0084] Step S1.2: Work Order Creation

[0085] After receiving the task parameters, a corresponding work order instance is created in the Flowable engine, bound to the department / province task ID, a unique work order number associated with the department / province task ID is generated synchronously, and the preset BPMN2.0 process template is activated.

[0086] Step S1.3, Role Assignment

[0087] Based on the role-permission mapping relationship in the organization's permission configuration library (such as "data processing position → instruction generation right" and "quality auditing position → result verification right"), the system intelligently matches the processing personnel and the auditing personnel according to the task type, supporting both independent processing by one person and processing by one person paired with two people.

[0088] Step S1.4, Notification Push

[0089] By using the RabbitMQ message middleware, notification information containing a work order link can be sent to relevant personnel via SMS, email, or in-system message to ensure that relevant personnel can obtain task information as soon as possible and start work in a timely manner.

[0090] Step S2: Multi-dimensional data audit and instruction generation

[0091] Step S2.1, Standard Extraction

[0092] The handler extracts the audit rules through the front-end work order interface, including:

[0093] Basic validation rules include standard field length, data format, and value range.

[0094] Business logic rules include data correlation, timing constraints, and vendor-defined specifications.

[0095] Device adaptation rules: including instruction parameter mapping table and execution end character matching rules;

[0096] Step S2.2, Template Loading

[0097] Based on the equipment vendor identifier (such as Huawei / ZTE) in the work order, the corresponding instruction template is dynamically loaded from the built-in multi-vendor equipment instruction configuration library;

[0098] Step S2.3, Smart Fill

[0099] The template engine is used to inject audit data that conforms to the audit rules into the instruction template, generate device-specific instructions, and synchronize the associated work order version number for traceability.

[0100] Step S2.4, Online Debugging

[0101] It provides a visual editing environment for users to adjust instructions in real time to ensure they meet actual needs;

[0102] Step S3: Hierarchical Instruction Audit and Process Control

[0103] The instruction audit process employs a dual-checking mechanism combining automatic verification and manual review to comprehensively ensure the accuracy and compliance of instructions.

[0104] Step S3.1, Automated Pre-inspection

[0105] Leveraging the efficiency of the regular expression engine, we can quickly verify the compliance of command syntax.

[0106] Verify the completeness of required fields based on the parameter mapping table;

[0107] In step S3.1, an OMC interface simulator is introduced to perform pre-execution testing and conduct preliminary risk screening, so as to discover and resolve potential problems as early as possible before the instructions are issued.

[0108] Step S3.2, Manual review

[0109] The auditor obtains the audit instructions from the Flowable task node and views the original text of the instructions, the audit rule matching results, and the device adaptation suggestions.

[0110] If the reviewer approves, the instruction issuance stage begins;

[0111] If the reviewer rejects the application, it will be returned to the designated stage with suggested modifications.

[0112] In step S3.2, the Flowable engine intelligently executes process branch decisions based on the review results;

[0113] If the reviewer approves, the process proceeds directly to the instruction issuance and execution node.

[0114] If the instruction is rejected, the rollback logic is triggered, and the work order is automatically and accurately rolled back to the nearest editable node according to preset rules, ensuring that the problem can be corrected in a timely and effective manner.

[0115] In step S3.2, if the instruction is rejected, the rollback logic is triggered, and the work order is automatically rolled back to the initial stage of instruction generation or the key stage of data auditing according to preset rules.

[0116] Step S4: Issuance of commands and status tracking for multiple vendor devices

[0117] Step S4.1, Protocol Conversion

[0118] By loading vendor-specific OMC interfaces (such as Huawei's Netconf interface, ZTE's SNMP interface, etc.) through the OMC interface gateway, standardized commands are converted into specified formats (such as XML / JSON / binary stream formats) that the device can recognize, thereby realizing protocol conversion and secure invocation of device commands to ensure that commands can be accurately received and executed by the device.

[0119] The OMC interface gateway supports dynamically loading vendor-specific OMC interface adapters and integrates security mechanisms such as OAuth2.0 authentication, HTTPS encrypted transmission, and request frequency limiting.

[0120] Step S4.2, Execution Tracing

[0121] Start an independent execution status monitoring thread to determine the instruction execution status in real time and accurately based on the execution end markers pre-set in the instruction configuration library of multiple vendors' devices;

[0122] In step S4.2, the multi-vendor device instruction configuration library stores instruction templates, parameter mapping relationships, execution end symbols, and OMC interface parameters for each vendor's devices;

[0123] Execution termination markers include, but are not limited to, specific strings, status codes, and heartbeat signals.

[0124] Step S4.3, Timeout Management

[0125] Configure a multi-level timeout mechanism. When a timeout event occurs, the corresponding mechanism will be automatically triggered to generate an exception work order and notify the operations and maintenance supervisor for intervention, effectively avoiding disorderly backlog and delays of tasks.

[0126] In step S4.3, the multi-level timeout mechanism is 5 minutes for the first-level warning duration, 10 minutes for the second-level warning duration, and 15 minutes for the forced termination duration.

[0127] Step S5: Result Processing and Closed-Loop Archiving

[0128] Step S5.1, Data Analysis

[0129] After the device execution result is returned via the OMC interface, the returned result is disassembled according to the manufacturer's protocol standard, and the result data is standardized and parsed according to the specific requirements of the manufacturer's protocol to extract core metadata;

[0130] Step S5.2, Compliance Verification

[0131] The parsed data is compared with the audit standards preset in the work order to verify its compliance.

[0132] After the reviewer confirms that the results are correct, the entire process data of the work order (including detailed operation logs, instruction version information, interaction records, etc.) is fully encrypted and compressed, and stored in a distributed storage system (such as HDFS distributed storage) according to the rule of "Ministry and Province Task ID + Timestamp". The work order status is updated synchronously through the Ministry and Province callback interface, and result summary information is attached to achieve a complete closed loop of data interaction.

[0133] If any abnormal situation occurs, the exception handling process will be triggered, the corresponding exception handling sub-work order will be automatically created, and relevant personnel will be notified in a timely manner to handle the situation manually, so as to ensure the rigor of the entire process and the reliability of the data.

[0134] Appendix Figure 2 The document describes the work order processing workflow and interaction process.

[0135] Main workflow: Task access → Work order creation → Personnel allocation → Instruction generation → Multi-level audit → Equipment interaction → Result processing → Feedback archiving.

[0136] Branch control: The process branches (pass / reject / abnormal) for instruction verification and result review are implemented through diamond-shaped decision nodes.

[0137] Support services: The organization permission library provides the basis for personnel allocation, the instruction configuration library supports multi-vendor device adaptation, and the monitoring system tracks the process status throughout the entire process.

[0138] This ministerial-provincial collaborative data processing system, based on the Flowable engine, is used to implement the above methods, including:

[0139] Ministry-Province Interaction Layer: Includes task receiving interface and result feedback interface, responsible for implementing task access and result feedback through standardized interfaces, and supports multi-protocol adaptation;

[0140] The Flowable engine core layer includes a process definition repository, a dynamic task scheduler, a process instance manager, and a historical process tracer, which are responsible for managing process definitions, instance lifecycles, and historical traceability.

[0141] The dynamic task scheduler supports allocating pending tasks according to strategies such as worker load, task priority, and geographic affiliation.

[0142] Business processing layer: includes work order instance generator and process node controller, responsible for the creation, management and monitoring of process node status of work orders;

[0143] Multi-vendor device adaptation platform: including command configuration center and OMC interface gateway. The command configuration center is used to manage device command templates and version control, and the OMC interface gateway is used to realize command protocol conversion and secure invocation.

[0144] The template management module of the instruction configuration center supports visual editing of device instruction templates, configuration of parameter mapping relationships, execution end marks, and OMC interface parameters.

[0145] Support layer: Includes data storage layer, organization permission configuration library and monitoring management module, responsible for providing basic services, including organization permissions, data storage and monitoring management;

[0146] Data storage layer: includes the main database and historical archive repository;

[0147] The main database includes an organization permission configuration library and a multi-vendor device instruction configuration library, which are used to store work order instances, process logs and device configuration data.

[0148] The historical archive is used to store data on completed work orders;

[0149] Monitoring and management module: includes process dashboard and operation audit log, used to display work order progress and record user operations in real time.

[0150] The Flowable engine-based inter-ministerial collaborative data processing device includes a memory and a processor; the memory is used to store computer programs, and the processor is used to execute the computer programs to implement the above-described method steps.

[0151] The readable storage medium stores a computer program that, when executed by a processor, implements the above-described method steps.

[0152] Compared with existing technologies, this ministerial-provincial collaborative data processing method based on the Flowable engine has the following characteristics:

[0153] Firstly, leveraging the powerful capabilities of the Flowable engine, a highly efficient and intelligent data processing workflow system for collaboration between the ministry and provinces has been successfully established. This workflow comprehensively covers all aspects, from the initial access of ministry and provincial tasks to the detailed processing of work orders, the precise execution of instructions, and the timely feedback of final results. It achieves automated and standardized management of the entire process, greatly improving overall work efficiency and reducing the risk of human error.

[0154] Secondly, for the complex scenario of multiple vendor devices, an innovative strategy of pre-configuring instruction templates and execution termination symbols is adopted, cleverly overcoming the challenge of device instruction adaptation. This ingenious design effectively ensures that instructions can be executed accurately across devices from different vendors, achieving efficient collaborative work across different vendors.

[0155] Third, the introduction of standardized OMC interfaces and a ministerial-provincial interface calling mechanism fully guarantees the efficiency of command execution and the timeliness and accuracy of result feedback from a technical perspective. This innovative measure effectively avoids problems such as data interaction delays and information loss caused by interface incompatibility in the past, laying a solid foundation for smooth data interaction between the ministry and provinces.

[0156] Fourth, the system incorporates scientifically sound personnel allocation and notification functions, coupled with a rigorous review mechanism, to comprehensively ensure the standardization and reliability of the data processing process. From task allocation to execution supervision and result review, each step is interconnected and orderly, effectively preventing task backlog and permission misalignment, and ensuring the quality and efficiency of data processing.

[0157] Based on the above advantages, this invention can significantly improve the overall efficiency and quality of data interaction between ministries and provinces, has broad industry application prospects and extremely high promotional value, and is expected to bring about a profound change in the field of collaborative data processing between ministries and provinces, helping relevant organizations achieve the goals of efficient, standardized and intelligent data interaction.

[0158] The embodiments described above are merely one specific implementation of the present invention. Ordinary changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for collaborative data processing between ministries and provinces based on the Flowable engine, characterized in that: Includes the following steps: Step S1: Access to Ministry / Province Tasks and Initialization of Work Orders Step S1.1, Interface Connection Establish a data exchange channel between the Ministry and the provinces via a RESTful API to receive task packages containing the Ministry and provincial task IDs, data standards, equipment manufacturer lists, and processing time limits. Step S1.2: Work Order Creation After receiving the task parameters, a corresponding work order instance is created in the Flowable engine, bound to the department / province task ID, a unique work order number associated with the department / province task ID is generated synchronously, and the preset BPMN2.0 process template is activated. Step S1.3, Role Assignment Based on the role-permission mapping relationship in the organization's permission configuration library, the system intelligently matches the combination of handler and approver according to the task type, supporting both single-person independent processing and single-person processing paired with two people. Step S1.4, Notification Push Using the RabbitMQ message middleware, notification information containing a work order link is sent to the relevant handler via SMS, email, or in-site message; Step S2: Multi-dimensional data audit and instruction generation Step S2.1, Standard Extraction The handler extracts the audit rules through the front-end work order interface, including: Basic validation rules include standard field length, data format, and value range. Business logic rules include data correlation, timing constraints, and vendor-defined specifications. Device adaptation rules: including instruction parameter mapping table and execution end character matching rules; Step S2.2, Template Loading Based on the equipment manufacturer identifier in the work order, the corresponding instruction template is dynamically loaded from the built-in multi-vendor equipment instruction configuration library; Step S2.3, Smart Fill The template engine is used to inject audit data that conforms to the audit rules into the instruction template, generate device-specific instructions, and synchronize the associated work order version number for traceability. Step S2.4, Online Debugging It provides a visual editing environment for users to adjust instructions in real time to ensure they meet actual needs; Step S3: Hierarchical Instruction Audit and Process Control Step S3.1, Automated Pre-inspection Use a regular expression engine to verify the compliance of command syntax; Verify the completeness of required fields based on the parameter mapping table; In step S3.1, an OMC interface simulator is introduced to perform pre-execution testing and conduct preliminary risk screening. Step S3.2, Manual review The auditor obtains the audit instructions from the Flowable task node and views the original text of the instructions, the audit rule matching results, and the device adaptation suggestions. If the reviewer approves, the instruction issuance stage begins; If the reviewer rejects the application, it will be returned to the designated stage with suggested modifications. Step S4: Multi-vendor device command issuance and status tracking Step S4.1, Protocol Conversion By loading the manufacturer's dedicated OMC interface through the OMC interface gateway, standardized commands are converted into a specified format that the device can recognize, thereby realizing protocol conversion and secure invocation of device commands; Step S4.2, Execution Tracing Start an independent execution status monitoring thread to determine the instruction execution status in real time based on the execution end markers pre-defined in the instruction configuration library of multiple vendors' devices; Step S4.3, Timeout Management Configure a multi-level timeout mechanism. When a timeout event occurs, the corresponding mechanism will be automatically triggered, an exception work order will be generated, and the operations and maintenance supervisor will be notified to intervene. Step S5: Result Processing and Closed-Loop Archiving Step S5.1, Data Analysis After the device execution result is returned via the OMC interface, the returned result is disassembled according to the manufacturer's protocol standard, and the result data is standardized and parsed according to the specific requirements of the manufacturer's protocol to extract core metadata; Step S5.2, Compliance Verification The parsed data is compared with the audit standards preset in the work order to verify its compliance. After the reviewer confirms that the results are correct, the entire process data of the work order is fully encrypted and compressed, and stored in a distributed storage system according to the rule of "Ministry and Province Task ID + Timestamp". The work order status is updated synchronously through the Ministry and Province callback interface, and result summary information is attached to achieve a complete closed loop of data interaction. If an abnormal situation occurs, the abnormal handling process will be triggered, the corresponding abnormal handling sub-work order will be automatically created, and relevant personnel will be notified in a timely manner for manual intervention.

2. The ministerial-provincial collaborative data processing method based on the Flowable engine according to claim 1, characterized in that: In step S3.2, the Flowable engine intelligently executes process branch decisions based on the review results; If the reviewer approves, the process proceeds directly to the instruction issuance and execution node. If the instruction is rejected, the rollback logic is triggered, and the work order is automatically and accurately rolled back to the nearest editable node according to preset rules.

3. The ministerial-provincial collaborative data processing method based on the Flowable engine according to claim 2, characterized in that: In step S3.2, if the instruction is rejected, the rollback logic is triggered, and the work order is automatically rolled back to the initial stage of instruction generation or the key stage of data auditing according to preset rules.

4. The ministerial-provincial collaborative data processing method based on the Flowable engine according to claim 1, characterized in that: In step S4.2, the multi-vendor device instruction configuration library stores instruction templates, parameter mapping relationships, execution end symbols, and OMC interface parameters for each vendor's devices. Execution termination markers include, but are not limited to, specific strings, status codes, and heartbeat signals.

5. The method for collaborative data processing between ministries and provinces based on the Flowable engine according to claim 1, characterized in that: In step S4.3, the multi-level timeout mechanism is 5 minutes for the first-level warning duration, 10 minutes for the second-level warning duration, and 15 minutes for the forced termination duration.

6. A ministerial-provincial collaborative data processing system based on the Flowable engine, characterized in that: To implement the method according to any one of claims 1 to 5, comprising: Ministry-Province Interaction Layer: Includes task receiving interface and result feedback interface, responsible for implementing task access and result feedback through standardized interfaces, and supports multi-protocol adaptation; The Flowable engine core layer includes a process definition repository, a dynamic task scheduler, a process instance manager, and a historical process tracer, which are responsible for managing process definitions, instance lifecycles, and historical traceability. Business processing layer: includes work order instance generator and process node controller, responsible for the creation, management and monitoring of process node status of work orders; Multi-vendor device adaptation platform: including command configuration center and OMC interface gateway. The command configuration center is used to manage device command templates and version control, and the OMC interface gateway is used to realize command protocol conversion and secure invocation. Support layer: Includes data storage layer, organization permission configuration library and monitoring management module, responsible for providing basic services, including organization permissions, data storage and monitoring management; Data storage layer: includes the main database and historical archive repository; The main database includes an organization permission configuration library and a multi-vendor device instruction configuration library, which are used to store work order instances, process logs and device configuration data. The historical archive is used to store data on completed work orders; Monitoring and management module: includes process dashboard and operation audit log, used to display work order progress and record user operations in real time.

7. A ministerial-provincial collaborative data processing device based on the Flowable engine, characterized in that: It includes a memory and a processor; the memory is used to store a computer program, and the processor is used to execute the computer program to implement the method according to any one of claims 1 to 5.

8. A readable storage medium, characterized in that: The readable storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1 to 5.

Images