Supply chain business index calculating and monitoring method based on dynamic configuration

Abstract

The invention discloses a supply chain business index calculating and monitoring method based on dynamic configuration. The method comprises the following steps: providing a unified dynamic configuration table; based on the scheduling types and the scheduling parameters, scheduling strategy classes are selected, scheduling tasks are created, and task life cycle management is carried out; when the scheduling task is triggered, obtaining business data according to the data source information and the data query statement; according to the calculation rule type, calling a calculation strategy class, and calculating the business data in combination with the calculation expression to obtain an index value; packaging the index value into a monitoring index according to the business service identifier and the business index name, adding a monitoring label to the monitoring index, and reporting the monitoring index to a visual monitoring platform; in a visual monitoring platform, the monitoring index is automatically found and displayed, multi-dimensional display and drilling analysis according to the monitoring label are supported, and an alarm rule is configured. According to the invention, the problems of hard coding, fixed calculation rule, rigid scheduling strategy and scattered configuration in index addition are solved.

Description

Technical Field

[0001] This invention relates to the field of digital monitoring and dynamic calculation technology of supply chain, and in particular to a method for calculating and monitoring supply chain business indicators based on dynamic configuration. Background Technology

[0002] Current supply chain monitoring requires frequent additions / adjustments of indicators (such as adding "SKU-level order fulfillment rate" and "monthly forecast deviation rate"), and the indicator calculation rules (such as counting, summation, difference, and custom formulas), data sources (different databases / tables), and update frequencies (real-time / hourly / daily) vary greatly.

