A rule engine execution method and device for different service scenarios

Abstract

The application relates to the technical field of rule engine, and discloses a rule engine execution method and device for different business scenarios, which comprises the following steps: presetting business execution rules on each node of different business scenarios; obtaining order data containing a preset type identifier; determining a user type corresponding to the order data based on the type identifier; dynamically matching the business execution rules based on the user type; and configuring a corresponding customer channel. The application has the advantages of automatically matching the business execution rules, and only needs to configure the customer channel, so that the configuration process is simplified, the applicability of the rule engine is stronger, and the order processing efficiency of the business system is effectively improved.

Description

Technical Field

[0001] This application relates to the field of rule engine technology, and in particular to a rule engine execution method and apparatus for different business scenarios. Background Technology

[0002] Using a rule engine to execute rules, by providing a visual rule editor and execution engine, makes rule writing and execution simpler and more efficient, separating business processes from business rules, and separating business decisions from application code, which facilitates the optimization of the rule engine.

[0003] The existing business system needs to support orders from multiple channels, such as the official website, Tmall, JD.com, smart lockers, and corporate websites, because the supply chain is being expanded to all aspects and channels. However, each type of order has a different processing method, and the existing rule engine is difficult to apply. Moreover, its configuration process is cumbersome, resulting in low order processing efficiency.

[0004] Regarding the aforementioned technologies, the inventors discovered that the existing rule engine execution methods in business systems have poor applicability, resulting in low order processing efficiency. Summary of the Invention

[0005] To improve the applicability of the rule engine in business systems and increase order processing efficiency, this application provides a rule engine execution method and apparatus for different business scenarios.

[0006] Firstly, this application provides a rule engine execution method for different business scenarios.

[0007] This application is achieved through the following technical solution:

[0008] A rule engine execution method for different business scenarios includes the following steps:

[0009] Pre-set business execution rules at each node in different business scenarios;

[0010] Retrieve order data containing preset type identifiers;

[0011] Based on the type identifier, the user type corresponding to the order data is determined;

[0012] Based on the user type, the business execution rules are dynamically matched, and the corresponding customer channels are configured.

[0013] In a preferred example, this application can be further configured as follows: the user types include key customers, foreign enterprises, ordinary customers, and customers with proprietary payment systems; the steps of presetting business execution rules at various nodes in different business scenarios include,

[0014] If the customer is a key client, first determine whether the order needs to be reviewed;

[0015] If it is a foreign company, the business system should be integrated into the user's own system first, and then the shipping warehouse should be determined.

[0016] For regular customers, you will be redirected to the official website page to confirm the shipping warehouse.

[0017] For customers with their own payment systems, valid order information is first exported from the user's own system to the business system before the shipping warehouse is determined.

[0018] In a preferred embodiment, this application can be further configured such that the step of first determining whether an order requires review includes,

[0019] Obtain a preset configuration table, and determine whether the customer number of the key customer is present in the configuration table, or...

[0020] Obtain the tax-exclusive amount of the orders corresponding to the key customers, and determine whether the tax-exclusive amount of the orders is greater than a preset amount threshold, or...

[0021] Obtain the shipping date of the orders corresponding to the key customers, and determine whether the shipping date of the orders is greater than the preset number of days since the order creation date;

[0022] If the customer number of the key customer is in the configuration table, or if the tax-exclusive amount of the order is greater than a preset amount threshold, or if the delivery date of the order is greater than a preset number of days from the order creation date, it is determined that the order of the key customer needs to be reviewed.

[0023] In a preferred embodiment, this application can be further configured to include the following steps:

[0024] If the customer number of the key customer does not appear in the configuration table, or if the tax-exclusive amount of the order is less than or equal to a preset amount threshold, or if the delivery date of the order is less than or equal to a preset number of days from the order creation date, it is determined that the order of the key customer does not require review. At this time, it is determined whether the payment method of the order of the key customer is online payment.

[0025] If the order payment method of the key customer is not online payment, a credit check will be conducted;

[0026] Once the credit check of the key customer is passed, the shipping warehouse will be determined.

[0027] In a preferred embodiment, this application can be further configured such that, if the order payment method for the key customer is not online payment, the credit check step includes,

[0028] Obtain the credit limit and payment period days of the key customers;

[0029] If the credit limit meets the preset requirements and the payment period meets the preset number of days, then the credit check of the key customer is passed.

[0030] In a preferred embodiment, this application can be further configured such that the step of dynamically matching the business execution rule based on the user type includes,

[0031] Based on the user type, the basic feature values ​​are obtained;

[0032] Based on the basic feature values ​​and the corresponding order data, additional feature values ​​are obtained;

[0033] By statistically analyzing the basic feature values ​​and the additional feature values, matching feature values ​​are obtained.

