A rule engine-based active early warning method, device, equipment and medium

Abstract

The application discloses a kind of active early warning method, device, equipment and medium based on rule engine, the method includes scanning the pool of business objects to be handled according to preset period and filtering to generate uniform business snapshot;Risk level is determined by calculating the length of stay and matching with multistage risk window;Determine the primary cause evidence field based on the rule set of blocking reason identification;Match disposal to generate deduplication key data;New early warning instance is created or in situ upgrade is executed based on deduplication key data;Early warning instance flow is transferred based on closed-loop state machine and is linked to close.The application matches interval by the length of stay and multistage risk window to identify risk level in advance, locates blocking reason based on the rule set of blocking reason identification, and controls the new creation and in situ upgrade of early warning instance using deduplication key data, combined with closed-loop state machine to realize the linkage of early warning instance and business state change Close, improve the early warning accuracy and timeliness of the business object to be handled.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a proactive early warning method, apparatus, device, and medium based on a rule engine. Background Technology

[0002] As businesses expand, the number of orders and work orders awaiting processing continues to grow, placing higher demands on timely monitoring of the fulfillment process. In existing technologies, business management systems typically use scheduled tasks to scan for pending business objects and trigger alerts based on a single timeout threshold. Specifically, when the processing time of a business object exceeds a preset fixed threshold, a timeout alert message is pushed to pre-designated personnel or groups.

[0003] However, existing technologies based on a single timeout threshold can only provide passive alerts after a business object has timed out. They cannot differentiate or identify the risk stage of the business object before the timeout occurs. Furthermore, the timeout alerts do not include the blocking reasons that caused the business object to stagnate. The alert messages are repeatedly pushed to fixed personnel in an indiscriminate mass distribution, and the alert status does not update in response to changes in the actual status of the business object. This results in resolving issues continuing to trigger alerts while unresolved issues are not escalated for processing, leading to low accuracy and timeliness of early warnings for pending business objects in existing technologies. Summary of the Invention

[0004] This invention provides a proactive early warning method, apparatus, device, and medium based on a rule engine, aiming to solve the problem of low accuracy and timeliness of early warnings for pending business objects in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a proactive early warning method based on a rule engine, comprising: The pool of business objects to be processed is scanned at a preset period to obtain candidate objects, and the candidate objects are filtered in the main table according to preset rules. At the same time, data is extracted from the business system in parallel to generate a unified business snapshot. Extract the status timestamp from the unified business snapshot and calculate the dwell time. Match the dwell time with a preset multi-level risk window to determine the risk level. Load the blocking cause identification rule set, and use the rule engine to input the attribute values ​​of the unified business snapshot into the conditional expression of the blocking cause identification rule set for evaluation, and determine the main cause evidence field according to the priority; The principal evidence field is matched with the risk level to generate deduplicated key data; Based on the deduplication key data, a preset warning instance table is retrieved. If no active instance exists, a new warning instance is created. If an active instance exists and the risk level is higher than the historical risk level, an in-situ upgrade is performed. The warning instance is driven to flow between state nodes based on a preset closed-loop state machine. At the same time, it listens for business state change events to close the warning instance in a coordinated manner, and generates a warning audit snapshot when the state transitions.

[0006] Secondly, embodiments of the present invention provide an active early warning device based on a rule engine, comprising: The data generation unit is used to scan the pool of business objects to be processed according to a preset period to obtain candidate objects, filter the candidate objects according to the preset rules of the main table, and extract data from the business system in parallel to generate a unified business snapshot. The data matching unit is used to extract the status timestamp from the unified business snapshot and calculate the dwell time, and match the dwell time with a preset multi-level risk window to determine the risk level. The data evaluation unit is used to load the blocking cause identification rule set, and evaluate the attribute values ​​of the unified business snapshot by inputting them into the conditional expression of the blocking cause identification rule set through the rule engine, and determine the main cause evidence field according to the priority. The data processing unit is used to match and process the principal evidence field with the risk level to generate deduplicated key data; The data judgment unit is used to retrieve a preset warning instance table based on the deduplication key data. If no active instance exists, a new warning instance is created. If an active instance exists and the risk level is higher than the historical risk level, an in-situ upgrade is performed. The data early warning unit is used to drive the early warning instance to flow between state nodes based on a preset closed-loop state machine, while listening for business state change events to shut down the early warning instance in a coordinated manner, and generating an early warning audit snapshot when the state transitions.

[0007] Thirdly, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the proactive early warning method based on a rule engine of the first aspect.

[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the proactive early warning method based on a rule engine of the first aspect.

[0009] This invention provides a proactive early warning method based on a rule engine, comprising: scanning a pool of pending business objects at a preset period to obtain candidate objects; filtering the candidate objects according to a preset rule master table; simultaneously extracting data from the business system in parallel to generate a unified business snapshot; extracting the state timestamp from the unified business snapshot and calculating the dwell time; matching the dwell time with a preset multi-level risk window to determine the risk level; loading a blocking cause identification rule set; evaluating the attribute values ​​of the unified business snapshot in the conditional expression of the blocking cause identification rule set through a rule engine, and determining the main cause evidence field according to priority; matching the main cause evidence field with the risk level to generate deduplicated key data; retrieving a preset early warning instance table based on the deduplicated key data; creating a new early warning instance if no active instance exists, and performing an in-situ upgrade if an active instance exists and the risk level is higher than the historical risk level; driving the early warning instance to flow between state nodes based on a preset closed-loop state machine, while listening for business state change events to close the early warning instance in a coordinated manner, and generating an early warning audit snapshot during state transition. This invention identifies risk levels in advance by matching dwell time with multi-level risk windows, locates the cause of blockage based on a rule set for identifying the cause of blockage, and uses deduplication key data to control the creation and in-situ upgrade of early warning instances. Combined with a closed-loop state machine, it realizes the linkage between early warning instances and changes in business status, thereby improving the accuracy and timeliness of early warnings for business objects to be processed.

[0010] This invention also provides a proactive early warning device, computer equipment, and storage medium based on a rule engine, which have the same beneficial effects as described above. Attached Figure Description

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

[0012] Figure 1 A flowchart illustrating a proactive early warning method based on a rule engine, provided in an embodiment of the present invention; Figure 2 A system architecture diagram of a proactive early warning method based on a rule engine provided in an embodiment of the present invention; Figure 3 A routing diagram for a proactive early warning method based on a rule engine, provided in an embodiment of the present invention; Figure 4 This is a schematic block diagram of an active early warning device based on a rule engine, provided for an embodiment of the present invention.

[0013] Explanation of reference numerals in the attached figures: 400. Active early warning device based on rule engine; 401. Data generation unit; 402. Data matching unit; 403. Data evaluation unit; 404. Data processing unit; 405. Data judgment unit; 406. Data early warning unit. Detailed Implementation

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

[0015] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0016] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0017] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0018] Please see below. Figure 1 , Figure 1 The flowchart of a proactive early warning method based on a rule engine provided in an embodiment of the present invention specifically includes steps S101 to S106.

[0019] S101. Scan the pool of business objects to be processed according to a preset period to obtain candidate objects, and filter the candidate objects according to the preset rules in the main table. At the same time, extract data from the business system in parallel to generate a unified business snapshot. S102. Extract the status timestamp from the unified business snapshot and calculate the dwell time. Match the dwell time with a preset multi-level risk window to determine the risk level. S103. Load the blocking cause identification rule set, and use the rule engine to input the attribute values ​​of the unified business snapshot into the conditional expression of the blocking cause identification rule set for evaluation, and determine the main cause evidence field according to the priority. S104. Match the primary cause evidence field with the risk level to generate deduplicated key data; S105. Based on the deduplication key data, retrieve the preset warning instance table. If there is no active instance, create a new warning instance. If there is an active instance and the risk level is higher than the historical risk level, perform an in-situ upgrade. S106. The warning instance is driven to flow between state nodes based on a preset closed-loop state machine. At the same time, the business state change event is monitored to close the warning instance in a coordinated manner, and a warning audit snapshot is generated when the state transitions.

[0020] In step S101, the pool of business objects to be processed is automatically scanned at a preset period to obtain candidate objects. These candidate objects are then filtered according to a preset rule table, eliminating objects that do not meet the criteria defined in the rule table. Based on this, the system extracts data related to the filtered objects from multiple business systems in parallel, and integrates the extracted data to generate a unified business snapshot, which serves as the unified data benchmark for subsequent steps.

