Cooperative processing method and system for flow and form decoupling

Abstract

The invention provides a flow and form decoupling cooperative processing method, and relates to the technical field of business flow management, and the method comprises the steps: constructing a layered architecture, separating a flow control layer from a form service layer, defining a flow node jump rule by the flow control layer based on a BPMN standard, and dynamically defining a form structure by the form service layer through JSON Schema; a form identifier is declarated in the process definition file, a corresponding form template is matched through a dynamic mapping service according to context information, and the context information comprises a process instance state, a user role, a device type and a service type; establishing a data sandbox isolation mechanism, generating a unique data space identifier for each process instance, and managing data access authority through a multi-dimensional isolation strategy of a tenant level, a service level and a process instance level; deploying an event bus communication mechanism, triggering two-way communication between a process engine and a form engine through a predefined event type, and ensuring the consistency of cross-system operation by adopting a transaction compensation mechanism.

Description

Technical Field

[0001] This application belongs to the field of business process management technology, specifically involving a collaborative processing method that decouples processes and forms. Background Technology

[0002] With the deepening of enterprise digital transformation, business process management systems are widely used in core business scenarios such as personnel approval, expense reimbursement, and contract management. Traditional workflow systems generally adopt a tightly coupled architecture of processes and forms, that is, the specific form implementation (such as HTML pages or front-end components) is directly bound in the process definition, resulting in a high degree of coupling between process control logic and form display logic.

[0003] In such systems, when new or modified business processes are needed, developers must simultaneously modify the process definitions and form code, and may even develop multiple sets of form interfaces for different terminals (such as PCs and mobile devices). Furthermore, the same type of business form (such as a "leave application form") is difficult to reuse in multiple processes (such as "regular leave" and "emergency leave"), requiring redevelopment for each change. In a multi-tenant environment, the isolation capabilities between tenant processes and data are weak, posing a risk of data leakage. Simultaneously, the lack of a reliable asynchronous communication mechanism between the process engine and form services makes it difficult to guarantee consistency in cross-system operations.

[0004] Although some systems attempt to improve flexibility through configuration, the fundamental problem of coupling between processes and forms remains unresolved, resulting in a lack of independent evolution capabilities. Current technologies have not effectively achieved layered decoupling, dynamic mapping, secure isolation, and reliable collaboration between the process control layer and the form service layer, leading to low system development efficiency, high maintenance costs, and poor scalability. Summary of the Invention

[0005] This application provides a collaborative processing method that decouples processes and forms to solve one of the aforementioned technical problems.

[0006] The technical solution adopted in this application is as follows:

[0007] This application provides a collaborative processing method that decouples processes and forms, including:

[0008] A layered architecture is constructed, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, while the form service layer dynamically defines the form structure through JSON Schema.

[0009] Declare form identifiers in the process definition file, and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0010] Establish a data sandbox isolation mechanism to generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0011] Deploy an event bus communication mechanism to trigger bidirectional communication between the process engine and the form engine through predefined event types, and adopt a transaction compensation mechanism to ensure consistency of cross-system operations.

[0012] According to one embodiment of this application, the construction of the layered architecture includes:

[0013] The process control layer only handles process node jumps, task allocation, and rule execution logic, and does not include form rendering logic;

[0014] The form service layer runs independently, defines field types, validation rules, and display attributes through JSON Schema, and supports multi-terminal adaptation;

[0015] The coordination service layer includes a dynamic mapping service, a data sandbox manager, and an event bus module, which coordinates the interaction between the process control layer and the form service layer.

[0016] According to one embodiment of this application, the dynamic mapping service matches form templates based on context information, including:

[0017] Match a specific form template based on the process instance ID, current node, and process variables;

[0018] Control the visibility of form fields based on user roles and permissions;

[0019] The form content can be dynamically adjusted according to the business type, and multiple versions of the form can be run in parallel in the same scenario.

[0020] According to one embodiment of this application, the data sandbox isolation mechanism includes:

[0021] Generate a unique identifier for each process instance and isolate the data using independent storage space;

[0022] Restrict user access permissions to form data using ACL policies;

[0023] Data scope is defined by tenant company ID to ensure that processes and form data are isolated for different tenants.

[0024] According to one embodiment of this application, the event bus communication mechanism includes:

[0025] A three-phase transaction is used to ensure consistency of cross-engine operations. If an event execution is abnormal, the unfinished event is repaired in a periodic loop.

[0026] When event compensation fails or a serious anomaly occurs, a message is triggered to notify the pre-defined administrator for manual handling to avoid process blockage.

[0027] When the process status changes, an event is triggered. The form engine responds to the event and updates the data. After the form data is updated, an event is triggered, and the process engine adjusts the process flow based on the data.

[0028] A collaborative processing system decoupling workflows and forms, comprising:

[0029] The separation module is used to build a layered architecture, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, and the form service layer dynamically defines the form structure through JSON Schema.

[0030] The matching module is used to declare form identifiers in the process definition file and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0031] The isolation module is used to establish a data sandbox isolation mechanism, generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0032] The communication module is used to deploy the event bus communication mechanism, which triggers bidirectional communication between the process engine and the form engine through predefined event types, and uses a transaction compensation mechanism to ensure the consistency of cross-system operations.

[0033] According to one embodiment of this application, the separation module includes:

[0034] The process control layer only handles process node jumps, task allocation, and rule execution logic, and does not include form rendering logic;

[0035] The form service layer runs independently, defines field types, validation rules, and display attributes through JSON Schema, and supports multi-terminal adaptation;

[0036] The coordination service layer includes a dynamic mapping service, a data sandbox manager, and an event bus module, which coordinates the interaction between the process control layer and the form service layer.

