Strategy arrangement and elastic deployment method and system for business and financial process automation

Abstract

The invention relates to the technical field of business and financial flow automation, in particular to a strategy arrangement and elastic deployment method and system for business and financial flow automation. The method comprises the following steps: in an operation monitoring stage of a business process, capturing and integrating multi-modal data streams, including structured transaction data, unstructured voucher image texts and user operation behavior sequences, generated by process execution in real time; and then, inputting the multi-modal data stream into a financial risk identification model which is trained based on historical compliance and violation cases in advance for real-time analysis. When the model identifies a potential risk pattern, the system automatically triggers an auditing alarm and generates a visual auditing report containing the risk data slices and associated contexts thereof. According to the invention, real-time, accurate and automatic monitoring of business and financial process risks is realized, and the depth, breadth and timeliness of risk identification are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of business and financial process automation technology, specifically to a strategy orchestration and flexible deployment method and system for business and financial process automation. Background Technology

[0002] In the context of current enterprise digital operations and refined management, the deep integration of business and finance has become a core path to improve organizational efficiency and strengthen risk control. While the application of various enterprise resource planning systems, business process management platforms, and professional financial software has achieved the digitalization and streamlining of business operations to a certain extent, significant shortcomings remain in real-time monitoring, in-depth insight, and intelligent risk prevention and control of business processes. Traditional monitoring methods largely rely on post-event querying and verification of structured transaction data, resulting in limited analytical dimensions and a severe lag behind the actual business activities, making it difficult to cope with the high frequency and complexity of modern business activities. Particularly noteworthy is that a large amount of key data containing risk information is scattered in unstructured documents (such as invoice images and scanned contracts) and behavioral logs reflecting user operating habits and intentions. These multimodal data sources are often isolated within the existing technological system, lacking effective correlation, integration, and a unified analytical framework, forming de facto "data silos" that cause a large number of potential risk clues to be obscured. Existing solutions based on fixed-rule logic engines can handle some explicit compliance issues, but their rigidity and static nature cannot adapt to the ever-evolving fraud methods and dynamic risk patterns. They lack sufficient sensitivity and responsiveness to identify highly concealed and novel violations. This inadequate monitoring capability creates blind spots in the enterprise's internal control system, potentially delaying the discovery and handling of abnormal transactions, amplifying economic losses, and even triggering compliance disputes that damage the company's reputation. Therefore, the industry urgently needs to embed an embedded audit mechanism with real-time perception, multi-source fusion, intelligent judgment, and automatic early warning capabilities into the nerve center of business processes. This mechanism can be seamlessly integrated into the execution environment of existing business and financial processes, continuously scanning and deeply analyzing full-volume, multi-modal operational data to achieve proactive discovery and precise intervention of potential risks, fundamentally improving the modernization level of enterprise risk immunity.

[0003] Therefore, existing technologies still need further development. Summary of the Invention

[0004] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a strategy orchestration and flexible deployment method and system for automating business and financial processes, so as to solve the problems existing in the prior art.

[0005] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides a strategy orchestration and flexible deployment method for automating business and financial processes, comprising: S1. Receive the business and financial process arrangement instruction input by the user through the graphical interface. The business and financial process includes multiple business nodes connected in sequence and the financial processing logic corresponding to each business node. S2. Parse the business and financial process arrangement instructions and generate an executable business and financial process template. The business and financial process template defines the triggering relationship between business events and financial actions and the data mapping rules. S3. In response to the deployment command, the business and financial process template is parsed into a set of distributed executable task units; S4. Based on the current system load and pre-configured resource policies, the task units are flexibly deployed to multiple computing nodes in the database appliance cluster; S5. When the business process template is running, monitor the execution status and resource consumption of each task unit in real time. S6. When changes in business traffic or node failures are detected, automatically perform elastic scaling operations, including dynamically allocating or releasing computing resources for task units.

[0006] Specifically, in step S1, the business nodes include contract approval, procurement and warehousing, and sales and delivery, and the financial processing logic includes generating accounting vouchers, triggering payment applications, and recognizing revenue.

[0007] Specifically, the process of generating the business and financial process template in step S2 includes: encapsulating business nodes into standardized components; connecting multiple standardized components by dragging and dropping based on the orchestration instructions to form a business process chain; and configuring a corresponding financial rule engine call interface for each standardized component.

[0008] Specifically, step S2 is followed by step S2a: using simulated business data to conduct sandbox testing on the business and financial process template to verify its logical correctness and data consistency.

[0009] Specifically, the elastic deployment process in step S4 includes: calculating the total computing resources required based on the complexity of the business process template and the estimated data volume; and allocating appropriate computing nodes to the task unit based on the resource strategy and the real-time resource pool status of the database appliance cluster.

[0010] Specifically, the resource strategy is an adaptive strategy based on an artificial intelligence prediction model, which is generated by: collecting historical business and financial process execution data, including process type, data volume, execution time, and peak resource consumption; and training a prediction model based on the historical execution data to predict the resource specifications required for newly deployed business and financial process templates.

[0011] Specifically, the elastic scaling operation in step S6 includes: inputting real-time monitoring data into the prediction model to predict the business load in the near future; and, based on the prediction results, pre-expanding computing resources for the corresponding task units before the peak of the business load arrives.

[0012] Specifically, in step S6, when a node failure is detected, a failover operation is automatically executed, which includes: quickly migrating the running task units and their current status data on the failed node to a standby healthy node in the cluster.

[0013] Specifically, the operation monitoring process in step S5 also includes an intelligent audit step: S5a. Real-time capture of financial data and operation logs generated during process execution to form a multimodal data stream, which includes structured transaction data, unstructured voucher image text, and user operation behavior sequences. S5b. Input the multimodal data stream into a pre-set financial risk identification model for real-time analysis. The risk identification model is a machine learning model trained based on historical compliant and non-compliant transaction cases. S5c: When the model identifies a potential risk pattern, it automatically triggers an audit alert and generates a visual audit report containing risk data slices and associated context.