[0021] In one embodiment, step S101 includes: The distributed scheduler triggers tasks according to a preset scanning strategy to perform incremental scanning on the pool of pending business objects and obtain the status bits of candidate objects. Read the status bits of the candidate objects and filter out objects with non-processable status markers to obtain the removed candidate objects; The control fields of the main rule table are retrieved, and the attributes of the eliminated candidate objects are verified one by one against the control fields to generate an applicable order set. The business entities of the applicable order set are traversed to initiate remote calls to multiple business systems in parallel to obtain discrete business attribute data; The business attribute data is cleaned and mapped and bound separately to generate a unified business snapshot.

[0022] In this embodiment, tasks are first triggered by a distributed scheduler according to a preset scanning strategy. The distributed scheduler is a task scheduling component deployed across multiple service nodes, capable of unified orchestration and periodic triggering of scanning tasks. For example, it can be implemented using distributed scheduled task frameworks such as Quartz or XXL-Job. The preset scanning strategy supports multi-dimensional periodic frequency settings. During regular working hours, the inspection cycle can be set to 30 minutes or one hour; while during specific business activities such as major promotions, the distributed scheduler automatically switches to a high-frequency scanning mode of 15 minutes based on time threshold conditions to increase the detection frequency of the pending business object pool. The pending business object pool refers to the collection of business objects currently in the pending set that need to be continuously monitored by the system. The pending set mainly includes order data with the status marked as pending shipment or partially shipped. For business scenarios with massive data volumes, the system performs incremental scanning on the pool of pending business objects. This incremental scanning logic is based on a time window, requesting only business objects whose state has changed between the last scan watermark and the current time point from the database. The scan watermark refers to the time reference point recorded when the last scan task was completed. Incremental scanning can effectively reduce the retrieval overhead of invalid data. After the task is triggered, the system initiates a query request to the underlying order microservice, extracts candidate objects in the pending set, and obtains the status bit of each candidate object. The status bit is an internal state enumeration value that identifies the current lifecycle stage of the business object.

[0023] Furthermore, the status bits of the candidate objects are read, and an applicability filtering procedure is executed to filter out objects with non-pending status markers. The system checks the status enumeration value of each candidate object one by one, removing objects marked as canceled, shipped, in the process of refund, or closed from the memory set, retaining only objects in the pending shipment or partially shipped pending processing status, thus obtaining the removed candidate objects. This filtering operation can exclude business objects that do not require warnings before entering subsequent rule verification, reducing invalid calculations.

[0024] Furthermore, the control fields of the main rule table are retrieved to perform rule-level validation on the removed candidate objects. The main rule table (warning_rule) is a pre-configured data table used to define the basic data for warning rules. Its control fields include a unique rule identifier (rule_id), business type (business_type), applicable order status (applicable_status), applicable channel (applicable_channel), and applicable category (applicable_category). The system validates the data attributes of the removed candidate objects against the control fields one by one, retaining only business objects that fully comply with the specific business type, channel, and category restrictions. This generates an applicable order set that strictly conforms to the processing boundaries of the rule engine. The applicable order set refers to the set of business objects determined to be included in the scope of this warning assessment after status filtering and rule validation.

[0025] After establishing the applicable order set, the system performs cross-service heterogeneous data integration. Specifically, the system iterates through each business entity in the applicable order set and initiates remote calls in parallel to multiple business systems to obtain discrete business attribute data. A remote call refers to the operation of requesting data from external business systems through a Remote Procedure Call (RPC) interface. In a specific scenario, the system can initiate remote calls in parallel to five core business systems. The system first extracts basic information fields from the order management system, including order number (order_no), channel code, category code, order creation time, and exception flag and description fields. Second, the system requests the payment voucher status and payment completion timestamp associated with the order from the payment system. Next, the system extracts the specific product code, the current warehouse code, real-time available inventory, and reserved inventory locked by other businesses from the inventory system. Furthermore, the system obtains the destination province, city, and district text information and the structured verification status code from the address resolution system through the address service interface. Finally, the system extracts the real-time inbound and outbound load rate and capacity congestion level of the specified warehouse node from the warehouse management microservice, and obtains the responsible customer service representative identifier, operations personnel identifier, and geographic region code associated with the order from the customer service and operations support system. Because these remote calls are initiated in parallel, the data collection time for a single business entity can be significantly reduced.

[0026] After acquiring all the aforementioned business attribute data, the system performs data cleaning and mapping binding on the data. Data cleaning refers to formatting and removing invalid values ​​from raw data of varying sources. Mapping binding refers to associating the cleaned discrete data fields with corresponding nodes in a unified data structure according to predefined structural relationships. The system serializes the scattered data entities into standardized business snapshot structure objects in memory, thus generating a unified business snapshot. This unified business snapshot is stored in the system's processing context in a specific data mapping format (e.g., JSON, JavaScript ObjectNotation, a lightweight structured data exchange format), serving as the absolute data benchmark for all subsequent warning logic judgments. The generation of the unified business snapshot completely isolates subsequent steps from direct dependence on external business systems, not only locking in the data aspect at the moment the business occurred but also preserving complete original evidence for final system audit traceability.

[0027] For example, in a specific application scenario, during a particular major promotional event period, the system configuration center loads a set of parameters identified as the event period. The distributed scheduler reads the high-frequency inspection instructions and wakes up the scanning service at a set specific time. The system sends a data retrieval instruction to the underlying database, with filtering conditions limited to orders in the pending shipment or partially shipped status, excluding all data records with shipped or canceled flags. This scan extracts 5,000 candidate pending shipment order records from the underlying database. The system locates a pending shipment order with a specific promotional identifier sequence among the 5,000 records, reads the order's channel attribute as mobile application, category as specific gift box, and payment status as paid. The system compares these attributes with the control fields of the default pending shipment warning rules pre-loaded in the main rule table, confirming that the order fully meets the rule's admission and interception conditions, and includes it in the applicable order set. The system then initiates snapshot encapsulation of the external data source. For this order, it extracts the actual payment completion time from the payment gateway (8 PM the previous day); the inventory status of the specific goods it contains from the inventory service node (current available inventory is zero, while reserved inventory is one hundred); the verification result of the target receiving area from the address resolution system (valid); the current load rate of the pre-allocated shipping warehouse from the warehousing system (nearly full capacity); and the primary customer service representative identifier and the identifier of the associated operations manager for this order from the employee organizational structure tree. The system assembles these attributes from various dimensions, instantiates a structured unified business snapshot object in memory, and places it into the main processing pipeline, passing it to the next step as basic input parameters.

[0028] In step S102, the status timestamp recorded in the unified business snapshot can be extracted, and the difference between it and the current time can be calculated to obtain the dwell time of the business object in the current state. Subsequently, the system matches the dwell time with the preset multi-level risk windows one by one, and determines the corresponding risk level according to the risk window interval in which the dwell time falls.

[0029] In one embodiment, step S102 includes: Extract the timestamp of the business object entering the current state from the unified business snapshot, and calculate the difference between it and the current server time to obtain the dwell time; Load the multi-level risk windows issued by the configuration center to extract the multiple window definition structures associated with the current business rules; Read the coefficient adjustment factor corresponding to the business scenario, and use the coefficient adjustment factor to scale the basic interval threshold in the window definition structure to obtain the scaled window definition structure; The dwell time is compared with the scaled window definition structure by interval boundaries, and the risk level code of the first hit window is extracted; The risk level code and the duration of stay parameter are attached as additional attributes to the unified business snapshot.

[0030] In this embodiment, after receiving the generated unified business snapshot, the system enters the time-dimensional risk assessment stage, calculating discrete risk quantification indicators based on dynamically elapsed time. The system first executes a dwell time calculation program. Specifically, the system extracts the timestamp of the business object encapsulated in the unified business snapshot when it enters the current state (i.e., the time attribute of the business object entering the current pending state), and calls the unified time synchronization interface of the system kernel to obtain the current server time. The unified time synchronization interface refers to the time service interface provided by the system kernel for outputting a consistent absolute time base to each service node. The system performs a difference calculation between the current server time and the timestamp of the business object entering the current state to obtain the absolute time span of the business object's stagnation in this specific state. This time span data structure is then converted into a floating-point value in hours, thus obtaining the dwell time, which is the dwell time parameter used in subsequent calculations.