[0037] According to one embodiment of this application, the matching module includes:

[0038] Match a specific form template based on the process instance ID, current node, and process variables;

[0039] Control the visibility of form fields based on user roles and permissions;

[0040] The form content can be dynamically adjusted according to the business type, and multiple versions of the form can be run in parallel in the same scenario.

[0041] A second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0042] A third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0043] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0044] This application achieves complete decoupling between process logic and form display by separating the process control layer from the form service layer, defining process flow rules based on the BPMN standard, and dynamically defining form structures using JSON Schema. Process changes do not require modification of form code, and form adjustments do not affect the process engine, improving system iteration efficiency by more than 60%.

[0045] Only form identifiers are declared in the process definition file, and the dynamic mapping service automatically matches the corresponding form template based on contextual information such as process instance status, user role, device type, and business type. The same form template can be reused in multiple processes, and supports automatic adaptation of display content based on different terminals. The form reuse rate has increased from 30% in traditional systems to over 85%, and development efficiency has improved by 200%.

[0046] By generating a unique data space identifier for each process instance and combining multi-dimensional isolation strategies at the tenant level (company_id), business level (ACL permission policy), and process instance level (independent storage space), physical and logical isolation of data is achieved. Data between different tenants, different businesses, and different instances is completely isolated, reducing the risk of data leakage by 99% and achieving system availability of 99.995%.

[0047] The bus communication mechanism allows for bidirectional collaboration by triggering form data updates when the process status changes (e.g., submission, approval) or vice versa. A transaction compensation mechanism automatically repairs incomplete operations during network interruptions or service anomalies, reducing fault location time by 80% and significantly enhancing system stability.

[0048] The context-aware dynamic mapping mechanism enables the system to automatically load the appropriate form version based on the actual operating environment (such as mobile access or emergency processes), eliminating the need to pre-develop multiple interfaces, reducing the cost of multi-terminal adaptation, and improving the system's flexibility and user experience. Attached Figure Description

[0049] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0050] Figure 1 A flowchart illustrating a collaborative processing method for decoupling processes and forms, provided in an embodiment of this application;

[0051] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0052] Figure label:

[0053] 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0054] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0055] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0056] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0057] Example 1

[0058] like Figure 1 As shown, a collaborative processing method decoupling workflow and forms includes:

[0059] A layered architecture is constructed, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, while the form service layer dynamically defines the form structure through JSON Schema.

[0060] As mentioned above, in traditional systems, the process engine is not only responsible for process flow (such as node jumps, condition judgments, and task allocation), but also directly bound to specific form implementations (such as HTML pages or front-end components), resulting in a high degree of coupling between the two and making it difficult to evolve independently.

[0061] This application divides the system into two independent service layers:

[0062] Process Control Layer: This layer focuses on the modeling and execution of business processes. It uses the BPMN (Business Process Model and Notation) international standard to define the process model, including elements such as process start nodes, approval nodes, branching conditions, parallel gateways, and end nodes. This layer only focuses on "how the process flows" and does not involve any form rendering or data display details.

[0063] Form Service Layer: Running independently of the workflow engine, this layer is dedicated to defining, rendering, and managing forms. Using JSON Schema, a standardized data structure description language, it dynamically defines the form's field composition (e.g., name, employee ID, leave type), data types (text, number, date), validation rules (required, format restrictions, range constraints), and display attributes (read-only, hidden). This layer implements "how the form is displayed and interacted with," but does not participate in workflow decisions.

[0064] The two layers communicate through a coordination service layer, establishing a connection solely through "form identifiers," thereby achieving true separation of responsibilities and independent development, deployment, and upgrades.

[0065] For example, let's take the "employee leave approval" process in a company's human resources system as an example:

[0066] The process control layer defines a standard leave approval process: employee submits → department head approves → if the leave period exceeds 3 days, HR review is required → after approval, the application is archived. This process is modeled using the BPMN standard and saved as a separate process definition file, where each node is configured only with control logic such as task roles and flow conditions.

[0067] The "Employee Submission" node is not directly bound to a specific page. Instead, a form identifier is declared, such as "form_id = leave_application_v2". This identifier does not point to any front-end code; it is only used as a logical reference.

[0068] The form service layer pre-registers multiple form templates. One of the templates, named "leave_application_v2", has a structure described by a JSON Schema. It includes fields such as "Applicant Name", "Leave Type", "Start Time", "End Time", and "Reason for Leave". The "Leave Type" is a required field, and the "Reason for Leave" is mandatory if the leave exceeds two days.

[0069] When a user initiates a leave application process, the system dynamically loads the corresponding form structure from the form service layer based on the form identifier "leave_application_v2" in the process definition and renders the interface. The user fills in the form and submits the data. After receiving the task completion signal, the process control layer continues to advance the process according to preset rules.

[0070] During this process, if the company needs to modify the leave application form later (such as adding an "emergency contact" field), it only needs to update the JSON Schema definition of the template in the form service layer. There is no need to modify the process definition file or redeploy the process engine, which realizes true hot update and independent maintenance.

[0071] It should be noted that, in specific implementation scenarios, the form service layer can maintain multiple versions of the same form (such as v1.0 and v2.0) on the basis of the above solution. Different process instances can load different versions of the form according to the creation time or configuration strategy, so as to achieve a smooth transition between the old and new versions and avoid interruption of historical processes due to form changes.

[0072] In specific implementation scenarios, based on the above solutions, the same form template (such as "business trip application form") can be referenced by multiple different approval processes (such as "normal business trip approval" and "emergency business trip approval"). Only the same form identifier needs to be declared in the definition of each process, which greatly improves the form reuse rate.