[0014] According to a second aspect of the present invention, a strategy orchestration and flexible deployment system for automating business and financial processes is provided, comprising: The workflow orchestration module is used to receive business and financial workflow orchestration instructions input by users through a graphical interface, and parse the instructions to generate executable business and financial workflow templates. The template parsing and task decomposition module is used to parse business and financial process templates into a set of distributed executable task units; The resource scheduling and elastic deployment module is used to elastically deploy task units to the computing nodes of the database appliance cluster based on resource policies; The operation monitoring and elastic control module is used to monitor the execution and resource consumption of task units in real time, and automatically perform elastic scaling and failover operations.

[0015] Beneficial effects: This invention, by introducing and implementing the aforementioned intelligent auditing steps, brings multi-level and substantial technological improvements and management benefits to enterprises. Its most direct and crucial advancement lies in breaking through the data barriers of traditional monitoring technologies. It achieves real-time capture, efficient alignment, and deep fusion of three major categories of heterogeneous data generated throughout the entire business process: structured transaction records, unstructured voucher images and text, and user operation behavior sequences. This constructs a unified and continuous multimodal data stream, providing an unprecedentedly complete data view for in-depth, multi-faceted risk analysis. Based on this, leveraging the powerful pattern recognition and prediction capabilities of machine learning models trained on massive amounts of historical cases, the system achieves a leap from mechanical judgment based on fixed rules to data-driven intelligent insights. It can dynamically learn and adapt to constantly changing internal risk characteristics and external fraud methods, thereby significantly improving the detection rate and accuracy of complex and hidden risk patterns. When the intelligent model identifies potential risk signals, the system can immediately and automatically trigger a tiered alert mechanism and simultaneously generate a visualized audit report integrating key risk data slices and complete business context. This automated response process significantly reduces the time cycle from risk identification to investigation intervention, freeing auditors from tedious data collection and preliminary screening work, allowing them to focus on high-value analysis, judgment, and decision-making. In summary, the application of this invention can help enterprises build a real-time, intelligent, and accurate digital risk prevention and control barrier, effectively strengthening in-process supervision and control, reducing the risk of financial misstatement and fraud, and providing more timely and reliable data support for management's strategic decision-making, ultimately promoting the modernization and sustainable healthy development of corporate governance systems. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the strategy orchestration and flexible deployment method for automating business and financial processes provided in a specific embodiment of the present invention. Figure 2 This is a schematic diagram of the system composition of the business and financial process automation strategy orchestration and flexible deployment system provided in a specific embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Based on the embodiments in this application, other similar embodiments obtained by those skilled in the art without creative effort should all fall within the scope of protection of this application. Furthermore, directional terms mentioned in the following embodiments, such as "up," "down," "left," and "right," are only for reference to the directions in the accompanying drawings; therefore, the directional terms used are for illustrative purposes and not for limiting the invention.

[0018] The present invention will be further described below with reference to the accompanying drawings and preferred embodiments.

[0019] Please see Figure 1 This invention provides a strategy orchestration and flexible deployment method for automating business and financial processes, comprising: S1. Receive the business and financial process arrangement instructions input by the user through the graphical interface. The business and financial process includes multiple business nodes connected in sequence and the financial processing logic corresponding to each business node.

[0020] It should be further explained that the graphical interface is a web-based visual designer. Users drag and drop predefined business nodes (such as "Contract Approval" and "Purchase Order Receipt") from the component library on the left to the central canvas area. Each business node is a pre-packaged standardized component with built-in API interfaces for business systems (such as ERP and CRM). When a user connects two nodes with a connecting line, the system automatically generates a data mapping configuration panel. In this panel, users can define how the output data of the upstream node is mapped to the input fields of the downstream node through drop-down selections or simple scripts. For example, the "Contract Amount" and "Customer Number" fields output by the "Contract Approval" node can be mapped to the "Amount" and "Customer Code" fields required by the "Create Accounts Receivable" node. This process greatly reduces the technical threshold for process orchestration, allowing business experts to build complex business and financial processes like building blocks without coding.

[0021] Furthermore, the graphical interface is implemented based on the Vue.js front-end framework and HTML5's Canvas technology. Each business node in the component library (such as "Contract Approval Completed") is a predefined JSON object with the structure shown below. When a user drags a node onto the canvas, that node object is instantiated.

[0022] { "componentId": "contract_approval", "componentName": "Contract Approval Completed", "inputSchema": {"contractId": "string", "approvalStatus": "boolean", "approvedAmount": "number"}, "outputSchema": {"contractId": "string", "amount": "number", "nextStep": "string"}, "actionEndpoint": "http: / / internal-api / trigger / contract" } When a user connects to a node, the system displays a data mapping configuration window. Mapping rules support two methods: 1) Simple mapping: Select the source and target fields via the drop-down menu, for example, map the approvedAmount of the upstream node to the amount of the downstream node.

[0023] 2) Script mapping: Use JavaScript syntax to write simple transformation logic, such as output.amount=input.approvedAmount 1.06; / / Add 6% tax. After configuration, the system generates a unique process definition ID (e.g., PID_20231027_001).

[0024] S2. Parse the business and financial process orchestration instructions and generate an executable business and financial process template. The business and financial process template defines the triggering relationship between business events and financial actions and the data mapping rules.

[0025] It should be further explained that when the user clicks the "Save" button, the system parses the graphical orchestration instructions on the canvas into a structured JSON or XML description file, namely the business and financial process template. This template precisely describes the execution order of nodes, conditional branches (e.g., IF Approval Amount > 1 million THEN…ELSE…), and the specific service addresses and parameters that each node needs to call. More importantly, it contains all the data mapping rules configured in step S1. This template is platform-independent, providing a foundation for subsequent flexible deployment.

[0026] Furthermore, the orchestration instructions are serialized into a YAML file conforming to the Apache Airflow DAG definition specification, i.e., the business process template. This template is stored in the cluster's distributed file system (such as HDFS) at the path / templates / PID_20231027_001.yaml. An example template fragment is shown below: dag_id: 'sales_order_to_revenue' schedule_interval: '@continuous' tasks: - task_id: 'listen_sales_order' operator: 'HttpSensor' endpoint: 'http: / / erp-api / sales / orders' params: {'status': 'approved'} - task_id: 'create_receivable' operator: 'PythonOperator' python_callable: 'accounting_rules.generate_receivable' op_args: ['{{ task_instance.xcom_pull(task_ids="listen_sales_order")}}'] This template precisely describes the task dependencies, execution logic, and parameters.