[0003] Existing monitoring solutions mainly rely on two types of technical approaches: a. Hard-coded development mode: New metrics require writing dedicated data collection code (such as SQL queries and calculation logic) and scheduling code (such as scheduled tasks), with a development cycle of ≥3 days, and modifications to calculation rules require recompilation and deployment; b. General BI tool (Business Intelligence, technologies and tools for data analysis and reporting) mode: Although it supports simple drag-and-drop configuration, the calculation rules are limited to preset functions (such as SUM / COUNT), and it cannot support supply chain-specific custom expressions (such as "pickup achievement rate = actual pickup quantity / planned pickup quantity × 100%)", and it does not support linkage with Prometheus / Grafana monitoring links.

[0004] Meanwhile, the existing solution has the problem of "strong coupling between configuration and computation": data sources, computation rules, and scheduling strategies are scattered in code or multiple configuration files, without a unified management carrier. After configuration changes, the service needs to be restarted manually, and tasks cannot be refreshed automatically, resulting in high operation and maintenance costs.

[0005] Therefore, the existing solution has the following drawbacks: 1. Low efficiency in adding new indicators: New indicators rely on hard coding and require the development of full-chain code for "data collection-calculation-scheduling". For example, adding an indicator such as "over-allocation" (over-allocation = actual allocation quantity - planned allocation quantity) requires writing SQL query statements, difference calculation logic, and timed scheduling functions. The development cycle is long and non-technical personnel cannot operate it.

[0006] 2. Fixed calculation rules: There is no customization capability. It only supports preset calculation logic (such as SUM / COUNT) and cannot adapt to complex custom expressions in the supply chain (such as "forecast deviation rate = |forecast sales - actual sales| / actual sales × 100%)". Furthermore, modifying the calculation rules (such as changing from "weekly achievement rate" to "daily achievement rate") requires refactoring the calculation code.

[0007] 3. Rigid scheduling strategy: The configuration changes are inflexible. The scheduling frequency (e.g., every 5 minutes / hour) needs to be hard-coded in the code (e.g., @Scheduled(fixedRate=300000)). Modifying the frequency requires restarting the service. It is impossible to switch the scheduling type according to the business scenario (e.g., use Cron scheduling on weekdays and fixed frequency scheduling on holidays).

[0008] 4. Dispersed configuration management: There is no unified carrier data source (DB connection information), calculation rules (formulas), and scheduling strategies (frequency). They are scattered in code, configuration files, and databases. There is no unified management table. After configuration changes, multiple links need to be manually synchronized, which is prone to errors and inefficient.

[0009] 5. No automatic refresh and resource reclamation after configuration changes: When calculation rules or scheduling strategies change, it is necessary to manually stop the old task and start the new task. Furthermore, it is impossible to automatically close the monitoring resources (such as Prometheus Gauge metrics) occupied by the old task, which may lead to resource leaks or conflicts between the old and new tasks. Summary of the Invention

[0010] In view of this, the purpose of this invention is to propose a method for calculating and monitoring supply chain business indicators based on dynamic configuration. By uniformly managing data sources, calculation rules, and scheduling strategies through a configuration table, it enables dynamic calculation and monitoring of supply chain business indicators (such as fulfillment rate and prediction deviation rate). The core solution is to address the problems of hard coding required for new indicators, fixed calculation rules, rigid scheduling strategies, and scattered configurations in traditional monitoring. It is suitable for scenarios such as cross-border e-commerce and manufacturing that require rapid iteration of monitoring indicators. Finally, it achieves indicator visualization and alerts through Prometheus / Grafana.

[0011] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: This invention provides a method for calculating and monitoring supply chain business indicators based on dynamic configuration, comprising the following steps: Step 1: Provide a unified and dynamic configuration table, which includes at least the business service identifier, business indicator name, data source information, data query statement, calculation rule type, calculation expression, scheduling type, and scheduling parameters; provide a configuration management interface for the configuration table to support adding, modifying, deleting, querying, verifying, and importing / exporting configurations. Step 2: Based on the scheduling type and scheduling parameters in the configuration table, select the corresponding scheduling strategy class and create a scheduling task to manage the lifecycle of all calling tasks; Step 3: When the scheduling task is triggered, obtain business data according to the data source information and data query statement in the configuration table; according to the calculation rule type in the configuration table, call the corresponding calculation strategy class, and calculate the business data in combination with the calculation expression to obtain the indicator value; Step 4: Based on the business service identifier and business indicator name in the configuration table, encapsulate the calculated indicator value into a monitoring indicator in a preset format, attach a corresponding monitoring tag to the monitoring indicator, report the monitoring indicator to the visualization monitoring platform, and manage the entire lifecycle of the monitoring indicator. Step 5: In the visualization monitoring platform, the monitoring indicator is automatically discovered and displayed. It supports multi-dimensional display and drill-down analysis based on the monitoring tags, and alarm rules are configured.

[0012] Furthermore, the configuration table in step 1 is a data table in a relational database, which contains at least the following fields: A unique identifier field used to uniquely identify each configuration record; The business service identifier field is used to distinguish different business domains; The Business Metric Name field is used to define a unique name for the monitored metric; The data source information field group includes the database connection address, database name, and table name; The data query statement field is used to define the structured query language statement for retrieving business data; The calculation rule type field indicates the calculation rule used. Its value is an enumeration type, including count, sum, difference, and custom expression. The calculation expression field, when the calculation rule type is a custom expression, is used to define specific mathematical calculation formulas; The scheduling type field indicates the scheduling type used. Its value is an enumeration type, including scheduling based on Cron expressions and scheduling based on fixed frequency. The scheduling parameter field is used to store a Cron expression or a fixed frequency of milliseconds according to the scheduling type; The monitoring tag field is used to define business dimension tags that need to be attached to monitoring metrics in the form of key-value pairs.

[0013] Furthermore, the configuration verification function of the configuration management interface in step 1 is implemented through an independent configuration verification engine, specifically including: The data query statement fields are parsed and logically validated to verify whether the table names and field names involved exist in the target data source. The calculation expression fields are parsed to verify whether the variables referenced in the formula have been defined in the associated field mapping relationship, and to check for the risk of division by zero. Perform non-empty validation on required fields; Verify whether the format of the scheduling parameter field conforms to the syntax specification of the corresponding type based on the scheduling type field.

[0014] Furthermore, step 2 specifically includes: Step 21: Define a scheduling strategy engine to encapsulate different scheduling logic through an enumeration class; for each scheduling type, implement a specific scheduling strategy class: if the scheduling type is a Cron expression-based scheduling, the corresponding scheduling strategy class is a Cron strategy, which is used to parse the Cron expression and create time-based scheduling tasks; if the scheduling type is a fixed-frequency scheduling, the corresponding scheduling strategy class is a fixed-frequency strategy, which is used to create periodic scheduling tasks at fixed millisecond intervals. Step 22: Maintain a task registry and a parameter mapping table; the task registry is a key-value pair data structure, where the key is a unique identifier of the configuration and the value is the task instance corresponding to the scheduled task created for that configuration; the parameter mapping table is used to store the correspondence between the unique identifier of each valid configuration and its currently effective scheduling parameters; Step 23: When the system starts up, when it scans the configuration table and finds a configuration that is enabled and has no associated task, the scheduling strategy engine selects the corresponding scheduling strategy class according to the scheduling type and scheduling parameters, and calls its specific strategy to create a calling task. The unique identifier of the configuration and the task instance are stored in the task registry, and the unique identifier of the configuration and the scheduling parameters are recorded in the parameter mapping table. Step 24: Start a background timed scanning thread to periodically compare the scheduling parameters recorded in the parameter mapping table with the latest scheduling parameters in the configuration table; when a change in scheduling parameters is detected or a configuration change event is detected, execute the task refresh process.

[0015] Furthermore, step 23 specifically includes: Step 231: At the initial startup of the system, perform a full scan process to traverse and query all configuration records marked as enabled in the configuration table; or during operation, when a configuration change event notification is received, perform an incremental scan process for the configuration record indicated by the configuration change event. Step 232: For each configuration record scanned, check if there is a task instance in the task registry with the unique identifier of the configuration as the key; if not, determine that there is no active task associated with the configuration. Step 233: For configurations that meet the conditions of being enabled and having no associated tasks, the scheduling strategy engine determines the corresponding scheduling type based on the value of the scheduling parameter field in the configuration table, then dynamically selects the corresponding scheduling strategy class based on the scheduling type, calls its specific strategy to create a calling task, and obtains a task instance used to control the lifecycle of the task. Step 234: Store the unique identifier of the configuration and the task instance in the task registry; at the same time, store the unique identifier of the configuration and its current scheduling parameters in the parameter mapping table; Step 24 specifically includes: Automatic task synchronization is achieved through a separate background timed scanning thread, which performs the following operations periodically at fixed time intervals: Step 241: Traverse all scheduling parameters in the parameter mapping table; Step 242: For each scheduling parameter, use the unique identifier of its stored configuration as an index to query the configuration table and obtain the latest scheduling parameter for that configuration. Step 243: Compare the scheduling parameters in the configuration table with the scheduling parameters in the parameter mapping table; Step 244: If the comparison results are inconsistent, it is determined that the scheduling parameters of the configuration have been changed, and the scheduling task for the configuration is refreshed. Step 245: When a configuration change event is detected, the scheduled task is refreshed directly for the configuration associated with the configuration change event; The scheduling task refresh process specifically includes: Based on the unique identifier of the configuration to be refreshed, retrieve and obtain the corresponding task instance from the task registry; call the cancellation method of the task instance to terminate the currently executing task instance. Remove the task instance corresponding to the unique identifier of this configuration from the task registry; remove the corresponding call parameter record from the parameter mapping table; Based on the latest information in the configuration table, create new scheduling tasks and corresponding task instances. The newly generated task instance is stored in the task registry, and the latest scheduling parameters are stored in the parameter mapping table to complete the synchronization.

[0016] Furthermore, step 3 involves calling the corresponding calculation strategy class based on the calculation rule type in the configuration table, specifically including: Define a computation strategy engine to encapsulate different computation logic through an enumeration class; For each type of calculation rule, implement a specific calculation strategy class: 1) If the calculation rule type is counting, then the corresponding calculation strategy class is counting strategy. The counting strategy is used to execute data query statements and count the number of record rows in the query result set as the indicator value. 2) If the calculation rule type is summation, the corresponding calculation strategy class is summation strategy. The summation strategy is used to parse the specified summation field name from the field mapping relationship associated with the calculation rule, and perform summation operation on all values ​​of the field in the query result set as the index value. 3) If the calculation rule type is difference, the corresponding calculation strategy type is difference strategy. The difference strategy is used to parse the minus number segment name and the subtracted number segment name from the field mapping relationship, perform subtraction operation on the corresponding field value of each record in the query result set, and accumulate the difference results of all records as the indicator value. 4) If the calculation rule type is a custom expression, the corresponding calculation strategy class is a custom expression strategy. The custom expression strategy is used to parse the correspondence between expression variables and business fields from the field mapping relationship, substitute the business field values ​​in the query result set into the corresponding variables in the calculation expression, and evaluate the expression after substituting the values ​​through the expression parsing engine to obtain the indicator value. The calculation strategy engine dynamically selects and calls the corresponding specific calculation strategy class based on the value of the calculation rule type field in the configuration table.

[0017] Furthermore, the expression parsing engine used in the custom expression strategy is the Spring Expression Language Parser, and its execution process includes: Parse the calculated expression field and extract all variable names that are wrapped by variable placeholders; Based on the field mapping relationship, each variable name is mapped to the corresponding business field name in the query result set; Iterate through the query result set, replace the actual value of the business field name in each record with the corresponding variable placeholder in the expression, and form a calculable numerical expression; The expression parsing engine is invoked to evaluate the numerical expression; The evaluation result is formatted to retain a set number of decimal places.