[0034] A preset matching threshold is set for the business execution rule. The matching feature value is compared with each matching threshold to determine the business execution rule that meets the conditions.

[0035] In a preferred embodiment, this application can be further configured such that the step of obtaining matching feature values ​​by statistically analyzing the basic feature values ​​and the additional feature values ​​includes,

[0036] When calculating the additional feature values, the values ​​include the initial additional feature values ​​and the probability values ​​corresponding to the additional attributes, and the additional feature values ​​increase as the probability values ​​increase.

[0037] The basic feature value and the additional feature value are added together to obtain the matching feature value.

[0038] In a preferred embodiment, this application can be further configured such that the step of comparing the matching feature value with each matching threshold to determine the business execution rule that meets the conditions includes:

[0039] The matching feature value is compared with each matching threshold to determine whether the matching feature value is within any of the matching thresholds;

[0040] If the matching feature value is within any of the matching thresholds, the business execution rule corresponding to the matching threshold is matched.

[0041] In a preferred embodiment, this application can be further configured to include the following steps:

[0042] If the matching feature value is outside each of the matching thresholds, then the highest priority business execution rule is matched according to the preset priority.

[0043] Secondly, this application provides a rule engine execution device for different business scenarios.

[0044] This application is achieved through the following technical solution:

[0045] A rule engine execution device for different business scenarios, including,

[0046] The business execution rules module is used to preset business execution rules at various nodes in different business scenarios;

[0047] The type identifier module is used to obtain order data containing preset type identifiers;

[0048] The user type module is used to determine the user type corresponding to the order data based on the type identifier;

[0049] The dynamic matching module is used to dynamically match the business execution rules based on the user type, and to configure the corresponding customer channels.

[0050] In a preferred embodiment, this application can be further configured such that the business execution rule module includes,

[0051] The Key Customers submodule is used to determine whether an order needs to be approved when the user type is a key customer.

[0052] The foreign enterprise sub-module is used to first embed the business system into the user's own system before determining the shipping warehouse when the user type is a foreign enterprise.

[0053] The "Regular Customer" submodule is used to redirect users to the official website before they can determine the shipping warehouse when the user type is "regular customer".

[0054] The proprietary payment system customer submodule is used to first export valid order information from the user's proprietary system to the business system before determining the shipping warehouse when the user type is a proprietary payment system customer.

[0055] In a preferred embodiment, this application can be further configured such that the key customer submodule includes,

[0056] The first judgment unit is used to obtain a preset configuration table and determine whether the customer number of the key customer is located in the configuration table;

[0057] The second judgment unit is used to obtain the tax-exclusive amount of the order corresponding to the key customer and to determine whether the tax-exclusive amount of the order is greater than a preset amount threshold.

[0058] The third judgment unit is used to obtain the shipping date of the order corresponding to the key customer and to determine whether the shipping date of the order is greater than the preset number of days since the order creation date;

[0059] The order review unit is used to determine that the orders of key customers need to be reviewed when the customer number of the key customer is in the configuration table, or when the tax-exclusive amount of the order is greater than a preset amount threshold, or when the delivery date of the order is greater than a preset number of days from the order creation date.

[0060] In a preferred embodiment, this application can be further configured such that the key customer submodule also includes,

[0061] The fourth judgment unit is used to determine that the order of the key customer does not need to be reviewed if the customer number of the key customer does not appear in the configuration table, or the amount of the order excluding tax is less than or equal to a preset amount threshold, or the delivery date of the order is less than or equal to a preset number of days from the order creation date. At this time, it is determined whether the payment method of the order of the key customer is online payment.

[0062] The fifth judgment unit is used to perform a credit check when the order payment method of the key customer is not online payment, and then determine the shipping warehouse when the credit check of the key customer is passed.

[0063] In a preferred embodiment, this application can be further configured such that the key customer submodule also includes,

[0064] The credit review unit is used to obtain the credit limit and payment period of the key customer, and confirm that the credit check of the key customer has passed when the credit limit meets the preset requirements and the payment period meets the preset number of days.

[0065] In a preferred embodiment, this application can be further configured such that the dynamic matching module includes,

[0066] The basic feature submodule is used to obtain basic feature values ​​based on the user type;

[0067] The additional feature submodule is used to obtain additional feature values ​​based on the basic feature values ​​and the corresponding order data;

[0068] The matching feature submodule is used to statistically analyze the basic feature values ​​and the additional feature values ​​to obtain matching feature values;

[0069] The matching submodule is used to preset the matching threshold of the business execution rule, compare the matching feature value with each matching threshold, and determine the business execution rule that meets the conditions.

[0070] In a preferred embodiment, this application can be further configured such that the dynamic matching module also includes,