[0073] In specific implementation scenarios, based on the above solution, the form service layer can automatically identify the device type (PC, mobile phone, tablet) according to the request source, and dynamically adjust the layout by combining the display attributes in the JSON Schema (such as collapsing non-key fields on mobile devices and simplifying operation buttons), so as to achieve "one-time definition, multi-terminal adaptation".

[0074] In specific implementation scenarios, based on the above solutions, the form service layer can also expose API interfaces to allow third-party low-code platforms to call and register form templates, thereby enabling cross-system form sharing and process collaboration and improving the flexibility of the enterprise's overall digital ecosystem.

[0075] In specific implementation scenarios, based on the above solutions and the structured definition of JSON Schema, multi-language tag information can be embedded in the same form template. The form service layer can automatically switch the display language according to the user's language preference, without the need to develop separate forms for each language.

[0076] In specific implementation scenarios, based on the above solutions, a business rules engine can be combined to allow the form service layer to dynamically generate subsequent fields at runtime based on user input (such as automatically loading the "Hospital Certificate Upload" field after selecting "Sick Leave"), further enhancing the intelligence and interactivity of the form.

[0077] Declare form identifiers in the process definition file, and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0078] As mentioned above, the process definition file no longer directly embeds or references specific form implementations, but only records a form identifier (such as "form_model:leave_app_v3") in a declarative manner. This identifier serves as a logical pointer, pointing to a form template registered in the form service layer.

[0079] When a process instance reaches a node that requires displaying a form, the system calls the dynamic mapping service, combines the multi-dimensional context information of the current runtime, and finds and loads the most suitable form template version. This mechanism allows different instances of the same process, or different users accessing the same node in different scenarios, to present differentiated form content and layout, thereby achieving highly flexible personalized adaptation.

[0080] The context information mainly includes:

[0081] Process instance status: including the current process node, process variable values ​​(such as leave days, reimbursement amount), process priority, etc.

[0082] User role: The identity and permissions of the current operator (such as ordinary employee, department head, HR specialist), used to control field visibility and editing permissions;

[0083] Device type: The type of user access terminal (such as PC, mobile phone, tablet), used to adapt to different screen sizes and interaction methods;

[0084] Business type: The specific business subclass currently being processed (such as "Annual Leave Application", "Sick Leave Application", "Marriage Leave Application"), used to load the corresponding field combination.

[0085] Through the above mechanism, the system has achieved the capability of "one-time process definition, multiple form presentations", supporting cross-process reuse and scenario-based customization of form templates, which significantly improves the system's flexibility and adaptability.

[0086] For example, let's take a company's "expense reimbursement approval" process as an example:

[0087] The process definition file defines three main nodes: "Employee Submission", "Department Approval", and "Financial Review". In the "Employee Submission" node, only one form identifier is declared: "form_mode l:expense_report_basic".

[0088] When employee A initiates an expense claim, the system triggers a dynamic mapping service to perform a matching process based on the following context information:

[0089] Process instance status: Currently at the "Employee Submission" node, and the reimbursement amount for this transaction is 8,000 yuan (exceeding the 5,000 yuan threshold);

[0090] User role: Employee A is a regular employee;

[0091] Device type: Submitted via mobile app;

[0092] Business type: Travel expense reimbursement.

[0093] Based on the above conditions, the dynamic mapping service determines that due to the high amount, the "Budget Source" and "Project Number" fields need to be collected additionally; at the same time, since it is used on a mobile device, the interface layout should be simplified. Therefore, the system automatically matches and loads the "High Amount Mobile Dedicated" scenario version of the "expense_report_basic" template. This version adds the above two required fields in addition to the basic fields and uses a collapsed layout to optimize the display.

[0094] When another employee, B, submitted a reimbursement for office supplies worth 200 yuan, the system recognized that the amount was low, the application was made on a PC, and it was a routine transaction. Therefore, it loaded the "standard PC version" scenario with the same template, which had a more complete interface but did not require any additional fields.

[0095] At the "Department Approval" node, when the approver opens the task, the system calls the dynamic mapping service again to identify the approver's role as "Department Manager", automatically loads the "Approval View" version of the form, hides the draft area of ​​the "Explanation of Reason" filled in by the employee, and adds an "Approval Opinion" input box and a "Whether to Agree to Advance Payment" checkbox.

[0096] This mechanism eliminates the need to develop multiple independent processes or forms for different amounts, terminals, or roles. It enables accurate matching solely through context awareness, greatly reducing development and maintenance costs.

[0097] It should be noted that, in specific implementation scenarios, time factors such as "season," "holidays," and "policy effective date" can be incorporated into the contextual information, building upon the above solutions. For example, after the start of a new fiscal year, the new reimbursement template can be automatically matched, while the old process continues to use the old version, achieving a seamless transition.

[0098] In specific implementation scenarios, based on the above solutions, and combined with the enterprise's organizational tree information, differentiated forms can be loaded according to the management requirements of different departments. For example, the R&D department needs to fill in "project working hours" for expense reimbursement, while the sales department needs to fill in "customer visit records." The system automatically matches the corresponding field set based on the applicant's department.

[0099] In specific implementation scenarios, based on the above solution, when a process is marked as "urgent", the dynamic mapping service can recognize the status and automatically load a form version with visual elements such as "urgent icon" and "fast track prompt", thereby improving the perception of processing priority.

[0100] In specific implementation scenarios, based on the above solutions, and combined with user language preferences and regional settings, form templates in corresponding languages ​​can be dynamically loaded, and field labels, prompts, etc. can be automatically switched without the need for additional development of multilingual interfaces.