[0018] Furthermore, step 4 specifically includes: Step 41: Generate a unique monitoring indicator name according to the business service identifier and business indicator name in the configuration table and in accordance with the predefined naming rules; Step 42: Create a Gauge-type monitoring metric that supports dynamic numerical updates under the monitoring metric name; Step 43: Based on the monitoring tag field in the configuration table, attach corresponding tag key-value pairs to the monitoring metrics; Step 44: Update the indicator values ​​obtained from each calculation to the monitoring indicator and report them to the visualization monitoring platform; Step 45: Maintain all active monitoring metrics through a resource management mapping table; Step 46: When the configuration is changed or deleted, perform the following resource reclamation operation: Retrieve the monitoring metrics corresponding to this configuration from the resource management mapping table; Call its shutdown method to turn off the monitoring metric and stop numerical updates; Clear the value cache for this monitoring metric; Cancel the monitoring metric to free up memory resources.

[0019] Furthermore, step 5 specifically includes: Step 51: Push all enabled monitoring metrics to the metrics data interface in real time. The Prometheus monitoring system obtains and stores the monitoring metrics from the metrics data interface through periodic polling. Step 52: Configure the Prometheus monitoring system as its data source in the visualization monitoring platform. By entering the prefix of the monitoring indicator name in the data query interface, the platform will automatically match and display all monitoring indicators reported by the monitoring system that meet the conditions. Step 53: Based on the monitoring tags attached to the monitoring indicators, provide functions for data filtering, grouping, and drill-down analysis by tag value in the visualization chart; Step 54: Pre-configure alarm rule templates related to supply chain business in the visualization monitoring platform. When adding new monitoring indicators, users can configure alarms by selecting the corresponding alarm rule template and adjusting the threshold. Alarm notifications support multiple message channels.

[0020] Furthermore, it also includes configuring synchronization and event-driven mechanisms: Configuration synchronization is achieved using a publish / subscribe event-driven pattern. The configuration management interface acts as an event publisher, publishing a configuration change event that carries a unique identifier of the configuration and the type of change when a configuration is added, modified, or disabled. The task lifecycle management acts as an event subscriber, monitoring the configuration change event, and automatically triggering refresh, stop, or create operations on the associated scheduled tasks upon receiving the configuration change event; The resource management mapping table also acts as an event subscriber, monitoring the configuration change events, and automatically triggering resource reclamation and cleanup operations on the associated monitoring metrics when it receives a configuration deletion or disabling.

[0021] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: This invention is based on the core design of "unified configuration table driving the entire link", achieving significant breakthroughs in efficiency, flexibility, and operation and maintenance costs: 1. Regarding the efficiency of adding new metrics, this invention achieves zero-code metric addition by managing data sources, calculation rules, and scheduling strategies through a unified and dynamic configuration table. Existing hard-coded solutions require writing code across the entire chain of "data collection - SQL query - calculation logic - scheduling task" to add a single metric, typically taking over 3 days to develop and relying on technical professionals. This invention integrates data sources, calculation rules, and scheduling strategies through a dynamic configuration table. Non-technical personnel only need to fill in the configuration table (e.g., enter query SQL, select calculation rules, and set scheduling frequency), and the metric can be deployed within 15 minutes, significantly improving efficiency and completely eliminating reliance on hard-coded methods.

[0022] 2. Regarding the flexibility of calculation rules, it supports dynamic switching between four types of calculation rules: "counting / summing / difference / custom expression," adapting to complex calculation scenarios in the supply chain. Existing general BI tools only support preset functions such as COUNT and SUM, which cannot adapt to complex custom calculations in supply chain scenarios (such as "pickup achievement rate = actual pickup quantity / planned pickup quantity × 100%" and "prediction deviation rate = |predicted sales - actual sales| / actual sales × 100%"). This invention supports four types of calculation rules: "counting / summing / difference / custom expression," which can be dynamically switched through the calculation rule type field in the configuration table. Custom expressions also support variable substitution (such as "${actual_qty}" associated with SQL query result fields). The adaptability to scenarios is improved compared to existing solutions, and modifying calculation rules does not require code adjustments, only updating the configuration table.

[0023] 3. Regarding scheduling strategies, existing solutions require hard-coding the scheduling frequency (e.g., every 5 minutes / hour) in the code. Modifying the frequency requires restarting the service, and the adjustment cycle exceeds 1 hour. Furthermore, the data source, calculation rules, and scheduling strategies are scattered across the code, configuration files, and database. Configuration changes require manual synchronization across multiple stages, resulting in a high error rate. This invention supports dual scheduling types of "Cron / fixed frequency," which can be switched with one click through the scheduling type field in the configuration table. After the configuration is changed, the system automatically stops the old task and starts the new task without restarting the service, thus reducing adjustment time.

[0024] 4. In terms of configuration management, the configuration table serves as a unified carrier, integrating the entire configuration chain of "data source-computation-scheduling" to achieve visualized management. Changes are automatically synchronized to all stages of scheduling, computation, and reporting, reducing the error rate.

[0025] 5. Regarding resource management and operation and maintenance costs, the system automatically stops old tasks and reclaims monitoring resources (such as disabling old Gauge metrics) to prevent resource leaks. In existing solutions, after configuration changes, old tasks and old monitoring metrics (such as Prometheus Gauges) are prone to remain, requiring manual investigation and cleanup, leading to redundant server resource usage. This invention manages task references through a task registry and manages metric resources through a resource management mapping table. When configurations are changed or deleted, old tasks are automatically stopped and old metrics are disabled. This reduces server resource usage compared to existing solutions, decreases manpower investment in operation and maintenance, and significantly reduces enterprise operation and maintenance costs. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is an execution flowchart of a method for calculating and monitoring supply chain business indicators based on dynamic configuration, provided in an embodiment of the present invention.

[0028] Figure 2 This is an architecture diagram of a supply chain business indicator calculation and monitoring system based on dynamic configuration provided in an embodiment of the present invention. Detailed Implementation

[0029] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] This invention uses a unified configuration table as its core driver, constructing a five-layer architecture: "Configuration Management Layer → Task Scheduling Layer → Dynamic Calculation Layer → Indicator Reporting Layer → Visual Monitoring Layer." This achieves a complete closed loop of "configuration-driven calculation and monitoring." The architecture of this invention for a supply chain business indicator calculation and monitoring system based on dynamic configuration is as follows: Figure 2 As shown.

[0031] Please see Figure 1This invention discloses a method for calculating and monitoring supply chain business indicators based on dynamic configuration. All stages use a "configuration table" as the sole input, and configuration changes automatically refresh downstream tasks. Scheduling and calculation logic are decoupled through a "strategy pattern," supporting dynamic expansion of new strategies (such as adding a "scheme by date range" type). Specifically, it includes the following steps: Step 1: Provide a unified dynamic configuration table, which includes at least the business service identifier, business indicator name, data source information, data query statement, calculation rule type, calculation expression, scheduling type, and scheduling parameters. Design a unified dynamic configuration table as the "configuration hub" of the entire system, integrating the configuration of the entire chain of data source, calculation, and scheduling. Combined with the configuration management interface and configuration verification engine, it realizes visualized, verifiable, and synchronized configuration management.