[0027] S3. In response to the deployment command, the business and financial process template is parsed into a set of distributed executable task units.

[0028] It's worth noting that after receiving the business and financial process template, the deployment engine first performs syntax and semantic checks. Next, using Directed Acyclic Graph (DAG) parsing technology, it decomposes the template into a set of dependent task units. Each task unit is an independent, executable computational task, such as "calling the contract approval status query interface," "executing the accounting entry rule engine," or "writing to the general ledger database." These task units are encapsulated as lightweight Docker container images, ensuring environmental consistency and isolation.

[0029] Furthermore, the deployment engine (a standalone service written in Go) reads the YAML template and uses the open-source library github.com / argoproj / argo-workflows / pkg / apis / workflow / v1alpha1 to parse it into a Kubernetes custom resource. Each task is parsed into an independent Kubernetes Job or Pod definition. For example, the create_receivable task is broken down into Pod configurations containing a specific Docker image (such as reg.internal.com / accounting:v1.2). Dependencies between task units are guaranteed to ensure execution order through the Pod's initContainers and dependency flags (such as depends On).

[0030] S4. Based on the current system load and pre-configured resource policies, the task units are flexibly deployed to multiple computing nodes in the database appliance cluster.

[0031] It's worth noting that the resource scheduler queries the resource manager of the database appliance cluster (e.g., based on Kubernetes) to obtain the real-time CPU and memory utilization of each compute node. Simultaneously, it combines pre-configured resource policies (e.g., "prioritize deployment to nodes with CPU utilization below 70%)" with optimized scheduling algorithms (e.g., an improved algorithm based on BinPacking) to allocate suitable compute nodes to each task unit. If the overall cluster load is high, the scheduler triggers automatic scaling, starting new compute nodes from the reserved resource pool and then deploying the task unit to them—this is known as "elastic deployment."

[0032] Furthermore, the resource scheduler is a deeply customized Kubernetes scheduler plugin that monitors cluster resources through the API Server. Its resource policy includes hard constraints: "The average CPU utilization of a single compute node must not exceed 85%, and the memory utilization must not exceed 80%." The reason for choosing 85% and 80% as thresholds is to reserve sufficient buffer resources for the operating system and sudden traffic surges, preventing node overload from causing a sharp performance degradation. The scheduling algorithm employs an improved Best-Fit Decreasing (BFD) algorithm, the pseudocode of which is as follows: 1. Sort the list of task units to be deployed from largest to smallest according to their required CPU resources; 2. FOR each task unit IN the sorted list; 3. Query all nodes to find the set of nodes that can meet the resource requirements of the task and whose CPU utilization is still below 85% after deployment; 4. In this set, select the node with the least remaining available CPU resources after deployment (i.e., the node that can be "fully utilized"). 5. Deploy the task unit to this node; 6. ENDFOR.

[0033] Understandably, the algorithm described above aims to improve resource utilization and reduce resource fragmentation.

[0034] S5. When the business process template is running, monitor the execution status and resource consumption of each task unit in real time.

[0035] It should be further explained that during system operation, each task container embeds a lightweight agent that collects its own CPU utilization, memory usage, network I / O, and task queue length metrics once per second, and reports them to the central monitoring platform. The monitoring platform provides a global dashboard, allowing administrators to visually view the health status of all process instances.

[0036] Furthermore, the monitoring system is built on a Prometheus + Grafana stack. Each task unit's Pod contains a built-in prometheus-node-exporter sidecar container, which collects the following metrics once per second: ①cpu_usage_seconds_total: Cumulative CPU usage time; ②memory_working_set_bytes: Size of the working set in memory; ③http_request_duration_seconds: HTTP request delay; Understandably, these metrics are stored in Prometheus' time-series database. The monitoring threshold is set to trigger an alert if CPU utilization exceeds 80% for 60 consecutive seconds. Choosing 60 seconds as the duration threshold is to avoid unintended capacity expansion due to sudden traffic spikes.

[0037] S6. When changes in business traffic or node failures are detected, automatically perform elastic scaling operations, including dynamically allocating or releasing computing resources for task units.

[0038] It's worth noting that the elastic controller dynamically adjusts resources based on monitoring data. Regarding traffic changes: the system presets thresholds. For example, if the resource utilization of a task unit consistently exceeds 85% (e.g., for 30 consecutive seconds), it automatically triggers horizontal scaling (scale-out), adding a new instance to that task unit to share the load. When the utilization consistently falls below 20%, it automatically scales in to save resources. Regarding node failures: a health check mechanism periodically (e.g., every 10 seconds) sends heartbeat checks to nodes. If no response is received after three consecutive heartbeats, the node is considered faulty. All running task units on that node, along with their current state (saved using distributed snapshot technology), are immediately and seamlessly migrated to other healthy nodes, achieving high availability.

[0039] Furthermore, the above-mentioned plan specifically includes: ① Elastic Scaling (for Traffic): Implemented using Kubernetes Horizontal Pod Autoscaler (HPA). The configuration rule is: when the average CPU utilization of all Pods in the target task unit exceeds 75% (this value is below the monitoring alert threshold for early intervention), scaling begins, with a maximum replica count of 10. The scaling speed policy (behavior) is set to scale up to 100% of the current replica count every 30 seconds. Choosing 75% as the scaling threshold ensures new replicas are started before the system reaches the 80% alert threshold, smoothly handling pressure. The 30-second interval avoids excessively frequent fluctuations.

[0040] ② Failover (for nodes): The Kubernetes Node Controller checks the health status of nodes every 10 seconds by default. If a node is offline for more than 5 minutes (i.e., 30 consecutive failed checks), it is marked as NotReady. Afterward, all Pods deployed on that node will be evicted and rescheduled to healthy nodes by the scheduler according to the policy in step S4. The 5-minute wait period is to avoid misjudgments caused by brief network fluctuations.

