Workflow node form configuration method and apparatus, and electronic device

Abstract

The application provides a workflow node form configuration method and device and electronic equipment, relates to the field of data processing, and solves the technical problem that the maintenance cost of the workflow node form is relatively high. The method comprises the following steps: deploying and setting a field permission rule table, a field mapping rule table, a dynamic verification rule table, a form version association table and a workflow node table in a data layer in a form configuration system; adding an associated field related to form field permission in the field permission rule to the workflow node table to obtain a workflow node table containing the associated field; and configuring a workflow node form by using the field permission rule table, the field mapping rule table, the dynamic verification rule table, the form version association table and the workflow node table containing the associated field.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a workflow node form configuration method, apparatus, and electronic device. Background Technology

[0002] Currently, in existing enterprise-level low-code development platforms, workflow and form integration solutions typically involve two relatively independent stages. First, form designers create forms using a drag-and-drop graphical interface, storing the form's component layout, field attributes, and other information in a database form definition table in JSON (JavaScript Object Notation) format. Second, workflow designers define approval nodes, flow conditions, and other process information using a process designer. When combining forms with workflows, the current practice is to specify the form identifier associated with a particular process node in the process definition file through hard-coding or simple configuration. When a user completes a pending task, the system queries the pre-bound form ID (identity) based on the current node identifier and loads the corresponding static form template for the user to fill out or view. The display, hiding, and editability of fields within a form are usually determined by the form's static configuration or an independent access control list. When a workflow node is associated with a complex form, the permissions for filling in different fields within the form are static. This typically requires designing multiple different forms for each node, or implementing field-level access control on the front end through cumbersome conditional judgment scripts, leading to a sharp increase in maintenance costs. Therefore, workflow node forms have relatively high maintenance costs. Summary of the Invention

[0003] The purpose of this application is to provide a workflow node form configuration method, apparatus, and electronic device to solve the technical problem of high maintenance costs associated with workflow node forms.

[0004] Firstly, this application provides a workflow node form configuration method, applied to a workflow node form configuration system, the method comprising: The data layer of the form configuration system deploys and sets up a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table. The field permission rule table stores the operation permission rules for each field in the form under different process nodes. The field mapping rule table determines the value mapping logic between form fields and process context data sources. The dynamic validation rule table stores the field validation logic that needs to be enabled in different process states. The form version association table stores the binding relationship between form versions and process instance versions. Add associated fields related to the form field permissions in the field permission rules to the workflow node table to obtain a workflow node table containing the associated fields; the associated fields include a form identifier that the node is bound by default, a field that indicates whether automatic submission after timeout is enabled, a field that indicates the timeout duration, and a field that indicates the first node to automatically flow after timeout; Configure workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields.

[0005] In one possible implementation, after deploying and setting the field permission rule table, field mapping rule table, dynamic validation rule table, form version association table, and workflow node table in the data layer of the form configuration system, it further includes: In the system, the data layer above the engine layer deploys and sets up the field permission rule engine corresponding to the field permission rule table, the process context mapper corresponding to the field mapping rule table, the dynamic validation adapter corresponding to the dynamic validation rule table, and the form version host corresponding to the form version association table. In the system, the engine layer corresponds to the upper service layer, which deploys a form rendering service unit, a process-driven service unit, and a data access service unit to provide a unified interface call capability to the upper layer. The service layer corresponds to the upper presentation layer to provide interaction with the system through a graphical user interface and the terminal's to-do page. In response to an open request for a pending task, the form rendering service unit calls the field permission rule engine to obtain field-level permission configuration data, calls the process context mapper to obtain field default values, and calls the form version manager to obtain the correct form version definition data. The field-level permission configuration data, the field default values, and the form version definition data are merged to generate a dynamic form, and the dynamic form is returned to the corresponding front end of the system. In response to a form submission operation, the dynamic validation adapter is triggered to execute the field validation logic corresponding to the process state awareness of the dynamic validation rule table, and after the field validation logic passes the validation, the data is written to the persistence layer of the system via the data access service unit.

[0006] In one possible implementation, configuring the workflow node form using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: During the design phase, in response to form design operations for the graphical user interface, a base form containing all field definitions is generated based on the form design operations. In response to a binding operation between a target workflow node and the form, a field-level permission configuration panel is displayed in the graphical user interface; the field-level permission configuration panel displays all fields in the selected form in a tree structure. In response to a selection operation performed on each of the fields, the permissions of each field are configured according to the selection operation; wherein the options corresponding to the selection operation include visible, editable, and required. In response to the submission operation indicating that the permission configuration is complete, the permission data with complete permission configuration is written into the field permission rule table. Each record in the field permission rule table stores the current form identifier, the current process node identifier, and the permission mask value calculated by the bitmask calculation rule.

[0007] In one possible implementation, configuring the workflow node form using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: During the runtime phase, in response to the workflow flow to the second node and the form to be rendered that is available for user operation, the rendering engine queries the field permission rule table based on the process node identifier corresponding to the second node and the form identifier corresponding to the form to be rendered, and obtains the permission mask set corresponding to the operation permission rules of all fields under the second node from the field permission rule table; During the dynamic process of the rendering engine generating front-end form components, corresponding permission attributes are set for each front-end form component.