[0031] Furthermore, the system loads the multi-level risk windows issued by the configuration center. The configuration center refers to a configuration management component that centrally manages and uniformly distributes various business rule parameters within the system. The multi-level risk windows are continuous, hierarchical intervals based on dwell time, used to characterize different levels of risk severity. They are not single, static judgment nodes, but rather rule matrices customized for different business scenarios. The system queries the associated risk window configuration table (warning_risk_window) and extracts multiple window definition structures associated with the current business rule. Each window definition structure encapsulates attributes such as risk level identifier (risk_level), interval start time value (window_start_hours), interval end time value (window_end_hours), color code (color), and upgrade target level for jumping to a higher level (upgrade_to_level).

[0032] Furthermore, the system reads the coefficient adjustment factor corresponding to the business scenario and uses this factor to scale the basic interval threshold in the window definition structure. The coefficient adjustment factor is a pre-configured multiplicative scaling parameter for different business scenarios, used to scale the basic interval threshold. The basic interval threshold is the system's default baseline judgment time, typically set to twenty hours. In special scenarios such as fresh produce, major promotional events, or cross-border logistics, the system uses the coefficient adjustment factor to differentiate the basic interval threshold. For example, for fresh produce, the system automatically assigns a coefficient of 0.5 to compress the window to accommodate its short shelf life and the need for early warning; for customized products, the system assigns a coefficient of 2.0 to expand the window to match its long production cycle; for orders during major promotional events, the system can assign a coefficient of 0.7 to shorten the window; and for cross-border orders, a coefficient of 1.5 can be assigned to appropriately widen the window. After the above scaling calculations, the system obtains the scaled window definition structure.

[0033] Based on this, the system compares the calculated dwell time with the scaled window definition structure one by one against the interval boundaries. Specifically, the system determines whether the dwell time is greater than or equal to the start time of the current interval and strictly less than the end time of the current interval. For windows configured with the highest risk level, their interval end time is usually set to a null value, and the system only verifies whether the dwell time exceeds the lower limit of its interval start when comparing. When the system scans the first risk window that meets the interval inclusion condition, the comparison process immediately terminates, and the system extracts the risk level code contained in the first hit window. In this embodiment, the system's default risk level is usually mapped to four progressively increasing levels: the initial intervention level of concern, the warning level of standard timeout, the severe level of serious violation of the performance agreement, and the emergency level of extreme abnormality.

[0034] Finally, the system adds the risk level code extracted from the interval comparison, along with the precise dwell time parameter used in the calculation, as new additional attribute nodes and mounts them to the unified business snapshot structure. At this point, the basic static unified business snapshot is given a dynamic risk depth identifier, which the system packages and passes to the next step for identifying the cause of the blockage.

[0035] For example, in a specific application scenario, the system takes a unified business snapshot of orders from a major promotional event. The system extracts the timestamp of the business object entering its current state. The snapshot data shows that the order entered the "pending shipment" state at 8 PM the previous day. The system reads the current server time through the unified time synchronization interface. Assuming it is 10:15 AM the next day, the system performs a time difference calculation, determining that the time interval is 14 hours and 15 minutes. This difference is then converted to a standard floating-point value, resulting in a dwell time of 14.25 hours. The system simultaneously reads the currently matched multi-level risk windows. Because the system is currently in promotional event mode, the coefficient adjustment factor issued by the configuration center is 0.7. Internally, the system dynamically degrades the baseline 20-hour basic interval threshold to 14 hours through multiplication, thereby redefining the boundaries of each level of risk interval. After coefficient scaling, the first-tier "attention level" risk window is defined by the system within a span of 12 hours starting and 24 hours ending, with the second-tier "warning level" risk window following immediately after. The system calculates the dwell time of 14.25 hours and compares it against the interval boundaries in the scaled window definition structure. It determines that 14.25 is greater than 12 and less than 24, precisely falling within the first tier of risk windows for the attention level. The system thus locks onto the target and extracts the risk level code configured for this first hit window, i.e., the attention level. Subsequently, the system attaches the specific dwell time parameter of 14.25 hours and the risk level code of the attention level as additional attributes of the risk calculation result to the unified business snapshot of this order.

[0036] In step S103, a pre-configured set of rules for identifying the cause of the blockage is loaded. The rule engine then evaluates the attribute values ​​from the unified business snapshot by feeding them one by one into the conditional expressions contained in the set of rules for identifying the cause of the blockage, thus obtaining the matching rules. When multiple matching rules exist, the system sorts them according to their priority and determines the principal cause evidence field accordingly, which serves as the basis for subsequent processing.

[0037] In one embodiment, step S103 includes: Load the blocking cause identification rule set and traverse the blocking cause identification rule set to apply the conditional expression corresponding to the blocking cause identification rule set to the unified business snapshot for attribute value detection; Collect the hit rules that return true values ​​in the attribute value detection, sort all the priority values ​​of the hit rules in ascending order, select the cause code of the hit rule with the highest priority after sorting as the primary cause, and use the remaining hit cause codes as secondary causes; Read the evidence field mapping list corresponding to the primary cause and secondary cause, and extract the corresponding values ​​from the unified business snapshot according to the evidence field mapping list to generate the primary cause evidence field.

[0038] In this embodiment, after receiving a unified business snapshot with risk levels attached, the system initiates the identification and analysis of the blocking cause. Following the multi-dimensional underlying node fields extracted from the unified business snapshot, the system reverse-engineers the fundamental physical or logical causes leading to the stagnation of the business object and outputs tamper-proof evidence data. The system's primary action is to load the blocking cause identification rule set extracted from the rule base. This blocking cause identification rule set (warning_reason_rule) refers to a pre-configured collection of identification rules used to determine the cause of business object stagnation. Each identification rule includes an independent rule code, reason code (reason_code), reason name, conditional decision logic tree, corresponding evidence field mapping list (evidence_fields), and a priority attribute defining the degree of importance. The system employs a self-developed or integrated rule engine. A rule engine is a software component that extracts business decision logic from the main application code in the form of rules, loads externally configured rule definition files, sequentially performs condition matching on input data, and outputs decision results. For example, it can be implemented using open-source rule engines such as Drools. The system iterates through each enabled identification rule in the set of rules for identifying the cause of the blockage, and applies the conditional expressions encapsulated within each identification rule to the input unified business snapshot for attribute value detection. The conditional expression is a judgment logic expression composed of comparison operators and logical operators with snapshot attribute fields as operands. Attribute value detection is the evaluation process of substituting the attribute values ​​of the corresponding nodes in the unified business snapshot into the conditional expression for logical operation and returning a true or false value.

[0039] When the system executes conditional judgments, it performs multi-dimensional attribute value detection for different abnormal scenarios. For stockout scenarios, the system issues instructions to the inventory node data area of ​​the unified business snapshot, and the judgment logic verifies whether the available inventory is always equal to zero and whether the reserved inventory is strictly greater than zero. For payment anomaly scenarios, the system checks the payment attribute node of the snapshot to verify whether the payment status is caught in the enumeration of abnormal states such as failure, suspension, or refund. For address anomaly scenarios, the system scans the address service node of the snapshot to determine whether the verification status bit is invalid or unconfirmed. For warehouse overload scenarios, the system extracts the warehouse node data of the snapshot to verify whether the current load rate indicator exceeds the 90% warning line, or whether the warehouse capacity status has been marked as near full load or full load.

[0040] When a single unified business snapshot possesses characteristics across multiple anomalies, the parallel evaluation of the rule execution engine will return multiple true-value matching results. At this point, the system triggers multi-cause processing logic. Specifically, the system collects the hit rules that returned true values ​​in the attribute value detection, calls a sorter to sort the priority values ​​embedded in all the hit rules in ascending order, selects the cause code mapped to the hit rule with the highest priority after sorting, and designates it as the primary cause of this warning event. Simultaneously, the system packages all remaining hit cause codes in the sorted sequence into an auxiliary array, collectively referred to as the secondary causes of this warning event. By defining primary and secondary causes, the system can still output clear attribution conclusions even when multiple causes coexist, avoiding confusion between causes.

[0041] After defining the primary and secondary causes, the system initiates the evidence solidification process. Specifically, the system reads the evidence field mapping list corresponding to the primary and secondary causes. This evidence field mapping list refers to a predefined list in each identification rule that specifies the snapshot field names upon which the determination of the cause depends. Based on this list, the system precisely projects the corresponding leaf node values ​​from the massive unified business snapshot to generate the primary cause evidence field. For example, if a stockout rule is hit, the system forcibly extracts the product code, available inventory value, reserved inventory value, and current warehouse code from the unified business snapshot as a structured evidence data cluster. The system then encapsulates the final primary cause's cause code, the secondary cause's cause code array, the Boolean value indicating the coexistence of multiple causes, and the extracted primary cause evidence field into a cause and evidence result object, which is then merged with the preceding unified business snapshot content and passed to the next step.