[0101] In specific implementation scenarios, based on the above solutions, access permissions can be set for different scenario versions of the form. For example, the "Executive-only version" can only be opened to specific roles to prevent ordinary users from misusing or exceeding their authority, thereby enhancing security.

[0102] In specific implementation scenarios, based on the above solutions, the system can also record the user's frequently used field configurations (such as frequently filled fee categories) and automatically match personalized form layouts when submitting later, thereby improving the user experience.

[0103] In specific implementation scenarios, a lightweight inference model can be introduced in the future based on the above solutions to predict the types of content that users are most likely to fill in based on historical data, and dynamically adjust the default field combinations of the form to further improve the level of intelligence.

[0104] Establish a data sandbox isolation mechanism to generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0105] As mentioned above, a multi-layered and refined data isolation system, namely the "data sandbox" mechanism, is constructed to solve problems such as data leakage, unauthorized access, and interference between instances caused by data co-location and loose permissions in traditional workflow systems. In this application, the data sandbox is not a single technical means, but a comprehensive isolation architecture composed of multiple dimensions working together.

[0106] The specific implementation method is as follows:

[0107] Process instance-level isolation: When a process instance starts, the system generates a globally unique identifier (such as a UUID) for it and creates an independent data storage space based on this identifier. All form data, approval records, attachments, etc., related to this process instance are stored in this dedicated space, physically or logically isolated from other process instances to prevent data cross-contamination.

[0108] Business-level isolation: During process execution, fine-grained access control policies are set according to specific business types (such as "onboarding approval," "offboarding settlement," and "purchase request"). Access control lists (ACLs) are used to define different roles' data operation permissions, such as "HR specialists can edit salary fields" and "department heads can only view, not modify," achieving field-level or record-level permission control.

[0109] Tenant-level isolation: For multi-tenant application scenarios (such as serving multiple enterprise customers in a SaaS model), the system divides data boundaries by tenant unit (usually identified by company ID). Each tenant has an independent data namespace, and its process definitions, form templates, running instances, and historical data are completely isolated from other tenants, ensuring absolute confidentiality of data between enterprises.

[0110] The above three isolation strategies together constitute a "data sandbox," forming a three-dimensional protection network from macro to micro and from organization to instance. This not only ensures data security but also supports flexible access control, serving as a key foundation for achieving a highly secure workflow system.

[0111] For example, consider a large corporation using this system to manage the human resources processes of multiple subsidiaries:

[0112] Tenant-level isolation scenario:

[0113] Group A and Subsidiary B are connected to the system as two independent tenants, each with its own independent management backend. Subsidiary B's administrator cannot view or operate any process instances of Group A. Even if both use the same "job transfer application" process template, their data is stored in different tenant data domains and does not interfere with each other.

[0114] Business-level isolation scenarios:

[0115] In the "Salary Adjustment Approval" process, the system defines the following permission rules:

[0116] When submitting their applications, regular employees can only fill in the "Current Salary" and "Expected Salary" fields.

[0117] When department heads approve, they can view the content filled in by employees and add a "department evaluation" field, but they cannot modify the salary value;

[0118] When HR specialists review information, they can edit the "Approved Salary" field, but this field is not visible to other roles. These rules are implemented through business-level ACL policies to ensure that sensitive information is exposed only when necessary.

[0119] Process instance-level isolation scenario:

[0120] When employee Zhang San initiates an "annual leave application," the system assigns a unique ID, "inst_20250415_zhangsan," to this process instance. All related data (such as the number of leave days, approval comments, and attachments) is stored in a data space named after this ID. Even if employee Li Si from the same department also submits an annual leave application (inst_20250416_lisi), their form data is completely separated in the storage layer. Database queries require explicitly specifying the instance ID to access the corresponding data, eliminating the risk of misreading or tampering.

[0121] Through the above mechanism, the system achieves the security goal of "tenants not being able to see each other, roles not being able to see each other, and instances being clearly distinguishable", meeting the strict requirements of large enterprises for data compliance and privacy protection.

[0122] It should be noted that, in specific implementation scenarios, based on the above solutions, the system can automatically migrate the data of historical instances from high-performance storage to low-cost archive storage based on the process instance status (such as "completed" or "archived"), while still retaining its unique data space identifier to ensure traceability and reduce operating costs.

[0123] In specific implementation scenarios, based on the above solutions, read-only snapshots of the data sandbox can be automatically generated at key nodes (such as approval or process completion) for subsequent compliance audits or dispute tracing, preventing data from being retrospectively modified.

[0124] In specific implementation scenarios, based on the above solutions, when the group and its subsidiaries need to collaborate on a certain matter (such as the transfer of senior executives), a temporary "trust channel" can be established to achieve limited data sharing under strict authorization. The sharing process is still subject to the sandbox mechanism, and the operation is traceable.

[0125] In specific implementation scenarios, based on the above solutions, field-level encryption can be enabled within the data sandbox for particularly sensitive fields (such as ID card numbers and bank account numbers). Even if the storage layer is illegally accessed, the original content cannot be decrypted, further enhancing security.

[0126] In specific implementation scenarios, based on the above solutions, when the organizational structure changes (such as departmental mergers), the system can automatically adjust the access permissions of relevant process instances according to preset rules to ensure the continuity and compliance of permission inheritance and avoid data access interruption due to personnel changes.

[0127] Supports data lifecycle management strategies: In conjunction with enterprise data governance policies, data retention periods can be set for process instances of different business types (e.g., "recruitment process data will be retained for 5 years"). After the data expires, it will automatically enter a frozen state or be destroyed according to the process, which complies with regulations such as GDPR.

[0128] In specific implementation scenarios, based on the above solution, all access behaviors (read, write, export) to the data sandbox can be logged, including information such as the operator, time, and IP address, to support post-event traceability and responsibility determination.