[0008] In one possible implementation, configuring the workflow node form using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: In response to a form opening operation for a pending task, a loading request is sent to the form rendering service unit via the front-end page; In response to the form rendering service unit receiving the loading request, it sends a fill request to the process context mapper and passes the current process instance identifier and the current form identifier; The process context mapper queries the field mapping rule table to obtain all valid mapping rules associated with the current form corresponding to the current form identifier from the field mapping rule table. The process context mapper retrieves raw data in parallel from different data sources according to the data source type and data source path defined in each of the all valid mapping rules. The data sources include at least one of the following: process global variables, organizational structure data of the initiator, approval records and approval opinions of historical nodes, and return values ​​of external system interfaces. In response to the completion of the acquisition of the original data, the process context mapper performs data calculation and format conversion according to the preset conversion expression in the effective mapping rules, and handles numerical operations, string concatenation, and condition judgment operations. At the same time, it handles data type conversion, empty value default value filling and circular dependency detection to obtain the value calculation results of all fields. The process context mapper encapsulates all the value calculation results into a temporary data object and returns the temporary data object to the form rendering service unit. The form rendering service unit intelligently merges the temporary data object with the original business data obtained from the data access service unit to obtain complete data. The complete data is returned to the front-end page, and the form corresponding to the complete data is displayed on the front-end page; some fields in the form corresponding to the complete data are filled with reasonable default values.

[0009] In one possible implementation, configuring the workflow node form using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: In response to a save or submit operation triggered during the form filling process on the front end, the form data corresponding to the save or submit operation and the context data of the current process node are sent from the front end to the dynamic validation adapter of the back end corresponding to the front end. The dynamic validation adapter queries the dynamic validation rule table for all validation rules associated with the current form and the form data. For each validation rule queried by the dynamic validation adapter, an activation condition expression for the validation rule is calculated; wherein, the activation condition expression references at least one variable among the current node identifier, previous node identifier, process initiator role, and current value of a field in the form of the process instance; rules whose calculation result of the activation condition expression is true are determined to belong to the execution set of the current validation. The dynamic validation adapter filters the validation rules one by one, and validates the target field according to the corresponding defined validation type based on each validation rule; In response to all the verification rules being verified successfully, the dynamic verification adapter returns a successful verification result, so that the front end can continue to perform the submission operation and write the data to the database. In response to the presence of a failed verification rule among all the verification rules, the dynamic verification adapter returns the prompt data of all the failed verification rules to the front end, so that the front end displays the prompt data to be corrected in the corresponding field position according to the prompt data.

[0010] In one possible implementation, configuring the workflow node form using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: In response to the modification completion operation for the form definition, copy all the definitions of the modified form corresponding to the modification completion operation and generate a first new record. Generate a new version number in the form version association table based on the first new record, and retain the old version of the form definition in the database and mark it as a historical version. In response to the start command of a new process instance, obtain the latest released new form version identifier, insert a second new record into the form version association table, and the second new record is used to record the binding relationship between the new process instance identifier and the new form version identifier corresponding to the new process instance and the current timestamp; In response to the new process instance flowing to the node of the form to be displayed, the rendering engine queries the form version association table based on the new process instance identifier, and obtains the new form version identifier corresponding to the new process instance identifier from the form version association table; the old form version identifier bound to the old process instance that has been running in the middle has not changed; The form definition and all associated rule configurations are loaded according to the new form version identifier, and the old process instance is displayed on the to-do page according to the old version structure corresponding to the old form version identifier.

[0011] Secondly, this application provides a workflow node form configuration device, applied to a form configuration system for workflow nodes, the device comprising: The deployment module is used to deploy and set up a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table at the data layer of the form configuration system. The field permission rule table stores the operation permission rules for each field in the form under different process nodes. The field mapping rule table determines the value mapping logic between form fields and process context data sources. The dynamic validation rule table stores the field validation logic that needs to be enabled in different process states. The form version association table stores the binding relationship between form versions and process instance versions. The module adds associated fields to the workflow node table that are related to the form field permissions in the field permission rules, resulting in a workflow node table containing the associated fields. The associated fields include a form identifier that the node is bound to by default, a field that indicates whether automatic submission after timeout is enabled, a field that indicates the timeout duration, and a field that indicates the first node to automatically proceed after timeout. The configuration module is used to configure workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields.

[0012] Thirdly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect above.

[0013] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method described in the first aspect above.

[0014] This application brings the following beneficial effects: This application provides a workflow node form configuration method, apparatus, and electronic device, which can deploy and set a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table at the data layer of the form configuration system. The field permission rule table stores the operation permission rules for each field in the form under different process nodes. The field mapping rule table determines the value mapping logic between form fields and process context data sources. The dynamic validation rule table stores the field validation logic that needs to be enabled in different process states. The form version association table stores the binding relationship between form versions and process instance versions. An association field related to the form field permissions in the field permission rules is added to the workflow node table to obtain a workflow node table containing the association field. The association field includes an indication of the node's default binding. The solution includes a form identifier, a field indicating whether automatic submission after timeout is enabled, a field indicating the timeout duration, and a first node indicating automatic transition after timeout. Workflow node forms are configured using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and a workflow node table containing the associated fields. In this solution, by dynamically binding form field-level permissions with workflow node semantics, the states of different fields at different process nodes within the same form can be configured through visual rules. This allows a single form to present a fully adapted state across multiple different approval nodes, eliminating the need to develop independent forms for each node. This achieves a leap in the granularity of form-workflow integration from the form level to the field level, significantly reducing repetitive design work, lowering development and maintenance costs, and solving the technical problem of high maintenance costs associated with workflow node forms.

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating the workflow node form configuration method provided in this application embodiment; Figure 2 An example of the overall system architecture diagram in the workflow node form configuration method provided in this application embodiment; Figure 3This is an example of a flowchart for dynamically binding and rendering field permissions in the workflow node form configuration method provided in this application embodiment; Figure 4 An example of a process context intelligent mapping sequence diagram in the workflow node form configuration method provided in this application embodiment; Figure 5 An example of a dynamic validation adapter workflow diagram in the workflow node form configuration method provided in this application embodiment; Figure 6 A schematic diagram of the structure of a workflow node form configuration device provided in an embodiment of this application; Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this application, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0020] Currently, while existing solutions achieve a basic integration of forms and workflows, they still have the following significant shortcomings in practical applications: First, the binding relationship between forms and workflow nodes is static and discrete. When a workflow node is associated with a complex form, the permissions for filling in different fields within the form (such as read, write, and hide) cannot dynamically change based on the semantic attributes of the workflow node. For example, the same "Leave Application Form" requires all fields to be editable in the "Applicant Filling" node, only some fields need to be displayed in the "Department Head Approval" node, and the "Leave Days" field needs to be modifiable. The "Human Resources Filing" node only allows viewing all fields. Existing solutions typically require designing three different forms for each node, or implementing field-level permission control on the front end through cumbersome conditional judgment scripts, leading to a sharp increase in maintenance costs.