[0071] An additional feature unit is used to statistically analyze the additional feature values, including initial additional feature values ​​and probability values ​​corresponding to additional attributes, wherein the additional feature values ​​increase as the probability values ​​increase;

[0072] The matching unit is used to add the basic feature value and the additional feature value to obtain the matching feature value.

[0073] In a preferred embodiment, this application can be further configured such that the matching submodule includes,

[0074] The comparison unit is used to compare the matching feature value with each matching threshold, determine whether the matching feature value is within any of the matching thresholds, and if the matching feature value is within any of the matching thresholds, match the business execution rule corresponding to the matching threshold.

[0075] In a preferred embodiment, this application may be further configured to include:

[0076] The static matching module, if the matching feature value is outside each of the matching thresholds, then matches the highest priority business execution rule according to the preset priority.

[0077] Thirdly, this application provides a computer device.

[0078] This application is achieved through the following technical solution:

[0079] A computer device 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 steps of the rule engine execution method for any of the different business scenarios described above.

[0080] Fourthly, this application provides a computer-readable storage medium.

[0081] This application is achieved through the following technical solution:

[0082] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the rule engine execution method for any of the different business scenarios described above.

[0083] In summary, compared with the prior art, the beneficial effects of the technical solution provided in this application include at least the following:

[0084] Business execution rules are preset at various nodes in different business scenarios, and then customized for orders from different channels such as the official website, Tmall, JD.com, smart lockers, and corporate websites. This makes the rule engine more applicable to different business scenarios. Order data containing preset type identifiers is obtained. Based on the type identifiers, the user type corresponding to the order data is determined. Based on the user type, the business execution rules are dynamically matched, and the corresponding customer channels are configured. This realizes automated matching of business execution rules, and only the customer channels need to be configured, simplifying the configuration process. The rule engine has greater applicability and effectively improves the order processing efficiency of the business system. Attached Figure Description

[0085] Figure 1 This is a schematic diagram of the main flow of a rule engine execution method for different business scenarios, provided as an exemplary embodiment of this application.

[0086] Figure 2 This is another exemplary embodiment of the present application, providing a flowchart of a rule engine execution method for different business scenarios, which presets business execution rules in different business scenarios.

[0087] Figure 3 A flowchart of an order review process for a rule engine execution method in a different business scenario, provided as another exemplary embodiment of this application.

[0088] Figure 4 This is a flowchart illustrating the dynamic matching of business execution rules in a rule engine execution method for different business scenarios, provided as an exemplary embodiment of this application.

[0089] Figure 5 This is a flowchart illustrating a rule engine execution method for different business scenarios based on matching feature values, provided as an exemplary embodiment of this application.

[0090] Figure 6 This is a structural block diagram of a rule engine execution device for different business scenarios, provided as an exemplary embodiment of this application. Detailed Implementation

[0091] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of this application.

[0092] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0093] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0094] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0095] Reference Figure 1 This application provides a rule engine execution method for different business scenarios. The main steps of the method are described below.

[0096] S1: Pre-set business execution rules at each node in different business scenarios;

[0097] S2: Retrieve order data containing preset type identifiers;

[0098] S3: Based on the type identifier, determine the user type corresponding to the order data;

[0099] S4: Based on the user type, dynamically match the business execution rules and configure the corresponding customer channels.

[0100] Specifically, based on the order processing workflow of the business system across different channels such as the official website, Tmall, JD.com, smart lockers, and corporate websites, the corresponding business execution rules are optimized and analyzed. When the business system is running normally, business execution rules are preset at various nodes in different business scenarios to allow for customized design of business execution rules for different scenarios. This enables the rule engine to adapt to various business scenarios, making it more versatile. The business execution rules are stored in a rule base, completely independent of the program.

[0101] Predefined type identifiers are used to distinguish user types. User types include key customer APIs, foreign enterprise GPSs, general customers, customers with proprietary payment systems, etc. Different user types have different type identifiers.

[0102] Based on the type identifier, determine the user type corresponding to the order data.

[0103] Based on user type, business execution rules are dynamically matched, and corresponding customer channels are configured to automatically match business execution rules.

[0104] In one embodiment, for orders from key customer API channels, during the execution of the rules engine, since API customers place orders using customer subheadings (i.e., customer names), if these customer subheadings are not pre-created in our customer management system, an abnormal situation will occur where the order cannot be matched with the corresponding customer and salesperson. Therefore, we adopt a method of periodically querying and binding orders with customer numbers, such as querying daily and calling our customer management system to obtain the latest customer list information, and periodically creating customer subheading information so that the customer subheadings correspond one-to-one with our customer numbers and salespersons.

[0105] Reference Figure 2 In one embodiment, the user types include key customers, foreign enterprises, ordinary customers, and customers with proprietary payment systems. S1: The step of presetting business execution rules at various nodes in different business scenarios includes...