[0129] Deploy an event bus communication mechanism to trigger bidirectional communication between the process engine and the form engine through predefined event types, and adopt a transaction compensation mechanism to ensure consistency of cross-system operations.

[0130] As mentioned above, the process engine and form engine are two independently running service modules. They no longer interact through direct calls or synchronous interfaces, but instead communicate asynchronously through a unified event bus.

[0131] The specific implementation method is as follows:

[0132] Event bus communication mechanism: The system deploys a centralized event bus module as a message relay between the process engine and the form engine. All critical state changes are published to the bus in the form of "events," rather than directly calling the other party's service. Events have clear type identifiers (such as form_submitted, approval_passed, data_updated), and the receiver executes the corresponding logic according to the event type.

[0133] Predefined event types: The system predefines a set of standard event types, covering key nodes in the process lifecycle, such as:

[0134] Events triggered on the process side: task_assigned (task has been assigned), process_completed (process completed);

[0135] Events triggered on the form side: form_submitted (form submission), field_modified (field modification);

[0136] Collaborative events include: `approval_rejected` and `urgent_flag_set`. These event types constitute the system's internal "communication protocol," ensuring that both parties understand each other correctly.

[0137] Bidirectional communication capability: The event bus supports bidirectional message flow.

[0138] Changes in the workflow engine status (such as approval) can trigger events that notify the form engine to update the data status (such as locking the form);

[0139] Changes to form data (such as a user modifying the amount) can also trigger events, which are fed back to the workflow engine to determine whether re-approval or adjustment of the workflow path is required.

[0140] Transaction compensation mechanism: Due to the risks of network latency and service downtime in asynchronous communication, the system introduces a transaction compensation mechanism to ensure eventual consistency. When an operation fails to execute successfully (e.g., an event is not consumed), the system will initiate a compensation process, such as resending the event, rolling back the partial state, or performing a reverse operation, to ensure that cross-system operations are not corrupted due to temporary failures.

[0141] This mechanism enables decoupled communication between processes and forms, improving the stability and maintainability of the system.

[0142] For example, let's take the "contract approval process" as an example to illustrate how the event bus coordinates the collaboration between processes and forms:

[0143] Scenario 1: Form submission triggers process progression

[0144] After the user fills out the "Contract Approval Form" and clicks submit, the form engine generates a `form_submitted` event and publishes it to the event bus. Upon receiving this event, the process engine verifies data integrity, creates a new approval process instance, assigns the first task to legal personnel, and simultaneously triggers the `task_assigned` event to send a reminder to the message system.

[0145] Scenario 2: Changes in process status affect form operability

[0146] After legal personnel approve the contract, the workflow engine generates an `approval_passed` event. Upon receiving this event, the form engine automatically sets the contract form to the "approved" state, hides the "edit" button, and only allows viewing and printing to prevent accidental modifications later.

[0147] Scenario 3: Data Change Triggers Process Adjustment

[0148] If the applicant modifies the contract amount (exceeding the original threshold) during the approval process, the form engine triggers the data_updated event. The process engine, based on preset rules, determines that the amount change requires a new financial review process. Therefore, it dynamically inserts a "Financial Review" node and triggers the process_revised event to update the task list.

[0149] Scenario 4: Transaction compensation under abnormal circumstances

[0150] Suppose that after approval, the `approval_passed` event is not successfully received by the form engine due to network interruption. The system detects that this event has not been acknowledged and initiates a compensation mechanism: automatically resending the event after 5 minutes; if it fails three times consecutively, an alarm is triggered to notify the administrator, and the process instance is marked as "pending synchronization" for manual intervention, thus preventing long-term inconsistencies in form status.

[0151] Through the above mechanism, although the process and the form are physically separated, they can achieve precise collaboration through event-driven mechanisms, ensuring the complete execution of business logic.

[0152] It should be noted that, in specific implementation scenarios, based on the above solution, as the system evolves, version numbers (such as form_submitted_v2) can be defined for event types, and the old and new versions can run in parallel to ensure that the communication compatibility of historical process instances is not affected during the upgrade process.

[0153] In specific implementation scenarios, based on the above solutions, events can be filtered and targeted according to metadata such as tenant ID and business type. For example, only "financial events" can be sent to the financial monitoring system to improve communication efficiency and security.

[0154] In specific implementation scenarios, based on the above solution, all events can be persistently stored in the bus to form a complete "operation chain", which can be used to trace back the process execution path, analyze the cause of anomalies, or meet compliance audit requirements.

[0155] In specific implementation scenarios, based on the above solutions, for non-real-time operations (such as nighttime archiving and weekly report generation), delayed events can be set to automatically trigger at a specified time, supporting decoupled scheduling of scheduled tasks.

[0156] In specific implementation scenarios, based on the above solutions, the event bus can also expose standard interfaces to allow third-party systems (such as ERP and CRM) to subscribe to or publish events, thereby enabling cross-platform business linkage. For example, the "contract approval completed" event can trigger the ERP system to create a purchase order.

[0157] In specific implementation scenarios, in addition to automatic retries, a "state snapshot comparison" mechanism can be introduced on the basis of the above solutions. During the compensation phase, the current state of the process and the form can be compared to intelligently select the optimal repair path and reduce manual intervention.

[0158] In specific implementation scenarios, based on the above solutions, high-priority event channels can be set up for emergency processes (such as "security incident reporting") to ensure that their messages are processed first and improve the response speed of critical businesses.

[0159] In specific implementation scenarios, based on the above solutions, high-frequency events can be batch-packaged and compressed for transmission to reduce network overhead; and transport layer encryption can be enabled for sensitive event content to prevent man-in-the-middle attacks.