[0021] Second, existing solutions lack the ability to intelligently map form fields to the workflow context. When the workflow reaches a certain node, the system can only simply load pre-set forms and cannot automatically fill in or derive default values, candidate values, or calculation formulas for form fields based on data accumulated in the workflow instance (such as applicant information, approval opinions, and workflow variables). For example, the "total reimbursement amount" field in the reimbursement process needs to be automatically calculated based on the amount in the details table, but existing solutions cannot perceive the workflow context and calculate it dynamically.

[0022] Third, existing solutions lack process status awareness for linked validation of form fields. Traditional form validation rules are statically preset and cannot detect whether the current workflow node is in "initial review" or "final review," nor can they adjust the strictness of validation based on different node identities. For example, in the "financial review" node, additional attachments are required when the reimbursement amount exceeds 10,000 yuan, while this requirement does not exist in ordinary approval nodes. Existing solutions can only hardcode such business logic in the form script or delegate it to the backend service, reducing the system's flexibility and configurability.

[0023] Fourth, there's the compatibility issue between multiple form versions and running process instances. When form designers modify the form structure, newly launched process instances should use the new form, while older process instances that are already running still need to display and validate data using the old form. Existing solutions lack an effective isolation and management mechanism for form versions and process instance versions, which can easily lead to data corruption or runtime anomalies.

[0024] Based on this, embodiments of this application provide a workflow node form configuration method, apparatus, and electronic device, which can solve the technical problem of high maintenance costs associated with workflow node forms.

[0025] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0026] Figure 1 This is a flowchart illustrating a workflow node form configuration method provided in an embodiment of this application. The method is applied to a workflow node form configuration system. Figure 1 As shown, the method includes: Step S110: Deploy and set the field permission rule table, field mapping rule table, dynamic validation rule table, form version association table, and workflow node table in the data layer of the form configuration system.

[0027] The table includes: a field permission rule table to store the operation permission rules for each field in the form under different process nodes; a field mapping rule table to determine the value mapping logic between form fields and process context data sources; a dynamic validation rule table to store the field validation logic that needs to be enabled in different process states; and a form version association table to store the binding relationship between form versions and process instance versions.

[0028] This application adds four core data tables to the existing form definition table and workflow instance table, which are used to store field permission rules, field mapping rules, dynamic validation rules, and form version association information, respectively. At the same time, the traditional workflow node table has been expanded to include associated fields related to form field permissions.

[0029] The first core table is the field permission rule table, named `fd_field_permission_rule`. This table records the operation permission rules for each field in the form under different process nodes. For example, the permission mask uses bitwise operations: 1 indicates the operation is allowed, and 0 indicates it is prohibited. The specific mask definitions are as follows: a value of 1 indicates visible only, a value of 3 indicates visible and editable, and a value of 7 indicates visible, editable, and required. This design allows a single record to represent multiple permission combinations, greatly reducing rule storage and improving query efficiency.

[0030] The second core table is the field mapping rule table, named `fd_field_mapping_rule`. This table defines the value mapping logic between form fields and process context data sources. For example, the meanings of data source types are as follows: `global_var` represents global variables for the process, such as business parameters passed in when the process starts; `initiator_attr` represents the attribute information of the process initiator, such as the initiator's department, job level, and employee ID; `history_opinion` represents approval opinions from historical nodes, which can be used to automatically populate the flow information in the approval chain; `external_api` represents the return value of an external system interface, such as obtaining customer information from a CRM system (Customer Relationship Management System); `system_const` represents system constants, such as the current time and the current operator.

[0031] The third core table is the dynamic validation rule table, named `fd_dynamic_validation_rule`. This table stores the field validation logic that needs to be enabled in different process states. The activation condition expression is the core design of this table. This expression can reference variables such as the current node identifier of the process instance, the previous node identifier, the role of the process initiator, or the current value of other fields in the form. The validation rule will only be executed when the expression evaluates to true.

[0032] The fourth core table is the form version association table, named fd_form_version_binding. This table records the binding relationship between form versions and process instance versions.

[0033] Step S120: Add associated fields related to form field permissions in the field permission rules to the workflow node table to obtain a workflow node table containing associated fields.

[0034] Among them, the associated fields include the form identifier that the node is bound to by default, a field that indicates whether automatic submission after timeout is enabled, a field that indicates the timeout duration, and a field that indicates the first node to automatically transition after timeout.

[0035] This application extends the traditional workflow node table by adding the following fields to the original fd_process_node table: default_form_id (representing the form identifier bound to the node by default), auto_submit_on_timeout (indicating whether automatic submission after timeout is enabled), timeout_duration (in hours) (representing the timeout duration), and timeout_target_node (indicating the target node for automatic workflow transition after timeout). Step S130: Configure the workflow node form using the field permission rule table, field mapping rule table, dynamic validation rule table, form version association table, and workflow node table containing associated fields.