[0042] For example, in a specific application scenario, the system receives an expanded unified business snapshot of a large-scale promotional order. The rule execution engine begins loading a complete set of rules for identifying blocking causes, including stockouts, payment anomalies, address anomalies, and warehouse overload. The system first feeds the snapshot into the stockout rule execution pipeline, parses the rule's conditional expression, and reads that the available inventory node value for the corresponding product in the snapshot is zero, while the reserved inventory node value is one hundred. Condition evaluation determines that this data structure satisfies the logical operation of the stockout rule, and this rule is hit, with its priority value marked as Level 1 (highest level). The system then concurrently feeds the snapshot into the warehouse overload rule execution pipeline, reading that the current load rate value of the warehouse nodes in the snapshot is 92%. Condition evaluation determines that 92% is greater than the preset warning line of 90%, and this rule is also hit, with its priority value marked as Level 4. Simultaneously, the system compares the address anomaly and payment anomaly rules, reading that the corresponding node statuses are both normal and valid; these two rules are not hit. Subsequently, the system integrated all hit rules that returned true values ​​and discovered two parallel causes. The system sorted these causes in ascending order based on priority values, determining the stockout cause code corresponding to the first priority level as the primary cause of the blockage, while the warehouse overstock cause code corresponding to the fourth priority level was categorized as a secondary cause. Finally, based on the evidence field mapping list of the stockout rule, the system projected and extracted the product code text, available inventory value equal to zero, and reserved inventory value equal to one hundred from the snapshot, generating the primary cause evidence field. This primary cause was set to stockout, the secondary cause list included warehouse overstock, and evidence data containing the numbers zero and one hundred were concatenated into the processing context. The data packet containing the complete attribution conclusion and evidence data was then sent to the next step.

[0043] In step S104, the primary cause evidence field determined in step S103 is matched with the risk level determined in step S102 to determine the handling information corresponding to the abnormal situation of the current business object. Based on this, the system performs concatenation and hash calculation based on the relevant identifiers of the business object to generate deduplicated key data to uniquely identify this warning, for use in the retrieval and control of subsequent warning instances.

[0044] In one embodiment, step S104 includes: Using the primary cause code in the primary cause evidence field and the risk level as the primary key, retrieve the preset treatment suggestion configuration table to extract treatment suggestions; Based on the attribution attribute of the unified business snapshot, the preset responsibility routing rule tree is retrieved using the main cause code and risk level to obtain the management object; Determine whether the risk level meets the upgrade triggering conditions; if it does, extract the upgrade responsibility role and add it to the management object. Extract the unique identifier of the business object, concatenate the unique identifier of the business object with the main code and perform hash calculation to generate deduplication key data.

[0045] In this embodiment, after extracting the complete cause code, risk level, and unified business snapshot data, the system enters the matching and distribution process between the handling action and the managed object. Through cross-querying of multi-dimensional attributes, information redundancy caused by indiscriminate mass messaging is eliminated, ensuring that abnormal business objects are assigned to the most accurate processing entity. The first sub-process of the system is the matching of handling suggestions. Specifically, the system uses the cause code and risk level in the cause evidence field as the primary key for joint retrieval and initiates a retrieval request to the preset handling suggestion configuration table (warning_action_suggestion). The handling suggestion configuration table is a pre-configured data table indexed by the combination of cause code and risk level, storing corresponding operation guidance mapping relationships. It contains a large number of pre-set operation guidance mapping relationships, and each record includes fields such as suggestion code (suggestion_code), suggestion text (suggestion_text), and operation entry link (action_entry). After the system finds the accurate record, it extracts the corresponding handling suggestion, which includes a text suggestion description and a front-end operation jump entry path. For example, in response to specific level alerts caused by stockouts, the system can extract suggested actions such as allocating internal inventory or switching warehouse delivery nodes; in response to alerts caused by address anomalies, the system can extract instructions requiring sales staff to proactively contact end customers to correct the physical address.

[0046] The second sub-process of the system is to execute joint responsibility routing. Unlike the traditional allocation model that binds to a single attribution field, the system performs a search based on the intersection of three core dimensions: first, the attribution attribute of the business entity in the unified business snapshot. This attribution attribute refers to attribute fields that characterize the physical or organizational affiliation of the business object, including the warehouse code, the regional code of the business, or the order sales channel code; second, the primary cause code; and third, the risk level. Using this three-dimensional joint vector, the system searches a preset responsibility routing rule tree, which is a routing rule structure that uses dimensions such as the cause code as matching conditions and internally encapsulates a multi-level hierarchical configuration array. The system first attempts to match a specific routing rule based on the primary cause code. If the rule matches successfully, the system parses the hierarchical configuration array within that rule: for the first responsibility level, the system, based on the routing field configuration, reverses back to the unified business snapshot to extract the attribution entity (such as the warehouse code), and then queries the personnel mapping table for the unique identifier of the responsible personnel corresponding to that attribution entity; for the second or third auxiliary responsibility level, the system extracts the identifier of the corresponding personnel based on the customer service or operations field in the snapshot. After the above-mentioned hierarchical analysis, the system obtains the management objects, which refer to the set of responsible personnel identifiers determined by routing matching for receiving and processing this warning.

[0047] While matching the basic management objects, the system retrieves the risk level assessment results to determine if the risk level meets the escalation trigger conditions. These escalation trigger conditions are preset in the configuration table to determine whether higher-level personnel need to be involved, such as a high-level risk or a timeout for a specific role. If the risk level meets the escalation trigger conditions, the system extracts the additionally configured escalation responsibility roles (such as customer service team leader, operations manager, or regional head) and adds the identifiers of these high-level personnel to the management objects. Furthermore, if the system fails to find a valid responsible person through all precise matching paths, it will forcibly activate the system's built-in fallback regional-level routing to prevent unclaimed alerts from becoming isolated.

[0048] The third sub-process of the system is generating deduplication key data for instance deduplication and version control. Specifically, the system extracts the unique identifier of the business object from the unified business snapshot. The unique identifier of the business object refers to the immutable global identification code of the business object, such as an order serial number. The system concatenates and merges the unique identifier of the business object with the main cause code in a strictly preset character order. In a specific scenario, the basic rule code that triggers the entire process can be further incorporated during concatenation to enhance the distinguishability of the key value. Subsequently, the system inputs the concatenated complete string into the hash operation module for hash calculation, for example, using the Message-Digest Algorithm 5 (MD5, a digest algorithm that maps inputs of arbitrary length to hash values ​​of fixed length), to generate a fixed-length hexadecimal string, which is the deduplication key data. The system then encapsulates and merges the matched handling suggestions, the management object identifier array covering the responsible personnel and upgrade managers, and the hash-generated deduplication key data before outputting them.

[0049] For example, in a specific application scenario, following the context of the preceding steps, the system obtains the core parameter vector: the primary cause code is the stockout code, the risk level is the attention level, and the associated attributes in the unified business snapshot include a specific warehouse code identifier and a specific order-taking customer service identifier. Using the stockout code and attention level as primary keys, the system retrieves the handling suggestion configuration table, finds the corresponding record, extracts the text field content of the handling suggestion as "allocate inventory or switch warehouses," and extracts the internal routing jump path parameters from the processing interface. Next, the system executes its core joint routing logic. Using the out-of-stock code as the matching condition, the routing engine precisely locates the dedicated responsibility routing rule tree configured specifically for out-of-stock situations and parses its hierarchical structure: the configuration command instructs the system to find the inventory administrator role at level one. The system extracts the warehouse code parameter from the snapshot, queries the personnel mapping microservice, and successfully returns the unique digital identifier of the inventory manager connected to that warehouse node. The configuration command further instructs the system to find the direct warehouse manager role at level two. The system again uses the warehouse code to find the unique digital identifier of the corresponding warehouse supervisor. Additionally, based on fallback logic, the system extracts the unique digital identifier of the original order-taking customer service representative from the snapshot as a follower. The system then determines the escalation trigger condition. Since the current risk level is only the most basic level of attention, which does not meet the escalation trigger threshold required by the configuration table, the system does not extract the identifiers of escalation responsibility roles such as regional managers from the organizational structure tree in this calculation. The system packages the three sets of identity identifiers—inventory manager, warehouse supervisor, and order-taking customer service representative—into a list of managed objects. Subsequently, the system proceeds to the deduplication hash calculation process for the deduplication key data: the system extracts the unique serial number text of the order from the promotional event, the encoded text of the default pending shipment rule, and the out-of-stock code text identified as the primary cause. These three text segments are then sequentially added and merged to form a continuous, complete string. This string is then fed into the MD5 hash function, outputting a string of absolutely unique deduplication key data composed of a hexadecimal hash character sequence. Finally, the system packages the data, including the proposed action, the management objects identified by three specific personnel, and this deduplication key data.

