Form process processing method based on Magic-API plug-in mechanism

Abstract

The invention discloses a form process processing method based on a Magic-API (Application Program Interface) plug-in mechanism, which comprises the following steps of: creating a multi-element plug-in in a Magic-API to obtain metadata information; designing and creating a database; generating a DSL (Digital Subscriber Line) structure through a form in combination with metadata information, and generating a dynamic form generation process definition through a visual tool based on a form engine; generating a data interface related to the form; associating the data interface with the dynamic form; defining a process node and a flow rule thereof through the process plug-in, and associating the process node with the corresponding form; the multi-element plug-in is packaged, and a user achieves form process processing through the multi-element plug-in. A data interface is associated with a dynamic form, and a corresponding form is automatically loaded when a task is executed; based on a Magic-API multi-element plug-in, a form template, a data interface and other related functions are dynamically generated according to metadata and are dynamically compiled and published, and a large amount of code modification does not need to be carried out.

Description

Technical Field

[0001] The present invention relates to a form flow processing method, in particular to a form flow processing method based on a Magic-API plug-in mechanism. Background Art

[0002] In modern enterprise application development, form and process processing are core requirements. Traditional form and process processing methods typically require extensive code development and maintenance, and have the following shortcomings: First, developers need to manually write a large amount of repetitive code, such as CRUD operations, form validation, and API interfaces. This not only wastes time and energy, but also makes it difficult to quickly respond to business needs, resulting in low development efficiency. Second, it is difficult to quickly respond to changes in demand due to the lack of modular design. When functions are changed, a large number of modifications to the existing code are required. The system's scalability and maintainability are limited, and its flexibility is insufficient. Summary of the Invention

[0003] In order to solve the deficiencies of the above technologies, the present invention provides a form flow processing method based on the Magic-API plug-in mechanism.

[0004] In order to solve the above technical problems, the technical solution adopted by the present invention is: a form process processing method based on the Magic-API plug-in mechanism, which specifically includes the following steps: Step S1: Create a multi-plugin in Magic-API and obtain metadata information through the meta-processor in Magic-API; Step S2: Design and create a database based on a metadata-driven approach; Step S3: Combine metadata information and generate DSL structure through form, and generate dynamic form through visualization tool based on form engine; Step S4: Return the DSL structure of the form to the process design, and establish a mapping relationship between the form and the process through the process design; the process designer determines the process branch based on the form fields and generates the process definition; and uses Magic-API to quickly generate data interfaces related to the form; Step S5: Associating the data interface in step S4 with the dynamic form in step S3 to generate a complete form structure; Step S6: Define the process nodes and their flow rules through the process plug-in in the multi-plug-in, and associate the process nodes with the corresponding forms; Step S7: Submit the form to the process engine, which processes the form; Step S8: The Magic-API multi-plugin updates the task status and notifies the front-end of the submission result.

[0005] Furthermore, the multiple plug-ins in step S1 include a metadata plug-in, which is used to realize end-to-end automated management from database fields to business processes; a form plug-in, which is used to build an extension component based on the metadata plug-in, automatically read the metadata definition and generate the corresponding form model; a process plug-in, which is used to model based on BPMN standardization, combine the metadata plug-in and the form plug-in, use XPath-like syntax to realize two-way binding between form fields and process variables, and dynamically set the process rule engine based on JUEL expression to realize task flow.

[0006] Furthermore, the metadata plug-in is a three-layer metadata model; the three-layer metadata model includes a basic layer, a business layer, and a process layer; the connection method of the three-layer metadata model specifically includes the following steps: Step A1: Mark the field metadata in the base layer through the metadata processor; Step A2: The business layer aggregates metadata of each field and generates entity constraint objects; Step A3: Analyze foreign key constraints between entity constraint objects using graph theory algorithms to automatically identify proportional relationships between entities; Step A4: The state machine drives the process flow; Step A5: Bind the status field of the business entity to the BPMN process node in the process layer to achieve two-way data synchronization.

