Business process processing algorithm and system based on multi-condition rule driving

Abstract

The invention provides a business process processing algorithm and system based on multi-condition rule driving. The business process processing algorithm comprises the following steps: receiving to-be-processed data from a data source; obtaining a rule list matched with the current data source; performing condition judgment processing on the to-be-processed data by applying the matched rule; analyzing the content of the rule, and establishing an OR logical relationship among condition groups; an AND logic relation is established among the conditions in the same condition group; processing each condition group in parallel, packaging judgment logic of each condition group into a task, sending the task to a thread pool for asynchronous execution, and judging whether a rule is triggered or not; a context processing object is constructed, judgment results of the condition groups are assembled into a trigger result object, and the context processing object is constructed; distributing the received to-be-processed data for processing the context object; the method has the advantages that computing power resources are concentrated to process calculation of multi-condition rule judgment, waste of the computing power resources is avoided, and the response speed and expandability of the system are improved.

Description

Technical Field

[0001] The present invention relates to the field of industrial software, and in particular to a business process processing algorithm and system driven by multiple conditional rules, which is used to implement an intermediate service system for distributing business process data of industrial software. Background Art

[0002] In modern industrial production, the control and operation of business processes are the key to ensuring production efficiency and quality. Traditionally, factories rely on manual process control, but with the rise of Internet of Things (IoT) technology, smart factory systems have gradually replaced manual operations and realized automated process control. At present, more and more factory equipment is connected to the Internet of Things, realizing real-time collection and monitoring of equipment data, such as processing numbers, unqualified numbers, electricity consumption and water consumption. These data are used for data recording and analysis in the production process, and the system decides whether to continue production activities by analyzing the data. For example, the invention patent with application publication number CN117471950A discloses an industrial equipment data collection method and system, and the invention patent with application publication number CN116647574A discloses an industrial Internet of Things equipment remote operation and maintenance method.

[0003] The equipment business processes in smart factory systems often need to perform operations based on specific conditions, which are usually determined by the data collected by the IoT terminal. For example, the conditions for loading and unloading automated equipment vary from device to device: Equipment A: The loading channel places left and right products. The left and right products execute two different sets of loading logics, and both must meet the OK status. The NG status requires triggering a new logic. B device: IoT collection information contains three barcode fields, and barcodes in different fields execute different loading and unloading logics; C equipment: When a fixed parameter value is collected and other parameters are not empty, unloading is performed.

[0004] The loading and unloading conditions of the three types of equipment A, B, and C are logically very different, and the equipment business process processing system must perform corresponding operations based on these personalized and differentiated conditions.

[0005] The existing solution includes the following steps: first, the business operation developer connects to the collected data message of the IoT terminal; second, accesses these variables in the business module and writes the change judgment logic; finally, writes the business operation logic and connects it with the aforementioned logic. However, this solution has at least the following problems: 1. The application scenarios and business needs of each factory are different, and diversified conditional rules are inevitable. Developers not only need to directly connect to the IoT data message and compile conditional judgment rules for each case, but also need to be directly responsible for troubleshooting and solving message problems or variable definition changes. Not only is the time and labor costs too high, but the execution efficiency of the customized code varies from person to person, resulting in a waste of computing resources.

[0006] 2. Developers need to repeatedly access variable condition judgment logic when connecting to each business operation requirement, resulting in code redundancy, increasing maintenance costs, and reducing the delivery efficiency of business process requirements. Especially in the process of demand changes and business iterations, repeated hard coding is repeated many times, and each relevant location needs to be updated, resulting in an extremely bloated system and difficulty in maintenance and expansion in the later stage. Summary of the invention

[0007] In view of the problems such as the cumbersome and inefficient development process of the above-mentioned business process processing system, the bloated and poor scalability of the business process processing system, and the system being able to quickly adapt to changes and expansions in scenarios and needs, the present invention aims to provide a relatively efficient and flexible business process processing algorithm and system driven by multi-conditional rules, which concentrates computing resources to process the calculations of multi-conditional rule judgments, avoids waste of computing resources, improves the response speed and scalability of the system, and provides reliable support for the automation of enterprise production management.

[0008] The technical solution adopted by the present invention to solve the above technical problems is: a business process processing algorithm driven by multiple conditional rules, comprising the following steps: Step S100: receiving data to be processed from a data source, and filtering unreasonable data to be processed; Step S200: obtaining a list of rules matching the current data source, and sending the data to be processed together with the matching rules; Step S300: using the matched rules to perform conditional judgment processing on the data to be processed, including steps S310 to S340: Step S310: receiving the data to be processed and the matching rules; Step S320: parsing the content of the rule: generating a list of condition groups, each of which contains multiple conditions; establishing an OR logical relationship between the condition groups; and establishing an AND logical relationship between the conditions in the same condition group; Step S330: Process each condition group in parallel: package the judgment logic of each condition group into a task and assign it to the thread pool for asynchronous execution to determine whether each condition group is triggered; after all the tasks are executed, determine whether the rule is triggered; Step S340: constructing a processing context object: assembling the judgment results of each of the condition groups and the contents of the conditions in the triggered condition group into a trigger result object; collecting the trigger result objects, together with the data to be processed of the data source, constructing a processing context object, and passing it downstream; Step S400: Distribute the received data to be processed of the processing context object.

[0009] The preferred technical solution adopted by the present invention to solve the above technical problem is: in the step S100, the data to be processed of the data source is the collected data from the device received through the Pulsar message queue and includes a timestamp; When filtering unreasonable data to be processed, the latest timestamp of the device and the timestamp of the received data to be processed are compared. If the timestamp of the data to be processed is smaller than the latest timestamp of the device, the data to be processed is discarded.

[0010] The preferred technical solution adopted by the present invention to solve the above technical problem is: the rules in the rule list obtained in step S200 are created by the following steps: Step S211: Select the object to which the rule applies; Step S212: creating a condition group; Step S213: adding a condition to the condition group; Step S214: determine whether multiple conditions need to be added to the current condition group, if so, repeat step S213, if not, jump to step S215; Step S215: determine whether multiple condition groups need to be created, if so, repeat step S212, if not, jump to step S216; Step S216: selecting an execution service; the execution service is defined by the connected downstream connection service side; Step S217: selecting additional configuration; the additional configuration includes the form of triggering rules and the range of data to be processed transmitted downstream; the form of triggering rules includes triggering by condition group and triggering by rule; Step S218: Save the configured rules to the rule cache component for acquisition in step S200.

[0011] The preferred technical solution adopted by the present invention to solve the above technical problem is: the rules in the rule list obtained in step S200 are verified by the following steps: Step S221: monitoring the data change signal of the business definition table, and when the data change signal of the business definition table is monitored, verifying the rule corresponding to the data source; Step S222: comparing the rules, comparing the business definition information of the data source with the configuration of the corresponding rule, and if the comparison result is abnormal, modifying the status flag of the rule to illegal; Step S223: Feedback invalidation information. When a rule is marked as illegal, the invalidation information is reflected in the rule configuration page in real time.