[0036] By dynamically binding form field-level permissions with workflow node semantics, the status of different fields in different workflow nodes (such as readable, writable, and hidden status) within the same form can be configured through visual rules. This allows a single form to present a completely adapted state in multiple different approval nodes without the need to develop independent forms for each node. This achieves a leap in the granularity of form and workflow integration from the form level to the field level, significantly reducing repetitive design work and lowering development and maintenance costs.

[0037] The solution provided in this application can serve as an adaptive configuration method for workflow node forms based on intelligent mapping and dynamic rendering. Its core lies in the introduction of four collaborative new design modules: a field permission rule engine, a process context mapper, a dynamic validation adapter, and a form version manager. The following details the database design, core processes, and module interactions, explaining how these four collaborative technical mechanisms jointly construct an intelligent and adaptive workflow node form configuration system.

[0038] In some embodiments, after deploying and setting the field permission rule table, field mapping rule table, dynamic validation rule table, form version association table, and workflow node table in the data layer of the form configuration system, the method may further include the following steps: In the system, the data layer deploys and sets the field permission rule engine corresponding to the upper engine layer, the process context mapper corresponding to the field mapping rule table, the dynamic validation adapter corresponding to the dynamic validation rule table, and the form version host corresponding to the form version association table. In the system, the engine layer corresponds to the upper service layer, which deploys and sets up form rendering service units, process-driven service units, and data access service units to provide unified interface call capabilities to the upper layer; the service layer corresponds to the upper presentation layer to provide interaction with the system through the graphical user interface and the terminal's to-do page. In response to an open request for a pending task, the form rendering service unit calls the field permission rule engine to obtain field-level permission configuration data, calls the process context mapper to obtain field default values, and calls the form version manager to obtain the correct form version definition data. The field-level permission configuration data, field default values, and form version definition data are then merged to generate a dynamic form, which is then returned to the corresponding front-end of the system. In response to a form submission, the dynamic validation adapter is triggered to execute the field validation logic corresponding to the process state awareness in the dynamic validation rule table. After the field validation logic passes the validation, the data is written to the persistent layer of the system via the data access service unit.

[0039] For example, in the overall system architecture design, Figure 2 The system architecture of this application and the collaborative relationships between its modules are shown, which are divided into four layers from bottom to top: data layer, engine layer, service layer and presentation layer.

[0040] At the data layer, four core data tables designed in this application, along with traditional form definition tables and workflow instance tables, are deployed, forming the system's data foundation. At the engine layer, four core components are deployed: a field permission rule engine, a process context mapper, a dynamic validation adapter, and a form version manager. These are the execution units that implement the various intelligent functions of this application. At the service layer, form rendering services, process-driven services, and data access services are deployed, providing unified interface call capabilities to the upper layers. At the presentation layer, end users interact with the system through a graphical configuration interface and a to-do page on mobile or PC.

[0041] The data flow between the engine and the service layer described above reflects the core working logic of this application: When a user requests to open a task, the form rendering service simultaneously calls the field permission rule engine to obtain field-level permission configuration, the process context mapper to obtain field default values, and the form version manager to obtain the correct form version definition. These three are then combined to generate a dynamic form, which is returned to the front end. When the user submits the form, the dynamic validation adapter is triggered to execute process state-aware validation logic. After successful validation, the data is written to the persistence layer via the data access service.

[0042] In some embodiments, the workflow node form is configured using a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table containing associated fields. Specifically, this may include the following steps: During the design phase, in response to form design operations for the graphical user interface, a base form containing all field definitions is generated based on the form design operations; in response to binding operations between target workflow nodes and forms, a field-level permission configuration panel is displayed in the graphical user interface; the field-level permission configuration panel displays all fields in the selected form in a tree structure. In response to a selection operation performed on each of all fields, the permissions for each field are configured according to the selection operation; the options corresponding to the selection operation include visible, editable, and required. In response to the submission operation after the permission configuration is completed, the permission data of the completed permission configuration is written to the field permission rule table. Each record in the field permission rule table stores the current form identifier, the current process node identifier, and the permission mask value calculated by the bitmask calculation rule.

[0043] As an example, the core process of dynamically binding field permissions... Figure 3 It details the complete process of field permissions from configuration to activation, which is divided into two phases: design time and runtime.

[0044] During the design phase, form designers first complete the basic form design in a graphical interface, generating a basic form containing all field definitions. Subsequently, when workflow designers bind a form to a workflow node, a field-level permission configuration panel pops up. This panel displays all fields in the selected form in a tree structure, allowing designers to select "visible," "editable," and "required" for each field. After configuration and submission, the system writes the collected permission information to the `fd_field_permission_rule` table, with each record storing the current form identifier, the current workflow node identifier, and the permission mask value calculated using bitmask rules.

[0045] This application solution lowers the technical threshold for configuring workflow-related forms. Business personnel can complete complex operations such as field permission allocation, mapping rule setting, and dynamic validation configuration through a graphical interface without relying on professional developers to write scripts or modify the database structure, which significantly improves the enterprise's information system's autonomy and controllability and business agility.

[0046] In some embodiments, the workflow node form is configured using a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table containing associated fields. Specifically, this may include the following steps: During runtime, in response to the workflow transitioning to the second node and the form to be rendered that is available for user operation, the rendering engine queries the field permission rule table based on the process node identifier corresponding to the second node and the form identifier corresponding to the form to be rendered. From the field permission rule table, it obtains the permission mask set corresponding to the operation permission rules of all fields under the second node. During the dynamic process of the rendering engine generating the front-end form components, corresponding permission attributes are attached and set for each front-end form component.