[0007] Furthermore, metadata information includes table information, column information, data type, index information and constraint information; table information includes table name and table description, column information includes column name, data type, whether to allow null, default value, primary key and foreign key; index information includes index name, index type and index column; constraint information includes primary key constraint, unique constraint, foreign key constraint and check constraint.

[0008] Furthermore, generating a dynamic form in step S3 specifically includes the following steps: Step S31: adopting the design and development integration mode, and based on the form plug-in in step S1, converting the metadata information into a DSL structure through a visual form designer; Step S32: Verification is implemented according to the validation rules in the DSL, and the front end renders the form in real time by connecting to and unloading the DSL.

[0009] Furthermore, in step S31, the metadata information is converted into a DSL structure, which specifically includes the following steps: Step B1: Convert the metadata information into an intermediate model, map the intermediate model database type to an intermediate type, generate an intermediate JSON structure, and perform standardization of the metadata information; Step B2: Implement various extended functions for the form based on the intermediate model, including UI components, validation rules, and dynamic drop-down boxes; Step B3: Enhance the dynamic form template to enable users to customize the DSL structure; Step B4: Output the final form in DSL format.

[0010] Furthermore, multiple extended functions are implemented in step B2, specifically including the following steps: Step B21: Convert the field type in the intermediate model to UI component mapping; Step B22: Convert the constraint conditions in the database into the verification rules of the front end; Step B23: Convert the foreign key in the database into a dynamic drop-down box.

[0011] Furthermore, in step S5, a complete form structure is generated, which specifically includes the following steps: Step S51: automatically convert the metadata and form DSL into a RESTful interface in the Magic-API interface through the interface conversion component; Step S52: Dynamically bind the RESTful interface generated by Magic-API to the form metadata; Step S53: Magic-API generates a data interface according to the metadata structure; Step S54: Bind the form DSL with the metadata; Step S55: When the form is loaded and submitted, the corresponding data interface is automatically called, and the data is processed through field mapping and converted into the parameter format required by the interface.

[0012] Furthermore, in step S51, the metadata and form DSL are automatically converted into a RESTful interface, which specifically includes the following steps: Step S51-1: Standardize the CRUD interface framework, define four basic operation templates based on the RESTful specification, and support dynamic injection of parameters; Step S51-2: Obtain the table name and primary key field through the database metadata, and add parameter validation rules based on the field type; Step S52-3: Perform bidirectional verification through metadata and form DSL to synchronize the verification rules to the Magic-API interface.

[0013] Furthermore, in step S6, the process node is associated with the corresponding form, which specifically includes the following steps: Step S61: Combine the generated form with the process engine to build a business process; Step S62: Designing a BPMN process; the BPMN process includes user tasks for displaying and filling in dynamically generated forms; Step S63: Bind the form to the specified user task; Step S64: When the user fills in and submits the form, the data interface in Magic-API submits the form data to the corresponding task through the REST API in the process plug-in.

[0014] The present invention discloses a form process processing method based on the Magic-API plug-in mechanism, which has the following beneficial effects: 1. By associating the data interface with the dynamic form, each process task is dynamically associated with a form. The corresponding form is automatically loaded when the task is executed, eliminating the need for developers to manually write a large amount of repetitive code, enabling rapid response to business needs. 2. Based on Magic-API multi-plug-in, the ability to obtain database metadata is increased, and form templates, data interfaces and other related functions are dynamically generated according to the metadata and dynamically compiled and published without the need for a large number of code modifications, which increases the scalability and maintainability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 Flowchart of the present invention.

[0016] Figure 2 This is a diagram of the Magic-API plug-in, process, and form interaction in the present invention. DETAILED DESCRIPTION