[0106] S11: If it is a key customer, first determine whether the order needs to be reviewed;

[0107] S12: If it is a foreign company, the business system should be integrated into the user's own system first, and then the shipping warehouse should be determined.

[0108] S13: If you are a regular customer, you will be redirected to the official website page first to confirm the shipping warehouse;

[0109] S14: If the customer has their own payment system, the valid order information should be exported from the user's own system to the business system before the shipping warehouse is determined.

[0110] User types include key customer APIs, foreign enterprise GPSs, general customers, and customers with their own payment systems. Corresponding business execution rules are set based on different user types.

[0111] If the user type is determined to be a key customer, then first determine whether the order needs to be reviewed;

[0112] If the user type is determined to be a foreign enterprise, the business system will be integrated into the user's own system first, and then the shipping warehouse will be determined.

[0113] If the user type is determined to be a regular customer, the user will be redirected to the official website before the shipping warehouse is determined.

[0114] If the user type is determined to be a customer with their own payment system, then the valid order information is first exported from the user's own system to the business system before the shipping warehouse is determined.

[0115] In one embodiment, the step of first determining whether an order requires review includes:

[0116] Obtain a preset configuration table, and determine whether the customer number of the key customer is present in the configuration table, or...

[0117] Obtain the tax-exclusive amount of the orders corresponding to the key customers, and determine whether the tax-exclusive amount of the orders is greater than a preset amount threshold, or...

[0118] Obtain the shipping date of the orders corresponding to the key customers, and determine whether the shipping date of the orders is greater than the preset number of days since the order creation date;

[0119] If the customer number of the key customer is in the configuration table, or if the tax-exclusive amount of the order is greater than a preset amount threshold, or if the delivery date of the order is greater than a preset number of days from the order creation date, it is determined that the order of the key customer needs to be reviewed.

[0120] Specifically, the configuration table is the customer CSR configuration table stored in the business system. The system queries the customer CSR configuration table to determine if the customer ID of a key customer is present in the table.

[0121] The system retrieves the tax-exclusive amount of orders placed by key customers and determines whether this amount exceeds a preset threshold. In this embodiment, the preset threshold can be 10,000.

[0122] Obtain the shipping date of orders placed by key customers and determine if the shipping date is more than a preset number of days from the order creation date. For example, determine if the key customer requires a shipping date more than 30 days from the order creation date.

[0123] When a key customer's customer number is in the configuration table, the order's tax-exclusive amount is greater than a preset amount threshold, or the order's shipping date is greater than a preset number of days since the order's creation date, then the order for a key customer is deemed to require review.

[0124] Reference Figure 3 The order review process includes:

[0125] Query the customer's CSR configuration table to verify whether master data auditing is required.

[0126] If master data review is required, determine whether the contact person needs authorization; if master data review is not required, verify whether the customer is a special customer; if the customer is a special customer, determine whether the contact person needs authorization; if the customer is not a special customer, complete the order review.

[0127] When the contact person does not require authorization, check if the invoice information has been modified; when the contact person requires authorization, mark the contact person as needing authorization, and then check if the invoice information has been modified.

[0128] If the invoice information has not been modified, check whether the customer package is frozen; if the invoice information has been modified, mark the invoice information as modified, and then check whether the customer package is frozen.

[0129] When the customer package is not frozen, check if the contact person is empty; when the customer package is frozen, mark the customer package as frozen, and then check if the contact person is empty.

[0130] If the contact person is not empty, the order review is completed; if the contact person is empty, the contact person is marked as empty, and then the order review is completed.

[0131] In one embodiment, the following steps are also included:

[0132] If the customer number of the key customer does not appear in the configuration table, or if the tax-exclusive amount of the order is less than or equal to a preset amount threshold, or if the delivery date of the order is less than or equal to a preset number of days from the order creation date, it is determined that the order of the key customer does not require review. At this time, it is determined whether the payment method of the order of the key customer is online payment.

[0133] If the order payment method of the key customer is not online payment, a credit check will be conducted;

[0134] Once the credit check of the key customer is passed, the shipping warehouse will be determined.

[0135] In one embodiment, if the order payment method of the key customer is not online payment, the credit check step includes:

[0136] Obtain the credit limit and payment period days of the key customers;

[0137] If the credit limit meets the preset requirements and the payment period meets the preset number of days, then the credit check of the key customer is passed.

[0138] Specifically, when a customer's order does not require review, the system first determines whether the payment method is online. In this embodiment, online payment refers to full payment, while offline payment refers to prepayment or credit payment.

[0139] If the order payment method for this key customer is online payment, i.e., payment in advance and delivery in advance, then the CRM credit limit occupation interface is called to determine the shipping warehouse and synchronize with SAP, and then the CRM credit limit release interface is called to complete the rule engine execution, without the need for credit checks.