[0050] In step S105, the system queries a preset warning instance table using the deduplication key data as the retrieval condition. If no active instance is found in the search results, the system creates a new warning instance and completes initialization; if an active instance exists, the system compares the current risk level with the historical risk level recorded for that active instance. If the risk level is higher than the historical risk level, an in-situ upgrade is performed, thereby avoiding the repeated creation of warning instances for the same anomaly.

[0051] In one embodiment, step S105 includes: The warning instance table is retrieved using the deduplication key data, and the set of activity records whose status bits do not include closed or invalid records is filtered. If the activity record set is empty, a new early warning instance is created, the business object number and the management object identifier are injected, and it is initialized to a new state. If a matching record exists in the activity record set, the historical risk level of the matching record is extracted and compared with the current risk level; if the risk level is higher than the historical risk level, an in-situ upgrade is performed, overwriting the risk level and adding the upgrade management object identifier; if the risk level is not higher than the historical risk level, a silent update is performed, updating only the scan timestamp and snapshot data.

[0052] In this embodiment, after obtaining complete management objects and deduplication key data, the system enters the instance storage and version iteration process that interacts with the persistent database. This completely prevents the defects caused by repeated timed scanning mechanisms, which lead to data fission in the database for the same anomaly and the repeated sending of redundant messages to end users. The core of the system is to make decisions on creating, updating, or upgrading in situ based on the deduplication key data.

[0053] The first phase of the system's operation involves the precise detection of activity warning status. Specifically, the system receives hexadecimal deduplicated data, constructs a database query statement, and retrieves a preset warning instance table (warning_instance) using the deduplicated data. The warning instance table is a data table that persistently stores data rows for each warning instance. Each data row contains at least the business object number, rule identifier, cause code, risk level, status, deduplicated key field, and upgrade count field. The system searches the warning instance table for records whose deduplicated key field is strictly equal to the input deduplicated key data and whose lifecycle status does not contain closed or invalidated enumeration values. This results in an activity record set, which is the collection of warning instance data rows that are currently in an incomplete lifecycle state. The second phase of the system's operation executes the decision logic. If the activity record set returned by the database query is determined to be empty, i.e., there is no activity conflict, the system triggers a new warning instance construction branch. Specifically, the system initializes a new primary key data row in the database to create a new early warning instance, injecting the business object number, rule identifier, cause code, and management object identifier into it. The management object identifier includes the identifier of the responsible person and the identifier of the backup upgrade personnel. The system forcibly initializes the status field of the newly created early warning instance to the newly created status, enters the current time as the absolute creation time, and asynchronously inserts all basic data content into the snapshot table associated with the foreign key to complete the binding between the newly created early warning instance and the unified business snapshot.

[0054] Furthermore, if the database query returns a set of activity records with exactly one matching record, the system immediately freezes the newly created branch and triggers a precise comparison and upgrade decision logic. Specifically, the system extracts the cached historical risk level from the matching record and performs a hierarchical depth comparison with the currently newly calculated risk level. If the system determines that the currently newly calculated risk level is significantly higher than the cached historical risk level in the severity sequence, it indicates that the business object has crossed a higher-level risk window boundary over time. At this point, the system initiates an in-situ upgrade process, where in-situ upgrade means updating the level and personnel information directly on the existing warning instance data row without creating a new data row. Specifically, the system directly performs an update operation on the existing data row: overwriting the internal risk level field with the current higher level; changing the status field from the original push or view status to the upgraded status; incrementing the cumulative upgrade count field; and simultaneously, the system compiles the newly acquired higher-level upgrade management object identifier into the push candidate sequence of the warning instance. After executing the database update, the system releases a signal to force a re-push event, ensuring that the new upgrade information is communicated to all responsible personnel at all levels. If the system determines that the currently calculated risk level is equal to or lower than the historical risk level in the severity sequence, i.e., the business object has not crossed the new risk window boundary, the system adopts the most conservative silent update strategy. Silent update refers to a low-disturbance update method that does not trigger state transitions or message pushes, but only synchronizes the underlying data. Specifically, the system does not perform a state transition for the warning instance, does not add any high-level personnel, and does not issue any push trigger signal. It only updates the last scan access timestamp of the data row and overwrites the latest snapshot data such as inventory or load indicators in the snapshot association table as a source traceability supplement, thereby completely avoiding the repeated sending of invalid low-level warnings.

[0055] For example, in a specific application scenario, at the first round of periodic inspection time, the system accesses the database layer with the deduplicated key data of the newly generated promotional order, submits a query request, and retrieves the warning instance table. The result shows that the activity record set corresponding to the deduplicated key data is empty. Based on this, the system proceeds to the new branch logic, inserts a brand new warning serial number data row into the database to create a new warning instance, initializes the status bit to the new status, injects the risk level as the attention level, injects the business object number and management object identifier, records the creation time, and binds the corresponding snapshot primary key, and then releases it to the downstream process. The system time advances to the next inspection cycle four hours later. The stagnation anomaly of the order has not been resolved by any manual intervention. The system's underlying distributed scheduler retrieves the order again. After recalculating the duration, the stagnation time has accumulated to 18.25 hours. After interval comparison, the system determines that 18.25 hours has exceeded the lower limit of the termination time of the attention level and fallen into the risk window range of the warning level. The generated deduplicated data was identical to that from four hours prior. The system, using this same deduplicated data, again initiated a database search. This time, the system clearly found a matching record for the deduplicated data with an unclosed activity status. The system extracted the historical risk level field of this matching record and discovered it was a level of concern from four hours ago. The system compared the newly generated warning level with the old concern level, determining that the warning level was at a higher severity level, meeting the trigger condition for crossing a higher risk window. The system immediately blocked the creation of new data rows and instead performed an in-situ escalation. First, the risk level field was overwritten from concern to warning; then, the status field was changed to escalated; internally, the system read the personnel update instruction, and due to the increased risk, added the upgrade management object identifier of a higher-level operations manager to the push target list; the system simultaneously updated the upgrade occurrence time of this warning instance data row and incremented the cumulative upgrade count field. After all core data columns have been saved, the system calls an external component to submit a re-push event instruction package based on the upgraded status to the downstream distribution engine, so as to ensure that the newly added operations manager can immediately capture the anomaly that crosses the upgrade boundary.

[0056] In step S106, the early warning instance is driven to sequentially transition between state nodes based on a preset closed-loop state machine, thereby managing the lifecycle of the early warning instance. Simultaneously, the system monitors business state change events; when a change in the state of a business object is detected, the early warning instance associated with that business object is closed. Furthermore, the system generates an early warning audit snapshot when the early warning instance undergoes a state transition, for subsequent review and verification.

[0057] Combination Figure 2 As shown, in one embodiment, step S106 includes: Based on the transition rules of the closed-loop state machine, the early warning instance is driven to flow between preset state nodes; wherein, the state node includes any one or more nodes among newly created, pushed, viewed, being processed, resolved, closed, upgraded, and invalidated; Deploy asynchronous listening channels in the business event message queue to capture business state change events that allow business objects to transition to their final state; Extract the business entity number from the business status change event, retrieve the associated activity warning instance in reverse, and issue a shutdown signaling; For the warning instance that has been stalled for more than a preset time threshold, a timeout escalation is triggered, and the corresponding status is raised to the upgraded node. At each state transition of the warning instance, multi-dimensional data is extracted, aggregated, and encoded to generate a warning audit snapshot.

[0058] In this embodiment, after an early warning instance is created or its data is updated, the system initiates the final stage closed-loop state machine module. This upgrades the discrete early warning instance data records into a stateful business flow with internal self-driving and external event response capabilities, allowing it to flow through multiple strictly defined state nodes and generating an early warning audit snapshot that can be traced back. The closed-loop state machine refers to a state flow model that predefines a set of state nodes and inter-node transition rules to manage the complete lifecycle of an early warning instance. The transition rules are constraints that limit the transition of an early warning instance to a specific target state node only.