[0017] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] like Figure 1 and 2 The form flow processing method based on the Magic-API plug-in mechanism shown in the figure specifically includes the following steps: Step S1: Create multiple plug-ins in Magic-API to connect key links such as forms, processes, data storage and process control, and obtain metadata information, i.e. table structure information, through the meta-processor in Magic-API; Magic-API is a Java-based interface rapid development framework for rapid development of data interfaces, providing operations for adding, deleting, modifying and querying form data. Based on the online configuration of multiple data sources in Magic-API, the ability to obtain database metadata is increased, and form templates, data interfaces and other related functions are dynamically generated based on the metadata, and dynamically compiled and published; the backend of the present invention is based on the SpringBoot framework, integrating Magic-API, forms and processes; Multiple plug-ins include metadata plug-ins, form plug-ins, and process plug-ins; The metadata plug-in uses a three-layer metadata model to achieve end-to-end automated management from database fields to business processes; the three-layer metadata model includes the basic layer, business layer, and process layer; Field-level metadata, including data types, validation rules, and UI component types, is defined at the foundational layer to enable the definition and management of atomic-level data elements. Type processors are loaded through the Java ServiceLoader mechanism, supporting runtime type extensions. A domain-oriented business object network is constructed through the business layer, and an entity relationship model is constructed by automatically inferring entity relationships through foreign key analysis. In this embodiment, a strongly connected component algorithm in graph theory is used to construct a 1:1 or 1:N association configuration; The process layer achieves deep binding between business processes and data states. Using two-way binding technology, form field changes automatically trigger state transitions and define the mapping between state machine metadata, i.e., state fields, and process nodes. The connection method of the three-layer metadata model includes the following steps: Step A1: Mark the field metadata in the base layer, such as varchar(50), NOT NULL, etc., through the metadata processor; the metadata processor optimizes and enriches the metadata information, generates a data dictionary, and analyzes data relationships; Step A2: The business layer aggregates metadata of each field to generate entity constraint objects; Step A3: Analyze foreign key constraints between entity constraint objects using a graph theory algorithm to automatically identify 1:1 or 1:N relationships. In this embodiment, analyze foreign key constraints between entity constraint objects using the Tarjan algorithm. The Tarjan algorithm is a classic algorithm for finding strongly connected components in a directed graph. In database entity constraint analysis, it can effectively detect circular dependencies formed by foreign key constraints. Atomic attributes of database fields, such as data types and constraints, are promoted to business entities, such as users and orders, and relationships between entities are established, achieving mapping from the field level to the entity level. Step A4: The state machine drives the process flow. The state machine can describe how the system transitions between finite states. In a business process, the state machine can precisely define the state change rules for business entities such as orders, leave requests, and approval processes, ensuring that the process flows according to the predetermined logic. Step A5: Link the status field of the business entity, such as status, to the BPMN process node. <conditionexpression>Binding is performed; bidirectional data synchronization is performed. When the form is submitted, the process variables are updated through event listening. When the process node of the process variable changes, the business status is written back through the process listener. That is, the status of the business entity, such as "Draft" and "Approved", is dynamically associated with the process node, such as "Submit" and "Approve", to achieve the binding of status and process.

[0019] By setting up a three-layer metadata model, the basic layer can be implemented independently of the database and support multiple data sources. The business layer and the process layer are loosely coupled through events, which is flexible. Among them, changes in the database table structure can be propagated to forms and processes in real time without restarting the service, which has a dynamic response effect. And through the state machine and two-way binding, it ensures that business data and process status are strictly synchronized, forming a closed loop and realizing end-to-end automated management from database fields to business processes.

[0020] The metadata plug-in provides Magic-API with a complete metadata management system, including data model definition, metadata storage, version control, relationship management, and query services. The plug-in can help developers define data structures in a declarative manner and automatically maintain the integrity and consistency of the data model; it automatically generates entity classes through AST analysis using dynamic metadata injection technology, uses a Git-like differential storage algorithm to achieve version backtracking of metadata changes, and decouples metadata from physical storage through Magic-API multi-data source configuration; it enables developers to define, manage, and use various data structures and business models in the system in a declarative manner.