[0047] During runtime, when the workflow reaches a certain node and the system needs to render a form for user interaction, the rendering engine first queries the `fd_field_permission_rule` table based on the combination of the workflow node identifier and the form identifier to obtain the permission mask set for all fields under that node. Subsequently, during the dynamic generation of the front-end form components, the rendering engine attaches corresponding permission attributes to each component. For example, for invisible fields, the system does not generate corresponding DOM elements; for visible but non-editable fields, the system renders them as plain text; for required fields, the system automatically adds front-end validation flags. The entire rendering process is completely driven by backend configuration and requires no front-end conditional judgment scripts.

[0048] Existing solutions only associate the entire form with process nodes. This application's solution, however, refines permission control to each individual field within the form through a dynamic binding mechanism that links field-level permissions with process node semantics. By constructing an `fd_field_permission_rule` field permission rule table at the database level and using bitmasks to efficiently store various permission states such as visibility, editability, and required fields, the system can dynamically generate a form interface that meets the current node's operational requirements during rendering. This means that the same form can present completely different field combinations and operational permissions at different approval stages, fundamentally eliminating the need to develop separate forms for each node or write numerous conditional judgment scripts on the front end.

[0049] In some embodiments, the workflow node form is configured using a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table containing associated fields. Specifically, this may include the following steps: In response to a form open operation for a pending task, a loading request is sent to the form rendering service unit via the front-end page; in response to the form rendering service unit receiving the loading request, a fill request is sent to the process context mapper, and the current process instance identifier and the current form identifier are passed; The process context mapper queries the field mapping rule table to obtain all valid mapping rules associated with the current form corresponding to the current form identifier. Based on the data source type and data source path defined in each valid mapping rule, the process context mapper retrieves raw data in parallel from different data sources. The data sources include at least one of the following: process global variables, the initiator's organizational structure data, historical node approval records and approval opinions, and return values ​​from external system interfaces. In response to the completion of the acquisition of raw data, the process context mapper performs data calculation and format conversion according to the preset conversion expressions in the effective mapping rules, and handles numerical operations, string concatenation, and condition judgment operations. It also handles data type conversion, empty value default value filling, and circular dependency detection to obtain the value calculation results of all fields. The process context mapper encapsulates all value calculation results into a temporary data object and returns the temporary data object to the form rendering service unit. The form rendering service unit intelligently merges the temporary data object with the original business data obtained from the data access service unit to obtain complete data. The complete data is returned to the front-end page and the form corresponding to the complete data is displayed on the front-end page. Some fields in the form corresponding to the complete data are filled with reasonable default values.

[0050] For the runtime sequence of the process context intelligent mapping mechanism, for example, Figure 4 The sequence diagram illustrates the complete workflow of the process context mapper when a user opens a task. This sequence diagram includes multiple participating entities such as the user, the front-end page, the form rendering service, the process context mapper, the `fd_field_mapping_rule` table, various data sources, and data access services.

[0051] When a user clicks on a task to open a form, the front-end page first sends a loading request to the form rendering service. Upon receiving the request, the form rendering service does not directly return the raw data; instead, it first sends a smart fill request to the process context mapper, simultaneously passing the current process instance identifier and form identifier. The process context mapper first queries the `fd_field_mapping_rule` table to obtain all valid mapping rules associated with the current form. Next, based on the data source type and data source path defined in each rule, the mapper retrieves raw data in parallel from different data sources. These data sources may include process global variables, the initiator's organizational structure information, historical approval records and opinions, and return values ​​from external system interfaces. After obtaining the raw data, the mapper performs data calculations and format conversions according to the preset conversion expressions in the rules, handling numerical operations, string concatenation, conditional judgments, and other operations. It also needs to handle data type conversions, filling in null values ​​and default values, and detecting circular dependencies. After all field values ​​have been calculated, the mapper encapsulates all results into a temporary data object and returns it to the form rendering service. The form rendering service intelligently merges this temporary data object with the original business data retrieved from the data access service, and returns the merged, complete data to the front-end page for display. In the form that the user sees at this point, most fields have been intelligently filled with reasonable default values; the user only needs to check or make minor adjustments before confirming and submitting.

[0052] In this embodiment, based on the intelligent mapping of process context to form fields using a rule engine, an independent field mapping rule engine is established through the fd_field_mapping_rule field mapping rule table. This engine can automatically calculate and fill default or candidate values ​​of form fields from various data sources such as global process variables, initiator attributes, historical approval records, and external interfaces, according to preset transformation expressions. This design greatly reduces the repetitive filling work for users in various approval stages, while ensuring the consistency and traceability of data between different nodes. It also implements process status-aware field linkage validation, enabling validation rules to be dynamically enabled or adjusted based on conditions such as the type of the current process node, the approver's role, and business thresholds.

[0053] The intelligent mapping engine significantly improves business workflow efficiency. The auto-fill function drastically reduces the amount of information users need to manually enter at each node, while also avoiding data quality issues caused by manual input errors, resulting in a significant improvement in process speed. This solution establishes an intelligent mapping engine between form fields and the process context, supporting automatic value retrieval, calculation, and filling of form fields from process variables, historical approval data, and user identity information, reducing repetitive manual entry.