[0059] Specifically, based on the transition rules of the closed-loop state machine, the system drives the early warning instance to sequentially flow between the state nodes of newly created, pushed, viewed, being processed, resolved, closed, upgraded, and invalidated. The early warning instance is initially in the newly created state node; when the message adaptation module successfully delivers the heterogeneous text to the enterprise intranet communication gateway and receives a confirmation receipt, the closed-loop state machine triggers a transition, pushing the state of the early warning instance to the pushed node and recording the last push time; when external personnel click on the early warning link to enter the details view through a mobile terminal or desktop management console, the terminal sends an implicit browsing feedback signal to the system, which immediately changes the state from the pushed node to the viewed node after capturing it; when the responsible personnel check the corresponding handling suggestion button in the interface and submit the handling action form, the system records the executor's identifier and the handling plan description, and advances the state of the early warning instance to the processing node.

[0060] During this lifecycle operation, the system deploys asynchronous listening channels on the business event message queue to achieve automated external linkage shutdown without manual intervention. The asynchronous listening channel refers to an event subscription channel that operates in a bypass listening mode, mounted on the message bus and decoupled from the main processing flow. The business event message queue refers to a message middleware (such as Kafka or RabbitMQ distributed message queue components) used by the underlying core business system to broadcast business object state change events. The system's listeners continuously deserialize the event stream in the bus. When an underlying microservice publishes a business state change event indicating that a business object has transitioned to its final state—for example, in a fulfillment scenario, a broadcast event indicating that an order has changed to a shipped, signed, or physically cancelled state—the system captures this business state change event. The final state refers to the irreversible final completion state in the business object's lifecycle.

[0061] Upon capturing the business status change event, the system immediately extracts the business entity ID from the event broadcast message, which is the globally unique ID of the business object. Using this business entity ID, the system reverse-engineers the alert database to retrieve all activity alert instances associated with this business object that are still in a processing, viewed, or pushed status (not yet completed). Without any manual confirmation, the system directly issues a closure signal to these activity alert instances, completely terminating their status at the closed node. The closure reason field details the automated linkage triggered by the underlying business status change, thereby achieving the linked closure of alert instances and business object status.

[0062] In addition to the successful termination path mentioned above, the system also has a timeout monitoring and protection program. For isolated alert instances that remain in the "pushed" or "viewed" state for an extended period of time beyond a preset time threshold without any manual feedback, the system automatically triggers the event generator to escalate the timeout, raising the corresponding status from the current node to the escalated node, and triggering a follow-up push instruction and additional routes for personnel, ensuring that the anomaly is not overlooked due to negligence on the part of responsible personnel.

[0063] When any critical state transition occurs in the aforementioned early warning instance, the system synchronously triggers the underlying snapshot capture audit module to extract multi-dimensional data, aggregate and encode it to generate an early warning audit snapshot. Specifically, the system extracts business snapshot nodes including the physical basic attributes of the order, the association mapping of the rule description node that hits the record, the risk calculation intermediate result node including the duration and level threshold determination, the causal evidence structure node separating the main and secondary causes and the absolute numerical basis, and the responsible routing personnel array node for assigning tracking basis. These five dimensions of unstructured data are then aggregated and encoded into a hierarchically clear plain text JSON (JavaScript Object Notation, a lightweight structured data exchange format) sequence, persistently stored in the system's underlying early warning audit evidence database, thereby generating the aforementioned early warning audit snapshot. Thus, the entire rule engine-based proactive early warning method completes closed-loop control over a single business flow slice.

[0064] For example, in a specific application scenario, after an upgrade warning is issued and the order is re-pushed during a major promotional event, the warning instance remains in a state of waiting for intervention through internal system processing. For example... Figure 2 As shown, the system uses a unified business snapshot (i.e., data covering dimensions such as inventory, payment, address, and load) to represent data. Figure 2 The system uses order snapshots as input for reason identification, identifying reasons such as stockouts, payment anomalies, address anomalies, and warehouse overload anomalies, and providing corresponding handling suggestions such as allocating inventory or switching warehouses, contacting customers or verifying payments, contacting customers to correct addresses, prioritizing packaging or switching warehouses; simultaneously, the system extracts attribution attributes (i.e., warehouse, customer service, operations, region, etc.) from the unified business snapshot. Figure 2The system uses the order attribution data (as defined in the system) to input risk level, cause code, and attribution attribute into the joint routing for responsible parties, thereby generating differentiated warning messages for the management objects identified by the routing. The system issues warning cards through the enterprise instant messaging channel; in this embodiment, the issued warning card is the generated differentiated warning message. After the gateway reports successful delivery, the status of the warning instance in the database changes from a newly created node to a pushed node. The inventory manager and warehouse supervisor who receive the alert receive a card with red and yellow tones in their enterprise office software. The warehouse supervisor clicks the link to enter the system's details terminal page. As the front-end initiates a page loading API (Application Programming Interface) request that reaches the back-end, the system verifies the user token and changes the status of the warning instance from a pushed node to a viewed node, recording the supervisor's viewing time in the operation log table. The warehouse supervisor reviewed the detailed evidence on the details page, specifically the data showing that the physical inventory was zero due to reserved space. Based on the system's auxiliary decision-making text, the supervisor directly triggered an inventory transfer instruction form for a nearby same-city warehouse node at the system entry point on the terminal page. After the action was submitted and reached the early warning system backend, the system immediately advanced the status of the early warning instance to the processing node and bound and recorded the warehouse supervisor's work action trajectory and processing plan parameters. One hour after the manual transfer instruction was transferred to the warehouse execution system, the warehouse's underlying control system physically completed the packaging, barcode scanning, and assembly line outbound operations of the goods. The underlying execution service then immediately broadcast a standard business status change event to the enterprise's core global message middleware. The core payload of this data packet declared that the order serial number had been reversed to the final physical enumeration value of "shipped". The backend service thread of the early warning system, operating in bypass listening mode, instantly captures the asynchronous message payload containing the order serial number through the asynchronous listening channel. It immediately parses the payload parameters, extracts the business entity number, and initiates a reverse search in the internal early warning instance relationship table. It precisely matches the active early warning instance record attached to this order that is currently in the "processing" node. The system determines that "shipped" is an irreversible final state and immediately initiates an interception and termination operation, writing a change instruction to the database. This overwrites and refreshes the status field of the early warning instance to "closed node," and automatically writes the traceability text triggered by the change in order status to "shipped" to the closure remarks field. Subsequently, the audit module is activated. The system aggregates and encodes the data from five core dimensions—the overall business situation at that moment, the triggered warning rules, the risk consumption time calculated down to the second, the evidence chain of stockouts and warehouse overload, and the routing and distribution records of the warehouse supervisor and operations manager—into a standard JSON format early warning audit snapshot, which is then stored in the audit storage index.

[0065] Combination Figure 3 As shown, Figure 3 The system architecture diagram is shown for the proactive early warning method based on a rule engine provided in this embodiment of the invention. Figure 3 The overall system architecture consists of six layers from top to bottom: The first level is the Vue alert frontend. Vue is a progressive frontend development framework for building user interaction interfaces. This frontend provides visual interfaces such as Kanban / lists, details / processing, rule / responsibility configuration, and state machines / reports. These are used for summarizing and displaying alert information and querying lists, viewing and handling details of individual alerts, visually configuring alert rules and responsibility routing relationships, and presenting closed-loop state machine flow and statistical reports.

[0066] The second layer consists of a Java early warning API and application orchestration services. Java refers to an object-oriented programming language, and API (Application Programming Interface) refers to a set of interfaces that allow the front-end and external systems to call the back-end service capabilities. This layer orchestrates the complete processing flow of "orchestration scanning - risk - cause - deduplication - push - closure", that is, it sequentially connects the processing logic of steps S101 to S106 of this application.

[0067] The third layer comprises two parallel parts: inspection scheduling and business object access, which connect to external systems. The inspection scheduling part is triggered periodically / event-wise, supporting configurable cycles of 30 minutes / 1 hour, and performs scanning of the pending order pool, corresponding to the task triggering process in step S101 using a distributed scheduler according to a preset scanning strategy. The business object access part accesses data via snapshots, uniformly extracting multi-dimensional fields such as order / inventory / payment / address / warehouse load / ownership, corresponding to the parallel data extraction from multiple business systems and generation of a unified business snapshot in step S101. External systems include systems for order management, ERP (Enterprise Resource Planning), WMS (Warehouse Management System), inventory management, payment management, address management, and warehouse load management. ERP provides heterogeneous data sources for generating the unified business snapshot.