[0032] In this embodiment, the configuration table in step 1 is a data table in a relational database, which contains at least the following fields: A unique identifier field used to uniquely identify each configuration record; The business service identifier field is used to distinguish different business domains; The Business Metric Name field is used to define a unique name for the monitored metric; The data source information field group includes the database connection address, database name, and table name; The data query statement field is used to define the structured query language statement for retrieving business data; The calculation rule type field indicates the calculation rule used. Its value is an enumeration type, including count, sum, difference, and custom expression. The calculation expression field, when the calculation rule type is a custom expression, is used to define specific mathematical calculation formulas; The scheduling type field indicates the type of scheduling used. Its value is an enumeration type, including scheduling based on Cron (a time-based scheduling syntax for configuring periodically executed tasks) expressions and scheduling based on a fixed frequency. The scheduling parameter field is used to store a Cron expression or a fixed frequency of milliseconds according to the scheduling type; The monitoring tag field is used to define business dimension tags that need to be attached to monitoring metrics in the form of key-value pairs.

[0033] Table 1: Configuration Table Structure and Field Definitions

[0034] In this embodiment, a configuration management interface is provided for the configuration table, which supports adding, modifying, deleting, querying, verifying, and importing / exporting configurations. Configuration export / import: Supports exporting configuration templates to enable quick copying of metrics (e.g., copying "daily achievement rate" configuration from "weekly achievement rate" to generate "daily achievement rate" configuration).

[0035] Export Function: After selecting the target configuration, the system automatically converts the configuration table fields into a JSON (JavaScript Object Notation, a lightweight data interchange format) template (including field descriptions, current values, and optional values), as shown in the example below: { "service": "allocation", "business_index": "allocation_rate", "description": "Pickup Achievement Rate Indicator Configuration Template", "fields": [ {"name": "db_url", "value": "jdbc:mysql: / / 192.168.1.100:3306 / mrp_db","desc": "database connection URL"}, {"name": "cal_rule", "value": 3, "desc": "Calculation rule (3 = custom expression)","options": [0,1,2,3]}, {"name": "cal_expression", "value": "${actual_qty} / ${plan_qty}*100","desc": "Custom calculation expression"} ] } Import function: After uploading a JSON template, the system automatically parses the field values, verifies their validity, and writes them into the configuration table. It supports batch import and enables quick copying of metrics (such as copying "daily achievement rate" from "weekly achievement rate").

[0036] In this embodiment, the configuration verification function of the configuration management interface in step 1 is implemented through an independent configuration verification engine, which adopts a dual mechanism of "syntax parsing + logic verification"; specifically including: The data query statement fields are parsed and logically validated. The exec_sql statement is parsed using the JSqlParser (JSQL parser: a Java library for parsing SQL statements) tool to verify whether the table names and field names involved exist in the target data source and to check the legality of the SQL syntax (such as matching brackets and correct keywords). The calculated expression field is parsed and logically validated using ExpressionParser. An expression parser (usually referring to a component used to parse and evaluate expressions) parses cal_expression, verifies whether the variables referenced in the formula have been defined in the associated field mapping relationship, checks for the risk of division by zero, and checks the legality of the expression syntax (such as legal operators and matching parentheses). Perform non-empty validation on required fields (core fields such as db_url, business_index, cal_rule, etc.) and check whether schedule_type matches the expression format (e.g., Cron type must conform to Cron syntax). Verify whether the format of the scheduling parameter field conforms to the syntax specification of the corresponding type based on the scheduling type field.

[0037] Step 2: Based on the scheduling type and scheduling parameters in the configuration table, select the corresponding scheduling strategy class and create a scheduling task, and manage the task lifecycle of all calling tasks; realize dynamic adaptation of scheduling type based on "strategy mode", and manage the entire lifecycle of tasks (creation / refresh / stop) to realize automatic response to configuration changes.

[0038] In this embodiment, step 2 specifically includes: Step 21: Define a scheduling strategy engine to encapsulate different scheduling logic through an enumeration class and support dynamic selection of strategies through the scheduling type field; Implement a specific scheduling strategy class for each scheduling type: If the scheduling type is Cron expression-based scheduling, the corresponding scheduling strategy class is Cron strategy, which is used to parse Cron expressions and create time-based scheduling tasks. Cron strategy (schedule_type=0): 1. CronTrigger is not a user-defined function, but a timed triggering component provided by the Quartz framework (a feature-rich open-source job scheduling library for creating scheduled tasks in Java applications), used to parse Cron expressions and trigger tasks; 2. Triggering logic: When the expression is a Cron expression, the system initializes a CronTrigger instance, passes in the expression parser CronExpression, and the Quartz scheduler binds the task instance through the triggerJob() method, triggering the task to execute at the time point defined by the expression (e.g., once every 5 minutes).

[0039] If the scheduling type is fixed-frequency scheduling, the corresponding scheduling strategy class is fixed-frequency strategy, which is used to create periodic scheduling tasks according to a fixed number of milliseconds interval. Fixed frequency strategy (schedule_type=1): 1. When the expression is a number of milliseconds (such as "300000"), use Quartz's SimpleTrigger component and set repeatInterval to the number of milliseconds corresponding to the expression to achieve fixed-interval triggering; 2. Suitable scenarios: Metrics with high real-time requirements (such as hourly order fulfillment monitoring).

[0040] Strategy expansion capabilities: 1. When adding a new scheduling type (such as "schedule by date range"), only an enumeration instance (such as DATE_RANGE(2)) and the corresponding scheduling strategy class need to be added. There is no need to modify the core scheduling logic, which has strong extensibility.

[0041] Step 22: Maintain a task registry `futureMap` (a thread-safe hash table implementation in Java) and a parameter mapping table `expressionMap`. The task registry is a key-value pair data structure, where the key is a unique identifier of the configuration and the value is the task instance corresponding to the scheduled task created for that configuration (used to control the task lifecycle). The parameter mapping table is used to store the correspondence between the unique identifier of each valid configuration and its currently effective scheduling parameters, for comparing whether the configuration has changed. Step 23: When the system (a supply chain business indicator calculation and monitoring system based on dynamic configuration) starts, when it scans the configuration table and finds a configuration that is enabled and has no associated task, the scheduling strategy engine selects the corresponding scheduling strategy class according to the scheduling type and scheduling parameters, and calls its specific strategy to create a calling task. The unique identifier of the configuration and the task instance are stored in the task registry, and the unique identifier of the configuration and the scheduling parameters are recorded in the parameter mapping table. In this embodiment, step 23 specifically includes: Step 231: At the initial startup of the system, perform a full scan process to traverse and query all configuration records marked as enabled in the configuration table; or during operation, when a configuration change event notification is received, perform an incremental scan process for the configuration record indicated by the configuration change event. Step 232: For each configuration record scanned, check if there is a task instance in the task registry with the unique identifier of the configuration as the key; if not, determine that there is no active task associated with the configuration. Step 233: For configurations that meet the conditions of being enabled and having no associated tasks, the scheduling strategy engine determines the corresponding scheduling type based on the value of the scheduling parameter field in the configuration table, then dynamically selects the corresponding scheduling strategy class based on the scheduling type, calls its specific strategy to create a calling task, and obtains a task instance used to control the lifecycle of the task. Step 234: Store the unique identifier of the configuration and the task instance in the task registry; at the same time, store the unique identifier of the configuration and its current scheduling parameters in the parameter mapping table; Step 24: Start a background timed scanning thread (execute once every 30 seconds) to periodically compare the scheduling parameters recorded in the parameter mapping table with the latest scheduling parameters in the configuration table; when a change in scheduling parameters is detected or a configuration change event is detected, execute the task refresh process.