[0041] It is understandable that the above solution has the following beneficial effects: 1) Through graphical arrangement and templates, agile construction and modification of business and financial processes have been achieved, greatly improving business response speed.

[0042] 2) By decomposing the process into distributed task units and deploying them elastically, the computing power of the database appliance cluster is fully utilized, achieving optimal resource utilization and avoiding resource waste and performance bottlenecks.

[0043] 3) Built-in elastic scaling and failover mechanisms ensure ultra-high reliability and continuity of processes when facing business peaks and hardware failures.

[0044] Specifically, in step S1, the business nodes include contract approval, procurement and warehousing, and sales and delivery, and the financial processing logic includes generating accounting vouchers, triggering payment applications, and recognizing revenue.

[0045] It should be further explained that the "Contract Approval" node is configured to listen for approval status change messages from the enterprise OA or contract management system. The "Purchase Receipt" node is configured to listen for receipt completion events from the warehouse management system (WMS). The "Sales Outbound" node is configured to listen for shipment confirmation events from the order management system. The corresponding financial processing logic is executed by the embedded financial rule engine. For example, the "Generate Accounting Voucher" logic calls preset accounting standard rules (such as IFRS or Chinese Accounting Standards), automatically calculates taxes, determines accounting subjects (e.g., Debit: Inventory, Credit: Accounts Payable - Provisional), and generates standardized accounting voucher data, which is then pushed to the financial system via API.

[0046] Understandably, these specific and industry-recognized core business scenarios strongly support and demonstrate the practicality, universality, and commercial value of the method, avoiding the uncertainty that may arise from overly abstract descriptions.

[0047] Specifically, the process of generating the business and financial process template in step S2 includes: encapsulating business nodes into standardized components; connecting multiple standardized components by dragging and dropping based on the orchestration instructions to form a business process chain; and configuring a corresponding financial rule engine call interface for each standardized component.

[0048] It should be further explained that the "standardized components" adopt a plug-in architecture. Each component contains three parts of metadata: a) Input / output data schema, which clearly defines which data fields the component needs and produces; b) Visual icons and attribute configuration panel; c) The address or function reference of the backend executor. When a user drags and drops a connection, the system is actually building a DAG-based workflow model at the underlying level. The connection lines represent the dependencies between data flow and control flow. "Configuring a corresponding financial rule engine call interface for each standardized component" means that the RESTful API endpoint for calling the financial rule engine (such as Drools, JBossRules) and the necessary authentication information have been hard-coded or configured in the component's backend executor. When the process reaches this node, it will automatically package the upstream data into the format required by the engine (such as JSON) for calling and parse the returned result.

[0049] Understandably, by using a component-based and plug-in-based design, technical details are hidden from business users, improving the system's maintainability and scalability. New business nodes can be easily developed and integrated as plug-ins without affecting the existing system.

[0050] Specifically, step S2 is followed by step S2a: using simulated business data to conduct sandbox testing on the business and financial process template to verify its logical correctness and data consistency.

[0051] It should be further explained that the system provides a sandbox testing environment, which is an isolated logical copy of the production cluster. Users can upload or directly write simulated business data files (such as JSON or CSV format) through the graphical interface, for example, simulating the approval data of a sales contract worth 1 million yuan. Then click the "Test Run" button. The system will execute the entire business and financial process template in the sandbox, but all write operations to the downstream formal business and financial systems (such as creating vouchers) will be redirected to a temporary test database. After the test is completed, the system will generate a detailed test report, including: a) Flowchart of execution path, highlighting the branches traversed; b) A snapshot of the input / output data for each node, allowing users to verify that the data mapping is correct; c) The final generated financial data results (such as simulated accounting vouchers) are automatically balanced (e.g., whether debits and credits are balanced).

[0052] Understandably, this invention can detect and correct logical errors and data mapping errors before the process is formally deployed, preventing defective processes from polluting the financial data of the production system, greatly reducing operational risks, and improving the robustness of the system and user trust.

[0053] Specifically, the elastic deployment process in step S4 includes: calculating the total computing resources required based on the complexity of the business process template and the estimated data volume; and allocating appropriate computing nodes to the task unit based on the resource strategy and the real-time resource pool status of the database appliance cluster.

[0054] It should be further explained that the "total computing resources required for computation" needs a quantitative model. A preferred implementation is to introduce the concept of "resource points." The system assigns a base resource point to each type of task unit (e.g., 1 point for a simple API call task, and 3 points for a complex rule calculation task). The total resource requirement (R_total) of the business and finance process template can be initially estimated using the following formula: in, It is the basic resource integral of task unit i. This is the processing capacity per unit of time (e.g., transactions per second, TPS) predicted for this task unit based on historical data, where n is the total number of task units. This formula combines the inherent complexity of the task with the workload. Then, the resource scheduler queries the real-time resource pool status of the cluster to obtain the available resource points for each node (calculated based on its remaining CPU and memory). The scheduling algorithm employs a modified Best-Fit algorithm, aiming to find the node combination that satisfies the R_total requirement with the least resource fragmentation.

[0055] Furthermore, a quantified resource score model is used to calculate total computing resources. The base score for each task unit is preset based on its historical execution data: 10 points for lightweight API calls, 30 points for medium-complexity calculations, and 50 points for heavy rule engine execution (e.g., Drools rules exceeding 100). The estimated load is input by the user during deployment or estimated based on the average historical data of similar processes. The formula for calculating the total resource requirement (R_total) is: in, Total resource points required for the business and finance process template; The total number of task units in this template; : No. Basic resource points for each task unit; : No. The estimated workload per unit of time for each task unit (e.g., number of transactions per second). The baseline workload is set at 100 TPS (Transactions Per Second). 100 TPS was chosen as the baseline because it represents a typical load that a single task unit can stably handle under standard configuration, as determined by stress testing.

[0056] The real-time resource pool status is obtained by querying the Kubernetes Metrics Server to get the available resource score by subtracting the allocated resources from the allocable resources of each node.

[0057] It is understandable that this invention elevates resource scheduling from simple resource matching to a level based on intelligent prediction and optimization, making resource allocation more accurate and efficient, thereby further improving the resource utilization of the entire cluster while ensuring performance.

