Intelligent file service system generation method based on low-code development mode

Abstract

The invention discloses an intelligent file service system generation method based on a low-code development mode. The method comprises the following steps: constructing a file service core data model, defining file metadata fields, a storage structure and an association relationship, and forming a standardized data architecture. According to the method, the core data model, the visual page component library and the drag-and-drop workflow template are constructed, linkage binding of data-component-process is achieved in combination with a low-code engine, and the efficiency bottleneck of a traditional development mode is broken through; through a three-way real-time synchronization mechanism, real-time hot repair and dynamic branch judgment, page layout and flow rule adjustment can take effect immediately through visual configuration, and the problem of dynamic demand response lag is solved; through the intelligent resource scheduling logic compiled through environment adaptation, a differentiation scheme is generated for different deployment environments, the configuration difference influence under a private cloud and server mixed deployment scene is remarkably reduced, the deployment failure rate is greatly reduced, and the system online stability is improved.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of computer software development and file management, and particularly relates to an intelligent file service system generation method based on a low-code development mode. BACKGROUND

[0002] As a core support of enterprise data management, the efficient development and flexible deployment of the intelligent file service system are crucial to business operation. At present, with the improvement of the fine and process requirements of enterprises on file management, the development demand of the intelligent file service system is increasing, but many problems still exist in the actual development process. 1. Development efficiency bottleneck: under the traditional coding mode, the basic functions such as file storage and query need to be repeatedly implemented, and such work occupies more than 70% of the development resources, which seriously restricts the system development progress. 2. Dynamic demand response lag: the user frequently adjusts the page layout and work flow rule, and each change needs to manually modify the front-end and back-end codes, which leads to a system iteration cycle of several weeks and makes it difficult to quickly respond to business changes. 3. Deployment environment fragmentation: in the private cloud and server hybrid deployment scenario, the configuration of different environments is quite different, which leads to a system deployment failure rate of more than 40%, affecting the system online stability. Therefore, an intelligent file service system generation method based on a low-code development mode is provided. SUMMARY

[0003] The application aims to provide an intelligent file service system generation method based on a low-code development mode to solve one of the problems in the background technology.

[0004] To solve the above technical problems, one technical solution adopted by the application is an intelligent file service system generation method based on a low-code development mode, which comprises the following steps. Step 1: build a file service core data model, define file metadata fields, storage structure and association relationship, and form a standardized data architecture; Step 2: based on the core data model, build a visual page component library, and establish a one-to-one mapping interface between component attributes and file metadata fields; Step 3: according to the business process requirements, configure the file flow node and path rule under the support of the page component library, and directly associate the node attributes with the file metadata fields to form a visual workflow template that can be dragged; Step 4: through the low-code engine, the page components and data model fields are mapped and bound, and the trigger logic of the workflow node and component operation is associated to form a data-component-process linkage binding relationship; Step five, based on the linkage binding relationship, combined with the file metadata field attribute, configure the intelligent business rule engine, set the automation logic; Step six, according to the characteristics of the target deployment environment, the environment adaptation and compilation of intelligent business rule engine and linkage binding relationship, generate executable program package; Step seven, deploy the executable program package and start running monitoring, real-time collection of running data, and feedback the analysis results to the page component library, visual workflow template and core data model.

[0005] As a further preferred of the technical solution: in step one, the core data model adopts dynamic field expansion mechanism, supports real-time adding or deleting custom metadata field through visual interface, and automatically synchronizes the database table structure, index rule and mapping interface of page component library when the field changes.

[0006] As a further preferred of the technical solution: in step four, the linkage binding relationship adopts three-way real-time synchronization mechanism, specifically including: If the page component operation triggers data change, automatically synchronize the workflow node state and core data model field value; If the workflow node state changes due to rule engine execution, reverse drive page component refresh display and write back core data model; If the core data model field is modified by an external system, trigger component re-rendering and workflow node verification at the same time.

[0007] As a further preferred of the technical solution: in step five, the intelligent business rule engine integrates machine learning module, automatically optimizes rule parameters by analyzing collected historical running data, and generates rule iteration suggestions for user confirmation.

[0008] As a further preferred of the technical solution: in step seven, the running monitoring includes real-time hot repair mechanism, if the page component is abnormal or the workflow is blocked, the problem node is located based on the linkage binding relationship, the component attribute or process rule is modified through the visual interface, and the modification content takes effect immediately after real-time compilation by the low-code engine without restarting the system.

[0009] As a further preferred of the technical solution: in step six, the environment adaptation and compilation includes intelligent resource scheduling logic, by detecting the CPU, memory, storage and network bandwidth parameters of the target environment, combining the calculation complexity of the intelligent business rule engine and the storage demand of the core data model, automatically generating differentiated deployment scheme, wherein, in the lightweight environment, non-core components are compressed, and in the high-performance environment, distributed storage strategy is enabled.

[0010] As a further preferred of the technical solution: in step two, the page component library terminal adaptive engine is integrated, the component layout, interaction mode and rendering precision can be automatically adjusted according to the hardware parameters of the access terminal, and the adaptation rule is associated with the terminal adaptation field in the core data model, and the user-defined terminal display priority is supported.

[0011] As a further preferred of the technical solution: in step three, the dynamic branch determination mechanism is built in the visualization workflow template, the multi-path flow rule is automatically generated based on the metadata field in the core data model, and the branch weight is configured through the visualization interface, and the rule is automatically synchronized to the linkage binding relationship when the rule is changed.

[0012] As a further preferred of the technical solution: the core data model includes a file life cycle management field set, the life cycle management field set is used to record the file full life cycle information, and the field set is linked with the running monitoring data to automatically trigger the expired file archiving or deleting process.

[0013] As a further preferred of the technical solution: the historical running data includes file flow transfer time consumption, approval rejection rate and permission call frequency.