[0140] If the order payment method for this key customer is not online, a credit check will be conducted, including obtaining the key customer's credit limit and payment period days.

[0141] If the credit limit meets the preset requirements and the payment period meets the preset number of days, the credit check of the key customer is passed. At this time, the CRM credit limit occupation interface is called to determine the shipping warehouse and synchronize with SAP. Then, the CRM credit limit release interface is called to complete the execution of the rule engine.

[0142] If the credit limit is insufficient, or the payment period exceeds the preset number of days, the application will be transferred to the finance department for manual review.

[0143] If the financial review is approved, the CRM quota usage interface is called to determine the shipping warehouse and synchronize with SAP. Then, the CRM quota release interface is called to complete the execution of the rule engine.

[0144] If the financial review fails, the order will be rejected and cancelled.

[0145] In one embodiment, during order selection, some abnormal data issues may cause selection failure, resulting in the order status remaining in "system warehouse adjustment". In response to this abnormal situation, the rule engine will periodically check whether there are any orders in the system that have been in the "order warehouse selection" state for a long time. If so, it will send a message to the relevant operations and maintenance personnel, who will intervene in a timely manner to check whether there are any abnormalities in the order data and ensure that the order is selected from the correct warehouse.

[0146] Reference Figure 4 In one embodiment, S4: the step of dynamically matching the service execution rules based on the user type includes,

[0147] S41: Based on the user type, obtain the basic feature values;

[0148] S42: Based on the basic feature values ​​and the corresponding order data, additional feature values ​​are obtained;

[0149] S43: Calculate the basic feature values ​​and the additional feature values ​​to obtain the matching feature values;

[0150] S44: Preset the matching threshold of the business execution rule, compare the matching feature value with each matching threshold, and determine the business execution rule that meets the conditions.

[0151] Specifically, different user types have different type identifiers and corresponding basic characteristic values. Basic characteristic values ​​are pre-set for each type identifier.

[0152] User type is determined based on type identifier, and corresponding basic characteristic value is determined based on user type. For example, the basic characteristic value for key customers is 5, the basic characteristic value for foreign enterprise GPS is 3, the basic characteristic value for ordinary customers is 1, and the basic characteristic value for customers with proprietary payment systems is 2.

[0153] Based on the basic feature values ​​and the corresponding order data, additional feature values ​​are obtained. These additional feature values ​​are calculated as follows: Customer Attribute Value + Order Value + Delivery Time Limit.

[0154] For example, based on the order data of key customers, the additional characteristic value of the user is determined to be customer attribute value 5 + order value 8 + delivery time limit 2 = 15.

[0155] The basic and additional feature values ​​are statistically analyzed, and the sum of the basic and additional feature values ​​is used as the predicted matching feature value.

[0156] The system pre-defines the matching thresholds corresponding to the business execution rules of each node in different business scenarios, and each matching threshold has a one-to-one mapping relationship with each business execution rule.

[0157] The predicted matching feature values ​​are compared with each matching threshold to determine the business execution rules that meet the conditions, so as to realize the dynamic matching of business execution rules for different business scenarios. The matching strategy changes with the user type and order data, which can better characterize the business execution rules to be executed when the order process calls the rule engine, enhance the applicability of the rule engine, and improve the order processing efficiency of the business system.

[0158] In one embodiment, the step of obtaining matching feature values ​​by statistically analyzing the basic feature values ​​and the additional feature values ​​includes:

[0159] When calculating the additional feature values, the values ​​include the initial additional feature values ​​and the probability values ​​corresponding to the additional attributes, and the additional feature values ​​increase as the probability values ​​increase.

[0160] The basic feature value and the additional feature value are added together to obtain the matching feature value.

[0161] Specifically, the additional feature values ​​include the initial additional feature values ​​and the probability values ​​corresponding to the additional attributes. The probability values ​​corresponding to the additional attributes are obtained by learning and predicting based on historical order data, such as user ID, ordered products, models and quantities, and order dates, using a logistic regression algorithm.

[0162] The additional eigenvalue increases as the probability value increases. Additional eigenvalue = initial additional eigenvalue + n * probability value corresponding to the additional attribute, where n is a positive integer. In this embodiment, n can be 2.

[0163] The matching feature value is obtained by adding the basic feature value and the initial additional feature value. That is, the matching feature value = basic feature value + initial additional feature value + n * probability value corresponding to the additional attribute.

[0164] Reference Figure 5 In one embodiment, S44: The step of comparing the matching feature value with each matching threshold to determine the service execution rule that meets the conditions includes,

[0165] S441: Compare the matching feature value with each matching threshold to determine whether the matching feature value is within any of the matching thresholds;