[0012] The preferred technical solution adopted by the present invention to solve the above technical problem is: in step S330, the step of determining whether the condition group is triggered is as follows: Step S331: Take out a sub-condition in the current condition group, and determine whether the sub-condition is legal and valid. If not, determine that the sub-condition is not satisfied and not triggered, and execute step S333. If yes, execute step S332; Step S332: selecting a corresponding condition processor according to the condition type specified in the sub-condition to determine whether the sub-condition is satisfied. If not, the sub-condition is determined not to be triggered. If satisfied, the sub-condition is determined to be triggered. Step S333: determine whether there is a next sub-condition. If not, execute step S334. If yes, take out the next sub-condition in the current condition group, and execute steps S331 to S333 in a loop until all sub-conditions under the current condition group are determined, and execute step S334. Step S334: If there is any unsatisfied sub-condition under the current condition group, the current condition group is determined to be unsatisfied and not triggered; if all sub-conditions under the current condition group are satisfied, the current condition group is determined to be satisfied and triggered.

[0013] The preferred technical solution adopted by the present invention to solve the above technical problem is: in step S330, the judgment logic of whether the rule is triggered is as follows: If all condition groups under the current rule are not satisfied, the current rule is determined to be not satisfied and not triggered; if at least one condition group under the current rule is satisfied, the current rule is determined to be satisfied and triggered.

[0014] Another technical solution adopted by the present invention to solve the above technical problem is: a business process processing system driven by multiple conditional rules, including the following system modules: The data source access processor is used to receive the data to be processed from the data source, filter out the unreasonable data to be processed, obtain a list of rules matching the current data source, and send the data to be processed and the matching rules together to the task executor; A task executor is used to receive the data to be processed and the matching rules from the data source access processor, and send them to the rule condition processing initiator; to receive the processing context object from the rule condition processing initiator, and pass it to the distributor downstream; to coordinate and manage the whole process and life cycle of the data to be processed from the data source in the business process processing system driven by multiple condition rules; A rule condition processing initiator is used to receive the data to be processed and the matching rules from the task executor, and coordinate the whole process of conditional judgment processing of the data to be processed by using the matching rules; to generate a list of condition groups, each of which contains multiple conditions; to establish an OR logical relationship between the condition groups; to package the judgment logic of each condition group into a task and hand it over to the thread pool for asynchronous execution, that is, to send it to the corresponding rule condition processor and wait for result feedback; to receive and summarize the trigger results of each condition group returned by each rule condition processor to determine whether the rule is triggered; to assemble the judgment results of each condition group and the content of the conditions in the triggered condition group into a trigger result object; to collect the trigger result objects, and to construct a processing context object together with the data to be processed of the data source, and return it to the task executor; A rule condition processor is used to receive a condition group processing task from a rule condition processing initiator, establish a logical relationship between the conditions in the same condition group, determine whether each condition group is triggered, and return the processing result to the rule condition processing initiator; A distributor is used to distribute the to-be-processed data of the processing context object received from the task executor.

[0015] Another technical solution adopted by the present invention to solve the above technical problem is: a computer device, including a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the steps of a business process processing algorithm driven by multiple conditional rules.

[0016] Another technical solution adopted by the present invention to solve the above technical problem is: a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of a business process processing algorithm driven by multiple conditional rules are implemented.

[0017] Another technical solution adopted by the present invention to solve the above technical problem is: a computer program product, including a computer program, which implements the steps of a business process processing algorithm driven by multiple conditional rules when executed by a processor.

[0018] Compared with the prior art, the advantages of the present invention are: on the one hand, by forming a pyramid-shaped hierarchical coordination among the task executor, the rule condition processing launcher, and the rule condition processor, the logical judgment of the rule conditions is decomposed and summarized layer by layer, overcoming the defects of code execution efficiency varying from person to person and algorithm waste caused by case-by-case compilation of conditional rules, optimizing and improving program execution efficiency, and effectively reducing the waste of computing resources.

[0019] On the other hand, through multi-condition rule drive and centralized management of rule condition judgment logic, the defects of extremely bloated system and difficult maintenance and expansion caused by repeated hard code writing in the process of demand changes and business iterations are overcome. The universality, simplicity and abstraction of program code are improved, the maintenance cost on the operation side is reduced, and the delivery efficiency on the development side is improved.

[0020] Furthermore, the hard-coded logic is low-code through the rule configuration module, reducing the workload of developers who directly connect to the IoT data packets; through the data source access processor and rule cache component, the performance bottleneck caused by multi-point access to IoT data collection or other data source data is reduced; through the rule configuration module and rule verification module, the technical threshold is lowered, allowing non-technical personnel, especially factory operators, to participate in the definition and management of business processes, thereby improving the efficiency of overall department demand delivery. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present invention will be further described in detail below in conjunction with the accompanying drawings and preferred embodiments, but those skilled in the art will appreciate that these drawings are drawn only for the purpose of explaining the preferred embodiments and therefore should not be used as a limitation on the scope of the present invention. In addition, unless otherwise specified, the drawings are only schematically representing the composition or structure of the described objects and may contain exaggerated displays, and the drawings are not necessarily drawn to scale.

[0022] Figure 1 A system block diagram of a business process processing system driven by multi-conditional rules; Figure 2 It is a correspondence diagram between the main process and system modules of the business process processing algorithm driven by multi-condition rules; Figure 3 Processing algorithm for business processes driven by multi-conditional rules Figure 1 ; Figure 4 Processing algorithm for business processes driven by multi-conditional rules Figure 2 ; Figure 5 A flowchart for executing rule creation for the rule configuration module; Figure 6 A flowchart for executing rule verification for a rule verification module; Figure 7 Processing algorithm for business processes driven by multi-conditional rules Figure 3 ; Figure 8 A flowchart for determining whether a condition group is triggered. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. Embodiment 1

[0024] like Figure 1 The business process processing system based on multi-condition rule driving provided by this embodiment is shown, including the following system modules: Module 1: Data source access processor, used to receive the data to be processed from the data source and filter out unreasonable data to be processed; used to obtain a list of rules that match the current data source and send the data to be processed and the matching rules to the task executor.

[0025] The data source access processor supports multiple data source access, preliminarily processes data, unifies data formats, and improves the flexibility and efficiency of data processing. It should be noted that the data source can be data collected by the IoT terminal, such as equipment production data, or data generated by various business function modules of the server, such as production plan data, etc. The data source access processor provided by the present invention does not limit what kind of data source is accessed.