[0042] In this embodiment, step 24 specifically includes: Automatic task synchronization is achieved through a separate background timed scanning thread, which performs the following operations periodically at fixed time intervals: Step 241: Traverse all scheduling parameters in the parameter mapping table; Step 242: For each scheduling parameter, use the unique identifier of its stored configuration as an index to query the configuration table and obtain the latest scheduling parameter for that configuration. Step 243: Compare the scheduling parameters in the configuration table with the scheduling parameters in the parameter mapping table; Step 244: If the comparison results are inconsistent, it is determined that the scheduling parameters of the configuration have been changed, and the scheduling task for the configuration is refreshed. Step 245: When a configuration change event is detected, the scheduled task is refreshed directly for the configuration associated with the configuration change event; Task lifecycle management achieves automatic synchronization of "configuration-task" through "task registry + configuration change monitoring".

[0043] In this embodiment, the scheduling task refresh process specifically includes: Based on the unique identifier of the configuration to be refreshed, retrieve the corresponding task instance from the task registry; call the cancellation method of the task instance (future.cancel(true), where true indicates interrupting the currently executing task) to terminate the currently executing task instance; when the task stops, call the closeResource interface of the metric reporting layer to retrieve the Gauge (a type of metric in Prometheus representing a value that can fluctuate arbitrarily) instance corresponding to the configuration from the gaugeMap (a ConcurrentHashMap storing metric references), call the ObservableDoubleGauge.close() method to close the metric, and simultaneously deregister the metric from the Prometheus registry to release memory resources. Prometheus Gauge is a monitoring metric type that supports dynamic numerical updates and is suitable for metrics that need to change in real time (such as achievement rate, inventory quantity). Remove the task instance corresponding to the unique identifier of this configuration from the task registry; remove the corresponding call parameter record from the parameter mapping table; Based on the latest information in the configuration table, create new scheduling tasks and corresponding task instances. The newly generated task instance is stored in the task registry, and the latest scheduling parameters are stored in the parameter mapping table to complete the synchronization.

[0044] Step 3: When the scheduling task is triggered, obtain business data according to the data source information and data query statement in the configuration table; according to the calculation rule type in the configuration table, call the corresponding calculation strategy class, and calculate the business data in combination with the calculation expression to obtain the indicator value; In this embodiment, step 3, which involves calling the corresponding calculation strategy class based on the calculation rule type in the configuration table, specifically includes: Define a computation strategy engine to encapsulate different computation logic through an enumeration class; For each type of calculation rule, implement a specific calculation strategy class: 1) If the calculation rule type is counting, then the corresponding calculation strategy class is counting strategy. The counting strategy is used to execute data query statements and count the number of record rows in the query result set as the indicator value. 2) If the calculation rule type is summation, the corresponding calculation strategy class is summation strategy. The summation strategy is used to parse the specified summation field name from the field mapping relationship associated with the calculation rule, and perform summation operation on all values ​​of the field in the query result set as the index value. 3) If the calculation rule type is difference, the corresponding calculation strategy type is difference strategy. The difference strategy is used to parse the minus number segment name and the subtracted number segment name from the field mapping relationship, perform subtraction operation on the corresponding field value of each record in the query result set, and accumulate the difference results of all records as the indicator value. 4) If the calculation rule type is a custom expression, the corresponding calculation strategy class is a custom expression strategy. The custom expression strategy is used to parse the correspondence between expression variables and business fields from the field mapping relationship, substitute the business field values ​​in the query result set into the corresponding variables in the calculation expression, and evaluate the expression after substituting the values ​​through the expression parsing engine to obtain the indicator value. The calculation strategy engine dynamically selects and calls the corresponding specific calculation strategy class based on the value of the calculation rule type field in the configuration table.

[0045] Table 2:

[0046] Example of Columns (monitoring labels): For calculating "over-allocation" (DIFF difference rule: actual allocation quantity - planned allocation quantity): it is necessary to specify "minuend = actual allocation quantity" and "subtrahend = planned allocation quantity", and the columns are stored as {"minuend":"actual_qty","subtrahend":"plan_qty"}; For calculating the "total shipment volume" (SUM summation rule): it is necessary to specify that "summation field = actual shipment number field", and columns are stored as {"sum":"actual_qty"}; For calculating the "pickup achievement rate" (EXPR custom expression rule): it is necessary to clarify the "correspondence between variables in the expression and business fields". The columns are stored as {"actual_qty":"actual_qty","plan_qty":"plan_qty"} (direct mapping, or alias mapping such as {"act":"actual_qty","pln":"plan_qty"}). The overall logic of Columns is as follows: Field mappings are extracted during configuration parsing → the calculation strategy engine reads the field mapping relationships according to rule type → business data is dynamically associated to perform calculations, broken down into four categories of calculation rules: (1) Adapting to COUNT counting rules (cal_rule=0) - No additional field mapping is required, only "record existence" is needed.

[0047] Field mapping requirements: columns can be left empty or stored as {"count":"*"} (default adaptation), representing "the number of non-empty records in the query results"; Implementation steps: 1. Configure the parser to parse columns. If it is a COUNT counting rule, ignore the specific field mapping and only mark "counting mode"; 2. The dynamic calculation layer performs data queries (e.g., "SELECT plan_no FROM allocation_plan WHERE create_time BETWEEN ? AND ?"). 3. The calculation strategy engine traverses the query result set, counts the number of non-empty record rows (filtering NULL or empty string records), and directly uses it as the indicator value.

[0048] Adaptation logic: The COUNT counting rule does not depend on the business meaning of specific fields, only that "the record exists". Therefore, field mapping only needs to mark the "counting" role, without binding specific business fields.

[0049] (2) Adapt to SUM summation rule (cal_rule=1) — Map the “summation field” to the business field.

[0050] Field mapping requirements: columns must contain the "sum" key, and the value is the field name of the required sum in the business table (such as actual order quantity, inventory quantity); Implementation steps: 1. Configure the parser to parse columns and extract the summation field name corresponding to sum (e.g., sum_field = columns.get("sum") = "actual_qty"); 2. The dynamic calculation layer performs data queries, obtains the query result set, and extracts the field values ​​of each record by sum_field; 3. The calculation strategy engine sums all field values ​​(filling empty values ​​with 0 to avoid calculation errors), and the result retains the number of decimal places according to the precision field.