[0014] Advantages of the application: 1. The application realizes the linkage binding of data-component-process by constructing the core data model, the visualization page component library and the drag-and-drop workflow template, combined with the low-code engine, reduces more than 70% of the repeated coding work, and breaks through the efficiency bottleneck of the traditional development mode; 2. The application realizes the three-way real-time synchronization mechanism, real-time hot repair and dynamic branch determination, so that the adjustment of page layout and process rules can be instantly effective through visual configuration, the system iteration cycle is shortened from weeks to minutes, and the dynamic demand response lag problem is solved; 3. The application realizes the intelligent resource scheduling logic of environment adaptation and compilation, generates differentiated schemes for different deployment environments, significantly reduces the influence of configuration differences in private cloud and server hybrid deployment scenarios, greatly reduces the deployment failure rate from more than 40%, and improves the system online stability. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0016] Figure 1This is a flowchart illustrating a method for generating an intelligent file service system based on a low-code development model according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example Figure 1 This is a flowchart illustrating a method for generating an intelligent file service system based on a low-code development model according to an embodiment of the present invention. It should be noted that if substantially the same result is achieved, the method of this application is not necessarily identical. Figure 1 The illustrated process sequence is limited. For example... Figure 1 As shown: A method for generating an intelligent file service system based on a low-code development model includes the following steps: Step 1: Construct the core data model for the file service, define file metadata fields, storage structure and relationships, and form a standardized data architecture; Specifically, first, we need to identify the core business requirements in the file service scenario and determine the basic file metadata fields, including basic attributes such as file name, type, size, creation time, modification time, storage path, owner, and permission identifier; Then, based on the basic fields, design the storage structure, clarify the data sharding rules, redundancy strategies and encryption methods, such as using partitioned tables to store metadata of different types of files, and setting encryption storage rules for key fields; Next, define the relationships between metadata fields, such as the ownership relationship between files and users, the inheritance relationship between file versions, and the inclusion relationship between folders and files, and visualize them through an entity relationship diagram (ER diagram); Next, deploy the dynamic field extension module, develop a visual operation interface, and support users to add, edit or delete custom metadata fields (such as file tags, approval status, etc.) in real time through drag and drop or form input, and configure field types (text, number, date, etc.) and validation rules. At the same time, an automatic synchronization mechanism for field changes is established. When a custom field is added, removed, or modified, the database table structure is automatically updated (such as adding columns or adjusting field types), index rules are rebuilt (to optimize the efficiency of related queries), and the mapping interface of the corresponding component in the page component library is updated synchronously. Finally, the basic field, storage structure, association relationship and dynamic expansion mechanism are integrated to form a standardized data architecture document containing data dictionary, storage specification and association rule, which serves as the basis for subsequent page component development and workflow configuration.

[0019] Step two, based on the core data model, build a visual page component library, and establish a one-to-one mapping interface between component attributes and file metadata fields. Specifically, first, based on the core data model constructed in step one, the attribute characteristics of all file metadata fields (including field type, data length, verification rule, display format, etc.) are sorted out, and the basic component types required by the page component library are determined, such as: text input component (corresponding to string type field such as file name), digital display component (corresponding to numerical value type field such as file size), date selection component (corresponding to date type field such as creation time), drop-down selection component (corresponding to enumeration type field such as permission identifier), file upload component (corresponding to interactive field associated with file storage path) and the like. Then, design attribute parameters for each basic component to ensure that the component attributes and the attribute characteristics of the corresponding metadata fields form a one-to-one mapping, for example: the "maximum length" attribute of the text input component maps the "character limit" of the file name field, the "option list" attribute of the drop-down selection component maps the "enumeration value range" of the permission identifier field, and a standardized mapping interface (such as a JSON format configuration file) is developed to realize the real-time association of component attributes and metadata field attributes. Next, the components are classified and packaged to build the hierarchical structure of the visual page component library, which is divided into basic display class (such as file information card component), interactive operation class (such as file editing component, permission setting component), file processing class (such as preview component, download component) and the like. The components under each module support drag-and-drop calling, and the default style and initial state of the components are configured. Then, integrate the terminal adaptive engine into the component library and develop a component adaptation rule configuration module to associate the layout parameters (such as width, arrangement method) of the component, the interaction method (such as click / scroll), the rendering precision (such as resolution adaptation) with the "terminal adaptation field" (such as terminal type, screen size threshold) in the core data model, for example: when the terminal is a mobile device, the file list component automatically switches to single-column layout and click interaction is changed to scroll interaction. At the same time, a terminal display priority configuration interface is developed to support users to customize the display priority of components under different terminals through visual operations (such as drag-and-drop sorting), and the priority rules are stored in the terminal adaptation field of the core data model for calling by the terminal adaptive engine. Finally, a real-time verification mechanism for component-field mapping is constructed. When the metadata fields of the core data model are dynamically expanded or changed (such as adding custom fields in step one), the mapping interface of the component library is automatically triggered to update, and the corresponding component attribute parameters are synchronously adjusted to ensure that the component attributes and metadata fields always maintain a one-to-one mapping relationship. A visual interface is provided to display all components and mapping states of the component library, allowing users to preview and call them.

[0020] Step three, according to the business process requirements, configure file transfer nodes and path rules under the support of page component library, node attributes are directly associated with file metadata fields, forming a visual workflow template that can be dragged and dropped; Specifically, first, analyze the business process requirements of file services (such as file approval, version transfer, cross-department distribution, etc.), determine the core transfer node types, such as: initiation node (corresponding to file creation / upload operation), review node (corresponding to department or role approval operation), processing node (corresponding to file editing / conversion operation), archiving node (corresponding to final file storage state), rejection node (corresponding to process return operation), etc., and assign a unique identifier to each node; Then, configure attribute parameters for each transfer node, including node name, processing role (associated with the "user" field in the core data model), processing time limit (associated with the "time threshold" metadata field), operation permission (associated with the "permission identifier" field), etc., to ensure that node attributes are directly associated with file metadata fields, such as: the "processing role" attribute of the review node maps the enumeration value of the "reviewer" field in the metadata, and the processing time limit attribute maps the value of the "maximum processing time" field; Next, based on the interactive components in the page component library (such as process line components, conditional judgment components), design the path rules between nodes, clearly define the trigger conditions from one node to the next node (such as passing the review to enter the next node, rejecting the review to return to the previous node), and bind the trigger conditions with the state values of the metadata fields (such as the "pass" and "reject" enumerations of the "review status" field); Then, integrate a dynamic branch determination mechanism into the path rule configuration, automatically generate multi-path transfer rules based on the metadata fields of the core data model (such as file type, size, department, etc.), such as: when the file type is "contract", the transfer path automatically includes the "legal review" node; when the file size exceeds 100MB, the transfer path automatically adds a "compression processing" node; At the same time, develop a visual interface for branch weight configuration, allowing users to set the priority weights of different branches (such as "urgent file" branch weight higher than "ordinary file" branch) through drag-and-drop sliders or numerical input, and store the weight rules in the configuration data of the workflow template, and associate them with the "process priority" field of the core data model; After that, a dragable visual workflow design interface is built to display the configured flow nodes and path rules in a graphical way (e.g. nodes are rectangular boxes and paths are lines with arrows), supporting users to adjust the positions of nodes by dragging, and modify the rules of paths by clicking, and the interface real-time links to the page component library to call the relevant components of the flow (e.g. node property editing component, path condition configuration component) to assist configuration; Finally, when the node properties or path rules are changed, the synchronization mechanism (associated with the linkage logic in step four) is automatically triggered to ensure that the configuration updates of the workflow template are reflected in real time in the association of data-component-flow, and the finally configured workflow is saved as a reusable template in the system template library for subsequent calling and modification.