[0054] In some embodiments, the workflow node form is configured using a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table containing associated fields. Specifically, this may include the following steps: In response to a save or submit operation triggered during the form filling process on the front end, the form data corresponding to the save or submit operation and the context data of the current process node are sent from the front end to the dynamic validation adapter of the corresponding back end. The dynamic validation adapter queries the dynamic validation rule table for all related form data corresponding to the current form; for each validation rule queried by the dynamic validation adapter, the activation condition expression of the validation rule is calculated; wherein, the activation condition expression references at least one variable among the current node identifier of the process instance, the previous node identifier, the process initiator role, and the current value of the field in the form; the rule whose calculation result of the activation condition expression is true is determined to belong to the execution set of the current validation. The dynamic validation adapter filters validation rules one by one and validates the target field according to the corresponding defined validation type based on each validation rule; in response to all validation rules passing the validation, the dynamic validation adapter returns a successful validation result, so that the front end can continue to perform the submission operation and write the data to the database. In response to the presence of a failed validation rule among all validation rules, the system returns the prompt data for all failed validation rules to the front end via the dynamic validation adapter, so that the front end can display the prompt data to be corrected in the corresponding field position based on the prompt data.

[0055] For a dynamic verification process with process status awareness, an example is... Figure 5 The workflow of the dynamic verification adapter in this application is demonstrated, highlighting the binding relationship between verification rules and process node states, as well as the verification execution mode of the backend driver.

[0056] When a user fills out a form on the front end and triggers a save or submit operation, the front end does not execute complete validation logic. Instead, it packages the form data along with the context information of the current process node and sends it to the backend dynamic validation adapter. Upon receiving the request, the dynamic validation adapter first queries the `fd_dynamic_validation_rule` table for all validation rules associated with the current form. For each rule found, the adapter needs to calculate its activation condition expression. The activation condition expression can reference variables such as the current node identifier of the process instance, the previous node identifier, the process initiator role, or the current value of other fields in the form. Only rules whose activation condition expression evaluates to true are included in the execution set for this validation. Subsequently, the adapter executes the filtered validation rules one by one, validating the target fields according to their defined validation type. If all rules pass validation, the adapter returns a successful validation result, and the front end can continue with the submission operation and write the data to the database. If there are rules that fail validation, the adapter summarizes the error messages for all failed rules and returns them to the front end. The front end then displays the validation error messages in the corresponding field positions, allowing the user to correct and resubmit.

[0057] Taking the reimbursement process as an example, a dynamic validation rule can be configured in the `fd_dynamic_validation_rule` table: the activation condition expression is set to the current node code equal to the financial review and the total reimbursement amount field value is greater than 10,000, and the validation content is set to the additional invoice field not being empty. When the process flows to the financial review node and the reimbursement amount exceeds 10,000 yuan, this rule automatically takes effect, forcing the upload of additional invoices; while at the initial review node or when the amount is less than 10,000 yuan, this rule will not be activated. This backend-driven validation mode allows business rules to be adjusted at any time without modifying the frontend code, while ensuring the global consistency and security of the validation logic.

[0058] The process state-aware conditional dynamic validation adaptation mechanism in this application differs from the traditional approach where validation rules are completely fixed during the form design phase. This solution deeply binds the effectiveness conditions of validation rules to the state characteristics of process nodes through the `fd_dynamic_validation_rule` dynamic validation rule table. Each validation rule is accompanied by an activation condition expression, which can flexibly reference variables such as the current node identifier, approver role, and real-time values ​​of other fields within the form. Execution of validation rules is handled in the backend, where the dynamic validation adapter filters and executes rules that meet the conditions in real-time based on the process context. This mechanism allows the same field to accept different levels of validation stringency at different approval stages, and changes to business rules take effect without requiring redeployment of the frontend application.

[0059] The dynamic validation and adaptation mechanism enables more agile adjustments to business rules. When an enterprise's approval policies change, administrators only need to modify or add validation rules and their activation conditions in the `fd_dynamic_validation_rule` table; no front-end code modification or service restart is required, and the changes take effect immediately.

[0060] In some embodiments, the workflow node form is configured using a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table containing associated fields. Specifically, this may include the following steps: In response to the operation that the modification of the form definition is completed, copy all the definitions of the modified form corresponding to the operation and generate the first new record. Based on the first new record, generate a new version number in the form version association table, and retain the old version of the form definition in the database and mark it as a historical version. In response to the start command of a new process instance, obtain the latest released new form version identifier, insert a second new record in the form version association table. The second new record is used to record the binding relationship between the new process instance identifier and the new form version identifier corresponding to the new process instance and the current timestamp. In response to a new process instance flowing to the node of the form to be displayed, the rendering engine queries the form version association table based on the new process instance identifier to obtain the new form version identifier corresponding to the new process instance identifier; the old form version identifier bound to the old process instance that has been running in the middle has not changed; the form definition and all associated rule configurations are loaded according to the new form version identifier, and the old process instance is displayed on the to-do page according to the old version structure corresponding to the old form version identifier.

[0061] In practical applications, to address the impact of form structure changes on running process instances, this application designs a two-way association and hosting mechanism between form versions and process instance versions. Each time a form designer modifies the form definition and clicks "publish," the system does not overwrite the original form record. Instead, it copies the entire definition of the current form, generates a new record, and assigns a new version number to the `fd_form_version_binding` table. The old version of the form definition is still retained in the database and marked as a historical version.

[0062] When an end user starts a new process instance, the system performs a binding action: it retrieves the latest published form version identifier, inserts a new record into the `fd_form_version_binding` table, recording the binding relationship between the current process instance identifier and the selected form version identifier, as well as the current timestamp. Subsequently, whenever the process instance reaches a node that needs to display the form, the rendering engine first queries the `fd_form_version_binding` table based on the instance identifier to obtain the corresponding form version identifier, and then loads the precise form definition and all associated rule configurations based on the version identifier. For older process instances that are already running, because their bound form version identifier has not changed, even if the administrator launches a new version of the form in the backend, the to-do page will still display according to the old structure, thus completely avoiding data corruption caused by field additions, deletions, or type changes.