[0068] The fourth layer is the core processing chain, which is the core execution entity of this application. It includes multiple processing steps connected in sequence: the risk level calculation step performs interval matching processing of "stay time - multi-level risk window", corresponding to step S102; the blockage cause identification step performs evaluation and extraction processing of "event chain - main cause / secondary cause evidence", corresponding to step S103; the disposal suggestion matching step performs retrieval and matching processing of "cause code + risk level - action"; the responsible person joint routing step performs three-dimensional cross-routing processing of "warehouse / region / channel + cause + risk level - responsible person"; the deduplication upgrade + closed-loop state machine step performs adjudication and control processing of "dedupe_key (i.e., deduplication key data) generation - cross-window upgrade - state flow", corresponding to steps S104, S105 and S106 respectively; the message adaptation and push step generates differentiated warning messages for channels such as WeChat / site, and the pushed message content includes order link + risk level + cause + suggested action + processing entry, which is used to accurately convey the warning to the management object determined by the route.

[0069] Interfacing with the core processing chain are two data support components: a rule configuration library and an alert instance and audit library. The rule configuration library stores `warning_rule` (the main rule table, containing control fields such as scope of application and priority), `warning_risk_window` (the risk window configuration table, containing the window definition structure for multi-level risk windows), and `warning_reason_rule` (the reason rule table corresponding to the blocking cause identification rule set). The alert instance and audit library stores `warning_instance` (the alert instance table, containing fields such as status bit and deduplication key), `warning_handle_record` / `push_record` (the processing record table and push record table recording handling actions and push behaviors), and `warning_match_snapshot` (the alert audit snapshot table containing hit snapshots). These data tables collectively support configurable rule management and traceability throughout the entire alert process.

[0070] The sixth level is statistical analysis, which summarizes and analyzes early warning data from multiple dimensions such as region, warehouse, category, channel, cause, and processing time, generating daily / weekly reports to provide data support for business management.

[0071] This application scans a pool of pending business objects at preset intervals and filters candidate objects according to a main rule table. Simultaneously, it extracts data from the business system in parallel to generate a unified business snapshot, establishing a consistent data benchmark for subsequent judgments. By matching the dwell time with preset multi-level risk windows to determine the risk level, it upgrades the binary timeout judgment based on a single threshold to a multi-level, layered risk identification, enabling early identification of the risk stage of business objects. Furthermore, by evaluating the attribute values ​​of the unified business snapshot in the conditional expressions of the blocking cause identification rule set and determining the primary cause evidence field based on priority, it ensures that warnings are issued even after timeouts. Simultaneously, it locates the cause of the blockage and solidifies the evidence, reducing the need for secondary investigations by responsible personnel; by matching the main cause evidence field with the risk level and generating deduplicated key data, and then controlling the creation and in-situ upgrade of early warning instances based on the deduplicated key data, it avoids duplicate alarms and indiscriminate mass alarms for the same anomaly; by driving the early warning instance to flow between state nodes through a closed-loop state machine, and listening for business state change events to link and close the early warning instance, and generating an early warning audit snapshot during state transition, it realizes closed-loop management and full traceability of the entire life cycle of early warning, thereby improving the accuracy and timeliness of early warnings for the business objects to be processed.

[0072] Combination Figure 4 As shown, Figure 4 A schematic block diagram of a rule engine-based proactive early warning device provided in an embodiment of the present invention. The rule engine-based proactive early warning device 400 includes: The data generation unit 401 is used to scan the pool of business objects to be processed according to a preset period to obtain candidate objects, filter the candidate objects according to the preset rules of the main table, and extract data from the business system in parallel to generate a unified business snapshot. Data matching unit 402 is used to extract the status timestamp from the unified business snapshot and calculate the dwell time, and match the dwell time with a preset multi-level risk window to determine the risk level; The data evaluation unit 403 is used to load the blocking cause identification rule set, and to evaluate the attribute values ​​of the unified business snapshot by inputting them into the conditional expression of the blocking cause identification rule set through the rule engine, and to determine the main cause evidence field according to the priority. Data processing unit 404 is used to match and process the principal evidence field with the risk level to generate deduplicated key data; Data judgment unit 405 is used to retrieve a preset warning instance table based on the deduplication key data. If there is no active instance, a new warning instance is created. If there is an active instance and the risk level is higher than the historical risk level, an in-situ upgrade is performed. The data early warning unit 406 is used to drive the early warning instance to flow between state nodes based on a preset closed-loop state machine, while listening to business state change events to close the early warning instance in a coordinated manner, and generating an early warning audit snapshot when the state transitions.

[0073] In this embodiment, the data generation unit 401 scans the pool of business objects to be processed according to a preset period to obtain candidate objects, filters the candidate objects according to a preset rule main table, and simultaneously extracts data from the business system in parallel to generate a unified business snapshot; the data matching unit 402 extracts the status timestamps from the unified business snapshot and calculates the dwell time, performs interval matching between the dwell time and a preset multi-level risk window, and determines the risk level; the data evaluation unit 403 loads the blocking cause identification rule set, and uses the rule engine to input the attribute values ​​of the unified business snapshot into the conditional expressions of the blocking cause identification rule set. The system assesses and determines the primary cause evidence field based on priority; the data processing unit 404 matches the primary cause evidence field with the risk level to generate deduplicated key data; the data judgment unit 405 retrieves a preset warning instance table based on the deduplicated key data, and if no active instance exists, a new warning instance is created; if an active instance exists and the risk level is higher than the historical risk level, an in-situ upgrade is performed; the data warning unit 406 drives the warning instance to flow between state nodes based on a preset closed-loop state machine, while listening for business state change events to close the warning instance in a coordinated manner, and generates a warning audit snapshot when the state transitions.

[0074] In one embodiment, the data generation unit 401 is specifically used for: The distributed scheduler triggers tasks according to a preset scanning strategy to perform incremental scanning on the pool of pending business objects and obtain the status bits of candidate objects. Read the status bits of the candidate objects and filter out objects with non-processable status markers to obtain the removed candidate objects; The control fields of the main rule table are retrieved, and the attributes of the eliminated candidate objects are verified one by one against the control fields to generate an applicable order set. The business entities of the applicable order set are traversed to initiate remote calls to multiple business systems in parallel to obtain discrete business attribute data; The business attribute data is cleaned and mapped and bound separately to generate a unified business snapshot.

[0075] In one embodiment, the data matching unit 402 is specifically used for: Extract the timestamp of the business object entering the current state from the unified business snapshot, and calculate the difference between it and the current server time to obtain the dwell time; Load the multi-level risk windows issued by the configuration center to extract the multiple window definition structures associated with the current business rules; Read the coefficient adjustment factor corresponding to the business scenario, and use the coefficient adjustment factor to scale the basic interval threshold in the window definition structure to obtain the scaled window definition structure; The dwell time is compared with the scaled window definition structure by interval boundaries, and the risk level code of the first hit window is extracted; The risk level code and the duration of stay parameter are attached as additional attributes to the unified business snapshot.

[0076] In one embodiment, the data evaluation unit 403 is specifically used for: Load the blocking cause identification rule set and traverse the blocking cause identification rule set to apply the conditional expression corresponding to the blocking cause identification rule set to the unified business snapshot for attribute value detection; Collect the hit rules that return true values ​​in the attribute value detection, sort all the priority values ​​of the hit rules in ascending order, select the cause code of the hit rule with the highest priority after sorting as the primary cause, and use the remaining hit cause codes as secondary causes; Read the evidence field mapping list corresponding to the primary cause and secondary cause, and extract the corresponding values ​​from the unified business snapshot according to the evidence field mapping list to generate the primary cause evidence field.

[0077] In one embodiment, the data processing unit 404 is specifically used for: Using the primary cause code in the primary cause evidence field and the risk level as the primary key, retrieve the preset treatment suggestion configuration table to extract treatment suggestions; Based on the attribution attribute of the unified business snapshot, the preset responsibility routing rule tree is retrieved using the main cause code and risk level to obtain the management object; Determine whether the risk level meets the upgrade triggering conditions; if it does, extract the upgrade responsibility role and add it to the management object. Extract the unique identifier of the business object, concatenate the unique identifier of the business object with the main code and perform hash calculation to generate deduplication key data.

[0078] In one embodiment, the data determination unit 405 is specifically used for: The warning instance table is retrieved using the deduplication key data, and the set of activity records whose status bits do not include closed or invalid records is filtered. If the activity record set is empty, a new early warning instance is created, the business object number and the management object identifier are injected, and it is initialized to a new state. If a matching record exists in the activity record set, the historical risk level of the matching record is extracted and compared with the current risk level; if the risk level is higher than the historical risk level, an in-situ upgrade is performed, overwriting the risk level and adding the upgrade management object identifier; if the risk level is not higher than the historical risk level, a silent update is performed, updating only the scan timestamp and snapshot data.