[0058] Specifically, the resource strategy is an adaptive strategy based on an artificial intelligence prediction model, which is generated by: collecting historical business and financial process execution data, including process type, data volume, execution time, and peak resource consumption; and training a prediction model based on the historical execution data to predict the resource specifications required for newly deployed business and financial process templates.

[0059] It should be further explained that the specific steps of the above method include: a) Data Acquisition: The system continuously collects detailed execution data for each deployed process instance, forming a training dataset. Each data record includes: process type (e.g., "Purchase to Payment"), total volume of input data (in KB), total execution time (seconds), and peak CPU and memory usage monitored during execution; b) Model Training: A Gradient Boosting Decision Tree (GBDT) model, such as XG Boost or Light GBM, is used for regression prediction. The model's input features (X) include process type (one-hot encoded) and estimated data volume. The prediction target (y) is the peak resource consumption (CPU peak and memory peak can be predicted separately). The model undergoes supervised learning using historical data, learning the relationship between complex nonlinear combinations of different features and resource consumption. c) Prediction and Application: When a user deploys a newly orchestrated template, the system first extracts its process type and estimated data volume, then inputs them into a pre-trained GBDT model. The model outputs a predicted peak resource consumption (CPU and memory). This predicted value serves as the core basis for resource score calculation, thereby achieving more accurate initial resource allocation. The GBDT model was chosen because it effectively handles tabular data, has a strong ability to capture non-linear relationships of features, and can handle feature interactions, making it very suitable for this scenario. Compared to simple linear regression, its prediction accuracy is higher.

[0060] Furthermore, the AI ​​prediction model employs the Light GBM (Light Gradient Boosting Machine) regression model. The specific training steps are as follows: 1. Data Acquisition: Collect historical data from the monitoring database for the past 6 months. Each record includes: process type (text, such as 'Procure-to-Pay'), data volume (numerical value, MB), execution time (numerical value, seconds), and peak resource consumption (numerical value, CPU millicores). (seconds). Approximately 100,000 records were collected. Six months of data were chosen to cover potential seasonal business fluctuations; 2. Feature Engineering: One-hot encoding is applied to the process type. The feature vector is [Is_Procure To Pay, Is_Order To Cash, Data_Volume_MB, Duration_Sec]. The prediction target (Label) is Peak_CPU_Cores (peak CPU core count). 3. Model Training: The LGBM Regressor using Light GBM was employed. Key hyperparameter settings are as follows: onum_leaves=31: Controls model complexity. 31 is the default value, which prevents overfitting while ensuring accuracy. olearning_rate=0.05: Learning rate, set to a small value to ensure stable training; on_estimators=100: Number of iterations, determined by cross-validation to ensure that the loss function converges after 100 iterations; omax_depth=-1: Do not limit the tree depth, let the model learn automatically; omin_data_in_leaf=20: Minimum data size for leaf nodes to prevent overfitting.

[0061] Furthermore, during training, the data is divided into training and test sets at 80% and 20% respectively. Mean squared error (MSE) is used as the loss function. 4. Model Application: When a user deploys a new template, the system extracts its feature vector, inputs it into the trained model, and obtains the predicted Peak_CPU_Cores value. This value is directly used to calculate BaseScore_i in Formula 1 (for example, if the prediction requires 2.5 CPU cores, then BaseScore_i can be set to 25). Its beneficial effect is that, through a data-driven AI model, resource estimation relying on human experience is replaced, improving prediction accuracy by approximately 30% compared to manual estimation, and greatly optimizing the rationality of initial resource allocation.

[0062] Understandably, through model prediction, the system can "plan ahead" and allocate appropriate resources to processes before they run, avoiding performance bottlenecks caused by insufficient resource allocation or resource waste caused by over-allocation, thus achieving truly intelligent resource operation and maintenance.

[0063] Specifically, the elastic scaling operation in step S6 includes: inputting real-time monitoring data into the prediction model to predict the business load in the near future; and, based on the prediction results, pre-expanding computing resources for the corresponding task units before the peak of the business load arrives.

[0064] It's important to further clarify that the system not only uses historical data to train the model for initial predictions but also utilizes time series forecasting models (such as ARIMA or LSTM networks) for short-term load forecasting. The elastic controller takes real-time monitoring data (e.g., the transaction processing rate of each task unit over the past 15 minutes) as a time series. This series is then fed into a pre-trained time series forecasting model, which predicts the transaction processing rate for the next 5-10 minutes. The system presets a scaling threshold; for example, if the predicted load over the next 5 minutes reaches 80% of the current processing capacity, it immediately triggers scaling operations to prepare additional task instances in advance to handle upcoming traffic spikes. The LSTM model was chosen because it is a variant of the Recurrent Neural Network (RNN), particularly adept at learning long-term dependencies from time series data, and can more accurately predict business loads with periodicity (e.g., daily peaks) and trends.