[0063] This application's solution introduces the `fd_form_version_binding` form version association table to achieve persistent binding between runtime instances and specific form versions. Each process instance establishes a binding relationship with the latest form version at startup, and thereafter uses the same form definition throughout its entire lifecycle. Any modifications made to the form by the administrator will generate a new version, affecting only subsequently started process instances, while remaining completely transparent to older, already running instances. By constructing a complete form version-process instance version association mechanism, it ensures that older, running instances are unaffected by changes to the form structure, while new instances automatically adopt the latest form definition, achieving a smooth upgrade. The form version hosting mechanism in this application guarantees high system availability and data consistency. Even with the coexistence of old and new form versions, all running process instances operate stably according to their respective bound versions, and the release of new versions will not impact older processes, completely eliminating the risk of runtime errors caused by form changes.

[0064] Figure 6 A schematic diagram of a workflow node form configuration device is provided. This device can be applied to a workflow node form configuration system. Figure 6 As shown, the workflow node form configuration device 600 includes: The deployment module 601 is used to deploy and set up a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table in the data layer of the form configuration system. The field permission rule table is used to store the operation permission rules for each field in the form under different process nodes. The field mapping rule table is used to determine the value mapping logic between form fields and process context data sources. The dynamic validation rule table is used to store the field validation logic that needs to be enabled in different process states. The form version association table is used to store the binding relationship between form versions and process instance versions. Add module 602 is used to add associated fields related to form field permissions in the field permission rules to the workflow node table, so as to obtain a workflow node table containing the associated fields; the associated fields include a form identifier that the node is bound by default, a field that indicates whether automatic submission after timeout is enabled, a field that indicates the timeout duration, and a field that indicates the first node to automatically flow after timeout; Configuration module 603 is used to configure workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields.

[0065] The workflow node form configuration device provided in this application embodiment has the same technical features as the workflow node form configuration method provided in the above embodiment, so it can also solve the same technical problems and achieve the same technical effects.

[0066] An electronic device provided in this application embodiment, such as Figure 7 As shown, the electronic device 700 includes a processor 702 and a memory 701. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the steps of the method provided in the above embodiments.

[0067] See Figure 7 The electronic device also includes a bus 703 and a communication interface 704. The processor 702, the communication interface 704 and the memory 701 are connected via the bus 703. The processor 702 is used to execute executable modules, such as computer programs, stored in the memory 701.

[0068] The memory 701 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 704 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0069] Bus 703 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0070] The memory 701 is used to store programs. After receiving an execution instruction, the processor 702 executes the program. The method executed by the apparatus defined by the process disclosed in any of the preceding embodiments of this application can be applied to the processor 702 or implemented by the processor 702.

[0071] The processor 702 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 702 or by instructions in software form. The processor 702 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 701, and processor 702 reads the information from memory 701 and, in conjunction with its hardware, completes the steps of the above method.

[0072] Corresponding to the above-described workflow node form configuration method, this application embodiment also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to execute the steps of the above-described workflow node form configuration method.

[0073] The workflow node form configuration device provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0074] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0075] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0076] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0077] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0078] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion 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 workflow node form configuration method described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0079] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0080] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A workflow node form configuration method, characterized in that, A form configuration system applied to workflow nodes, the method comprising: The data layer of the form configuration system deploys and sets up a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table. The field permission rule table stores the operation permission rules for each field in the form under different process nodes. The field mapping rule table determines the value mapping logic between form fields and process context data sources. The dynamic validation rule table stores the field validation logic that needs to be enabled in different process states. The form version association table stores the binding relationship between form versions and process instance versions. Add associated fields related to the form field permissions in the field permission rules to the workflow node table to obtain a workflow node table containing the associated fields; the associated fields include a form identifier that the node is bound by default, a field that indicates whether automatic submission after timeout is enabled, a field that indicates the timeout duration, and a field that indicates the first node to automatically flow after timeout; Configure workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields.

2. The method according to claim 1, characterized in that, After deploying and setting the field permission rule table, field mapping rule table, dynamic validation rule table, form version association table, and workflow node table in the data layer of the form configuration system, it also includes: In the system, the data layer above the engine layer deploys and sets up the field permission rule engine corresponding to the field permission rule table, the process context mapper corresponding to the field mapping rule table, the dynamic validation adapter corresponding to the dynamic validation rule table, and the form version host corresponding to the form version association table. In the system, the engine layer corresponds to the upper service layer, which deploys a form rendering service unit, a process-driven service unit, and a data access service unit to provide a unified interface call capability to the upper layer. The service layer corresponds to the upper presentation layer to provide interaction with the system through a graphical user interface and the terminal's to-do page. In response to an open request for a pending task, the form rendering service unit calls the field permission rule engine to obtain field-level permission configuration data, calls the process context mapper to obtain field default values, and calls the form version manager to obtain the correct form version definition data. The field-level permission configuration data, the field default values, and the form version definition data are merged to generate a dynamic form, and the dynamic form is returned to the corresponding front end of the system. In response to a form submission operation, the dynamic validation adapter is triggered to execute the field validation logic corresponding to the process state awareness of the dynamic validation rule table, and after the field validation logic passes the validation, the data is written to the persistence layer of the system via the data access service unit.