[0021] Step four, through the low-code engine, the mapping binding between page components and data model fields is established, and the trigger logic of workflow nodes and component operations is associated to form the linkage binding relationship of data-component-flow; Specifically, first, the mapping rule configuration module of the low-code engine is initialized to define the association syntax (e.g. based on JSON configuration protocol) between page components, data model fields and workflow nodes, and to clearly describe the format of the binding relationship (including the corresponding relationship of component ID, field identifier, node unique identifier and trigger event type); Then, through the visual configuration interface of the low-code engine, the target component in the page component library is called, the corresponding metadata field in the core data model is selected, and the mapping binding between component properties and field values is established - for example, the "state text" property of the "file status display component" is bound to the "approval status" field of the data model, and the "value display" property of the "file size component" is bound to the "file size" field, and a mapping relationship table is generated and stored in the configuration center of the engine; Next, the trigger logic of workflow nodes and component operations is associated: for the interactive operations of page components (such as clicking the "submit for audit" button component, modifying the "file priority" drop-down component), the corresponding workflow node state change rule is configured through the low-code engine - for example, when the "submit for audit" button component is clicked, the workflow is triggered to switch from the "initiation node" to the "department audit node"; when the value of the "file priority" component is changed to "urgent", the "processing time limit" property of the workflow node is triggered to update synchronously to the value of the "urgent processing time length" field in the data model; Then, the underlying logic of the three-way real-time synchronization mechanism is implemented, which is as follows: Develop a data change listening module. When the page component operation causes the data model field value to change (such as editing the component to modify the "file name" field), the engine automatically extracts the change information, synchronously updates the properties associated with the field in the workflow node (such as the "associated file identifier" of the node), and records the synchronization log; Deploy the node state reverse drive module. When the workflow node changes state due to rule engine execution (such as the "audit node" state changing to "pass"), the engine automatically triggers the corresponding page component refresh (such as the "audit result display component" updating to the "pass" icon), and simultaneously writes the node state value back to the "process state" field of the data model; Configure the external data modification response mechanism. When the core data model field is modified by an external system (such as a third-party storage service) (such as the "storage path" field update), the engine triggers the re-rendering of the associated component (such as the path parameter update of the "file download component") in real time, and starts the workflow node verification (verifies whether the new path meets the current node's storage rules); Finally, through the linkage relationship visualization interface of the low-code engine, the binding relationship and synchronization status between the data model field, page component, and workflow node are displayed in graph form, supporting users to adjust the association logic through drag-and-drop, and automatically generating linkage configuration files (such as XML format) as the basis for subsequent intelligent business rule engine configuration.

[0022] Step five, based on the linkage binding relationship, combined with the file metadata field attributes, configure the intelligent business rule engine, and set the automation logic; Specifically, first, based on the data-component-process linkage binding relationship formed in step four, sort out the business scenarios that need to be automatically processed in the file service scenario (such as automatic approval, expiration reminder, and exception interception), and clearly define the file metadata field attributes associated with each scenario (such as "file type", "priority", "processing status", etc.); Then, configure the basic automation rules of the intelligent business rule engine: through the visual rule configuration interface, define the rule trigger condition (based on the metadata field attribute) and the execution action (associated with the workflow node or page component operation); for example, set "when the 'priority' field in the file metadata is 'urgent' and the 'flow time' exceeds 24 hours", trigger the "timeout warning" action, and the execution action includes: the workflow node is automatically marked as "to be urgently handled", the "state prompt" component in the page component displays a red warning mark, and the "processing status" field in the core data model is updated to "warning"; Next, integrate machine learning modules into the intelligent business rules engine, develop data collection interfaces, collect historical operation data in real time (including file transfer time, approval rejection rate, permission call frequency, etc.), and establish a rule optimization model; for example, by analyzing the characteristics of files with a high "approval rejection rate" (such as "contract files + lack of 'legal review marker' field"), the model automatically identifies the direction of rule optimization; Then, based on the output of the machine learning model, automatically optimize the rule parameters: the engine dynamically adjusts the rule trigger threshold based on historical data patterns (such as optimizing the threshold of "automatic activation of manual review when the approval rejection rate of ordinary files exceeds 30%" from 30% to 25% according to actual data), and generates rule iteration suggestions (such as "suggest adding a rule that 'financial files must be reviewed by the general manager if the amount exceeds 100,000'"), which are pushed to the user for confirmation through a visual interface; At the same time, associate the automated rules with the three-way real-time synchronization mechanism: when page component operations, workflow node states, or core data model fields change (triggering synchronization in the linkage binding relationship), the intelligent business rules engine automatically checks whether the rule conditions are met, and if so, executes the preset actions in real time, ensuring that the automated logic is in real-time linkage with the state of data, components, and processes; Finally, build a rule validity checking mechanism: simulate the operation of configured automated rules, verify the accuracy of rule triggering by injecting historical data (such as simulating the "emergency file timeout" scenario to check whether the warning action is triggered correctly), and feed back the checking results to the rule configuration interface, allowing users to adjust rule conditions or actions through drag-and-drop, ensuring that the automated logic meets business needs.

[0023] Step six, according to the characteristics of the target deployment environment, adapt and compile the intelligent business rules engine and linkage binding relationship to the environment, and generate an executable program package; Specifically, first, develop an environment detection module to scan the hardware and software characteristics of the target deployment environment through automated scripts or probe tools, collect key parameters, including CPU core count, memory capacity, storage space size, network bandwidth peak, operating system type and version, database type (such as MySQL, PostgreSQL), middleware configuration (such as Tomcat, Nginx), etc., and package the parameter data as an environment feature dataset; Then, analyze the computational complexity of the intelligent business rules engine and the storage requirements of the core data model: based on the number of automated rules in the rule engine, the trigger frequency, and the algorithmic consumption of the machine learning module (such as parallel computing requirements during historical data analysis), evaluate the required computing resources; combined with the metadata field size of the core data model, the total file storage, and the expected data growth, determine the allocation standard of storage resources; Next, based on the environmental feature dataset and resource demand analysis results, a differentiated deployment scheme is generated through intelligent resource scheduling logic: if the target environment is a lightweight environment (such as edge nodes, low-configuration servers, represented by CPU core number ≤ 2, memory ≤ 4GB), non-core components are compressed (such as turning off the real-time optimization function of the machine learning module, simplifying the advanced rendering effect of the page component), and only core functions such as file transfer and basic approval are retained; if the target environment is a high-performance environment (such as private cloud clusters, high-configuration servers, represented by CPU core number ≥ 8, memory ≥ 32GB, and support for distributed storage), a distributed storage strategy is enabled (metadata and file content of the core data model are stored separately, metadata is stored in the master node database, and file content is stored in the slave node), and the parallel computing mode of the rule engine (multi-threaded processing of rule triggering and execution) is activated; Then, the intelligent business rule engine and the linkage binding relationship are adapted and compiled according to the differentiated scheme: according to the differentiated scheme, the configuration parameters of the rule engine are adjusted (such as reducing the rule trigger detection frequency in a lightweight environment, and increasing the number of parallel threads in a high-performance environment), the synchronization mechanism of the linkage binding relationship is modified (such as using incremental synchronization instead of full synchronization in a low-bandwidth environment), and the adapted rules and binding relationships are converted into executable code for the target environment (such as generating.exe files for Windows environments and.sh scripts for Linux environments) through the compilation module of the low-code engine; At the same time, a compilation result verification mechanism is established to simulate the hardware limitations of the target environment (such as limiting CPU and memory through virtual machines), run the compiled intermediate code, detect whether the core functions (such as file upload transfer and rule automatic triggering) are executed normally, and verify whether the resource occupation meets the expectations (such as memory occupation ≤ 2GB in a lightweight environment); Finally, the verified compilation results are packaged into an executable program package, including the adapted rule engine binary file, the linkage binding relationship configuration file, the environment dependent library (such as a specific version of JRE, database driver), and the deployment instruction document. The program package supports one-key installation and automatically reads the target environment parameters to complete the initialization configuration.

[0024] Step seven, deploy the executable program package and start running monitoring, real-time collection of running data, and feedback of analysis results to the page component library, visual workflow template and core data model; Specifically, first, execute the deployment process of the executable program package: load the program package through the one-key installation script, automatically complete the configuration of the environment dependent library (such as installing the adapted JRE version, database driver), interface with the storage resources of the target environment (such as mounting the distributed storage path or local disk directory), and initialize the mapping relationship between the core data model and the database table structure, ensuring that the program package is correctly associated with the hardware and software resources of the deployment environment; Then, start the running monitoring module, configure real-time monitoring indicators: including the rendering success rate of page components, response delay (such as file preview component loading time), workflow node flow efficiency (such as node average processing time, path jump success rate), intelligent business rule engine execution status (such as rule triggering success rate, automatic action execution time), and core data model field access frequency, storage read-write performance, etc. The monitoring module collects these indicator data in real time through the embedding technology; Next, establish a real-time data collection and storage mechanism: collect the above monitoring indicators through multi-thread asynchronous collection, and store the data in categories - business data such as file flow time, approval rejection rate, and permission call frequency are associated with the "running statistics field set" of the core data model, system data such as component exception logs and workflow blocking records are stored in a special monitoring database, and the data change trend is recorded in time series format; Then, automatically analyze the collected data: identify abnormal states through pre-set analysis rules, for example, when the page component response delay exceeds the threshold value (such as 500ms), it is determined as a component exception, when the workflow node stays for more than twice the "processing time limit" metadata field value, it is determined as a process block, and when the rule engine triggering success rate is less than 90%, it is determined as a rule configuration deviation; At the same time, trigger the real-time hot repair mechanism (if an exception is detected): locate the problem source based on the data-component-process linkage binding relationship - if it is a component exception, it is automatically associated with the property configuration of the corresponding component in the page component library; if it is a process block, it is located to the corresponding node of the visual workflow template; through the modification entry provided by the visual interface, the user can directly adjust the component rendering parameters (such as reducing the rendering precision of mobile terminal components) or process rules (such as shortening the processing time limit of a node), and the modified content takes effect immediately after being compiled by the low-code engine in real time, without the need to restart the system; After that, the regular analysis results (non-exception class) are fed back to the target objects, including: Feedback to the page component library: based on the component response delay data, optimize the terminal adaptation rules of the component (such as adding a "lightweight rendering" option for high-delay components), and adjust the default layout parameters of the component on different terminals; Feedback to the visual workflow template: according to the node processing time distribution, automatically suggest adjusting the workflow path rules (such as adding "parallel processing branch" to high-frequency blocking nodes), and update the weight parameters of the dynamic branch judgment mechanism; Feedback to the core data model: based on field access frequency analysis, optimize the index rules (such as adding a joint index to high-frequency access fields), and adjust the archiving strategy of the "lifecycle management field set" in combination with storage read-write performance data (such as increasing the archiving retention period of high-frequency access files); Finally, a running monitoring report is generated to visualize charts (such as component performance trend charts and workflow flow efficiency heat maps) to show the analysis results and clear optimization points (such as parameter iteration suggestions for the rule engine) that require manual intervention, and the report data is synchronized to the machine learning module of the intelligent business rule engine as training data for optimizing rule parameters, forming a closed loop of "monitoring-analysis-feedback-optimization".

[0025] In this embodiment, specifically: in step one, the core data model adopts a dynamic field extension mechanism, supporting real-time addition or deletion of custom metadata fields through a visual interface, and automatically synchronously updating the database table structure, index rules, and mapping interfaces of the page component library when the fields are changed; Specifically, first, the core data model has a built-in dynamic field extension module, which provides a graphical operation interface (such as a drag-and-drop field configuration panel and a form-based field editing window), supports users to add custom metadata fields (for example, adding "signing party" and "validity period" fields for contract files, and adding "project number" and "confidentiality level" fields for R&D documents) or delete redundant fields (such as the "temporary tag" field) in real time according to business scenarios, and can configure the basic properties of the fields (including field type: text, number, date, enumeration, etc.; verification rules: required item, length limit, format verification, etc.; display name: field alias displayed by the front-end component) directly in the interface; Then, when the user completes the addition, deletion, or property modification operation of the field through the visual interface, the system automatically triggers a linkage synchronization mechanism, as follows: For the database table structure: dynamically generate a DDL statement (such as an ALTER TABLE statement), and automatically add a column (match the added field), delete a column (match the deleted field), or adjust the column properties (such as changing the field type from "varchar(50)" to "varchar(100)") in the corresponding data table without manually writing a database script; For the index rules: if the added field is a high-frequency query field (such as "project number"), the system automatically creates a single-column index or a joint index (such as a composite index combined with "creation time") for the field; if the deleted field is associated with an index, the corresponding index entry is automatically deleted to avoid invalid indexes occupying storage resources; For the mapping interfaces of the page component library: automatically update the association configuration of the components and the metadata fields (such as a JSON format mapping file), so that the corresponding interactive components (such as a drop-down selection component and a date picker component) in the page component library can immediately recognize the added fields and establish property mapping (such as the "validity period" field and the "default value" and "format" properties of the date selection component), or disassociate the deleted fields from the components, ensuring that there is no invalid field dependency when the components are called; Through this mechanism, the "visualization operation-full link automatic synchronization" closed loop of custom metadata fields is realized without the intervention of technical personnel in coding, greatly improving the flexibility and business adaptation efficiency of data models.

[0026] In this embodiment, specifically: in step four, the linkage binding relationship adopts a three-way real-time synchronization mechanism, specifically including: If the page component operation triggers data changes, automatically synchronize and update the workflow node state and core data model field values; If the workflow node state changes due to rule engine execution, reverse drive the page component to refresh and display and write back the core data model; If the core data model field is modified by an external system, trigger component re-rendering and workflow node verification at the same time; Specifically, the three-way real-time synchronization mechanism is realized through the event listening and automatic triggering logic of the low-code engine, ensuring that the states of the page component, workflow node, and core data model are real-time consistent, and the specific process is as follows: When the user performs an interactive operation on the page component (such as selecting "urgent" through the "file priority" drop-down component and clicking the "submit for review" button component), the page component will generate a data change event (including the change field identifier and new value). The low-code engine captures the event through the pre-set mapping binding relationship, automatically performs two operations of synchronously updating the workflow node state and writing back the core data model field, as follows: Synchronize and update the workflow node state: for example, after the "submit for review" operation is triggered, the workflow automatically switches from the "initiation node" to the "department audit node", and updates the "handler", "start time", and other attributes of the node (associated with the "auditor", "audit start time" fields of the core data model); Write back the core data model field: write the new value generated by the component operation (such as "urgent") into the corresponding metadata field of the core data model (such as the "file priority" field), to ensure that the data source and the component operation result are consistent; When the intelligent business rule engine executes the automatic logic (such as determining "file approval timeout"), the workflow node state changes (such as from "department audit node" to "timeout warning node"), and the low-code engine captures the node state change signal, triggers the reverse driving mechanism, as follows: Drive the page component to refresh and display: for example, after the "timeout warning node" state is triggered, the "process status component" in the page automatically refreshes from "under review" to "timeout warning" and displays a red reminder identifier; Write back the core data model: write the node state change result (such as "timeout warning") into the "process status" field of the core data model, and update the "timeout time" and other associated fields, to ensure that the data model records the process status in real time; When an external system (such as an enterprise OA system, a third-party storage service) modifies the core data model field through the API interface (such as the OA system updates the "file department" field, and the storage service updates the "file storage path" field), the core data model will trigger a field change notification, as follows: Trigger page component re-rendering: for example, after the "file storage path" field is modified, the "file download component" and "preview component" in the page automatically re-render, updating the download / preview link to the new path; Start workflow node verification: the system verifies whether the current workflow node meets the department association rule (such as "finance department files require finance director review node") according to the new field value (such as "file department" is changed to "finance department"), and if not, automatically adjusts the node transfer path to ensure compliance with the process; Through the above three-way synchronization logic, real-time linkage of page interaction, process status, and data storage is achieved, avoiding information lag or inconsistency, and supporting the system's rapid response to dynamic business needs.

[0027] In this embodiment, specifically: in step five, the intelligent business rule engine integrates a machine learning module, which automatically optimizes rule parameters by analyzing collected historical operation data, and generates rule iteration suggestions for user confirmation; Specifically, the machine learning module integrated in the intelligent business rule engine realizes automatic rule iteration through the closed-loop process of "data collection-feature analysis-model training-rule optimization-suggestion generation", as follows: First, the machine learning module collects historical operation data in real time through the system operation monitoring mechanism (step seven), including file transfer time (such as the average processing time of each workflow node, the number of timeouts), approval rejection rate (such as the rejection rate of different file types, the metadata field associated with the rejection reason), permission call frequency (such as the number of accesses to files by specific roles, permission change records), etc. The collected data will be cleaned (to remove outliers such as misoperation caused by ultra-short transfer time), standardized (to unify time, proportion, and other data formats), and feature extracted (such as associating "rejection rate" with "file type", "processing role", and other fields to form a feature vector) to provide high-quality input for model training; Then, the module uses a combination of supervised learning and unsupervised learning algorithms (such as decision trees and regression analysis) to analyze the preprocessed data, as follows: For existing rule parameters (such as "approval timeout threshold" and "threshold for triggering manual review based on rejection rate"), the regression model analyzes the correlation between parameter values and business results (such as timeout processing efficiency and review accuracy), and finds the optimal parameter range; By clustering algorithm to mine the business patterns that are not covered by existing rules, for example, find that the approval rejection rate in the combination scene of "contract type file + amount>500,000" is significantly higher than that in other scenes, identify the potential rule optimization space; Then, based on the model analysis results, the machine learning module automatically adjusts the key parameters of the existing rules, as follows: If the analysis finds that "when the file transfer time exceeds 24 hours (original threshold), the subsequent approval efficiency decreases by 40%", and the data shows that 20 hours is the efficiency inflection point, then automatically optimize the threshold of the "timeout warning" rule from 24 hours to 20 hours; If it is found that "the approval rejection rate of department A is highest when the threshold is 30%", then adjust the "rejection rate trigger review" threshold of this department to 25% to balance efficiency and accuracy; Then, the module generates specific rule iteration suggestions based on the pattern mining results, including adding new rules, adjusting rule conditions or actions, etc., and attaches data analysis basis; For example, based on the analysis result of "high rejection rate of contract type files and many due to 'lack of legal audit mark'", generate the suggestion: "add a rule: when the file type is 'contract' and the 'legal audit mark' field is empty, automatically trigger the 'legal pre-audit' node"; The suggestion is presented through a visual interface, including data support charts (such as a heat map of rejection rate and field association), for the user to determine whether to adopt it; Finally, the optimized parameters or new rules confirmed by the user are automatically synchronized to the rule library of the intelligent business rules engine, and are associated with the data model, page component, and workflow node through the linkage binding relationship (step four), ensuring that the optimized rules take effect in the system in real time - for example, the adjusted "timeout threshold" is synchronized to the "processing time limit" attribute of the workflow node and the "timeout reminder" display logic of the page component, realizing seamless connection between rule optimization and system operation; Through this process, the machine learning module enables the rule engine to have self-evolution ability, without the need for manual analysis of data one by one to dynamically adapt to business changes, improving the accuracy of rules and the intelligent level of the system.

[0028] In this embodiment, specifically, in step seven, the running monitoring includes a real-time hot repair mechanism: If a page component exception or workflow blockage is detected, the problem node is located based on the linkage binding relationship, and the component attribute or process rule is directly modified through the visual interface, and the modified content takes effect immediately after being compiled by the low-code engine in real time, without the need to restart the system; Specifically, the real-time hot repair mechanism in running monitoring relies on the data-component-process linkage binding relationship established in step seven to realize immediate repair of the whole process, and the specific process is as follows: The operation monitoring module tracks the status of page components (such as rendering success rate, interaction response time) and workflow nodes (such as flow continuity, path matching degree) in real time through burying points. When a component fails to render, the response delay exceeds the threshold, or a workflow node is stalled or abnormally jumps, an exception signal is automatically captured. Then, based on the linkage binding relationship, the problem source is traced back - if it is a component exception, the associated data model field and related workflow node are located through the component ID, and the data consistency or node state influence is checked; if it is a workflow blockage, the associated metadata field and triggering component are located through the node identifier, and the flow condition or operation triggering logic is checked. Then, the system opens a visual repair interface, provides a component attribute configuration panel (such as adjusting rendering parameters) or a process design canvas (such as modifying node attributes, path rules) for users to directly modify. The modified content takes effect immediately after incremental compilation by the low-code engine (only the related code fragments are updated), and the original configuration is overwritten. The entire process does not need to restart the system, realizes minute-level repair of page components and workflow problems, and ensures the continuous operation of the system.

[0029] In this embodiment, specifically: in step six, the environment adaptation compilation includes intelligent resource scheduling logic: By detecting the CPU, memory, storage, and network bandwidth parameters of the target environment, combining the calculation complexity of the intelligent business rule engine and the storage requirements of the core data model, a differentiated deployment scheme is automatically generated, wherein non-core components are compressed in a lightweight environment, and a distributed storage strategy is enabled in a high-performance environment; Specifically, the intelligent resource scheduling logic is the core execution layer of the environment adaptation compilation, and its running process is as follows: First, the key hardware parameters of the target deployment environment are collected by automatic detection tools (such as hardware probes, system command calls), including CPU core number, total memory capacity, available storage space, network bandwidth peak, etc., and these parameters are quantified as environment performance indicators (such as lightweight environment judgment threshold: CPU≤2 cores, memory≤4GB, bandwidth≤10Mbps; high-performance environment judgment threshold: CPU≥8 cores, memory≥32GB, support distributed file system); Second, based on the configuration information of the intelligent business rule engine (such as the number of rules, the triggering frequency of a single rule, the real-time calculation requirements of the machine learning module), the calculation complexity is evaluated, and at the same time, the storage resource requirements are determined according to the total amount of metadata fields of the core data model, the file storage size, and the expected growth rate; On this basis, the intelligent resource scheduling logic automatically matches the environmental performance and resource demand: if it is determined to be a lightweight environment (such as an edge server, a low-configuration terminal), a component compression mechanism is started, specifically including turning off the real-time parameter optimization function of the machine learning module in the rule engine, simplifying the advanced rendering effect (such as dynamic animation, high-definition preview) in the page component library, and retaining only the core rules such as file basic flow and approval, so as to reduce the computing power and memory occupation; if it is determined to be a high-performance environment (such as a private cloud cluster, a high-configuration physical machine), a distributed storage strategy is activated, the metadata of the core data model and the file entity are stored separately (the metadata is stored in the master node relational database, and the file entity is distributedly stored in the slave node disk array), and the parallel computing mode (multi-threaded processing of rule triggering and execution) of the rule engine is enabled, and the full function of the machine learning module is retained, so as to improve the efficiency of large-scale file processing and complex rule execution. Through this dynamic adaptation logic, it is ensured that the executable program package generated can realize the core function with optimal resource occupation in different hardware environments, balancing the running efficiency and environmental compatibility.

[0030] In this embodiment, specifically: in step two, the page component library integrates a terminal self-adaptation engine, and the component layout, interaction mode and rendering precision can be automatically adjusted according to the hardware parameters of the access terminal, and the adaptation rules are associated with the terminal adaptation field in the core data model, supporting user-defined terminal display priority. Specifically, the terminal self-adaptation engine integrated by the page component library realizes cross-terminal compatibility through multi-level adaptation logic, and the specific process is as follows: First, the engine built-in terminal hardware parameter detection module collects hardware characteristics in real time through the system interface (such as browser UA information, device sensor data) of the access terminal, including terminal type (mobile phone, tablet, PC, smart terminal, etc.), screen size (such as 6.7 inches, 27 inches), resolution (such as 720P, 4K), processor performance (such as low-end / mid-end / high-end chip) and network bandwidth (such as 4G / 5G / WiFi) and other parameters as the basis for adaptation adjustment; Secondly, based on the collected hardware parameters, the engine automatically adjusts the core attributes of the components, specifically including: Component layout: on a small-screen terminal (such as a mobile phone), the file list component automatically switches from a multi-column grid layout to a single-column flow layout, reducing horizontal scrolling; on a large-screen terminal (such as a PC), the multi-column layout is retained and a side toolbar component is added, improving information density; Interaction mode: touch-screen terminals (such as tablets) change the component interaction from "click" to "slide + long press" (such as sliding a file card to display an operation menu), and non-touch-screen terminals (such as PCs) maintain "click + drag" interaction (such as dragging a file component to a folder component to move); Rendering accuracy: low-end terminals (such as low-end mobile phones) automatically reduce the image resolution of the file preview component (from high definition to standard definition) and turn off dynamic loading animations; high-end terminals (such as high-end PCs) maintain high-definition rendering and enable smooth transition effects; At the same time, the adaptation rules of the engine are deeply related to the "terminal adaptation fields" in the core data model, such as "terminal type priority", "screen size threshold", "performance level adaptation strategy", etc. The preset threshold in the model field (such as "mobile terminal maximum width threshold = 768px") serves as the trigger condition for engine layout switching, and the performance level correspondence recorded in the field (such as "low-end chip → basic rendering mode") directly guides the adjustment of rendering accuracy. In addition, the system provides a visual terminal display priority configuration interface, and users can customize the function display priority of different terminals by dragging and sorting (such as dragging "PC" to the first place and "mobile phone" to the second place). The terminal with high priority retains complete component functions (such as the file online editing component), and the terminal with low priority only displays core functions (such as the file preview and download components). The configuration results are synchronized in real time to the "terminal adaptation fields" in the core data model for engine calling and execution, finally realizing the dual optimization of "adaptability and user demand" of components on different terminals.

[0031] In this embodiment, specifically: in step three, the visual workflow template has a built-in dynamic branching judgment mechanism: Based on the metadata fields in the core data model, multi-path flow rules are automatically generated, and the branching weights can be configured through the visual interface. When the rules change, they are automatically synchronized to the linkage binding relationship; Specifically, the dynamic branching judgment mechanism of the visual workflow template is driven by the metadata fields of the core data model, realizing the automatic generation and flexible adjustment of the process path, and the specific process is as follows: First, the mechanism automatically scans the key metadata fields in the core data model (such as file type, size, department, priority, etc.), and generates multi-path flow rules based on field attributes (such as enumeration values, numerical ranges, logical relationships). For example, when the "file type" metadata field is "contract", automatically insert the "legal audit" node in the basic flow path; when the "file size" field value exceeds 100MB, automatically generate the branch path of "compression processing → storage optimization"; when the "department" is "finance department", the flow path is automatically associated with the "finance director approval" node, ensuring that the path matches the business attributes of the file accurately; Secondly, the system provides a visual branch weight configuration interface, supporting users to set the priority weight of each branch through dragging the slider, inputting numerical values, or clicking the order, etc. For example, for the two branches of "urgent files" and "ordinary files", the user can set the "urgent files" branch weight to 80% (preferential processing) and the "ordinary files" to 20%. The weight value will be stored in the configuration data of the workflow template and associated with the "process priority" field of the core data model, affecting the process scheduling order. Finally, when the branch rule (such as adding / deleting branch conditions, modifying metadata field association) or branch weight changes, the system will automatically trigger the synchronization mechanism of "data-component-process linkage binding relationship" in step four: update the association logic between workflow nodes and metadata fields, adjust the branch display content of page components (such as process path display components), and synchronize the association rules of corresponding fields in the core data model, ensuring that changes in branch judgment logic are reflected in the linkage relationship between data, components, and processes in real time, without the need for manual re-binding, ensuring the dynamic adaptability of the workflow template.

[0032] In this embodiment, specifically: the core data model includes a file lifecycle management field set, which is used to record file lifecycle information, and the field set is linked with the running monitoring data to automatically trigger the expired file archiving or deletion process; Specifically, the file lifecycle management field set in the core data model is a structured field set specially used to record the key information of the whole process of a file from creation to final extinction. It includes specific fields such as file creation time, last modification time, last access time, preset expiration time, current lifecycle state (such as "active", "to be archived", "archived", "to be deleted"), version iteration record, storage location identifier, archiving trigger threshold (such as "30 days of inaccessibility"), deletion trigger threshold (such as "1 year of inaccessibility after archiving"), etc., covering every stage of the file in the system. The field set forms a linkage mechanism with the real-time data collected by the running monitoring module in step seven (such as the actual file access frequency, the last access time, the current storage occupancy, etc.): when the running monitoring data meets the preset conditions in the lifecycle management field set, the system automatically triggers the corresponding process - for example, if the difference between the "last access time" and the current system time exceeds the "archiving trigger threshold" field value (such as 30 days), and the "current lifecycle state" of the file is "active", the archiving process is automatically started, the file is migrated from the main storage area to the archiving storage area, and the "storage location identifier" field is updated to the archiving path, and the "current lifecycle state" field is updated to "archived"; if the "archived" state of the file lasts for more than the "deletion trigger threshold" field value (such as 1 year), and the running monitoring data shows that the "access frequency" during the period is 0, the deletion process is automatically triggered, the physical deletion or logical marked deletion of the file is performed, and the "current lifecycle state" is updated to "deleted", and the deletion time is recorded in the field set; Through the real-time linkage of the field set and the running monitoring data, the automatic management of the file lifecycle is realized, the manual intervention is reduced, the storage resource occupancy is optimized, and the efficient operation and maintenance of the file service system is ensured.

[0033] In this embodiment, specifically: the historical running data includes file flow consumption time, approval rejection rate, and permission invocation frequency; Among them, the file flow consumption time refers to the time data of the file flowing between the nodes of the workflow and being processed in a single node, including single node processing time (such as the time of the file in the "department audit node" from entering to completing the processing), cross-node flow consumption time (such as the transmission time from the "initiation node" to the "audit node"), and total flow consumption time, the system will classify and statistics according to file type, priority, processing role, etc. dimensions, which is used to identify process bottlenecks (such as a node with too long average consumption time), and provides data support for optimizing node processing time limit rules; The approval rejection rate refers to the proportion of the number of times that a file is rejected in an approval node to the total number of approvals in the node, and the statistical dimensions include file type (such as contract type, report type), approval level (such as department level, company level), processor, etc. For example, "the rejection rate of contract type files in the legal audit node" and "the rejection rate of department manager approval", etc. By analyzing the common characteristics of high rejection rate scenarios (such as the lack of certain metadata fields), the approval rule iteration can be driven (such as adding the precondition that "contract files must contain the legal preliminary audit mark"); The permission calling frequency refers to the number and frequency of calling file permissions (such as viewing, editing, downloading, and deleting) by different users, roles, or departments, including the high-frequency called permission types (such as the most frequent "viewing permission"), high-frequency calling roles (such as department administrators), and corresponding file types. The system will record the time distribution and associated operations of permission calling, which is used to optimize the permission allocation rules (such as automatically adapting a more convenient permission acquisition path for roles that frequently call certain permissions). After these data are collected and cleaned, they are used by the machine learning module to mine business rules, such as adjusting the approval trigger threshold by analyzing the "high rejection rate file flow time consumption characteristics", or optimizing the permission verification rules based on the "permission calling frequency and file importance association", to finally realize the self-evolution of the intelligent business rule engine.

[0034] In summary, the embodiment of the present application provides a kind of intelligent file service system generation method based on low code development mode, by building the core data model containing dynamic field extension mechanism, build the visual page component library integrated terminal adaptive engine, configure the workflow template with dynamic branch determination, form the three-way real-time synchronous linkage relationship of data-component-process with the aid of low code engine, combined with the intelligent business rule engine of integrated machine learning module realizes the optimization of automation logic, then through environmental adaptation compilation generates differentiated deployment scheme, finally through the operation monitoring containing real-time hot repair forms a closed loop, greatly improves the development efficiency, dynamic response capability and deployment stability, realizes the efficient generation and flexible operation and maintenance of intelligent file service system.

[0035] It should be noted that each embodiment in the present specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts of each embodiment can be referred to each other.

[0036] The above only describes the preferred embodiments of the present application and does not limit the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A low-code development mode-based intelligent file service system generation method, characterized in that, The method comprises the following steps: Building a file service core data model, defining file metadata fields, storage structure and association, and forming a standardized data architecture; Based on the core data model, a visual page component library is built, and the component attributes are mapped to the file metadata fields one by one; According to the business process requirements, the file transfer nodes and path rules are configured under the support of the page component library, the node attributes are directly associated with the file metadata fields, and a visual workflow template that can be dragged is formed; Through the low-code engine, the page components and data model fields are mapped and bound, and the trigger logic of the workflow nodes and component operations is associated, forming a data-component-process linkage binding relationship; Based on the linkage binding relationship, the intelligent business rule engine is configured combined with the file metadata field attributes, and the automatic logic is set; According to the characteristics of the target deployment environment, the intelligent business rule engine and the linkage binding relationship are environment-adapted and compiled to generate an executable program package; Deploy the executable program package and start running monitoring, collect running data in real time, and feed back the analysis results to the page component library, visual workflow template and core data model.

2. The method of claim 1, wherein the method is characterized by: The core data model adopts a dynamic field expansion mechanism, supports real-time addition or deletion of custom metadata fields through a visual interface, and automatically synchronously updates the database table structure, index rules and mapping interfaces of the page component library when the fields are changed.

3. The method of claim 1, wherein the method further comprises: receiving a request for a file; and providing the requested file to the user. The linkage binding relationship adopts a three-way real-time synchronization mechanism, specifically including: If the page component operation triggers data changes, the workflow node state and core data model field values are automatically updated; If the workflow node state changes due to rule engine execution, the page component is refreshed and displayed in reverse and the core data model is written back; If the core data model field is modified by an external system, the component is re-rendered and the workflow node is verified.

4. The method of claim 1, wherein the low-code development pattern-based intelligent file service system is generated. The intelligent business rule engine integrates a machine learning module, which automatically optimizes rule parameters by analyzing collected historical running data and generates rule iteration suggestions for user confirmation.

5. The method of claim 1, wherein the low-code development pattern-based intelligent file service system is generated. The running monitoring includes a real-time hot repair mechanism. If a page component exception or workflow blockage is detected, the problem node is located based on the linkage binding relationship, the component attributes or process rules are directly modified through the visual interface, and the modified content is compiled in real time by the low-code engine and takes effect immediately without restarting the system.

6. The method of claim 1, wherein the low-code development pattern-based intelligent file service system is generated. The environment adaptation and compilation include intelligent resource scheduling logic. By detecting the CPU, memory, storage and network bandwidth parameters of the target environment, combining the calculation complexity of the intelligent business rule engine and the storage requirements of the core data model, a differentiated deployment scheme is automatically generated, wherein non-core components are compressed in a lightweight environment, and a distributed storage strategy is enabled in a high-performance environment.

7. The method of claim 1, wherein the method further comprises: receiving a request for a file; and providing the requested file to the user. The page component library integrates a terminal adaptation engine, and the component layout, interaction mode and rendering precision can be automatically adjusted according to the hardware parameters of the access terminal. The adaptation rules are associated with the terminal adaptation fields in the core data model, and the user can customize the terminal display priority.

8. The method of claim 1, wherein the low-code development pattern-based intelligent file service system is generated. In step three, the visualization workflow template has a built-in dynamic branch decision mechanism, which automatically generates multi-path flow rules based on metadata fields in the core data model, and supports configuring branch weights through the visualization interface. When the rules change, it automatically synchronizes to the linkage binding relationship.

9. The method of claim 2, wherein the low-code development pattern-based intelligent file service system is generated. The core data model includes a set of file lifecycle management fields, which are used to record file lifecycle information, and the field set is linked with the operation monitoring data to automatically trigger the expired file archiving or deletion process.

10. The method of claim 4, wherein the low-code development pattern-based intelligent file service system is generated. The historical operation data includes file flow time consumption, approval rejection rate and permission call frequency.

Images