[0021] Based on the Magic-API db module, add the Meta metadata module to obtain DataMetaData metadata information through the dynamic data source DataSource. Metadata information includes table information, column information, data type, index information, and constraint information; table information includes table name and table description; column information includes column name, data type, whether null is allowed, default value, primary key, and foreign key; index information includes index name, index type, and index column; constraint information includes primary key constraint, unique constraint, foreign key constraint, and check constraint; the code for obtaining metadata information in this embodiment is as follows: / ** * Database query module * / public class MetaData { DataSource dataSource; public MetaData(DataSource dataSource) { this.dataSource = dataSource; } @Comment("Get database information") public List <string>info() { try { Connection connection = dataSource.getConnection(); DatabaseMetaData metaData = connection.getMetaData(); return getDataBaseInfo(metaData); } catch (SQLException e) { throw new RuntimeException(e);}} @Comment("获取数据表") public List <tabledata>tables(@Comment(name = "tableName", value = "表名") String tableName) { try { Connection connection = dataSource.getConnection(); DatabaseMetaData metaData = connection.getMetaData(); return getTables(metaData, connection.getCatalog(), tableName); } catch (SQLException e) { throw new RuntimeException(e);}} @Comment("获取表字段") public List <columndata>columns(@Comment(name = "tableName", value ="Table name") String tableName) { try { Connection connection = dataSource.getConnection(); DatabaseMetaData metaData = connection.getMetaData(); return getColumns(metaData, tableName); } catch (SQLException e) { throw new RuntimeException(e);}} public List <tabledata>getTables(DatabaseMetaData metaData, Stringcatalog, String tn) throws SQLException { List <tabledata>list = new ArrayList<>(); try(ResultSet tables = metaData.getTables(catalog, null, tn, null)) { while (tables.next()) { String tableName = tables.getString("TABLE_NAME"); / / Table name String tableType = tables.getString("TABLE_TYPE"); / / Table type String remarks = tables.getString("REMARKS"); / / Table remarks TableData table = new TableData(tableName, tableType, remarks); list.add(table); System.out.println(tableName + " - " + tableType + " - " + remarks);}} catch (Exception e) { e.printStackTrace();} return list;} public List <columndata>getColumns(DatabaseMetaData metaData, Stringtablename) throws SQLException { List <columndata>list = new ArrayList<>(); try(ResultSet columns = metaData.getColumns(null, null, tablename+"%", null)) { while (columns.next()) { ColumnData table = new ColumnData(columns); list.add(table);}}catch (Exception e){ e.printStackTrace();} return list;} public static List <string>getDataBaseInfo(DatabaseMetaData dbmd)throws SQLException { List <string>infos = new ArrayList<>(); infos.add("Users known to the database: " + dbmd.getUserName()); infos.add("Comma-separated list of database system functions: " +dbmd.getSystemFunctions()); infos.add("A comma-separated list of database time and date functions: " + dbmd.getTimeDateFunctions()); infos.add("Comma-separated list of database string functions: " +dbmd.getStringFunctions()); infos.add("The database vendor's preferred term for 'schema': " + dbmd.getSchemaTerm()); infos.add("Database URL: " + dbmd.getURL()); infos.add("Is read-only allowed: " + dbmd.isReadOnly()); infos.add("Database product name:" + dbmd.getDatabaseProductName()); infos.add("Database version:" + dbmd.getDatabaseProductVersion()); infos.add("Driver name: " + dbmd.getDriverName()); infos.add("Driver version: " + dbmd.getDriverVersion()); infos.add("Table type used in the database"); return infos;}} public ColumnData(ResultSet columns) { try { this.tableCat = columns.getString("TABLE_CAT"); this.tableSchemaName = columns.getString("TABLE_SCHEM"); / / Table schema (may be empty). In Oracle, the namespace is obtained. Other databases are unknown. this.tableName = columns.getString("TABLE_NAME"); / / Table name this.columnName = columns.getString("COLUMN_NAME"); / / Column name this.dataType = columns.getInt("DATA_TYPE"); / / Corresponding SQL type of java.sql.Types (column type ID) this.dataTypeName = columns.getString("TYPE_NAME"); / / java.sql.Types type name (column type name) this.columnSize = columns.getInt("COLUMN_SIZE"); / / Column size this.decimalDigits = columns.getInt("DECIMAL_DIGITS"); / / Decimal digits this.numPrecRadix = columns.getInt("NUM_PREC_RADIX"); / / Radix (usually 10 or 2) -- unknown this.nullAble = columns.getInt("NULLABLE"); / / Is null allowed? this.remarks = columns.getString("REMARKS"); / / Column description this.columnDef = columns.getString("COLUMN_DEF"); / / Default value this.charOctetLength = columns.getInt("CHAR_OCTET_LENGTH"); / / For char type, the length is the maximum number of bytes in the column this.isNullAble = columns.getString("IS_NULLABLE"); } catch (SQLException e) { throw new RuntimeException(e);}} The form plugin is an extension built on the metadata plugin, automatically reading metadata definitions and generating corresponding form models. The form model uses a DSL language to define, configure, and render dynamic forms, using declarative syntax to describe form structure, behavior, and interaction rules. The front-end of this invention is based on Vue.js, rendering dynamic forms and process interfaces.