[0166] S442: If the matching feature value is within any of the matching thresholds, match the business execution rule corresponding to the matching threshold.

[0167] By predicting the matching feature value of each order data and comparing it with the preset matching threshold based on the matching threshold corresponding to the business execution rules of each node in different business scenarios, it is determined whether the matching feature value is within any matching threshold.

[0168] If the matching feature value is within any matching threshold, the corresponding business execution rule is matched, thus realizing dynamic matching of business execution rules for different business scenarios.

[0169] In one embodiment, the following steps are also included:

[0170] S443: If the matching feature value is outside each of the matching thresholds, then the highest priority business execution rule is matched according to the preset priority.

[0171] By using a pre-defined priority business execution strategy table, matching feature values ​​can be matched with business execution rules under different priorities. In this embodiment, a static matching strategy is adopted to match the highest priority business execution rule corresponding to the matching feature value, in order to improve the problem of no matching results from the rule engine when the predicted matching feature value is outside each matching threshold, and further enhance the applicability of the rule engine execution scheme.

[0172] In summary, a rule engine execution method for different business scenarios pre-sets business execution rules at various nodes in different business scenarios, thereby customizing the business execution rules for orders from different channels such as the official website, Tmall, JD.com, smart lockers, and corporate websites. This makes the rule engine applicable to different business scenarios and more versatile. The method acquires order data containing pre-set type identifiers, determines the user type corresponding to the order data based on the type identifiers, dynamically matches the business execution rules based on the user type, and configures the corresponding customer channels. This achieves automated matching of business execution rules, and only requires configuring the customer channels, simplifying the configuration process. The rule engine is more versatile and effectively improves the order processing efficiency of the business system. It can dynamically match corresponding business execution rules for different business scenarios, making it more versatile; it simplifies the configuration process, improves order processing efficiency, and enhances the user's order placement experience.

[0173] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0174] Reference Figure 6 This application also provides a rule engine execution device for different business scenarios, which corresponds one-to-one with the rule engine execution method for different business scenarios in the above embodiments. The rule engine execution device for different business scenarios includes...

[0175] The business execution rules module is used to preset business execution rules at various nodes in different business scenarios;

[0176] The type identifier module is used to obtain order data containing preset type identifiers;

[0177] The user type module is used to determine the user type corresponding to the order data based on the type identifier;

[0178] The dynamic matching module is used to dynamically match the business execution rules based on the user type, and to configure the corresponding customer channels.

[0179] Furthermore, the business execution rule module includes,

[0180] The Key Customers submodule is used to determine whether an order needs to be approved when the user type is a key customer.

[0181] The foreign enterprise sub-module is used to first embed the business system into the user's own system before determining the shipping warehouse when the user type is a foreign enterprise.

[0182] The "Regular Customer" submodule is used to redirect users to the official website before they can determine the shipping warehouse when the user type is "regular customer".

[0183] The proprietary payment system customer submodule is used to first export valid order information from the user's proprietary system to the business system before determining the shipping warehouse when the user type is a proprietary payment system customer.

[0184] Furthermore, the key customer submodule includes,

[0185] The first judgment unit is used to obtain a preset configuration table and determine whether the customer number of the key customer is located in the configuration table;

[0186] The second judgment unit is used to obtain the tax-exclusive amount of the order corresponding to the key customer and to determine whether the tax-exclusive amount of the order is greater than a preset amount threshold.

[0187] The third judgment unit is used to obtain the shipping date of the order corresponding to the key customer and to determine whether the shipping date of the order is greater than the preset number of days since the order creation date;

[0188] The order review unit is used to determine that the orders of key customers need to be reviewed when the customer number of the key customer is in the configuration table, or when the tax-exclusive amount of the order is greater than a preset amount threshold, or when the delivery date of the order is greater than a preset number of days from the order creation date.

[0189] Furthermore, the key customer submodule also includes,

[0190] The fourth judgment unit is used to determine that the order of the key customer does not need to be reviewed if the customer number of the key customer does not appear in the configuration table, or the amount of the order excluding tax is less than or equal to a preset amount threshold, or the delivery date of the order is less than or equal to a preset number of days from the order creation date. At this time, it is determined whether the payment method of the order of the key customer is online payment.

[0191] The fifth judgment unit is used to perform a credit check when the order payment method of the key customer is not online payment, and then determine the shipping warehouse when the credit check of the key customer is passed.

[0192] Furthermore, the key customer submodule also includes,

[0193] The credit review unit is used to obtain the credit limit and payment period of the key customer, and confirm that the credit check of the key customer has passed when the credit limit meets the preset requirements and the payment period meets the preset number of days.

[0194] Furthermore, the dynamic matching module includes,

[0195] The basic feature submodule is used to obtain basic feature values ​​based on the user type;