3. The method according to claim 1, characterized in that, The configuration of workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: During the design phase, in response to form design operations for the graphical user interface, a base form containing all field definitions is generated based on the form design operations. In response to a binding operation between a target workflow node and the form, a field-level permission configuration panel is displayed in the graphical user interface; the field-level permission configuration panel displays all fields in the selected form in a tree structure. In response to a selection operation performed on each of the fields, the permissions of each field are configured according to the selection operation; wherein the options corresponding to the selection operation include visible, editable, and required. In response to the submission operation indicating that the permission configuration is complete, the permission data with complete permission configuration is written into the field permission rule table. Each record in the field permission rule table stores the current form identifier, the current process node identifier, and the permission mask value calculated by the bitmask calculation rule.

4. The method according to claim 1, characterized in that, The configuration of workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: During the runtime phase, in response to the workflow flow to the second node and the form to be rendered that is available for user operation, the rendering engine queries the field permission rule table based on the process node identifier corresponding to the second node and the form identifier corresponding to the form to be rendered, and obtains the permission mask set corresponding to the operation permission rules of all fields under the second node from the field permission rule table; During the dynamic process of the rendering engine generating front-end form components, corresponding permission attributes are set for each front-end form component.

5. The method according to claim 2, characterized in that, The configuration of workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: In response to a form opening operation for a pending task, a loading request is sent to the form rendering service unit via the front-end page; In response to the form rendering service unit receiving the loading request, it sends a fill request to the process context mapper and passes the current process instance identifier and the current form identifier; The process context mapper queries the field mapping rule table to obtain all valid mapping rules associated with the current form corresponding to the current form identifier from the field mapping rule table. The process context mapper retrieves raw data in parallel from different data sources according to the data source type and data source path defined in each of the all valid mapping rules. The data sources include at least one of the following: process global variables, organizational structure data of the initiator, approval records and approval opinions of historical nodes, and return values ​​of external system interfaces. In response to the completion of the acquisition of the original data, the process context mapper performs data calculation and format conversion according to the preset conversion expression in the effective mapping rules, and handles numerical operations, string concatenation, and condition judgment operations. At the same time, it handles data type conversion, empty value default value filling and circular dependency detection to obtain the value calculation results of all fields. The process context mapper encapsulates all the value calculation results into a temporary data object and returns the temporary data object to the form rendering service unit. The form rendering service unit intelligently merges the temporary data object with the original business data obtained from the data access service unit to obtain complete data. The complete data is returned to the front-end page, and the form corresponding to the complete data is displayed on the front-end page; some fields in the form corresponding to the complete data are filled with reasonable default values.

6. The method according to claim 2, characterized in that, The configuration of workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: In response to a save or submit operation triggered during the form filling process on the front end, the form data corresponding to the save or submit operation and the context data of the current process node are sent from the front end to the dynamic validation adapter of the back end corresponding to the front end. The dynamic validation adapter queries the dynamic validation rule table for all validation rules associated with the current form and the form data. For each validation rule queried by the dynamic validation adapter, an activation condition expression for the validation rule is calculated; wherein, the activation condition expression references at least one variable among the current node identifier, previous node identifier, process initiator role, and current value of a field in the form of the process instance; rules whose calculation result of the activation condition expression is true are determined to belong to the execution set of the current validation. The dynamic validation adapter filters the validation rules one by one, and validates the target field according to the corresponding defined validation type based on each validation rule; In response to all the verification rules being verified successfully, the dynamic verification adapter returns a successful verification result, enabling the front end to continue the submission operation and write the data to the database. In response to the presence of a failed verification rule among all the verification rules, the dynamic verification adapter returns the prompt data of all the failed verification rules to the front end, so that the front end displays the prompt data to be corrected in the corresponding field position according to the prompt data.

7. The method according to claim 1, characterized in that, The configuration of workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields includes: In response to the modification completion operation for the form definition, copy all the definitions of the modified form corresponding to the modification completion operation and generate a first new record. Generate a new version number in the form version association table based on the first new record, and retain the old version of the form definition in the database and mark it as a historical version. In response to the start command of a new process instance, obtain the latest released new form version identifier, insert a second new record into the form version association table, and the second new record is used to record the binding relationship between the new process instance identifier and the new form version identifier corresponding to the new process instance and the current timestamp; In response to the new process instance flowing to the node of the form to be displayed, the rendering engine queries the form version association table based on the new process instance identifier, and obtains the new form version identifier corresponding to the new process instance identifier from the form version association table; the old form version identifier bound to the old process instance that has been running in the middle has not changed; The form definition and all associated rule configurations are loaded according to the new form version identifier, and the old process instance is displayed on the to-do page according to the old version structure corresponding to the old form version identifier.

8. A workflow node form configuration device, characterized in that, A form configuration system applied to workflow nodes, the apparatus comprising: The deployment module is used to deploy and set up a field permission rule table, a field mapping rule table, a dynamic validation rule table, a form version association table, and a workflow node table at the data layer of the form configuration system. The field permission rule table stores the operation permission rules for each field in the form under different process nodes. The field mapping rule table determines the value mapping logic between form fields and process context data sources. The dynamic validation rule table stores the field validation logic that needs to be enabled in different process states. The form version association table stores the binding relationship between form versions and process instance versions. The module adds associated fields to the workflow node table that are related to the form field permissions in the field permission rules, resulting in a workflow node table containing the associated fields. The associated fields include a form identifier that the node is bound to by default, a field that indicates whether automatic submission after timeout is enabled, a field that indicates the timeout duration, and a field that indicates the first node to automatically proceed after timeout. The configuration module is used to configure workflow node forms using the field permission rule table, the field mapping rule table, the dynamic validation rule table, the form version association table, and the workflow node table containing the associated fields.

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

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images