[0026] Module 2: Task executor, used to receive the data to be processed and the matching rules from the data source access processor, and send them to the rule condition processing initiator; used to receive the processing context object from the rule condition processing initiator, and pass it to the distributor downstream; used to coordinate and manage the entire process and life cycle of the data to be processed from the data source in the business process processing system driven by multiple condition rules.

[0027] The task executor plays the role of the central nervous system module in the business process processing system driven by multi-conditional rules. While improving the overall efficiency of rule-based business process processing, it meets the needs of different business scenarios and takes into account real-time and data consistency.

[0028] Module 3: Rule condition processing initiator, used to receive the pending data and matching rules from the task executor, coordinate the whole process of conditional judgment and processing of the pending data using the matching rules; used to generate a list of condition groups, each condition group contains multiple conditions; establish a logical relationship between the condition groups; used to package the judgment logic of each condition group into a task and hand it over to the thread pool for asynchronous execution, that is, send it to the corresponding rule condition processor and wait for result feedback; used to receive and summarize the trigger results of each condition group returned by each rule condition processor to determine whether the rule is triggered; used to assemble the judgment results of each condition group and the content of the conditions in the triggered condition group into a trigger result object; collect the trigger result objects, build the processing context object together with the pending data of the data source, and return it to the task executor.

[0029] Module 4: Rule condition processor, used to receive condition group processing tasks from the rule condition processing initiator, establish logical relationships between conditions in the same condition group; used to determine whether each condition group is triggered, and return the processing results to the rule condition processing initiator.

[0030] The relationship between the rule condition processing initiator and the rule condition processor is like the relationship between a manager and an executor. The rule condition processing initiator does not directly perform the specific execution of the condition judgment processing, but entrusts the specific execution of the condition judgment processing to the specific rule condition processor. Its main job is to coordinate and summarize the processing results of each specific rule condition processor.

[0031] The rule condition processor is the smallest module unit for conditional judgment processing, which supports conditional structure expansion and improves the flexibility and efficiency of rule condition judgment.

[0032] Module 5: Distributor, used to distribute the data to be processed received from the processing context object of the task executor.

[0033] Furthermore, the multi-condition rule-driven business process processing system provided in this embodiment further includes the following system modules for rule creation and storage: Module 6: Rule configuration module, used to create and define rules; used to select the objects to which the rules apply; used to create condition groups; used to add conditions in condition groups; used to determine whether multiple conditions need to be added to the current condition group, if so, to add conditions to the condition group, if not, used to determine whether multiple condition groups need to be created, if so, to create condition groups, if not, used to select execution of business; the execution of business is defined by the downstream docking business side of the access; used to select additional configuration; additional configuration includes the form of triggering rules and the range of data to be processed passed to the downstream; the form of triggering rules includes triggering by condition group and triggering by rule; used to save the configured rules to the rule cache component for data source access processor to obtain.

[0034] The rule configuration module converts hard-coded logic into low-code, allowing operators to implement complex business rules through intuitive configuration, greatly reducing functional maintenance costs.

[0035] Module 7: Rule verification module, used to verify the rules created by the rule configuration module; used to monitor the data change signal of the business definition table, and when the data change signal of the business definition table is monitored, the rules corresponding to the data source are verified; used to compare the rules, and compare the business definition information of the data source with the configuration of the corresponding rules. If the comparison result is abnormal, the status mark of the rule is modified to illegal; used to feedback invalidation information, when a rule is marked as illegal, the invalidation information is reflected in real time on the rule configuration page.

[0036] The rule verification module can check the validity of rule configuration data in real time, provide timely feedback on failure information, and improve the robustness and reliability of the system.

[0037] Module eight: rule cache component, used to store the rules created by the rule configuration module for the data source access processor to obtain. The rule cache component provided in this embodiment includes two basic functions: function one: cache rules; function two: cache refresh.

[0038] The rule cache component adopts a combination of local cache + timed refresh + local cache hot update to ensure performance and real-time performance when rules are used frequently.

[0039] Function 1: Cache rules further include local cache rules and mapping table maintenance. Local cache rules cache the rules created by the rule configuration module in the local cache, reducing the number of database accesses, eliminating the need for I / O operations, and improving the efficiency of data access. Mapping table maintenance maintains a mapping table in the rule cache component to directly map the device ID and data source identifier to the corresponding rule list, thereby increasing the speed at which the data source access processor obtains the rule list.

[0040] Function 2: Cache refresh further includes periodic refresh and local cache hot refresh. Periodic refresh is performed by the rule cache component to regularly refresh the latest rules from the database to ensure the real-time nature of the rules stored in the rule cache component. Local cache hot update is performed by the rule cache component to broadcast a notification to each instance when a rule configuration change is detected, triggering a cache refresh of a specific device to ensure that the rules stored in the rule cache component are consistent with the data in the database.

[0041] like Figures 2 to 8 As shown, the following is combined with the business process processing algorithm based on multi-condition rule driving provided in this embodiment, combined with the various steps of the algorithm, the specific system modules that execute each step, and how the data to be processed is transmitted between the various system modules, to dynamically and concretely explain the operating principles of the business process processing algorithm and system based on multi-condition rule driving provided in this embodiment and the beneficial effects they produce.

[0042] The business process processing algorithm based on multi-condition rule driving includes the following steps: like Figure 3 As shown, step S100: receiving data to be processed from a data source, and filtering unreasonable data to be processed.

[0043] This step is performed by the data source access processor. In this embodiment, the data to be processed of the data source is the collected data from the device received through the Pulsar message queue and includes a timestamp. Due to network delays, interruptions, and other reasons, the data to be processed in the Pulsar message queue may arrive out of order. When filtering unreasonable data to be processed, the data source access processor filters according to the event timestamp of each piece of data to be processed to ensure that the data to be processed is processed in chronological order. Specifically, the data source access processor compares the latest timestamp of the device and the timestamp of the received data to be processed. If the timestamp of the data to be processed is less than the latest timestamp of the device, the data to be processed is discarded.

[0044] Step S200: Obtain a list of rules that match the current data source, and send the data to be processed together with the matching rules.

[0045] This step is performed by the data source access processor. Since the data source in this embodiment is the device data collected by the IoT terminal, the data source access processor requests the rule cache component to obtain a list of rules that matches the current data source based on the device ID bound to the incoming data to be processed. The rule cache component directly maps to the corresponding rule list through a mapping table based on the device ID and data source identifier, and quickly returns the matching rule list. The data source access processor sends the received data to be processed and the rules in the matching rule list to the task executor.

[0046] like Figure 7As shown, step S300: using the matching rules to perform conditional judgment processing on the data to be processed, including steps S310 to S340: Step S310: receiving data to be processed and matching rules.