[0051] Adaptation logic: The SUM summation rule only requires specifying "which field to sum", and the field mapping locks the target field through the "sum" key, so that "changing tables / fields only requires modifying the mapping, without changing the calculation logic".

[0052] (3) Adapt DIFF difference rules (cal_rule=2) — Map “minuend / subtrahend” to business fields.

[0053] Field mapping requirements: columns must contain two keys, "minuend" (minuend) and "subtrahend" (subtrahend), which correspond to two fields in the business table, respectively; Implementation steps: 1. Configure the parser to parse columns and extract field mapping relationships (e.g., minuend_field = "actual_qty", subtrahend_field = "plan_qty"); 2. The dynamic calculation layer performs data queries, obtains the query result set, and extracts the value of each record according to the two field names; 3. The calculation strategy engine performs the "minuend - subtrahend" operation (e.g., actual_qty - plan_qty), filling null values ​​with 0 to avoid negative numbers being processed according to business requirements (e.g., over-allocation is allowed to be negative, while inventory gap is prohibited from being negative, so the absolute value is taken). 4. If multiple sets of differences need to be summed (such as "total over-allocation of the entire warehouse"), calculate the difference of each individual record first, and then sum the results of all records.

[0054] Adaptation logic: The core of the DIFF difference rule is "the comparison of the values ​​of two fields". The field mapping locks the logical role through fixed key names (minuend / subtrahend). No matter how the business field name changes (such as "actual quantity of goods picked" changing from actual_qty to real_qty), only the mapping value needs to be modified, and the calculation logic remains unchanged.

[0055] (4) Adapt to EXPR custom expression rules (cal_rule=3) — Map "expression variables" to business fields.

[0056] Field mapping requirements: The key of columns is "variable name in the expression", and the value is "business field name" (direct mapping or alias mapping is supported); Implementation steps: 1. Configure the parser to parse columns and generate a "variable-field" mapping table (e.g., varFieldMap = {"actual_qty":"actual_qty","plan_qty":"plan_qty"}, or alias mapping {"act":"actual_qty","pln":"plan_qty"}). 2. Configure the parser to parse cal_expression (e.g., "${actual_qty} / ${plan_qty}*100") and extract all ${variable name} (e.g., actual_qty, plan_qty); 3. The dynamic calculation layer executes data queries, obtains the query result set, and assigns the "business field values" to the "expression variables" (e.g., actual_qty = 100, plan_qty = 80) according to the field mapping relationship of varFieldMap. 4. The calculation strategy engine (based on SpEL parsing) evaluates the expression (100 / 80*100) after variable substitution, and the result is formatted according to precision.

[0057] Adaptation Logic: The core of EXPR custom expression rules is "flexible expressions". Field mapping solves the "binding problem between expression variables and business fields", supports arbitrarily complex expressions (such as multiple variables, nested operations "(${act}-${pln}) / ${pln}*100"), and adapts to supply chain-specific calculation scenarios (such as prediction deviation rate and inventory turnover days).

[0058] (5) Core capabilities for parsing custom expressions The core capabilities and their implementation methods are as follows: 1. Field parsing and replacement: SpEL (Spring Expression Language, a powerful expression language provided by the Spring framework for querying and manipulating object graphs at runtime) is used as the expression parsing technology, supporting complex mathematical operations and variable substitution; Implementation steps: ① Parse \({variable name} (e.g., \){actual_qty}) in cal_expression; ② Extract the corresponding variable values ​​from the Map in the exec_sql query result set; ③ Substitute the variable values ​​into the expression to generate an executable SpEL expression (such as "100 / 80*100").

[0059] 2. Numerical precision control: It uses the "Uniform Numeric Formatting Component" for processing, rather than processing within the expression itself; Implementation logic: After the expression is calculated, the precision field (default 2 decimal places) in the configuration table is obtained, and the result is formatted using the DecimalFormat utility class (e.g., new DecimalFormat("#.00").format(result)) to ensure that the indicator value is standardized.

[0060] Validation: Before parsing, validate the expression syntax (e.g., parentheses matching, operator validity), catch ArithmeticException during calculation (e.g., division by zero), return the default value 0, and log the result.

[0061] In this embodiment, the expression parsing engine used in the custom expression strategy is the Spring Expression Language Parser, and its execution process includes: Parse the calculated expression field and extract all variable names that are wrapped by variable placeholders; Based on the field mapping relationship, each variable name is mapped to the corresponding business field name in the query result set; Iterate through the query result set, replace the actual value of the business field name in each record with the corresponding variable placeholder in the expression, and form a calculable numerical expression; The expression parsing engine is invoked to evaluate the numerical expression; The evaluation result is formatted to retain a set number of decimal places.

[0062] Step 4: Based on the business service identifier and business indicator name in the configuration table, encapsulate the calculated indicator value into a monitoring indicator in a preset format, attach a corresponding monitoring tag to the monitoring indicator, report the monitoring indicator to the visualization monitoring platform, and manage the entire lifecycle of the monitoring indicator (creation / closure).

[0063] In this embodiment, step 4 specifically includes: Step 41: Based on the business service identifier and business indicator name in the configuration table, generate a unique monitoring indicator name according to the predefined naming rules. The predefined naming rules are: business service identifier + underscore + business indicator name, that is, add an underscore between the business service identifier and the business indicator name to form the monitoring indicator name; for example: if the business service identifier is erp-mrp and the business indicator name is OnWayCount (on-the-way count), then the generated monitoring indicator name = erp-mrp_OnWayCount.

[0064] Step 42: Create a Gauge-type monitoring metric that supports dynamic numerical updates under the monitoring metric name; Step 43: Based on the monitoring tag field in the configuration table, attach corresponding tag key-value pairs to the monitoring metrics; Step 44: Update the indicator values ​​obtained from each calculation to the monitoring indicator and report them to the visualization monitoring platform; Step 45: Maintain all active monitoring metrics through a resource management mapping table; (1) Metric encapsulation logic (corresponding to MetricsTask) Metric type selection: Use the Prometheus Gauge type (supports dynamic numerical updates), and the metric name is a combination of service and business_index (e.g., "allocation_allocation_rate"). Business tag addition: Based on the custom_label field in the configuration table, business dimensions (such as plan number, warehouse) are used as indicator tags (such as allocation_rate{plan_no="PL2025001",warehouse="LA"} 98), supporting multi-dimensional splitting and viewing; Dynamic metric updates: After each calculation task is executed, the Gauge metric value is updated to ensure that the monitoring data is synchronized in real time.

[0065] Step 46: When the configuration is changed or deleted, perform the following resource reclamation operation: Retrieve the monitoring metrics corresponding to this configuration from the resource management mapping table; Call its shutdown method to turn off the monitoring metric and stop numerical updates; Clear the value cache for this monitoring metric; Cancel the monitoring metric to free up memory resources.