[0065] Furthermore, short-term load forecasting employs the ARIMA (Autoregressive Integrated Moving Average) model. The specific steps are as follows: 1. Data Preparation: Obtain the TPS time series data for a specific task unit over the past 60 minutes, denoted as _____. ; 2. Model Fitting and Prediction: The ARIMA model from the statsmodels library was used. Based on pattern analysis of historical data, the optimal parameters for ARIMA were (p=2, d=1, q=2). (Autoregressive order): Indicates that the current value is related to the values ​​of the previous two time points, and can capture short-term trends; (Difference order): Perform first-order differences to make the sequence stationary; (Moving average order): Considering the prediction error of the first two time points; after model fitting, predict the TPS value for the next 5 minutes. ; 3. Capacity Expansion Decision: Set a capacity expansion trigger threshold of 70% of the current processing capacity. That is, if the predicted TPS value... If the current maximum processing capacity exceeds 70% (determined by the current number of replicas), scaling up will be triggered immediately. Choosing 70% as the threshold provides sufficient time (5 minutes) to start new Pod instances and complete service registration and discovery, thus preparing for peak traffic. The number of new replicas for scaling up is determined by the formula... Calculate, where: This represents the system's prediction for the next 5 minutes ( The total system load or key indicator value; calculated in real time by the time series prediction model. The model will make rolling predictions based on historical monitoring data (such as indicators in the last 30 minutes). The reason for choosing a 5-minute prediction window is to reserve enough time (such as 2-3 minutes) for the system to start new Pod instances, so that they can be started and ready before the load really arrives, thereby achieving smooth expansion and avoiding system overload. This represents the maximum processing capacity of a single Pod instance. This is a preset, known constant, and this value is usually determined through stress testing before application deployment. For example, if testing shows that a Pod instance can handle a maximum of 1000 requests per second (1000 QPS) while ensuring normal response latency (e.g., 99% of requests <200ms), then SinglePodCapacity is set to 100, which is the baseline unit for system scaling. The calculation is to handle the predicted load. Theoretically, the total number of Pods required must be an integer (0.7 Pods cannot be started), so the result of the division must be rounded up. For example, if the result is 3.2, it means that at least 4 Pods are needed to fully handle the load; if the result is 3.0, then exactly 3 Pods are needed. Rounding up ensures that the system's processing capacity is always greater than or equal to the predicted load, which is a key guarantee for system stability. This indicates the number of healthy Pod replicas currently running in the system. Understandably, the logic of the entire formula is to subtract the current number of Pods from the total number of Pods needed in the future, which gives the number of replicas that need to be added (or removed): If the result is positive (e.g., 2), it means that expansion is needed and the system should start 2 new replicas; If the result is zero, it means that the current number of replicas exactly meets the prediction requirements, and no action is needed; If the result is negative (e.g., -1), it means that the system needs to be scaled down, and one copy should be removed.

[0066] Understandably, this invention represents a leap from "passive response" to "proactive prediction," effectively avoiding system performance fluctuations caused by resource expansion delays and ensuring service stability of over 99.9%. It upgrades elastic scaling from a passive, current-indicator-based response mode to a proactive, prediction-based prevention mode. This effectively prevents service degradation or interruptions that may occur due to expansion delays during periods of rapid traffic increases, thus providing a smoother, higher-quality user experience.

[0067] Specifically, in step S6, when a node failure is detected, a failover operation is automatically executed, which includes: quickly migrating the running task units and their current status data on the failed node to a standby healthy node in the cluster.

[0068] It's important to further explain that the key technologies for achieving failover are distributed snapshots and state recovery. The system periodically (e.g., after each complete transaction unit) takes a lightweight snapshot of the execution state of each task unit (including variables in memory, processing progress, and results of calls to external systems) and persists it to highly available shared storage (such as the distributed file system of a database appliance cluster). When the monitoring system detects a node failure, the failover manager performs the following steps: a) Quickly launch a new task unit container on a pre-selected backup healthy node; b) Load the most recent successful snapshot of this task unit from shared storage; c) Resume execution from the snapshot point.

[0069] Furthermore, to ensure that data is not lost, the system adopts at-least-once semantics, which allows certain operations to be executed repeatedly in rare cases, but the correctness of the final result is guaranteed through the idempotency design of the business logic.

[0070] Furthermore, failover is achieved through Kubernetes' Stateful Sets combined with Persistent Volumes (PVs). For stateful task units (such as instances processing long-running processes), their Pods are defined as Stateful Sets. These Pods mount a PV based on network storage (such as Ceph RBD) to store state data. State data storage employs a timed snapshot mechanism. After each indivisible business transaction is completed (such as successfully generating a credential), the process context in memory (such as the current node and processed data) is serialized into a JSON file and saved to the PV's ` / snapshots / ` directory. The filename includes a timestamp, such as `context_20231027120000.json`. Failover process: 1. Node failure detected (connectivity lost for 5 minutes); 2. The control plane will start a new Pod instance on a healthy node and mount the same PV (guaranteed by volume Claim Templates). 3. After a new Pod starts, its Init Container executes a recovery script. This script searches for the latest snapshot file in the PV's / snapshots / directory (using the command ls -t|head -n 1). 4. The script loads the latest snapshot file content into memory, and the process engine continues execution from that snapshot point. Choosing a 5-minute fault determination time and a transaction-based snapshot is to minimize the risk of data duplication or loss while ensuring that the fault actually occurred. Its benefit is that even for stateful and complex business processes, automatic and lossless fault recovery can be achieved, reducing business interruption time from hours to minutes.

[0071] Understandably, this invention enables business interruption recovery within minutes or even seconds, minimizing the impact of hardware or software failures on continuously operating business processes and meeting the extremely high continuity requirements of enterprise-critical business systems.

[0072] Specifically, the operation monitoring process in step S5 also includes an intelligent audit step: S5a. Real-time capture of financial data and operation logs generated during process execution to form a multimodal data stream, which includes structured transaction data, unstructured voucher image text, and user operation behavior sequences. It should be further explained that the core of this step is the real-time capture and alignment of multimodal data. The key to implementation lies in establishing a unified data pipeline to perform real-time acquisition, preprocessing, and correlation of data from different sources and in different formats, specifically including the following solutions: 1. Capture Structured Transaction Data: Utilize database log capture tools (such as Debezium) deployed on a database appliance to capture business database transaction logs (such as MySQL's bin log or Oracle's redo log) in real time. The capture frequency is set to once per second to ensure near real-time data accuracy. The captured data includes structured fields such as transaction ID, amount, account, timestamp, and operation type (create, delete, update). This data is converted to Avro format and sent to the structured-financial-data topic via a message queue (such as Apache Kafka). Avro format is chosen because it has a built-in schema, which facilitates serialization and version control. 2. Capture unstructured document image text: (1) Image Acquisition: The voucher images generated during the process (such as scanned copies of invoices and contract attachments) are usually stored in file servers or object storage (such as AWS S3). By listening to the event notifications of the storage service (such as S3EventNotification), subsequent processing is immediately triggered when a new file (such as a file with the path / invoices / 2023 / 10 / 27 / inv_001.pdf) is stored.

[0073] (2) Text Extraction: The open-source TesseractOCR5.0 engine was used to perform text recognition on the voucher image. To improve accuracy, image preprocessing was required, including: ① Grayscale conversion: Converting a color image to a grayscale image.