[0047] The task executor receives the data to be processed and the rules in the rule list that match it from the data source access processor, and sends them to the rule condition processing initiator. In this embodiment, the rules may include but are not limited to rule name, device, custom business event, business type, business data source type, filtering configuration, rule details, additional configuration, etc.

[0048] Step S320: parse the content of the rule: generate a list of condition groups, each condition group contains multiple conditions; establish an OR logical relationship between the condition groups; establish an AND logical relationship between the conditions in the same condition group.

[0049] Step S330: Process each condition group in parallel: package the judgment logic of each condition group into a task and assign it to the thread pool for asynchronous execution to determine whether each condition group is triggered; after all tasks are executed, determine whether the rule is triggered.

[0050] Step S340: Construct a processing context object: Assemble the judgment results of each condition group and the contents of the conditions in the triggered condition group into a trigger result object; collect the trigger result objects, and construct the processing context object together with the data source's to-be-processed data, and pass it downstream.

[0051] What needs to be further explained about steps S320 to S340 is that, first, the rule condition processing initiator parses the content of the rule at the condition group level, generates a condition group list, each condition group contains multiple conditions, and establishes an OR logical relationship between the condition groups.

[0052] Subsequently, the rule condition processing launcher packages the judgment logic of each condition group into a task and assigns it to the thread pool for asynchronous execution, that is, it is sent to the corresponding rule condition processor. If there are several condition groups under a rule item, the judgment tasks of several condition groups will be executed in parallel, and the rule condition processing launcher will wait for the result feedback.

[0053] After receiving the condition group processing task from the rule condition processing initiator, each rule condition processor establishes a logical relationship between the conditions in the same condition group it receives, and each determines whether the received condition group is triggered. Each rule condition processor processes each condition group in parallel, and each returns the processing result to the rule condition processing initiator.

[0054] like Figure 8As shown, the process involves a determination step in which each rule condition processor determines whether a condition group is triggered in step S330, which is specifically as follows: Step S331: Take out a sub-condition in the current condition group and determine whether the sub-condition is legal and valid. If not, determine that the sub-condition is not satisfied and not triggered, and execute step S333. If so, execute step S332.

[0055] Step S332: Select the corresponding condition processor according to the condition type specified in the sub-condition to determine whether the sub-condition is satisfied. If not, the sub-condition is determined not to be triggered. If satisfied, the sub-condition is determined to be triggered. Figure 8 Two typical conditional handlers are listed in.

[0056] Step S333: Determine whether there is a next sub-condition. If not, execute step S334, which means that all conditions contained in the condition group have been judged, and start the logical judgment of the condition group. If so, take out the next sub-condition in the current condition group, and loop through steps S331 to S333 until all sub-conditions under the current condition group have been judged, and execute step S334.

[0057] Step S334: Since the conditions in the same condition group are logically related, if there is any unsatisfied sub-condition under the current condition group, the current condition group is judged to be unsatisfied and not triggered; if all sub-conditions under the current condition group are satisfied, the current condition group is judged to be satisfied and triggered.

[0058] The rule condition processing initiator receives and summarizes the triggering results of each condition group returned by each rule condition processor, and determines whether the rule is triggered.

[0059] This process involves the judgment logic of the rule condition processing launcher in step S330 to determine whether the rule is triggered, which is as follows: Since there is an OR logical relationship between each condition group, if all condition groups under the current rule are not met, the current rule is judged to be not met and not triggered; if at least one condition group under the current rule is met, the current rule is judged to be met and triggered.

[0060] After all rule judgments and processing are completed, the rule condition processing initiator builds a processing context object, that is, assembles the judgment results of each condition group and the contents of the conditions in the triggered condition group into a trigger result object, collects the trigger result objects, and builds the processing context object together with the data source's to-be-processed data, and passes it downstream, that is, returns it to the task executor.

[0061] The task executor receives the processing context object from the rule condition processing initiator and passes it downstream to the distributor, which executes step S400.

[0062] Step S400: Distribute the received data to be processed of the processing context object.

[0063] The above is an introduction to the main process of the business process processing algorithm driven by multi-conditional rules. The following further introduces the related processes of rule creation, verification, and storage. These processes are relatively independent of the main process and are specifically executed by the rule configuration module, rule verification module, and rule cache component. The latest rules and rule lists are stored in the rule cache component for the data source access processor to call and use.

[0064] like Figure 5 As shown, the rule configuration module is responsible for creating and defining rules. The rules in the rule list obtained by the data source access processor in step S200 are created by the rule configuration module through the following steps: Step S211: Select the object to which the rule applies. In this embodiment, since the data produced by the device at the IoT end is used as the data source, the operator selects the device to which the rule applies in this step. You can configure only one device, or you can choose to configure the rule for all devices. When all devices are configured, when the data to be processed flows into the data source access processor, no matter which device the device ID points to, it will be configured for processing by the rule.

[0065] Step S212: Create a condition group.

[0066] Step S213: Add a condition to the condition group.

[0067] Step S214: Determine whether multiple conditions need to be added to the current condition group. If so, repeat step S213; if not, jump to step S215.

[0068] Step S215: Determine whether multiple condition groups need to be created. If so, repeat step S212; if not, jump to step S216.

[0069] Steps S212 to S215 are the process of creating condition groups and adding conditions to each condition group. The present invention is called "business process processing algorithm and system based on multi-condition rule drive" because when the industrial Internet of Things system is applied to the complex actual factory production and operation process, its data processing rules are usually multi-condition and multi-condition group.

[0070] Step S216: Select execution service; the execution service is defined by the connected downstream docking service side.

[0071] Step S217: select additional configuration; the additional configuration includes the form of triggering rules and the range of data to be processed transmitted downstream; the form of triggering rules includes triggering by condition group and triggering by rule.

[0072] Step S218: Save the configured rules to the rule cache component for acquisition in step S200.

[0073] Furthermore, if a new rule configuration is added or changed, the local cache of the rule cache component will be updated synchronously. The specific synchronous update scope includes all rules under the device item corresponding to the current rule configuration, and the rule configuration module will reload these rules to the rule cache component.

[0074] like Figure 6 As shown, the rule verification module is responsible for verifying the rules created by the rule configuration module. The rules in the rule list obtained by the data source access processor in step S200 are verified by the rule verification module through the following steps before being retrieved and used: Step S221: Monitor the data change signal of the business definition table. The rule verification module has multiple listeners, which specifically monitor the data change signal of the business definition table of the data source connected to the rule engine. When the data change signal of the business definition table is monitored, the rule corresponding to the data source is verified.

[0075] Step S222: Compare rules. The rule verification module compares the business definition information of the data source with the configuration of the corresponding rule. If the comparison result is abnormal, the status flag of the rule is modified to illegal.

[0076] Step S223: Feedback of failure information: When a rule is marked as illegal, the rule verification module reflects the failure information in real time on the rule configuration page to remind the operator to pay attention to the problem at the rule configuration level, and guide and promote the operator to solve the problem.