[0196] The additional feature submodule is used to obtain additional feature values ​​based on the basic feature values ​​and the corresponding order data;

[0197] The matching feature submodule is used to statistically analyze the basic feature values ​​and the additional feature values ​​to obtain matching feature values;

[0198] The matching submodule is used to preset the matching threshold of the business execution rule, compare the matching feature value with each matching threshold, and determine the business execution rule that meets the conditions.

[0199] Furthermore, the dynamic matching module also includes,

[0200] An additional feature unit is used to statistically analyze the additional feature values, including initial additional feature values ​​and probability values ​​corresponding to additional attributes, wherein the additional feature values ​​increase as the probability values ​​increase;

[0201] The matching unit is used to add the basic feature value and the additional feature value to obtain the matching feature value.

[0202] Furthermore, the matching submodule includes,

[0203] The comparison unit is used to compare the matching feature value with each matching threshold, determine whether the matching feature value is within any of the matching thresholds, and if the matching feature value is within any of the matching thresholds, match the business execution rule corresponding to the matching threshold.

[0204] Furthermore, a rule engine execution device for different business scenarios also includes,

[0205] The static matching module, if the matching feature value is outside each of the matching thresholds, then matches the highest priority business execution rule according to the preset priority.

[0206] For specific limitations regarding the rule engine execution device for a different business scenario, please refer to the limitations on the rule engine execution method for a different business scenario mentioned above, which will not be repeated here. Each module in the aforementioned rule engine execution device for a different business scenario can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0207] In one embodiment, a computer device is provided, which may be a server. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a rule engine execution method for any of the different business scenarios described above.

[0208] In one embodiment, a computer-readable storage medium is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0209] S1: Pre-set business execution rules at each node in different business scenarios;

[0210] S2: Retrieve order data containing preset type identifiers;

[0211] S3: Based on the type identifier, determine the user type corresponding to the order data;

[0212] S4: Based on the user type, dynamically match the business execution rules and configure the corresponding customer channels.

[0213] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0214] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

Claims

1. A method for executing rules engine for different service scenarios, characterized in that, The method comprises the following steps, presetting business execution rules at each node of different business scenarios; obtaining order data containing a preset type identifier; determining a user type corresponding to the order data based on the type identifier; dynamically matching the business execution rules based on the user type, and configuring a corresponding customer channel; wherein the step of dynamically matching the business execution rules based on the user type comprises, obtaining a basic feature value based on the user type; obtaining an additional feature value according to the basic feature value and the corresponding order data; statistically obtaining a matching feature value from the basic feature value and the additional feature value; presetting a matching threshold of the business execution rules, comparing the matching feature value with each matching threshold, and determining the business execution rules that meet the conditions.

2. The method of claim 1, wherein the different service scenarios are determined by a service type of the UE. The user types include key customers, foreign enterprises, ordinary customers, and customers with self-payment systems. The step of presetting business execution rules at each node of different business scenarios comprises, if the customer is a key customer, first determine whether the order needs to be audited; if the customer is a foreign enterprise, first implant the business system into the user's own system to determine the delivery warehouse; if the customer is an ordinary customer, first jump to the official website page to determine the delivery warehouse; if the customer is a customer with a self-payment system, first export valid order information from the user's own system to the business system to determine the delivery warehouse.

3. The method of claim 2, wherein, The step of first determining whether the order needs to be audited comprises, obtaining a preset configuration table to determine whether the customer number of the key customer is in the configuration table, or obtaining the tax-free amount of the order corresponding to the key customer to determine whether the tax-free amount of the order is greater than a preset amount threshold, or obtaining the delivery date of the order corresponding to the key customer to determine whether the delivery date of the order is greater than a preset number of days from the order creation date; when the customer number of the key customer is in the configuration table, or the tax-free amount of the order is greater than the preset amount threshold, or the delivery date of the order is greater than the preset number of days from the order creation date, it is determined that the order of the key customer needs to be audited.

4. The method of claim 3, wherein the different service scenarios are determined by a service type of the service request. The method further comprises the following steps, when the customer number of the key customer does not appear in the configuration table, or the tax-free amount of the order is less than or equal to the preset amount threshold, or the delivery date of the order is less than or equal to the preset number of days from the order creation date, it is determined that the order of the key customer does not need to be audited, and at this time it is determined whether the payment method of the order of the key customer is online payment; if the payment method of the order of the key customer is offline payment, credit checking is performed; when the credit checking of the key customer is passed, the delivery warehouse is determined.

5. The method of claim 4, wherein, The step of performing credit checking if the payment method of the order of the key customer is offline payment comprises, obtaining the credit limit and account period of the key customer; if the credit limit meets the preset requirement and the account period meets the preset number of days, the credit checking of the key customer is passed.