[0074] ② Binarization: Otsu's method is used to automatically determine the threshold, converting the image to black and white to highlight the text. The formula for Otsu's method is to select a threshold... This maximizes the inter-class variance between the foreground (text) and the background. Physically, it means finding the optimal threshold to separate the target from the background.

[0075] ③ Layout analysis: Identify document structure, such as headings, tables, and paragraphs.

[0076] The identified text (including key fields such as "invoice number", "amount" and "supplier name") is structured and associated with the corresponding transaction ID, and is also sent in JSON format to the Kafka topic unstructured-doc-text; 3. Capture user action sequence: Embed a behavior collection SDK (e.g., custom development based on the OpenTelemetry standard) into the management front-end of the process execution. Record the key action sequence of the user on the interface, including: user ID, action time, action object (e.g., order number), action type (e.g., "approved", "rejected"), IP address, and action time. This behavior data is sent in JSON format to the Kafka topic user-behavior-seq; 4. Multimodal Data Stream Association: The data streams from the three Kafka topics mentioned above are uniformly connected to a stream processing engine (such as Apache Flink). The Flink job uses a time-window association mechanism to associate the data. The join key is the transaction ID. The join window size is set to 5 seconds. That is, the system will attempt to associate structured data, OCR text, and behavioral data arriving within 5 seconds that have the same transaction ID, merging them into a complete multimodal data record. The reason for choosing a 5-second window is to balance data integrity and real-time performance, allowing time differences for data from different sources without compromising audit real-time performance due to an excessively large window.

[0077] S5b. Input the multimodal data stream into a pre-set financial risk identification model for real-time analysis. The risk identification model is a machine learning model trained based on historical compliant and non-compliant transaction cases. It should be further explained that the core of this step is the construction and real-time reasoning of the financial risk identification model, and the specific methods include: 1. Model Selection and Rationale: The XG Boost (eXtreme Gradient Boosting) algorithm is preferred for constructing the financial risk identification model. The reasons for choosing XG Boost are: its excellent processing capability for structured tabular data, fast training speed, strong interpretability (it can provide feature importance ranking), and effective prevention of overfitting, making it very suitable for the risk classification task in this scenario. 2. Feature Engineering: Feature extraction is performed on the multimodal data generated in S5a to form feature vectors. Feature examples include: ①From structured data: transaction amount, transaction time (whether it is outside working hours, such as 20:00-6:00), transaction frequency (the number of transactions by this supplier recently), whether the amount is an integer, and whether the amount is close to the approval limit.

[0078] ② From unstructured text: Use TF-IDF (Term Frequency-Inverse Document Frequency) to extract keyword features from voucher description text; use regular expressions to match abnormal keywords (such as "rebate" or "kickback").

[0079] ③ User behavior data: Whether the operation sequence is abnormal (e.g., user A just submitted, and user B approves it within 1 second), and whether the user's login IP address is abnormal (e.g., usually in Shanghai, but overseas today). Ultimately, this forms a feature vector of approximately 200 dimensions.

[0080] 3. Model Training: ① Training data: Collect at least 10,000 historical transaction records, of which at least 500 are known violations (positive samples). The proportion of positive samples is no less than 5% to ensure that the model can learn sufficient risk patterns.

[0081] ② The key hyperparameter settings are as follows: max_depth=6: Controls the maximum depth of the tree to prevent overfitting; learning_rate=0.1: learning rate, balancing training speed and accuracy; subsample=0.8: Use 80% of the samples in each iteration to increase randomness and improve generalization ability; scale_pos_weight=(number of negative samples / number of positive samples): Automatically calculated to handle the imbalance between positive and negative samples.

[0082] ③ The model output is a risk probability value (P) between 0 and 1.

[0083] 4. Real-time Analysis: The trained XG Boost model is deployed as a high-performance gRPC microservice. The stream processing engine (Flink) converts the real-time correlated multimodal data records into feature vectors and then calls the model service for real-time inference. The inference latency is required to be less than 100 milliseconds.

[0084] S5c: When the model identifies a potential risk pattern, it automatically triggers an audit alert and generates a visual audit report containing risk data slices and associated context.

[0085] It should be further explained that the core of this step is intelligent decision-making and report generation, and the specific solutions include: 1. Risk Assessment: Set a risk probability threshold. When the model outputs the risk probability When this occurs, it is considered a potential risk. The rationale for choosing a threshold of 0.7 is that it represents a business-verified balance. A threshold that is too low (e.g., 0.5) would lead to too many false positives, increasing the workload of auditors; a threshold that is too high (e.g., 0.9) would lead to false negatives. 0.7 ensures a high detection rate while keeping the false positive rate at an acceptable level of around 20%. 2. Triggering Audit Alerts: Once a risk is identified, the system will immediately issue an alert through the following channels: ① The transaction record is highlighted in red on the monitoring screen.

[0086] ② Send a message to the pre-defined WeChat / DingTalk group for auditors, in the format:

Smart Audit Alert

[0087] 3. Generate a visual audit report: The report is automatically generated and saved as a PDF. The report not only includes risk conclusions, but more importantly, it provides an "evidence package," including: ① Risk data slice: List the core characteristics and values ​​that lead to high risk, such as: "Transaction amount (500,000 yuan) exceeds 10 times the supplier's historical average transaction amount (50,000 yuan)" and "Approval operation interval (1 second) is much lower than the average interval (300 seconds)".

[0088] ②Contextual association: (1) Provide a complete timeline of the transaction.

[0089] (2) Embed a thumbnail of the voucher image and highlight the suspicious text area identified by OCR.

[0090] (3) Provide links to similar historical cases for auditors to refer to and compare.

[0091] Understandably, this invention enables real-time, automated, and accurate identification of risks in business and financial processes. It transforms auditing from "post-event spot checks" to "in-process intervention," freeing up more than 90% of manpower from transactional tasks; through multimodal data fusion analysis, it can discover hidden risks that traditional single-dimensional auditing cannot detect, increasing the risk detection rate by approximately 35%; and the automatically generated detailed reports greatly improve the efficiency and quality of auditing work.