[0077] The rules created by the rule configuration module and the rules verified by the rule verification module are ultimately stored in the rule cache component. The two major functions of the rule cache component, cache rules and cache refresh, have been explained in the previous introduction to the system module and will not be repeated here.

[0078] In addition, the present invention also relates to a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of a business process processing algorithm driven by multiple conditional rules are implemented. It also relates to a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by the processor, the steps of a business process processing algorithm driven by multiple conditional rules are implemented. It also relates to a computer program product, including a computer program, which, when executed by the processor, implements the steps of a business process processing algorithm driven by multiple conditional rules.

[0079] To summarize, the business process processing algorithm and system driven by multi-conditional rules provided by the present invention, on the one hand, form a pyramid-shaped hierarchical coordination among the task executor, the rule condition processing initiator, and the rule condition processor, so as to decompose and coordinate the logical judgment of the rule conditions layer by layer, overcome the defects of code execution efficiency varying from person to person and algorithm waste caused by case-by-case compilation of conditional rules, optimize and improve the program execution efficiency, and effectively reduce the waste of computing resources.

[0080] On the other hand, through multi-condition rule drive and centralized management of rule condition judgment logic, the defects of extremely bloated system and difficult maintenance and expansion caused by repeated hard code writing in the process of demand changes and business iterations are overcome. The universality, simplicity and abstraction of program code are improved, the maintenance cost on the operation side is reduced, and the delivery efficiency on the development side is improved.

[0081] Furthermore, the hard-coded logic is low-code through the rule configuration module, reducing the workload of developers who directly connect to the IoT data packets; through the data source access processor and rule cache component, the performance bottleneck caused by multi-point access to IoT data collection or other data source data is reduced; through the rule configuration module and rule verification module, the technical threshold is lowered, allowing non-technical personnel, especially factory operators, to participate in the definition and management of business processes, thereby improving the efficiency of overall department demand delivery.

[0082] The following two specific embodiments applied to actual working conditions and operating environments more intuitively illustrate the operating logic and effect manifestation of the business process processing algorithm and system driven by multiple conditional rules provided by the present invention. Embodiment 2

[0083] This embodiment takes the business process processing of loading and unloading of automated equipment A (equipment ID_1691375190061285376) in a smart factory as an example to illustrate the operation process of the business process processing algorithm and system driven by multi-condition rules provided by the present invention in actual production scenarios, so as to show the working principle of the algorithm and system in a more concrete and intuitive way.

[0084] Step 1: Rule configuration.

[0085] Factory operators configure rules in custom scenarios. Loading and unloading of automated equipment is usually classified as reporting business. Since loading and unloading of automated equipment needs to be triggered based on the equipment change data collected by the IoT terminal, the collected data stream is used as the data source, and the scenario is named as collection reporting. The collected stream data source is used as the access data source for the scenario.

[0086] After the data source is determined, the rule structure can also be determined, which includes the structure in the condition group and the structure of the additional configuration. The parameter rules in the condition group can specify specific parameters, such as scan code value, part serial number, signal, etc., which depends on the IoT acquisition variables under the device.

[0087] After specifying the acquisition variables, you can specify the condition type, including the acquisition change type and the acquisition comparison type. You can then construct specific condition clauses based on the condition type. Additional configuration can configure field filtering for this scenario, and choose to distribute the result data by condition group or by rule as a whole.

[0088] In this embodiment, the loading condition of device A is: when the scan code value changes and the value of the inspection status is NG; the unloading condition is: when the part serial number changes and the unloading batch code changes. It can be seen that device A needs to perform two business operations, one is loading and the other is unloading. Loading and unloading can define two business events respectively, or they can be combined into one loading and unloading event. The difference between the two is that the relationship between the event and the overall rule is one-to-one. A rule can only select and configure one event. Defining two business events means that two rules need to be created, and the downstream routes become two. The rule engine used by the business process processing system driven by multi-conditional rules provided by the present invention supports two configuration methods, and the operation can be selected according to the needs. In order to facilitate the display box to understand the configuration structure, this embodiment defines two business operations as one event, namely, the loading and unloading event.

[0089] Then proceed with rule configuration. First, select the device specified by the rule as device A, name the rule "Device A Loading and Unloading", and then define the rule conditions: create the first condition group and name it "Loading"; add the first sub-condition, select the acquisition variable as the scanned code value, and select the condition as change; add the second sub-condition, select the acquisition variable as the inspection status, select the condition as logical matching, select the matching rule as "yes", and the condition value as "NG", and the first condition group configuration is complete.

[0090] Create a second condition group and name it "Blanking"; add the first sub-condition, where the collection variable is selected as the part serial number and the selection condition is change; add the second sub-condition, where the collection variable is selected as the blanking batch code and the selection condition is change. From now on, two simple condition groups have been configured.

[0091] Next, specify the business events that need to be triggered, select the custom loading and unloading events, and the event triggering form is triggered by the condition group. Finally, configure the field set transmitted to the downstream, select to transmit the scanned code value and inspection status when the loading condition group is triggered, and to transmit the part serial number and unloading batch code when the unloading condition group is triggered.

[0092] At this point, the rule configuration is complete. Select Submit to refresh the cache immediately and the rule will take effect immediately.

[0093] An example of the above rule structure is as follows (hereinafter referred to as [Rule Example]): {"businessDataSource":"ACQUISITION_STREAM","businessType":"ACQUISITION_REPORTING","contents":[{"conditions":[{"detail":{"dimensionType":"BUSINESS_FUNCTION","targetKey":"LJXLH"},"id":"48d3e51174b04aaf454f902ed5fdbd1f","type":"ACQUISITION_CHANGE","valid":true},{"detail":{"dimensionType":"BUSINESS_FUNCTION","targetKey":"XLPCM"},"id":"48d3e51174b04aaf454f902ed5fdbd20","type":"ACQUISITION_CHANGE","valid":true}],"id":"5fad1d823505c7dbd3ce8a5dc6f9e7d6","tag":"下料"},{"conditions":[{"detail":{"dimensionType":"BUSINESS_FUNCTION","targetKey":"SMZ"},"id":"48d3e51174b04aaf454f902ed5fdbd2f","type":"ACQUISITION_CHANGE","valid":true},{"id":"77df3316997102e05a5b8641af03aa2c","type":"ACQUISITION_COMPARISON","valid":true,"detail":{"symbol":"YES","targetKey":"JYZT","dimensionType":"BUSINESS_FUNCTION","comparativeValue":"NG","targetVarDataType":"STRING","comparisonParamType":"CUSTOM_VALUE"}}],"id":"5fad1d823505c7dbd3ce8a5dc6f9e7d7","tag":"上料"}],"customBusinessEvent":"LOADING_OR_UNLOADING","deviceId":1691375190061285376,"extraConfig":{"resultConfig":{"taggedFilterFields":[{"tags":["loading"] ,"filterFields":[{"type":"BUSINESS_FUNCTION","targetKey":"SMZ"},{"type":"BUSINESS_FUNCTION","target tKey":"JYZT"}]},{"tags":["Blanking"],"filterFields":[{"type":"BUSINESS_FUNCTION","targetKey":"LJXLH"},{" type":"BUSINESS_FUNCTION","targetKey":"XLPCM"}]}]},"triggerConfig":{"eventTriggerMode":"MULTI"}}}, Step 2: Collect data sources and access the system.