[0022] The process plug-in is based on BPMN2.0 standard visual modeling, combined with metadata plug-in and form plug-in, and uses XPath-like syntax to achieve two-way binding between form fields and process variables; and dynamically sets the process rule engine based on JUEL expression to realize task flow.

[0023] Step S2: Design and create a database; specifically including the following steps: Step S21: using a metadata-driven approach to achieve automated integration of database design and form data storage; Step S22: Implementing data structure management throughout the entire life cycle through visualization tools; Step S3: Create a form and generate a DSL structure through the form in combination with metadata information. Generate a dynamic form through visualization based on the form engine. The form engine is a tool for quickly creating and managing dynamic forms. It allows users to define form fields, layouts, and validation rules through a visual interface or configuration files without writing code. It is widely used in scenarios such as data collection, questionnaires, and approval processes to improve development efficiency and ensure data consistency.

[0024] The specific steps include: Step S31: Using the design-development integration model, the form plug-in in step S1 is used to convert the metadata information into a DSL structure through a visual form designer, generating a declarative form DSL that complies with the JSON Schema specification. The declarative form DSL is a domain-specific language specifically used to describe the structure and behavior of a form. Step S32: A high-performance form rendering engine generates a dynamic form. That is, the front end renders the form in real time by connecting to the DSL and implements field verification, visibility, etc. according to the validation rules in the DSL.

[0025] Among them, the form includes field types, labels, validation rules, etc.

[0026] Converting metadata information into a DSL structure involves the following steps: Step B1: Convert metadata information into an intermediate model. Map the database type to the intermediate type, generate an intermediate JSON structure, and perform standardization of metadata information. For example, convert VARCHAR to string and INT to number. The code for standardizing metadata information in this embodiment is as follows: json { "fields": [ { "name": "username", "type": "string", "constraints": {"required": true, "maxLength": 50} }, { "name": "age", "type": "number", "constraints": {"required": false}}]} Step B2: Generate a form DSL based on the intermediate model that supports multiple extended functions; the extended functions include UI components, validation rules, and dynamic drop-down boxes; Step B21: Convert the field type in the intermediate model to a UI component mapping. The matching rules can be overridden through the configuration file. The matching rule code is as follows: yaml # Component mapping rules mappings: string: default: "input" formats: email: "email-input" number: "number-input" date: "date-picker" The conversion result example: json { "type": "input", "field": "username", "label": "Username" } Step B22: Convert the constraints in the database into validation rules in the front end. For example, if the database constraint is nullable: false, the converted validation rule is "required": true; if the database constraint is maxLength: 50, the converted validation rule is "max": 50, "message": "Exceeds length limit". The sample code of this embodiment is as follows: "rules": [ {"required": true, "message": "Username cannot be empty"}, {"max": 50, "message": "The length cannot exceed 50 characters"} ] Step B23: Convert the foreign key in the database into a dynamic drop-down box. If the field is the foreign key dept_id, an associated query interface and drop-down component will be automatically generated. The sample code is as follows: { "type": "select", "field": "dept_id", "label": "Department", "options": " / api / dept / list", / / Dynamically load options "props": { "valueField": "id", "labelField": "name" }} Step B3: Enhance the dynamic form template to support user-defined DSL structures and override default rules. This is done by providing a basic DSL template and injecting metadata through placeholders to achieve replacement. In this embodiment, the placeholder is ${field}. The sample code for the dynamic form template enhancement is as follows: { "type": "${component}", "field": "${name}", "label": "${label|capitalize}" / / Pipeline filter support } Result after replacement: { "type": "input", "field": "username", "label": "Username" } Step B4: Output the final form in DSL format; that is, generate a form DSL in JSON Schema format that can be directly rendered. The sample code for the final output is as follows: json { "formId": "user_form", "fields": [ { "type": "input", "field": "username", "label": "Username", "rules": [ {"required": true, "message": "Required field"}, {"max": 50, "message": "Length limit 50 characters"} ]}, { "type": "number-input", "field": "age", "label": "age" }, { "type": "select", "field": "dept_id", "label": "Department", "options": " / api / dept / list" }], "actions": [ {"type": "submit", "url": " / api / user / submit"} ]} This process is fully automated, with zero manual conversion from the database to the form DSL. It also supports complex scenarios, such as custom components and validation rules, through the rule engine and templates, and has good scalability. It also ensures strict synchronization between database constraints and front-end validation, guarantees consistency, and achieves a closed-loop conversion from metadata to DSL, significantly reducing form development and maintenance costs.