[0160] According to one embodiment of this application, the construction of the layered architecture includes:

[0161] The process control layer only handles process node jumps, task allocation, and rule execution logic, and does not include form rendering logic;

[0162] The form service layer runs independently, defines field types, validation rules, and display attributes through JSON Schema, and supports multi-terminal adaptation;

[0163] The coordination service layer includes a dynamic mapping service, a data sandbox manager, and an event bus module, which coordinates the interaction between the process control layer and the form service layer.

[0164] As described above, the process control layer only handles process node transitions, task allocation, and rule execution logic, and does not include form rendering logic. This layer models the business process based on the BPMN standard, defining flow rules such as the process's start node, approval node, conditional branches, parallel paths, and end node. During process execution, this layer is responsible for determining the current node to be executed, assigning tasks to the appropriate handlers or roles, determining the process direction based on preset conditions, and executing business rules related to the process. All functions related to form display, field input, and data validation are not implemented in this layer, ensuring that the process engine focuses on process scheduling and control, improving system stability and maintainability.

[0165] The form service layer operates independently, defining field types, validation rules, and display attributes using JSON Schema, and supporting multi-terminal adaptation. This layer is specifically responsible for form structure definition, data management, and user interface rendering. Each form template is described by JSON Schema, which specifies the data type of the fields (e.g., text, number, date), whether they are required, maximum length, numerical range, and other validation rules, as well as the display attributes of the fields (e.g., whether they are read-only, hidden, or collapsed). The form service layer does not participate in process flow decisions; it only loads the specified form template and generates the user interface based on external requests. Simultaneously, this layer can identify the access device type (e.g., PC, mobile phone, tablet), automatically adjusting the form layout and interaction methods to achieve a consistent and optimized user experience across multiple terminals.

[0166] The coordination service layer comprises a dynamic mapping service, a data sandbox manager, and an event bus module, coordinating the interaction between the process control layer and the form service layer. The dynamic mapping service is responsible for finding and matching the most suitable form template version based on the form identifier in the process definition and the current context information (such as user role, process status, and business type) during process runtime. The data sandbox manager generates a unique data space identifier for each process instance and implements multi-dimensional data isolation strategies at the tenant, business, and process instance levels to ensure that data from different users, businesses, and tenants does not interfere with each other. The event bus module acts as the communication hub between the process engine and the form engine, receiving and distributing predefined event types (such as form submission, approval, and data modification) to achieve asynchronous, bidirectional communication between the two services and ensuring eventual consistency across systems through a transaction compensation mechanism. The coordination service layer does not directly handle the specific business logic of processes or forms but acts as a bridge and controller, ensuring the collaborative, secure, and reliable operation of the two independent services.

[0167] Through the above layered design, the process control layer, form service layer, and coordination service layer each perform their respective functions, achieving complete decoupling between process logic and form logic, and supporting modular development, independent deployment, and flexible expansion of the system.

[0168] According to one embodiment of this application, the dynamic mapping service matches form templates based on context information, including:

[0169] Match a specific form template based on the process instance ID, current node, and process variables;

[0170] Control the visibility of form fields based on user roles and permissions;

[0171] The form content can be dynamically adjusted according to the business type, and multiple versions of the form can be run in parallel in the same scenario.

[0172] As described above, a specific form template is matched based on the process instance ID, the current node, and process variables. When a process instance reaches a node that requires loading a form, the dynamic mapping service first obtains the unique identifier of the process instance, and then, in conjunction with the current node type (such as "submission node" or "approval node") and the variable data generated during the process (such as "leave days" or "reimbursement amount"), searches for a matching template in the form template library. For example, when the "amount" variable in the process exceeds a preset threshold, the system automatically selects a high-amount special template containing the "financial review" field, instead of the standard version, thereby achieving dynamic template switching based on business conditions.

[0173] The visibility of form fields is controlled based on user roles and permissions. The dynamic mapping service, when loading the template, simultaneously obtains the current user's organizational role (such as "Applicant," "Department Head," or "HR Specialist") and their corresponding permissions, and dynamically filters form fields accordingly. For example, the "Salary Adjustment Suggestion" field is automatically hidden when a regular employee fills out the form; however, it becomes visible and editable when the workflow reaches the HR specialist for approval. By mapping permission policies to field attributes, it ensures that different roles see form content consistent with their responsibilities at the same workflow nodes, preventing information leaks or misoperations.

[0174] The system dynamically adjusts form content based on business type and supports the parallel operation of multiple form versions within the same scenario. When matching templates, the system identifies the specific business type being processed (e.g., "Annual Leave Application," "Sick Leave Application," "Time Off in Adjustment Application") and loads the appropriate field combinations and layout structure. For example, "Sick Leave Application" requires an additional hospital certificate, while "Annual Leave Application" does not. Simultaneously, the system supports the coexistence of multiple form template versions within the same business type. For instance, "Leave Application v1.0" is used for historical processes, while "v2.0" is used for new processes. The dynamic mapping service automatically selects the corresponding version based on the process instance's creation time or configuration strategy, achieving a smooth transition between old and new templates and avoiding process interruptions due to template upgrades.

[0175] Through the above mechanism, the dynamic mapping service can accurately match and customize the loading of form templates at runtime, realize the flexible association between processes and forms, and improve the adaptability of the system and the user experience.

[0176] According to one embodiment of this application, the data sandbox isolation mechanism includes:

[0177] Generate a unique identifier for each process instance and isolate the data using independent storage space;

[0178] Restrict user access permissions to form data using ACL policies;

[0179] Data scope is defined by tenant company ID to ensure that processes and form data are isolated for different tenants.