[0094] Step 1 (corresponding to step S100): the collected data is cleaned by the flink program and flows into the data source access processor as the data source entrance through the pulsar message queue.

[0095] The following is an example of the data to be processed that flows into the data source entrance at a certain moment (hereinafter referred to as [collected data example]): {"tenementId":"1130021","acqData":{"col_83":{"businessFunctionCode":"JYZT","lastNotNullVal":"OK","lastVal":"OK","functionType":"COMMON","currentVal":"NG"},"col_84":{"businessFunctionCode":"XLPCM","lastNotNullVal":"PCM13795842","lastVal":"PCM13795842","functionType":"COMMON","currentVal":"PCM13795843"},"col_81":{"businessFunctionCode":"SMZ","lastNotNullVal":"TEST-TM-000007773","lastVal":"TEST-TM-000007773","functionType":"COMMON","currentVal":"TEST-TM-000007774"},"col_82":{"businessFunctionCode":"LJXLH","lastNotNullVal":"LJXL000001275","lastVal":"LJXL000001275","functionType":"COMMON","currentVal":"LJXL000001275"},"col_80":{"businessFunctionCode":"TD2KJZT","lastNotNullVal":"0.00","lastVal":"0.00","functionType":"COMMON","currentVal":"0.00"},"col_79":{"businessFunctionCode":"TD1KJZT","lastNotNullVal":"1","lastVal":"1","functionType":"COMMON","currentVal":"1"}},"deviceId":"1691375190061285376","eventTimestamp":"1731306938000"} Among them, eventTimestamp represents the timestamp of the IoT end data collection, deviceId is the device ID, acqData represents the device data collection data set, and it can be seen that there are 6 collection variables in acqData, namely col_79, col_80, col_81, col_82, col_83, and col_84. The number of the collection variable is an identifier, and the corresponding variable has a business meaning, among which the field businessFunctionCode corresponds to the business meaning. In this embodiment, businessFunctionCode is the col_81, col_83, col_82, and col_84 variables of SMZ, JYZT, LJXLH, and XLPCM, which respectively represent the scan code value, inspection status, part serial number, and batch code of blanking.

[0096] Step 2 (corresponding to step S100): A memory-level mapping table is maintained in the data source access processor, which can map from the device ID to the latest data collection timestamp of the device flowing into the rule engine. The timestamp of the current data collection is 1731306938000, so the data in the mapping table is 1691375190061285376 -> 1731306938000. Assuming that a new collection data flows in at this time, and the eventTimestamp of the data is 1731306937000, the timestamp is less than 1731306938000, and the data is considered expired data and will be discarded.

[0097] Step 3 (corresponding to step S200): Obtain all rule information of device ID_1691375190061285376 and data source type ACQUISITION_STREAM (acquisition stream data source) from the rule cache component, taking into account the rules of the wildcard device, and retrieve all rules of device ID -1 and data source type ACQUISITION_STREAM. The collection of the two sets of rules is the total rule list that device A needs to process. If no rules are matched, the data processing ends.

[0098] Step 4 (corresponding to step S200): Divide the rules from the rule list into two rule sets according to the executor type corresponding to the specified business event. In this embodiment, it can be parsed from [Rule Example] that the business event to be triggered is identified as LOADING_OR_UNLOADING. The executor type executorType has been specified at the beginning of the definition of this event. The type of executor has been specified as a general task executor (GENERAL). How to specify it is determined by the characteristics of the downstream business operations. The related tasks of collecting reports are generally handed over to the general task executor for execution. Therefore, the two rule sets are placed in the general task executor together with the collected data to start executing the task. Whether the collected data has been processed and acked to the upstream pulsar queue is determined by the result status of the task executor executing the task.

[0099] Step 3: Rule condition judgment under the coordination of the task executor.

[0100] Step 1 (corresponding to the part executed by the task executor in step S300): The task executor receives the [collected data example] + [rule example], and the data needs to be processed in three steps: the first step is to call the rule condition processing initiator and the rule condition processor; the second step is to find the corresponding distributor; the third step is to call the distributor to distribute the context data. The entire process of these three steps is packaged into a task and put into the thread pool to start preparing for asynchronous task execution.

[0101] Step 2 (corresponding to the part executed by the rule condition processing initiator and the rule condition processor in step S300): The first step is to call the rule condition processing initiator and the rule condition processor.

[0102] [Rule Example] contents represents a list of condition groups, in which the two elements represent the two condition groups of material loading judgment and material unloading judgment respectively, and tag uniquely identifies the entire condition group. The condition group contains a condition list conditions, and the elements (sub-conditions) in conditions have an AND logical relationship, while the elements (condition groups) in contents have an OR logical relationship. The type element in conditions indicates that the type of the condition judgment is a collection change class, and the targetKey in details corresponds to the businessFunctionCode in the collected data. Valid indicates that the current state of this sub-condition is normal and valid. On the contrary, the condition in the false state will be judged as a non-triggering condition before being processed by the rule condition processor, thereby affecting the judgment result of the entire condition group.

[0103] The condition types in [Rule Examples] are all collection change types. In addition, there is also a collection comparison type. The condition structure of the comparison type includes rule symbols (such as logical judgment symbols such as >, <, =), comparison values, comparison variables and other information, which are used to determine whether the collection value satisfies the comparison expression.

[0104] The rule condition processing initiator receives the [collection data example] + [rule example] sent by the task executor. For the internal condition group list contents parsed from the [rule example], traverse the contents and process each condition group in parallel. The parallel subtask parses the condition list conditions in the condition group, traverses the conditions to obtain each sub-condition, and the sub-condition type is ACQUISITION_CHANGE. Then find the rule condition processor of the collection change class and start processing the sub-condition {"detail":{"dimensionType":"BUSINESS_FUNCTION","targetKey":"SMZ"},"id":"48d3e51174b04aaf454f902ed5fdbd2f","type":"ACQUISITION_CHANGE","valid":true}.