[0027] Step S4: Return the form's DSL structure to the process design. Through the process design, a mapping relationship between the form and the process is established. The process designer determines the process branches based on the form fields and generates a process definition. Magic-API is then used to quickly generate form-related data interfaces. These interfaces include form data submission interfaces, form data addition interfaces, form data deletion interfaces, form data query interfaces, and form data update interfaces. Step S5: Associating the data interface in step S4 with the dynamic form in step S3 to generate a complete form structure; that is, associating the generated data interface with the front-end form to ensure that the form data can be correctly stored and read; and automatically associating the data interface with the front-end form through dynamic binding and metadata-driven implementation, specifically including the following steps: Step S51: Map the data interface to the metadata of the form; automatically convert the metadata and the form DSL into the RESTful interface in the Magic-API interface through the interface conversion component, reducing the development workload and quickly building the backend service; specifically, the following steps are included: Step S51-1: Standardize the CRUD interface framework, define four basic operation templates based on the RESTful specification, build interface templates, and support dynamic parameter injection; the basic operation templates include insert, delete, update, and query; Step S51-2: Get the table name and primary key field through the database metadata, and add parameter validation rules based on the field type; for example, for the id field in the user table, generate a basic CRUD interface path; Database metadata refers to information that describes the database structure, including tables, columns, data types, indexes, and constraints, helping users understand how the database is organized. Database metadata is stored in system tables for use by database management systems and developers.

[0028] Step S51-3: Perform bidirectional verification through metadata and form DSL to synchronize the verification rules to the Magic-API interface; after the database table structure is changed, the full-link automatic update from metadata to form DSL and then to Magic-API interface can be completed within ten minutes.

[0029] Step S52: Dynamically bind the RESTful interface generated by Magic-API to the form metadata; utilize the Magic-API dynamic compilation mechanism to quickly generate the RESTful interface and form template by reading the database metadata. At the same time, form generation and process design are implemented through configuration, significantly improving development efficiency; Step S53: Magic-API generates a data interface according to the metadata structure; Step S54: Bind the form DSL with the metadata; Step S55: When the form is loaded and submitted, the corresponding data interface is automatically called, and the data is processed through field mapping and converted into the parameter format required by the interface.