6. The method of claim 1, wherein the different service scenarios are determined based on a service type of the service request. The step of statistically obtaining a matching feature value from the basic feature value and the additional feature value comprises, The additional characteristic value is counted, including the initial additional characteristic value and the probability value corresponding to the additional attribute, and the additional characteristic value increases with the increase of the probability value; The matching characteristic value is obtained by adding the basic characteristic value and the additional characteristic value.

7. The method of claim 1, wherein the method further comprises: The step of comparing the matching characteristic value with each matching threshold to determine the business execution rule that meets the condition includes, The matching characteristic value is compared with each matching threshold to determine whether the matching characteristic value is within any of the matching thresholds; If the matching characteristic value is within any of the matching thresholds, the business execution rule corresponding to the matching threshold is matched.

8. The method of claim 7, wherein the different service scenarios are determined by a service type of the UE. Further comprising the steps of, If the matching characteristic value is outside each of the matching thresholds, the business execution rule with the highest priority is matched according to the preset priority.

9. A rule engine execution apparatus for different service scenarios, characterized in that, Including, A business execution rule module is configured to preset business execution rules on each node of different business scenarios; A type identification module is configured to obtain order data containing a preset type identification; A user type module is configured to determine a user type corresponding to the order data based on the type identification; A dynamic matching module is configured to dynamically match the business execution rules based on the user type and configure corresponding customer channels; wherein the dynamic matching module includes, A basic characteristic sub-module is configured to obtain a basic characteristic value based on the user type; An additional characteristic sub-module is configured to obtain an additional characteristic value based on the basic characteristic value and the corresponding order data; A matching characteristic sub-module is configured to count the basic characteristic value and the additional characteristic value to obtain a matching characteristic value; A matching sub-module is configured to preset matching thresholds of the business execution rules, compare the matching characteristic value with each matching threshold, and determine the business execution rule that meets the condition.

10. The apparatus of claim 9, wherein, The business execution rule module includes, A VIP sub-module is configured to determine whether an order needs to be audited when the user type is a VIP; An overseas enterprise sub-module is configured to implant a business system into a user's own system to determine a delivery warehouse when the user type is an overseas enterprise; A general customer sub-module is configured to jump to an official website page to determine a delivery warehouse when the user type is a general customer; An own payment system customer sub-module is configured to export valid order information from a user's own system to a business system to determine a delivery warehouse when the user type is an own payment system customer.

11. The apparatus of claim 10, wherein, The VIP sub-module includes, A first judgment unit is configured to obtain a preset configuration table and determine whether the customer number of the VIP is in the configuration table; A second judgment unit is configured to obtain the order tax-free amount corresponding to the VIP and determine whether the order tax-free amount is greater than a preset amount threshold; A third judgment unit is configured to obtain the delivery date of the order corresponding to the VIP and determine whether the delivery date of the order is greater than a preset number of days from the order creation date. The order auditing unit is configured to determine that the order of the VIP customer needs to be audited when the customer number of the VIP customer is located in the configuration table, or the tax-free amount of the order is greater than a preset amount threshold, or the delivery date of the order is greater than a preset number of days from the order creation date.

12. The apparatus of claim 11, wherein, The VIP customer sub-module further includes, The fourth judging unit is configured to determine that the order of the VIP customer does not need to be audited when the customer number of the VIP customer does not appear in the configuration table, or the tax-free amount of the order is less than or equal to the preset amount threshold, or the delivery date of the order is less than or equal to the preset number of days from the order creation date, and then determine whether the payment method of the order of the VIP customer is online payment. The fifth judging unit is configured to perform credit check when the payment method of the order of the VIP customer is offline payment, and then determine the delivery warehouse when the credit check of the VIP customer is passed.

13. The apparatus of claim 12, wherein, The VIP customer sub-module further includes, The credit auditing unit is configured to obtain the credit limit and the account period of the VIP customer, and determine that the credit check of the VIP customer is passed when the credit limit meets a preset requirement and the account period meets a preset number of days.

14. The apparatus of claim 9, wherein, The dynamic matching module further includes, The additional feature unit is configured to count the additional feature value, including the initial additional feature value and the probability value corresponding to the additional attribute, and the additional feature value increases with the increase of the probability value. The matching unit is configured to add the basic feature value and the additional feature value to obtain the matching feature value.

15. The apparatus of claim 9, wherein, The matching sub-module includes, The comparing unit is configured to compare the matching feature value with each matching threshold, determine whether the matching feature value is located within any of the matching thresholds, and match the business execution rule corresponding to the matching threshold when the matching feature value is located within any of the matching thresholds.

16. The apparatus of claim 15, wherein, Further includes, The static matching module is configured to match the business execution rule with the highest priority according to a preset priority when the matching feature value is located outside each of the matching thresholds.

17. A computer device, comprising: The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 8.

Images