[0105] Get the targetKey as SMZ, and find the collected data with the businessFunctionCode of acqData as SMZ in [Collected Data Example]. If the data corresponding to the businessFunctionCode is not found, it is considered that there is no variable concerned by the sub-condition in the collected data, and the sub-condition is not satisfied, and the condition group is not satisfied. Since the data of SMZ can be found in [Collected Data Example], the values ​​of lastVal (previous value) and currentVal (current value) are compared. If TEST-TM-000007773 != TEST-TM-000007774, it is determined that the condition for changing the collected data is satisfied.

[0106] Continue to traverse the second sub-condition, the type of the second sub-condition is ACQUISITION_COMPARISON, find the rule condition processor of the collection comparison class, and start processing the sub-condition {"id":"77df3316997102e05a5b8641af03aa2c","type":"ACQUISITION_COMPARISON","valid":true,"detail":{"symbol":"YES","targetKey":"JYZT","dimensionType":"BUSINESS_FUNCTION","comparativeValue":"NG","targetVarDataType":"STRING","comparisonParamType":"CUSTOM_VALUE"}}.

[0107] Get the targetKey as JYZT, and find the collected data with businessFunctionCode of acqData as JYZT in [Collected Data Example]. If the data with the corresponding businessFunctionCode is not found, it is considered that there is no variable concerned by the sub-condition in the collected data, and the sub-condition is not satisfied, and the condition group is not satisfied. Since JYZT data can be found in [Collected Data Example], a logical comparison is performed to compare the currentVal (current value) with the comparativeValue (comparison value) of the sub-condition. If NG == NG, it is determined that the condition is satisfied.

[0108] At this point, there are two sub-conditions under the material loading condition group and all the sub-conditions are satisfied, so the condition group is satisfied, so the material loading condition is determined to be triggered. Similarly, in the first sub-condition processing {"detail":{"dimensionType":"BUSINESS_FUNCTION","targetKey":"LJXLH"},"id":"48d3e51174b04aaf454f902ed5fdbd1f","type":"ACQUISITION_CHANGE","valid":true} of another parallel condition group processing task, it can be seen that the LJXLH variable before and after values ​​LJXL000001275 in the collected data have not changed, and the sub-condition is determined to be unsatisfied. Since the sub-conditions in the condition group are in a logical relationship, the material unloading condition group is determined to be unsatisfied. Based on the above results, if the overall rule has a condition group that meets the trigger condition, the overall rule is triggered, and the specific triggered operation is the material loading operation.

[0109] After all the subtasks of waiting for the rule judgment are processed, the subtask will return an assembled trigger result object TriggerResult. The rule condition processing initiator will assemble the trigger results returned by the subtask into a whole processing context object, together with the rule information and the collected source data, and return it to the upper-level task executor.

[0110] The second step is to find the corresponding distributor.

[0111] The memory has a mapping table that stores the mapping relationship from the data source to the distributor. The distributor of the collection data source can be directly obtained through ACQUISITION_STREAM in the [Rule Example].

[0112] The third sub-step is to call the distributor to distribute the context data.

[0113] [Rule Example] Under [Collected Data Example], the rules are met, the LOADING_OR_UNLOADING event will be triggered, and the collected data will enter the distributor together and be distributed to the specific downstream queue.