[0066] (2) Reclaiming index resources (corresponding to BusinessMetricsServiceImpl.closeResource) Automatic resource reclamation is performed when configurations are changed or deleted: Retrieve the Gauge instance with the corresponding configuration ID from the gaugeMap (a ConcurrentHashMap that stores metric references); Call the ObservableDoubleGauge.close() method to close the metric and stop updating the value; Clear the indexMap of the numerical cache for this metric to avoid interference from old data; The underlying mechanism unregisters metrics through Prometheus's CollectorRegistry (a component in the Prometheus client library used to register and manage metric collectors), freeing up memory resources and completely removing metrics from the monitoring system.

[0067] Step 5: In the visualization monitoring platform, the monitoring metric is automatically discovered and displayed. It supports multi-dimensional display and drill-down analysis based on the monitoring tags, and alarm rules are configured. Grafana (an open-source visualization and analysis platform, typically integrated with data sources such as Prometheus for creating dashboards and charts) links dashboard configuration with dynamic configuration tables to achieve "instant visualization upon adding a metric".

[0068] In this embodiment, step 5 specifically includes: Step 51: Push all enabled monitoring metrics to the metrics data interface in real time. The Prometheus monitoring system (an open-source system monitoring and alerting toolkit used to collect, store, and query time-series data) obtains and stores monitoring metrics from the metrics data interface through periodic polling. Step 52: Configure the Prometheus monitoring system as its data source in the visualization monitoring platform. By entering the prefix of the monitoring indicator name (such as "allocation_") in the data query interface, it will automatically match and display all monitoring indicators that meet the conditions. Step 53: Based on the monitoring tags attached to the monitoring indicators, provide functions in the visualization chart to filter data by tag value, group display, and drill-down analysis (such as clicking "LA Warehouse" to view the achievement rate of all plans under that warehouse); Step 54: Pre-configure alarm rule templates related to supply chain business in the visualization monitoring platform (such as "achievement rate <85% alarm"). When adding new monitoring indicators, users can configure alarms by selecting the corresponding alarm rule template and adjusting the threshold. There is no need to reconfigure the alarm logic. Alarm notifications support multiple message channels (such as DingTalk, email, etc.).

[0069] This embodiment also includes configuring synchronization and event-driven mechanisms: Configuration synchronization is achieved using a publish / subscribe event-driven pattern. The configuration management interface acts as an event publisher, publishing a configuration change event that carries a unique identifier of the configuration and the type of change when a configuration is added, modified, or disabled. The task lifecycle management acts as an event subscriber, monitoring the configuration change event, and automatically triggering refresh, stop, or create operations on the associated scheduled tasks upon receiving the configuration change event; The resource management mapping table also acts as an event subscriber, monitoring the configuration change events, and automatically triggering resource reclamation and cleanup operations on the associated monitoring metrics when it receives a configuration deletion or disabling.

[0070] Event delivery mechanism: Based on Spring EventBus (Event Bus: a communication pattern for passing event messages between different components or modules), it supports asynchronous processing, avoids configuration operation blocking, and ensures system response speed.

[0071] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for calculating and monitoring supply chain business indicators based on dynamic configuration, characterized in that, Includes the following steps: Step 1: Provide a unified and dynamic configuration table, which includes at least the business service identifier, business indicator name, data source information, data query statement, calculation rule type, calculation expression, scheduling type, and scheduling parameters; provide a configuration management interface for the configuration table to support adding, modifying, deleting, querying, verifying, and importing / exporting configurations. Step 2: Based on the scheduling type and scheduling parameters in the configuration table, select the corresponding scheduling strategy class and create a scheduling task to manage the lifecycle of all calling tasks; Step 3: When the scheduling task is triggered, obtain business data according to the data source information and data query statement in the configuration table; according to the calculation rule type in the configuration table, call the corresponding calculation strategy class, and calculate the business data in combination with the calculation expression to obtain the indicator value; Step 4: Based on the business service identifier and business indicator name in the configuration table, encapsulate the calculated indicator value into a monitoring indicator in a preset format, attach a corresponding monitoring tag to the monitoring indicator, report the monitoring indicator to the visualization monitoring platform, and manage the entire lifecycle of the monitoring indicator. Step 5: In the visualization monitoring platform, the monitoring indicator is automatically discovered and displayed. It supports multi-dimensional display and drill-down analysis based on the monitoring tags, and alarm rules are configured.

2. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 1, characterized in that, The configuration table in step 1 is a data table in a relational database, which contains at least the following fields: A unique identifier field, used to uniquely identify each configuration record; The business service identifier field is used to distinguish different business domains; The Business Metric Name field is used to define a unique name for the monitored metric; The data source information field group includes the database connection address, database name, and table name; The data query statement field is used to define the structured query language statement for retrieving business data; The calculation rule type field indicates the calculation rule used. Its value is an enumeration type, including count, sum, difference, and user-defined expression. The calculation expression field, when the calculation rule type is a custom expression, is used to define specific mathematical calculation formulas; The scheduling type field indicates the scheduling type used. Its value is an enumeration type, including scheduling based on Cron expressions and scheduling based on fixed frequency. The scheduling parameter field is used to store a Cron expression or a fixed frequency of milliseconds according to the scheduling type; The monitoring tag field is used to define business dimension tags that need to be attached to monitoring metrics in the form of key-value pairs.

3. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 2, characterized in that, The configuration verification function of the configuration management interface in step 1 is implemented through an independent configuration verification engine, specifically including: The data query statement fields are parsed and logically validated to verify whether the table names and field names involved exist in the target data source. The calculation expression fields are parsed to verify whether the variables referenced in the formula have been defined in the associated field mapping relationship, and to check for the risk of division by zero. Perform non-empty validation on required fields; Verify whether the format of the scheduling parameter field conforms to the syntax specification of the corresponding type based on the scheduling type field.

4. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 1, characterized in that, Step 2 specifically includes: Step 21: Define a scheduling strategy engine to encapsulate different scheduling logic through an enumeration class; for each scheduling type, implement a specific scheduling strategy class: if the scheduling type is a Cron expression-based scheduling, the corresponding scheduling strategy class is a Cron strategy, which is used to parse the Cron expression and create time-based scheduling tasks; if the scheduling type is a fixed-frequency scheduling, the corresponding scheduling strategy class is a fixed-frequency strategy, which is used to create periodic scheduling tasks at fixed millisecond intervals. Step 22: Maintain a task registry and a parameter mapping table; the task registry is a key-value pair data structure, where the key is a unique identifier of the configuration and the value is the task instance corresponding to the scheduled task created for that configuration; the parameter mapping table is used to store the correspondence between the unique identifier of each valid configuration and its currently effective scheduling parameters; Step 23: When the system starts up, when it scans the configuration table and finds a configuration that is enabled and has no associated task, the scheduling strategy engine selects the corresponding scheduling strategy class according to the scheduling type and scheduling parameters, and calls its specific strategy to create a calling task. The unique identifier of the configuration and the task instance are stored in the task registry, and the unique identifier of the configuration and the scheduling parameters are recorded in the parameter mapping table. Step 24: Start a background timed scanning thread to periodically compare the scheduling parameters recorded in the parameter mapping table with the latest scheduling parameters in the configuration table; when a change in scheduling parameters is detected or a configuration change event is detected, execute the task refresh process.

5. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 4, characterized in that, Step 23 specifically includes: Step 231: At the initial startup of the system, perform a full scan process to traverse and query all configuration records marked as enabled in the configuration table; or during operation, when a configuration change event notification is received, perform an incremental scan process for the configuration record indicated by the configuration change event. Step 232: For each configuration record scanned, check if there is a task instance in the task registry with the unique identifier of the configuration as the key; if not, determine that there is no active task associated with the configuration. Step 233: For configurations that meet the conditions of being enabled and having no associated tasks, the scheduling strategy engine determines the corresponding scheduling type based on the value of the scheduling parameter field in the configuration table, then dynamically selects the corresponding scheduling strategy class based on the scheduling type, calls its specific strategy to create a calling task, and obtains a task instance used to control the lifecycle of the task. Step 234: Store the unique identifier of the configuration and the task instance in the task registry; at the same time, store the unique identifier of the configuration and its current scheduling parameters in the parameter mapping table; Step 24 specifically includes: Automatic task synchronization is achieved through a separate background timed scanning thread, which performs the following operations periodically at fixed time intervals: Step 241: Traverse all scheduling parameters in the parameter mapping table; Step 242: For each scheduling parameter, use the unique identifier of its stored configuration as an index to query the configuration table and obtain the latest scheduling parameter for that configuration. Step 243: Compare the scheduling parameters in the configuration table with the scheduling parameters in the parameter mapping table; Step 244: If the comparison results are inconsistent, it is determined that the scheduling parameters of the configuration have been changed, and the scheduling task for the configuration is refreshed. Step 245: When a configuration change event is detected, the scheduled task is refreshed directly for the configuration associated with the configuration change event; The scheduling task refresh process specifically includes: Based on the unique identifier of the configuration to be refreshed, retrieve and obtain the corresponding task instance from the task registry; call the cancellation method of the task instance to terminate the currently executing task instance. Remove the task instance corresponding to the unique identifier of this configuration from the task registry; remove the corresponding call parameter record from the parameter mapping table; Based on the latest information in the configuration table, create new scheduling tasks and corresponding task instances. The newly generated task instance is stored in the task registry, and the latest scheduling parameters are stored in the parameter mapping table to complete the synchronization.

6. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 1, characterized in that, Step 3 involves calling the corresponding calculation strategy class based on the calculation rule type in the configuration table, specifically including: Define a computation strategy engine to encapsulate different computation logic through an enumeration class; For each type of calculation rule, implement a specific calculation strategy class: 1) If the calculation rule type is counting, then the corresponding calculation strategy class is counting strategy. The counting strategy is used to execute data query statements and count the number of record rows in the query result set as the indicator value. 2) If the calculation rule type is summation, the corresponding calculation strategy class is summation strategy. The summation strategy is used to parse the specified summation field name from the field mapping relationship associated with the calculation rule, and perform summation operation on all values ​​of the field in the query result set as the index value. 3) If the calculation rule type is difference, the corresponding calculation strategy type is difference strategy. The difference strategy is used to parse the minus number segment name and the subtracted number segment name from the field mapping relationship, perform subtraction operation on the corresponding field value of each record in the query result set, and accumulate the difference results of all records as the indicator value. 4) If the calculation rule type is a custom expression, the corresponding calculation strategy class is a custom expression strategy. The custom expression strategy is used to parse the correspondence between expression variables and business fields from the field mapping relationship, substitute the business field values ​​in the query result set into the corresponding variables in the calculation expression, and evaluate the expression after substituting the values ​​through the expression parsing engine to obtain the indicator value. The calculation strategy engine dynamically selects and calls the corresponding specific calculation strategy class based on the value of the calculation rule type field in the configuration table.

7. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 6, characterized in that, The expression parsing engine used in the custom expression strategy is the Spring Expression Language Parser, and its execution process includes: Parse the calculated expression field and extract all variable names that are wrapped by variable placeholders; Based on the field mapping relationship, each variable name is mapped to the corresponding business field name in the query result set; Iterate through the query result set, replace the actual value of the business field name in each record with the corresponding variable placeholder in the expression, and form a calculable numerical expression; The expression parsing engine is invoked to evaluate the numerical expression; The evaluation result is formatted to retain a set number of decimal places.

8. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 1, characterized in that, Step 4 specifically includes: Step 41: Generate a unique monitoring indicator name according to the business service identifier and business indicator name in the configuration table and in accordance with the predefined naming rules; Step 42: Create a Gauge-type monitoring metric that supports dynamic numerical updates under the monitoring metric name; Step 43: Based on the monitoring tag field in the configuration table, attach corresponding tag key-value pairs to the monitoring metrics; Step 44: Update the indicator values ​​obtained from each calculation to the monitoring indicator and report them to the visualization monitoring platform; Step 45: Maintain all active monitoring metrics through a resource management mapping table; Step 46: When the configuration is changed or deleted, perform the following resource reclamation operation: Retrieve the monitoring metrics corresponding to this configuration from the resource management mapping table; Call its shutdown method to turn off the monitoring metric and stop numerical updates; Clear the value cache for this monitoring metric; Cancel the monitoring metric to free up memory resources.

9. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 1, characterized in that, Step 5 specifically includes: Step 51: Push all enabled monitoring metrics to the metrics data interface in real time. The Prometheus monitoring system obtains and stores the monitoring metrics from the metrics data interface through periodic polling. Step 52: Configure the Prometheus monitoring system as its data source in the visualization monitoring platform. By entering the prefix of the monitoring indicator name in the data query interface, all monitoring indicators that meet the conditions will be automatically matched and displayed. Step 53: Based on the monitoring tags attached to the monitoring indicators, provide functions for data filtering, grouping, and drill-down analysis by tag value in the visualization chart; Step 54: Pre-configure alarm rule templates related to supply chain business in the visualization monitoring platform. When adding new monitoring indicators, users can configure alarms by selecting the corresponding alarm rule template and adjusting the threshold. Alarm notifications support multiple message channels.

10. The method for calculating and monitoring supply chain business indicators based on dynamic configuration as described in claim 1, characterized in that, It also includes configuring synchronization and event-driven mechanisms: Configuration synchronization is achieved using a publish / subscribe event-driven pattern. The configuration management interface acts as an event publisher, publishing a configuration change event that carries a unique identifier of the configuration and the type of change when a configuration is added, modified, or disabled. The task lifecycle management acts as an event subscriber, monitoring the configuration change event, and automatically triggering refresh, stop, or create operations on the associated scheduled tasks upon receiving the configuration change event; The resource management mapping table also acts as an event subscriber, monitoring the configuration change events, and automatically triggering resource reclamation and cleanup operations on the associated monitoring metrics when it receives a configuration deletion or disabling.

Images