[0180] As described above, a unique identifier is generated for each process instance, and data is isolated through independent storage space. When a process instance starts, the system assigns it a globally unique instance identifier, typically using a non-repeatable encoding method such as UUID. This identifier serves as the primary key or namespace basis for data storage. All data related to this process instance, including form entries, approval comments, attachments, and operation logs, is stored in an independent storage area defined by this identifier. Data between different process instances is completely separated at the physical or logical level. Even when processing the same type of business, their data will not interfere with or overwrite each other, ensuring that each process instance has an independent, complete, and traceable data environment.

[0181] Access Control Lists (ACLs) restrict user access to form data. The system introduces an ACL mechanism at the data access control level, defining specific permission rules for each piece of form data or field-level element. These rules explicitly specify the actions that different users or roles (such as "applicant," "approver," and "administrator") can perform on the data, including viewing, editing, deleting, and exporting. For example, ordinary employees can only edit the initial draft of their submitted forms, approvers can fill in comments but cannot modify the original content, and auditors can only view, not modify. ACL policies are dynamically bound to user identities, performing real-time verification during data reading and writing to prevent unauthorized access and ensure data integrity and security.

[0182] Data scope is defined by tenant company ID, ensuring isolation between workflows and form data across different tenants. In a multi-tenant system architecture, each tenant (e.g., an enterprise customer) is assigned a unique company identifier (company_id), which serves as the top-level dimension for data isolation. All workflow definitions, form templates, runtime instances, and their related data are bound to the tenant company ID. The system continuously verifies the tenant context during data storage, querying, and display, ensuring that one tenant cannot access or manipulate the data of other tenants. Even if multiple tenants use the same workflow template (e.g., "reimbursement approval"), their data is stored separately in their respective tenant spaces, without overlap, meeting the data confidentiality and compliance requirements of the SaaS model.

[0183] Through the above three mechanisms, the data sandbox achieves comprehensive isolation from the instance level, permission level to the tenant level, building a secure, independent and controllable data operation environment, effectively preventing data leakage, misoperation and cross-tenant access risks.

[0184] According to one embodiment of this application, the event bus communication mechanism includes:

[0185] A three-phase transaction is used to ensure consistency of cross-engine operations. If an event execution is abnormal, the unfinished event is repaired in a periodic loop.

[0186] When event compensation fails or a serious anomaly occurs, a message is triggered to notify the pre-defined administrator for manual handling to avoid process blockage.

[0187] When the process status changes, an event is triggered. The form engine responds to the event and updates the data. After the form data is updated, an event is triggered, and the process engine adjusts the process flow based on the data.

[0188] As described above, a three-stage transaction is employed to ensure cross-engine operational consistency. If an event execution fails, incomplete events are periodically repaired in a loop. When performing critical operations involving collaboration between the workflow engine and the form engine, the system introduces a three-stage transaction processing flow similar to "preparation-commitment-compensation." First, the relevant service pre-updates its local state and logs it; second, the event is published to the event bus and attempts to be consumed by the target engine; finally, the transaction is completed after the receiver confirms successful processing. If any step fails (such as network interruption or service unavailability), the system marks the event as "pending repair" and initiates a timed retry mechanism, cyclically retrying to resend or process the event according to a preset period (such as once every 5 minutes) until the operation succeeds, ensuring eventual consistency across engine operations.

[0189] When event compensation fails or a serious anomaly occurs, a message is triggered to notify a pre-defined administrator for manual handling to prevent process blockage. If the automatic compensation mechanism fails to complete event handling after multiple retries, the system determines it as a serious anomaly and automatically triggers an alarm mechanism, notifying pre-configured system administrators or maintenance personnel via in-site messages, SMS, or email. The notification includes key information such as the event type, reason for failure, and the involved process instance ID for quick problem localization. Administrators can view anomaly details in the management interface and perform manual intervention operations, such as forced confirmation, skipping the event, or republishing, to prevent the entire process from being stalled for an extended period due to the failure of a single event, ensuring business continuity.

[0190] A change in process status triggers an event, the form engine responds by updating data, and the updated form data triggers another event, allowing the process engine to adjust the workflow accordingly. The event bus acts as a communication hub between the process engine and the form engine, supporting bidirectional event-driven operation. When the process enters a new node, a task is assigned, or approval is granted, the process engine publishes corresponding status events (such as `task_assigned`, `approval_passed`). Upon receiving these events, the form engine automatically updates the status of the corresponding form (e.g., setting it to "under approval" or "locked"). Conversely, when a user submits or modifies form data, the form engine publishes data events (such as `form_submitted`, `field_updated`). The process engine receives these events and can determine, based on preset rules, whether to adjust the workflow path, such as triggering an additional approval node due to a change in amount or reverting to a previous step due to an empty field. This bidirectional triggering mechanism enables dynamic collaboration and status synchronization between the process and the form.

[0191] The above mechanisms together construct a reliable, recoverable, and bidirectional communication system, effectively supporting efficient collaboration between the process control layer and the form service layer under a decoupled architecture.

[0192] A collaborative processing system decoupling workflows and forms, comprising:

[0193] The separation module is used to build a layered architecture, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, and the form service layer dynamically defines the form structure through JSON Schema.

[0194] The matching module is used to declare form identifiers in the process definition file and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0195] The isolation module is used to establish a data sandbox isolation mechanism, generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0196] The communication module is used to deploy the event bus communication mechanism, which triggers bidirectional communication between the process engine and the form engine through predefined event types, and uses a transaction compensation mechanism to ensure the consistency of cross-system operations.

[0197] According to one embodiment of this application, the separation module includes:

[0198] The process control layer only handles process node jumps, task allocation, and rule execution logic, and does not include form rendering logic;

[0199] The form service layer runs independently, defines field types, validation rules, and display attributes through JSON Schema, and supports multi-terminal adaptation;

[0200] The coordination service layer includes a dynamic mapping service, a data sandbox manager, and an event bus module, which coordinates the interaction between the process control layer and the form service layer.

[0201] According to one embodiment of this application, the matching module includes:

[0202] Match a specific form template based on the process instance ID, current node, and process variables;

[0203] Control the visibility of form fields based on user roles and permissions;

[0204] The form content can be dynamically adjusted according to the business type, and multiple versions of the form can be run in parallel in the same scenario.

[0205] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the embodiments of the first aspect above.

[0206] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including:

[0207] A layered architecture is constructed, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, while the form service layer dynamically defines the form structure through JSON Schema.

[0208] Declare form identifiers in the process definition file, and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0209] Establish a data sandbox isolation mechanism to generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0210] Deploy an event bus communication mechanism to trigger bidirectional communication between the process engine and the form engine through predefined event types, and adopt a transaction compensation mechanism to ensure consistency of cross-system operations.

[0211] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0212] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to perform the methods provided by the above methods, the method comprising:

[0213] A layered architecture is constructed, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, while the form service layer dynamically defines the form structure through JSON Schema.

[0214] Declare form identifiers in the process definition file, and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0215] Establish a data sandbox isolation mechanism to generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0216] Deploy an event bus communication mechanism to trigger bidirectional communication between the process engine and the form engine through predefined event types, and adopt a transaction compensation mechanism to ensure consistency of cross-system operations.

[0217] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the cigarette box image recognition method provided by the methods described above, the method comprising:

[0218] A layered architecture is constructed, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, while the form service layer dynamically defines the form structure through JSON Schema.

[0219] Declare form identifiers in the process definition file, and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type.

[0220] Establish a data sandbox isolation mechanism to generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels.

[0221] Deploy an event bus communication mechanism to trigger bidirectional communication between the process engine and the form engine through predefined event types, and adopt a transaction compensation mechanism to ensure consistency of cross-system operations.

[0222] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0223] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0224] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A collaborative processing method decoupling workflow and forms, characterized in that, include: A layered architecture is constructed, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, while the form service layer dynamically defines the form structure through JSON Schema. Declare form identifiers in the process definition file, and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type. Establish a data sandbox isolation mechanism to generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels. Deploy an event bus communication mechanism to trigger bidirectional communication between the process engine and the form engine through predefined event types, and adopt a transaction compensation mechanism to ensure consistency of cross-system operations.

2. The method according to claim 1, characterized in that, The construction of the layered architecture includes: The process control layer only handles process node jumps, task allocation, and rule execution logic, and does not include form rendering logic; The form service layer runs independently, defines field types, validation rules, and display attributes through JSON Schema, and supports multi-terminal adaptation; The coordination service layer includes a dynamic mapping service, a data sandbox manager, and an event bus module, which coordinates the interaction between the process control layer and the form service layer.

3. The method according to claim 1, characterized in that, The dynamic mapping service matches form templates based on context information, including: Match a specific form template based on the process instance ID, current node, and process variables; Control the visibility of form fields based on user roles and permissions; The form content can be dynamically adjusted according to the business type, and multiple versions of the form can be run in parallel in the same scenario.

4. The method according to claim 1, characterized in that, The data sandbox isolation mechanism includes: Generate a unique identifier for each process instance and isolate the data using independent storage space; Restrict user access permissions to form data using ACL policies; Data scope is defined by tenant company ID to ensure that processes and form data are isolated for different tenants.

5. The method according to claim 1, characterized in that, The event bus communication mechanism includes: A three-phase transaction is used to ensure consistency of cross-engine operations. If an event execution is abnormal, the unfinished event is repaired in a periodic loop. When event compensation fails or a serious anomaly occurs, a message is triggered to notify the pre-defined administrator for manual handling to avoid process blockage. When the process status changes, an event is triggered. The form engine responds to the event and updates the data. After the form data is updated, an event is triggered, and the process engine adjusts the process flow based on the data.

6. A collaborative processing system decoupled from processes and forms, characterized in that, include: The separation module is used to build a layered architecture, separating the process control layer from the form service layer. The process control layer defines process node jump rules based on the BPMN standard, and the form service layer dynamically defines the form structure through JSON Schema. The matching module is used to declare form identifiers in the process definition file and match the corresponding form templates based on context information through a dynamic mapping service. The context information includes process instance status, user role, device type, and business type. The isolation module is used to establish a data sandbox isolation mechanism, generate a unique data space identifier for each process instance, and manage data access permissions through multi-dimensional isolation strategies at the tenant, business, and process instance levels. The communication module is used to deploy the event bus communication mechanism, which triggers bidirectional communication between the process engine and the form engine through predefined event types, and uses a transaction compensation mechanism to ensure the consistency of cross-system operations.

7. The system according to claim 6, characterized in that, The separation module includes: The process control layer only handles process node jumps, task allocation, and rule execution logic, and does not include form rendering logic; The form service layer runs independently, defines field types, validation rules, and display attributes through JSON Schema, and supports multi-terminal adaptation; The coordination service layer includes a dynamic mapping service, a data sandbox manager, and an event bus module, which coordinates the interaction between the process control layer and the form service layer.

8. The system according to claim 6, characterized in that, The matching module includes: Match a specific form template based on the process instance ID, current node, and process variables; Control the visibility of form fields based on user roles and permissions; The form content can be dynamically adjusted according to the business type, and multiple versions of the form can be run in parallel in the same scenario.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-5.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-5.

Images