[0114] The following is the workflow of the rule cache component in this embodiment: At the beginning of system startup, all rule information will be queried from the database, and then grouped by device + data source type, and stored in the memory in the form of a two-dimensional table, i.e., device ID_1691375190061285376 + ACQUISITION_STREAM -> [

Rule Example 1

Rule Example 2

[0115] When adding, updating, disabling or enabling rules in the rule configuration module, the rule cache component will actively initiate a refresh of the device dimension rules, for example, reloading all the rules under device ID_1691375190061285376 and overwriting the original cache. In the rule verification module, when the rule sub-condition verification result changes from legal to illegal, or from illegal to legal, the device dimension rule refresh will also be actively initiated.

[0116] The following is the workflow of the rule verification module in this embodiment: Each data source corresponds to a validator, and the collection data source also corresponds to a validator. The services related to the collection data source include collection configuration, business function configuration, etc. Their configuration changes indirectly affect the rule condition judgment. Therefore, when the business related to the data source changes, a data change signal of the business definition table will be issued. The validator monitors these signals, and when the data change signal of the business definition table is monitored, a rule check of the relevant equipment will be performed.

[0117] Step 1 (corresponding to step S221): the verifier monitors the device ID_1691375190061285376, that is, the verification signal of device A.

[0118] Step 2 (corresponding to step S222): Under the acquisition data source verifier, first obtain the rule list of all acquisition data sources under the device, and then query all acquisition variable information and business function definition information under the device.

[0119] Step 3 (corresponding to step S222): Traverse all sub-conditions in all condition groups under the rule, and compare the acquisition variable number / business function in the acquisition variable information / business function definition and business function association under the device in turn. For example, when dimensionType is ACQUISITION_VARIABLE under condition, targetKey may be configured as col_81. Only when the col_81 variable is configured under the acquisition variable information of the device, this sub-condition will be legal, because the variable definition of IoT acquisition originates from this variable information table.

[0120] Similarly, when dimensionType is BUSINESS_FUNCTION and targetKey is SMZ, the legal condition of this sub-condition must be that the SMZ business function exists in the business function definition information, that is, it must be defined before it can be referenced, otherwise the reference is invalid.

[0121] Step 4 (corresponding to step S223): List the rules that need to be changed after comparison and sorting, and then update these rules in batches. After the update is completed, refresh the cache, and then the invalid condition mark can be seen on the rule configuration page. Embodiment 3

[0122] On the basis of Example 2, the loading condition of device B is that the signal changes and the changed value is OK. Compared with Example 2, the changes in the rules between the two are only the changes in the equipment and the changes in the content of a condition group. The overall execution process is arranged by the system, and only the configuration needs to be modified to change the conditions for the execution of the production automation process, thereby avoiding a lot of repetitive workload.

[0123] In addition, there will be other data sources besides the collected data source, and there will be corresponding rule structures for other data sources, which will be reflected in the system interface in a completely different rule configuration form from the scenarios related to the collected data source. Accordingly, the processing judgment logic, data distribution logic, and configuration verification logic of the rule sub-conditions will vary in specific details, but the algorithm flow and system module functions can all be applied, thus laying the foundation for the expansion of the business process processing algorithm and system driven by multi-condition rules provided by the present invention.

[0124] It can be seen from the second and third embodiments that the business process processing algorithm and system based on multi-condition rule driving provided by the present invention have the following advantages in practical applications: In terms of development efficiency, the rule configuration module is used to reduce the workload of developers and improve development efficiency. In terms of code simplicity, it avoids repeated writing of similar conditional judgment logic and improves the simplicity and maintainability of the code. In terms of system performance, the rule cache component and task executor are used to optimize system performance and improve the real-time and efficiency of data processing. In terms of flexibility, it supports multiple data source access and rule configuration to meet the needs of different business scenarios. In terms of scalability, the design of rule condition processing launcher, rule condition processor and distributor supports flexible configuration of conditional structure extension and data distribution, thereby improving the scalability of the system. In terms of reliability, the rule verification module and consistency task executor are used to ensure the robustness of the system and the consistency of the data.

[0125] It should be noted that like reference numerals denote similar items in the following drawings, and thus, once an item is defined in one drawing, it may not be further defined or explained in subsequent drawings.

[0126] The above is an introduction to the business process processing algorithm and system based on multi-condition rule-driven provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the present invention and its core ideas. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified in a number of ways, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A business process processing algorithm driven by multiple conditional rules, characterized by: The following steps are involved: Step S100: receiving data to be processed from a data source, and filtering unreasonable data to be processed; Step S200: obtaining a list of rules matching the current data source, and sending the data to be processed together with the matching rules; Step S300: using the matched rules to perform conditional judgment processing on the data to be processed, including steps S310 to S340: Step S310: receiving the data to be processed and the matching rules; Step S320: parsing the content of the rule: generating a list of condition groups, each of which contains multiple conditions; establishing an OR logical relationship between the condition groups; and establishing an AND logical relationship between the conditions in the same condition group; Step S330: Process each condition group in parallel: package the judgment logic of each condition group into a task and assign it to the thread pool for asynchronous execution to determine whether each condition group is triggered; after all the tasks are executed, determine whether the rule is triggered; Step S340: constructing a processing context object: assembling the judgment results of each of the condition groups and the contents of the conditions in the triggered condition group into a trigger result object; collecting the trigger result objects, together with the data to be processed of the data source, constructing a processing context object, and passing it downstream; Step S400: Distribute the received data to be processed of the processing context object.

2. The business process processing algorithm based on multi-condition rule driving according to claim 1 is characterized in that: In the step S100, the data to be processed of the data source is collected data from a device received through a Pulsar message queue and includes a timestamp; When filtering unreasonable data to be processed, the latest timestamp of the device and the timestamp of the received data to be processed are compared. If the timestamp of the data to be processed is smaller than the latest timestamp of the device, the data to be processed is discarded.

3. The business process processing algorithm based on multi-condition rule driving according to claim 1 is characterized in that: The rules in the rule list obtained in step S200 are created by the following steps: Step S211: Select the object to which the rule applies; Step S212: creating a condition group; Step S213: adding a condition to the condition group; Step S214: determine whether multiple conditions need to be added to the current condition group, if so, repeat step S213, if not, jump to step S215; Step S215: determine whether multiple condition groups need to be created, if so, repeat step S212, if not, jump to step S216; Step S216: selecting an execution service; the execution service is defined by the connected downstream connection service side; Step S217: selecting additional configuration; the additional configuration includes the form of triggering rules and the range of data to be processed transmitted downstream; the form of triggering rules includes triggering by condition group and triggering by rule; Step S218: Save the configured rules to the rule cache component for acquisition in step S200.

4. The business process processing algorithm based on multi-condition rule driving according to claim 1 is characterized in that: The rules in the rule list obtained in step S200 are verified by the following steps: Step S221: monitoring the data change signal of the business definition table, and when the data change signal of the business definition table is monitored, verifying the rule corresponding to the data source; Step S222: comparing the rules, comparing the business definition information of the data source with the configuration of the corresponding rule, and if the comparison result is abnormal, modifying the status flag of the rule to illegal; Step S223: Feedback invalidation information. When a rule is marked as illegal, the invalidation information is reflected in the rule configuration page in real time.

5. The business process processing algorithm based on multi-condition rule driving according to claim 1 is characterized in that: In step S330, the steps of determining whether the condition group is triggered are as follows: Step S331: Take out a sub-condition in the current condition group, and determine whether the sub-condition is legal and valid. If not, determine that the sub-condition is not satisfied and not triggered, and execute step S333. If yes, execute step S332; Step S332: selecting a corresponding condition processor according to the condition type specified in the sub-condition to determine whether the sub-condition is satisfied. If not, the sub-condition is determined not to be triggered. If satisfied, the sub-condition is determined to be triggered. Step S333: determine whether there is a next sub-condition. If not, execute step S334. If yes, take out the next sub-condition in the current condition group, and execute steps S331 to S333 in a loop until all sub-conditions under the current condition group are determined, and execute step S334. Step S334: If there is any unsatisfied sub-condition under the current condition group, the current condition group is determined to be unsatisfied and not triggered; if all sub-conditions under the current condition group are satisfied, the current condition group is determined to be satisfied and triggered.

6. The business process processing algorithm based on multi-condition rule driving according to claim 1 is characterized in that: In step S330, the judgment logic of whether the rule is triggered is as follows: If all condition groups under the current rule are not satisfied, the current rule is determined to be not satisfied and not triggered; if at least one condition group under the current rule is satisfied, the current rule is determined to be satisfied and triggered.

7. A business process processing system driven by multiple conditional rules, characterized by: Includes the following system modules: The data source access processor is used to receive the data to be processed from the data source, filter out the unreasonable data to be processed, obtain a list of rules matching the current data source, and send the data to be processed and the matching rules together to the task executor; A task executor, used for receiving the data to be processed and the matching rules from the data source access processor, and sending them to the rule condition processing initiator; Used to receive the processing context object from the rule condition processing initiator and pass it to the distributor downstream; Used to coordinate and manage the entire process and life cycle of the data to be processed from the data source in the business process processing system driven by multiple conditional rules; A rule condition processing initiator is used to receive the data to be processed and the matching rules from the task executor, coordinate the whole process of conditional judgment processing of the data to be processed by using the matching rules; to generate a list of condition groups, each of which contains multiple conditions; and to establish an OR logical relationship between each of the condition groups; It is used to package the judgment logic of each condition group into a task and assign it to the thread pool for asynchronous execution, that is, to send it to the corresponding rule condition processor and wait for result feedback; it is used to receive and summarize the triggering results of each condition group returned by each rule condition processor to determine whether the rule is triggered; Used to assemble the judgment results of each of the condition groups and the contents of the conditions in the triggered condition group into a trigger result object; collect the trigger result objects, together with the to-be-processed data of the data source, to construct a processing context object, and return it to the task executor; A rule condition processor, used for receiving a condition group processing task from a rule condition processing initiator, and establishing a logical relationship between the conditions in the same condition group; Used to determine whether each of the condition groups is triggered, and return the processing result to the rule condition processing initiator; A distributor is used to distribute the to-be-processed data of the processing context object received from the task executor.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the processor implements the steps of the multi-condition rule-driven business process processing algorithm described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the business process processing algorithm based on multi-condition rule driving described in any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the business process processing algorithm based on multi-condition rule driving described in any one of claims 1 to 6 are implemented.

Images