[0030] Step S6: Define process nodes and their flow rules through the process plug-in, and associate the process nodes with corresponding forms; the flow rules include the process startup conditions, the jump rules between process nodes, and the approval logic, which respectively control the triggering time of the process, the flow path, and the task execution method; the method of dynamically associating processes with forms enables each process task to be dynamically associated with a form, and the corresponding form is automatically loaded when the task is executed, so that the form data and process data are seamlessly integrated. Specifically, the following steps are included: Step S61: Combine the generated form with the process engine to build a business process; Step S62: Designing a BPMN process; the BPMN process includes user tasks for displaying and filling in dynamically generated forms; Step S63: Bind the form to the specified user task; Step S64: The user fills in and submits the form to the process engine, which processes the task. When the user fills in and submits the form, the data interface in Magic-API submits the form data to the corresponding task through the REST API in the process plug-in. The saved form data is used as a process variable for subsequent process use. The process engine is a software component used to automate and manage business processes. It coordinates the interactions between tasks, people, and systems by defining and executing workflows. The traffic engine supports process modeling, monitoring, and optimization, and is often used in scenarios such as approval and order processing.

[0031] The process start condition is dynamically determined based on an EL expression. In this embodiment, the executive approval process is triggered by ${formData.amount > 10000}. The jump rules between process nodes are used to control the selection of different paths of the process. <sequenceflow>of <conditionexpression>Dynamically parse form fields, based on form data, process variables, or external system data. This embodiment dynamically parses the following form fields: xml <conditionexpression xsi:type="tFormalExpression"> ${formData.department == 'Finance'} < / conditionexpression> The approval logic controls the allocation and execution of tasks, supporting single-person approval, joint approval and other modes; <usertask assignee="${formData.manager}">Dynamically assign approvers and support countersignature.

[0032] Step S7: Package the developed multi-plugin and publish it to the plug-in repository of Magic-API. Users can update the task status through the multi-plugin and notify the front-end submission result; that is, other users can install and use the plug-in through the plug-in repository to quickly implement the form process processing function.

[0033] Based on the Magic-API plug-in mechanism, this invention deeply integrates metadata management, form generation and process engine for the first time, forming a method for automated management from form design to process processing. Through the plug-in mechanism and configuration design, it reduces development and maintenance costs, realizes automated management of business processes, improves system maintainability and applicability, and can significantly improve development efficiency in scenarios with frequent demand changes and complex business processes.

[0034] The above embodiments are not limitations of the present invention, and the present invention is not limited to the above examples. Any changes, modifications, additions or substitutions made by technicians in this technical field within the scope of the technical solution of the present invention also fall within the scope of protection of the present invention.< / usertask> < / conditionexpression> < / sequenceflow> < / string> < / string> < / columndata> < / columndata> < / tabledata> < / tabledata> < / columndata> < / tabledata> < / string> < / conditionexpression>

Claims

1. A form flow processing method based on the Magic-API plug-in mechanism, characterized in that: The specific steps include: Step S1: Create a multi-plugin in Magic-API and obtain metadata information through the meta-processor in Magic-API; Step S2: Design and create a database based on a metadata-driven approach; Step S3: Combine metadata information and generate DSL structure through form, and generate dynamic form through visualization tool based on form engine; Step S4: Return the DSL structure of the form to the process design, and establish a mapping relationship between the form and the process through the process design; The process designer determines the process branch based on the form fields and generates the process definition; And use Magic-API to quickly generate data interfaces related to the form; Step S5: Associating the data interface in step S4 with the dynamic form in step S3 to generate a complete form structure; Step S6: Define the process nodes and their flow rules through the process plug-in in the multi-plug-in, and associate the process nodes with the corresponding forms; Step S7: Submit the form to the process engine, which processes the form; Step S8: The Magic-API multi-plugin updates the task status and notifies the front-end of the submission result.

2. The form flow processing method based on the Magic-API plug-in mechanism according to claim 1, characterized in that: The multiple plug-ins in step S1 include metadata plug-ins, which are used to implement end-to-end automated management from database fields to business processes; Form plug-in, used to build extension components based on metadata plug-in, automatically read metadata definitions and generate corresponding form models; The process plug-in is used for standardized modeling based on BPMN. It combines the metadata plug-in and the form plug-in, uses XPath-like syntax to implement two-way binding between form fields and process variables, and dynamically sets the process rule engine based on JUEL expressions to realize task flow.