[0079] In one embodiment, the data early warning unit 406 is specifically used for: Based on the transition rules of the closed-loop state machine, the early warning instance is driven to flow between preset state nodes; wherein, the state node includes any one or more nodes among newly created, pushed, viewed, being processed, resolved, closed, upgraded, and invalidated; Deploy asynchronous listening channels in the business event message queue to capture business state change events that allow business objects to transition to their final state; Extract the business entity number from the business status change event, retrieve the associated activity warning instance in reverse, and issue a shutdown signaling; For the warning instance that has been stalled for more than a preset time threshold, a timeout escalation is triggered, and the corresponding status is raised to the upgraded node. At each state transition of the warning instance, multi-dimensional data is extracted, aggregated, and encoded to generate a warning audit snapshot.

[0080] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0081] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0082] This invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the computer device may also include various network interfaces, a power supply, a graphics card, etc., to utilize the graphics card's performance to operate the model, such as for inference and training.

[0083] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0084] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A proactive early warning method based on a rule engine, characterized in that, include: The pool of business objects to be processed is scanned at a preset period to obtain candidate objects, and the candidate objects are filtered in the main table according to preset rules. At the same time, data is extracted from the business system in parallel to generate a unified business snapshot. Extract the status timestamp from the unified business snapshot and calculate the dwell time. Match the dwell time with a preset multi-level risk window to determine the risk level. Load the blocking cause identification rule set, and use the rule engine to input the attribute values ​​of the unified business snapshot into the conditional expression of the blocking cause identification rule set for evaluation, and determine the main cause evidence field according to the priority; The principal evidence field is matched with the risk level to generate deduplicated key data; Based on the deduplication key data, a preset warning instance table is retrieved. If no active instance exists, a new warning instance is created. If an active instance exists and the risk level is higher than the historical risk level, an in-situ upgrade is performed. The warning instance is driven to flow between state nodes based on a preset closed-loop state machine. At the same time, it listens for business state change events to close the warning instance in a coordinated manner, and generates a warning audit snapshot when the state transitions.

2. The proactive early warning method based on a rule engine according to claim 1, characterized in that, The process of scanning the pool of business objects to be processed according to a preset period to obtain candidate objects, filtering the candidate objects according to a preset rule main table, and simultaneously extracting data from the business system in parallel to generate a unified business snapshot includes: The distributed scheduler triggers tasks according to a preset scanning strategy to perform incremental scanning on the pool of pending business objects and obtain the status bits of candidate objects. Read the status bits of the candidate objects and filter out objects with non-processable status markers to obtain the removed candidate objects; The control fields of the main rule table are retrieved, and the attributes of the eliminated candidate objects are verified one by one against the control fields to generate an applicable order set. The business entities of the applicable order set are traversed to initiate remote calls to multiple business systems in parallel to obtain discrete business attribute data; The business attribute data is cleaned and mapped and bound separately to generate a unified business snapshot.

3. The proactive early warning method based on a rule engine according to claim 1, characterized in that, The process of extracting the status timestamp from the unified business snapshot and calculating the dwell time, then matching the dwell time with a preset multi-level risk window to determine the risk level, includes: Extract the timestamp of the business object entering the current state from the unified business snapshot, and calculate the difference between it and the current server time to obtain the dwell time; Load the multi-level risk windows issued by the configuration center to extract the multiple window definition structures associated with the current business rules; Read the coefficient adjustment factor corresponding to the business scenario, and use the coefficient adjustment factor to scale the basic interval threshold in the window definition structure to obtain the scaled window definition structure; The dwell time is compared with the scaled window definition structure by interval boundaries, and the risk level code of the first hit window is extracted; The risk level code and the duration of stay parameter are attached as additional attributes to the unified business snapshot.

4. The proactive early warning method based on a rule engine according to claim 1, characterized in that, The loading blocking cause identification rule set is evaluated by the rule engine by inputting the attribute values ​​of the unified business snapshot into the conditional expressions of the blocking cause identification rule set, and determining the main cause evidence field according to priority, including: Load the blocking cause identification rule set and traverse the blocking cause identification rule set to apply the conditional expression corresponding to the blocking cause identification rule set to the unified business snapshot for attribute value detection; Collect the hit rules that return true values ​​in the attribute value detection, sort all the priority values ​​of the hit rules in ascending order, select the cause code of the hit rule with the highest priority after sorting as the primary cause, and use the remaining hit cause codes as secondary causes; Read the evidence field mapping list corresponding to the primary cause and secondary cause, and extract the corresponding values ​​from the unified business snapshot according to the evidence field mapping list to generate the primary cause evidence field.

5. The proactive early warning method based on a rule engine according to claim 1, characterized in that, The step of matching the principal evidence field with the risk level to generate deduplicated key data includes: Using the primary cause code in the primary cause evidence field and the risk level as the primary key, retrieve the preset treatment suggestion configuration table to extract treatment suggestions; Based on the attribution attribute of the unified business snapshot, the preset responsibility routing rule tree is retrieved using the main cause code and risk level to obtain the management object; Determine whether the risk level meets the upgrade triggering conditions; if it does, extract the upgrade responsibility role and add it to the management object. Extract the unique identifier of the business object, concatenate the unique identifier of the business object with the main code and perform hash calculation to generate deduplication key data.

6. The proactive early warning method based on a rule engine according to claim 1, characterized in that, The process of retrieving a preset early warning instance table based on the deduplication key data, creating a new early warning instance if no active instance exists, and performing an in-situ escalation if an active instance exists and the risk level is higher than the historical risk level, includes: The warning instance table is retrieved using the deduplication key data, and the set of activity records whose status bits do not include closed or invalid records is filtered. If the activity record set is empty, a new early warning instance is created, the business object number and the management object identifier are injected, and it is initialized to a new state. If a matching record exists in the activity record set, the historical risk level of the matching record is extracted and compared with the current risk level; if the risk level is higher than the historical risk level, an in-situ upgrade is performed, overwriting the risk level and adding the upgrade management object identifier; if the risk level is not higher than the historical risk level, a silent update is performed, updating only the scan timestamp and snapshot data.

7. The proactive early warning method based on a rule engine according to claim 1, characterized in that, The pre-defined closed-loop state machine drives the early warning instance to transition between state nodes, while simultaneously monitoring business state change events to close the early warning instance in a coordinated manner, and generating an early warning audit snapshot during state transitions, including: Based on the transition rules of the closed-loop state machine, the early warning instance is driven to flow between preset state nodes; wherein, the state node includes any one or more nodes among newly created, pushed, viewed, being processed, resolved, closed, upgraded, and invalidated; Deploy asynchronous listening channels in the business event message queue to capture business state change events that allow business objects to transition to their final state; Extract the business entity number from the business status change event, retrieve the associated activity warning instance in reverse, and issue a shutdown signaling; For the warning instance that has been stalled for more than a preset time threshold, a timeout escalation is triggered, and the corresponding status is raised to the upgraded node. At each state transition of the warning instance, multi-dimensional data is extracted, aggregated, and encoded to generate a warning audit snapshot.

8. A proactive early warning device based on a rule engine, characterized in that, include: The data generation unit is used to scan the pool of business objects to be processed according to a preset period to obtain candidate objects, filter the candidate objects according to the preset rules of the main table, and extract data from the business system in parallel to generate a unified business snapshot. The data matching unit is used to extract the status timestamp from the unified business snapshot and calculate the dwell time, and match the dwell time with a preset multi-level risk window to determine the risk level. The data evaluation unit is used to load the blocking cause identification rule set, and evaluate the attribute values ​​of the unified business snapshot by inputting them into the conditional expression of the blocking cause identification rule set through the rule engine, and determine the main cause evidence field according to the priority. The data processing unit is used to match and process the principal evidence field with the risk level to generate deduplicated key data; The data judgment unit is used to retrieve a preset warning instance table based on the deduplication key data. If no active instance exists, a new warning instance is created. If an active instance exists and the risk level is higher than the historical risk level, an in-situ upgrade is performed. The data early warning unit is used to drive the early warning instance to flow between state nodes based on a preset closed-loop state machine, while listening for business state change events to shut down the early warning instance in a coordinated manner, and generating an early warning audit snapshot when the state transitions.

9. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the proactive warning method based on a rule engine as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the proactive early warning method based on a rule engine as described in any one of claims 1 to 7.

Images