[0092] Please see Figure 2 The present invention provides another embodiment, which provides a strategy orchestration and flexible deployment system for automating business and financial processes. The strategy orchestration and flexible deployment system for automating business and financial processes includes: The process orchestration module 100 is used to receive business and financial process orchestration instructions input by the user through a graphical interface, and parse the instructions to generate executable business and financial process templates. The template parsing and task decomposition module 200 is used to parse the business and financial process template into a set of distributed executable task units; The resource scheduling and elastic deployment module 300 is used to elastically deploy task units to the computing nodes of the database appliance cluster based on resource policies. The operation monitoring and elastic control module 400 is used to monitor the execution and resource consumption of task units in real time, and automatically perform elastic scaling and failover operations.

[0093] It should be further explained that the process orchestration module 100 is specifically implemented as an independent web application server, providing a graphical interface and including a process definition parser; the template parsing and task decomposition module 200 and the resource scheduling and elastic deployment module 300 can be integrated, with a deeply customized Kubernetes Master node at its core. This extends the native scheduler, enabling it to understand the semantics of business process templates and perform intelligent scheduling; the operation monitoring and elastic control module 400 is built based on open-source monitoring systems such as Prometheus and includes a custom elastic controller. This controller continuously monitors monitoring data and drives Kubernetes to perform scaling and failover operations according to policies. All these modules communicate with the compute and storage nodes of the database appliance through a high-speed internal network, forming a tightly integrated whole.

[0094] Understandably, this system translates innovative methods into concrete and implementable hardware systems, clearly defines the division and collaboration of each functional module, and provides clear architectural guidance for those skilled in the art to build such systems.

[0095] In a preferred embodiment, this application also provides an electronic device, the electronic device comprising: The computer device includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, implement the strategy orchestration and flexible deployment method for automating business processes. The computer device can be broadly categorized as a server, terminal, or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include non-volatile storage media and internal memory. The non-volatile storage media may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs the steps of the method of the present invention.

[0096] This invention can be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the methods of embodiments of the invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0097] Those skilled in the art will understand that the method steps of this invention can be performed by a computer program instructing related hardware, such as a computer device or processor, to perform the steps of this invention when executed. Depending on the context, any references herein to memory, storage, databases, or other media may include non-volatile and / or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc.

[0098] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0099] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for strategy orchestration and flexible deployment of automated business and financial processes, characterized in that, Includes the following steps: S1. Receive the business and financial process arrangement instruction input by the user through the graphical interface. The business and financial process includes multiple business nodes connected in sequence and the financial processing logic corresponding to each business node. S2. Parse the business and financial process arrangement instructions and generate an executable business and financial process template. The business and financial process template defines the triggering relationship between business events and financial actions and the data mapping rules. S3. In response to the deployment command, the business and financial process template is parsed into a set of distributed executable task units; S4. Based on the current system load and pre-configured resource policies, the task units are flexibly deployed to multiple computing nodes in the database appliance cluster; S5. When the business process template is running, monitor the execution status and resource consumption of each task unit in real time. S6. When changes in business traffic or node failures are detected, automatically perform elastic scaling operations, including dynamically allocating or releasing computing resources for task units.

2. The method according to claim 1, characterized in that, In step S1, the business nodes include contract approval, procurement and warehousing, and sales and delivery. The financial processing logic includes generating accounting vouchers, triggering payment applications, and recognizing revenue.

3. The method according to claim 1, characterized in that, The specific process of generating the business and financial process template in step S2 includes: encapsulating business nodes into standardized components; connecting multiple standardized components by dragging and dropping based on the orchestration instructions to form a business process chain; and configuring a corresponding financial rule engine call interface for each standardized component.

4. The method according to claim 3, characterized in that, Step S2 is followed by step S2a: using simulated business data to conduct sandbox testing on the business and financial process template to verify its logical correctness and data consistency.

5. The method according to claim 1, characterized in that, The specific process of elastic deployment in step S4 includes: calculating the total computing resources required based on the complexity of the business and financial process template and the estimated data volume; and allocating appropriate computing nodes to the task unit based on the resource strategy and the real-time resource pool status of the database appliance cluster.

6. The method according to claim 5, characterized in that, The resource strategy is an adaptive strategy based on an artificial intelligence prediction model. Its generation method includes: collecting historical business and financial process execution data, including process type, data volume, execution time, and peak resource consumption; training a prediction model based on the historical execution data to predict the resource specifications required for newly deployed business and financial process templates.

7. The method according to claim 6, characterized in that, The specific process of the elastic scaling operation in step S6 includes: inputting real-time monitoring data into the prediction model to predict the business load in the near future; and, based on the prediction results, pre-expanding computing resources for the corresponding task units before the peak of the business load arrives.

8. The method according to claim 1, characterized in that, In step S6, when a node failure is detected, a failover operation is automatically performed, which includes: quickly migrating the running task units and their current status data on the failed node to a standby healthy node in the cluster.

9. The method according to claim 1, characterized in that, The operation monitoring process in step S5 also includes an intelligent audit step: S5a. Real-time capture of financial data and operation logs generated during process execution to form a multimodal data stream, which includes structured transaction data, unstructured voucher image text, and user operation behavior sequences. S5b. Input the multimodal data stream into a pre-set financial risk identification model for real-time analysis. The risk identification model is a machine learning model trained based on historical compliant and non-compliant transaction cases. S5c: When the model identifies a potential risk pattern, it automatically triggers an audit alert and generates a visual audit report containing risk data slices and associated context.

10. A strategy orchestration and flexible deployment system for automating business and financial processes, used to implement the method described in any one of claims 1 to 9, characterized in that, include: The workflow orchestration module is used to receive business and financial workflow orchestration instructions input by users through a graphical interface, and parse the instructions to generate executable business and financial workflow templates. The template parsing and task decomposition module is used to parse business and financial process templates into a set of distributed executable task units; The resource scheduling and elastic deployment module is used to elastically deploy task units to the computing nodes of the database appliance cluster based on resource policies; The operation monitoring and elastic control module is used to monitor the execution and resource consumption of task units in real time, and automatically perform elastic scaling and failover operations.

Images