3. The form flow processing method based on the Magic-API plug-in mechanism according to claim 2, characterized in that: The metadata plug-in is a three-layer metadata model; the three-layer metadata model includes a basic layer, a business layer, and a process layer; the connection method of the three-layer metadata model specifically includes the following steps: Step A1: Mark the field metadata in the base layer through the metadata processor; Step A2: The business layer aggregates metadata of each field and generates entity constraint objects; Step A3: Analyze foreign key constraints between entity constraint objects using graph theory algorithms to automatically identify proportional relationships between entities; Step A4: The state machine drives the process flow; Step A5: Bind the status field of the business entity to the BPMN process node in the process layer to achieve two-way data synchronization.

4. The form flow processing method based on the Magic-API plug-in mechanism according to claim 3, characterized in that: The metadata information includes table information, column information, data type, index information and constraint information; table information includes table name and table description, column information includes column name, data type, whether it is allowed to be empty, default value, primary key and foreign key; index information includes index name, index type and index column; constraint information includes primary key constraint, unique constraint, foreign key constraint and check constraint.

5. The form flow processing method based on the Magic-API plug-in mechanism according to claim 4, characterized in that: The step S3 generates a dynamic form, which specifically includes the following steps: Step S31: adopting the design and development integration mode, and based on the form plug-in in step S1, converting the metadata information into a DSL structure through a visual form designer; Step S32: Verification is implemented according to the validation rules in the DSL, and the front end renders the form in real time by connecting to and unloading the DSL.

6. The form flow processing method based on the Magic-API plug-in mechanism according to claim 5, characterized in that: The step S31 converts the metadata information into a DSL structure, specifically including the following steps: Step B1: Convert the metadata information into an intermediate model, map the intermediate model database type to an intermediate type, generate an intermediate JSON structure, and perform standardization of the metadata information; Step B2: Implement various extended functions for the form based on the intermediate model, including UI components, validation rules, and dynamic drop-down boxes; Step B3: Enhance the dynamic form template to enable users to customize the DSL structure; Step B4: Output the final form in DSL format.

7. The form flow processing method based on the Magic-API plug-in mechanism according to claim 6, characterized in that: The step B2 implements multiple extended functions, specifically including the following steps: Step B21: Convert the field type in the intermediate model to UI component mapping; Step B22: Convert the constraint conditions in the database into the verification rules of the front end; Step B23: Convert the foreign key in the database into a dynamic drop-down box.

8. The form flow processing method based on the Magic-API plug-in mechanism according to claim 7, characterized in that: The step S5 generates a complete form structure, which specifically includes the following steps: Step S51: automatically convert the metadata and form DSL into a RESTful interface in the Magic-API interface through the interface conversion component; Step S52: Dynamically bind the RESTful interface generated by Magic-API to the form metadata; Step S53: Magic-API generates a data interface according to the metadata structure; Step S54: Bind the form DSL with the metadata; Step S55: When the form is loaded and submitted, the corresponding data interface is automatically called, and the data is processed through field mapping and converted into the parameter format required by the interface.

9. The form flow processing method based on the Magic-API plug-in mechanism according to claim 8, characterized in that: The step S51 automatically converts the metadata and form DSL into a RESTful interface, specifically including the following steps: Step S51-1: Standardize the CRUD interface framework, define four basic operation templates based on the RESTful specification, and support dynamic injection of parameters; Step S51-2: Obtain the table name and primary key field through the database metadata, and add parameter validation rules based on the field type; Step S52-3: Perform bidirectional verification through metadata and form DSL to synchronize the verification rules to the Magic-API interface.

10. The form flow processing method based on the Magic-API plug-in mechanism according to claim 9, characterized in that: In step S6, the process node is associated with the corresponding form, which specifically includes the following steps: Step S61: Combine the generated form with the process engine to build a business process; Step S62: Designing a BPMN process; the BPMN process includes user tasks for displaying and filling in dynamically generated forms; Step S63: Bind the form to the specified user task; Step S64: When the user fills in and submits the form, the data interface in Magic-API submits the form data to the corresponding task through the REST API in the process plug-in.

Images