Message processing method and system based on rule engine

Abstract

The invention is suitable for the technical field of message processing, and provides a message processing method and system based on a rule engine, and the method comprises the steps: receiving a message event from asynchronous message middleware after a responsibility chain processing engine in a message center core service is started, a message processing flow comprising a plurality of processors is driven to be executed according to a preset sequence; wherein the responsibility chain processing engine comprises a receiver verification processor, a rule engine routing decision processor, a message copywriting generation processor and a sending task creation processor; determining a target receiving user list through a receiver verification processor according to the message type and the service identifier in the message event; calling a rule engine for each user in the target receiving user list through a rule engine routing decision processor, and generating an ordered channel sequence of each user based on the message event; through a message copywriting generation processor, generating message copywriting corresponding to different channels according to the ordered channel sequence and the message template parameters of each user; creating a sending task containing a channel identifier for each user based on the message copywriting and the corresponding ordered channel sequence through a sending task creation processor; and calling the channel adaptation layer, and executing the sending task. The message reaching success rate and the user experience are improved, the maintenance cost of the system is reduced, and the iteration efficiency and the expansibility are improved.

Description

Technical Field

[0001] This application belongs to the field of message processing technology, and in particular relates to a message processing method and system based on a rule engine. Background Technology

[0002] In existing technologies, message processing systems serve as a core bridge connecting services and users, undertaking diverse information delivery tasks ranging from business alerts and order notifications to marketing campaigns. However, existing technologies generally face numerous challenges in achieving efficient, reliable, and easy-to-maintain message delivery.

[0003] First, many systems' message routing strategies—the decision logic for choosing which channel (e.g., in-app push, SMS, email) to send messages to users—are typically implemented using hard-coded or simple conditional logic. This approach results in tight coupling between routing rules and business code, leading to rigid routing strategies and difficulty in achieving differentiated channel selection. Second, multiple steps in message processing (such as determining the recipient, validation, channel decision, and message generation) are often integrated into a single service, forming a tightly coupled monolithic architecture. This architecture results in poor scalability and maintainability when adding new processing steps or modifying existing logic. Summary of the Invention

[0004] This application provides a message processing method and system based on a rule engine, which can solve the technical problems of rigid routing decisions, highly coupled processing flow, and difficulty in maintaining and expanding the system in existing message processing systems.

[0005] In a first aspect, embodiments of this application provide a message processing method based on a rules engine, including:

[0006] After the chain of responsibility processing engine in the core service of the message center starts, it receives message events from the asynchronous message middleware and drives the message processing flow containing multiple processors to be executed in a predetermined order; wherein, the chain of responsibility processing engine includes a receiver verification processor, a rule engine routing decision processor, a message text generation processor, and a sending task creation processor.

[0007] The receiver verification processor determines the target receiving user list based on the message type and service identifier in the message event.

[0008] The rule engine routing decision processor invokes the rule engine for each user in the target receiving user list to generate an ordered channel sequence for each user based on the message event.

[0009] The message text generation processor generates message texts corresponding to different channels based on each user's ordered channel sequence and message template parameters.

[0010] The sending task creation processor creates a sending task containing a channel identifier for each user based on the message text and the corresponding ordered channel sequence.

[0011] Invoke the channel adaptation layer to execute the sending task.

[0012] In one possible implementation of the first aspect, after the chain of responsibility processing engine in the message center core service starts, receiving message events from the asynchronous message middleware, the process further includes:

[0013] When a business event occurs, the business triggering end constructs a message event containing the message type, the business identifier, and the message template parameters, and publishes the message event to the asynchronous message middleware;

[0014] The message center core service consumes the message events from the asynchronous message middleware and triggers the chain of responsibility processing engine to start.

[0015] In one possible implementation of the first aspect, the chain of responsibility processing engine further includes a user profile query processor; the method further includes:

[0016] The user profile query processor can be used to query the profile data of each user in the target receiving user list in batches.

[0017] The step of using the rule engine routing decision processor to invoke the rule engine for each user in the target receiving user list, and generating an ordered channel sequence for each user based on the message event, includes:

[0018] The rule engine routing decision processor calls the rule engine for each user in the target receiving user list, and generates an ordered channel sequence for each user based on the message event and the profile data of each user.

[0019] The step of generating message text corresponding to different channels through the message text generation processor, based on each user's ordered channel sequence and message template parameters, includes:

[0020] The message copy generation processor generates message copy corresponding to different channels based on each user's ordered channel sequence, profile data, and message template parameters.

[0021] In one possible implementation of the first aspect, determining the target receiving user list through the receiver verification processor based on the message type and service identifier in the message event includes:

[0022] The receiver verification processor queries the pre-configured mapping relationship based on the message type to obtain the corresponding business parser identifier.

[0023] Invoke the service parser corresponding to the service parser identifier and pass the service identifier to the service parser;

[0024] The service parser executes a service query associated with the message type and returns a set of user identifiers obtained based on the service identifier, thereby forming the target receiving user list.

[0025] In one possible implementation of the first aspect, the business query executed by the business parser includes at least one of the following:

[0026] If the message type indicates a device alarm, then query the device service to obtain the device associated party identifier corresponding to the service identifier;

[0027] If the message type indicates a change in order status, then query the order service to obtain the order user identifier corresponding to the business identifier;

[0028] If the message type represents a marketing campaign, then query the marketing platform to obtain the preset user group identifier corresponding to the business identifier;

[0029] The device associated party identifier, the order-placing user identifier, and the preset user group identifier constitute the user identifier set.

[0030] In one possible implementation of the first aspect, the step of invoking the rule engine for each user in the target receiving user list through the rule engine routing decision processor, and generating an ordered channel sequence for each user based on the message event, includes:

[0031] Based on the rule engine routing decision processor, a decision fact object containing the user's profile data and the message event is created for each user;

[0032] The decision fact objects for multiple users will be provided to the rule engine;

[0033] Based on the rule engine, each decision fact object is matched with the routing rules in the rule base, and the action defined in the corresponding routing rule is executed for each successfully matched decision fact object to determine its ordered channel sequence.

[0034] Based on the rule engine routing decision processor, the ordered channel sequences of all users are collected, and a mapping relationship between user identifiers and ordered channel sequences is generated.

[0035] The routing rules in the rule base include conditional rules and action rules; the conditional rules are configured to make logical judgments on message events and profile data in the decision fact object; the action rules are used to define an ordered channel sequence containing at least one channel identifier for the decision fact object when the conditional rules are satisfied.

[0036] In one possible implementation of the first aspect, the chain of responsibility processing engine further includes a frequency and do-not-disturb verification processor; the step of generating message text corresponding to different channels based on the ordered channel sequence and message template parameters for each user through the message text generation processor further includes:

[0037] The frequency and non-disturbance verification processor performs transmission suppression verification on the ordered channel sequence of each user and outputs the verified ordered channel sequence.

[0038] The transmission suppression verification includes user-level do-not-disturb verification and user-level frequency verification.

[0039] The user-level do-not-disturb verification includes:

[0040] For each user, determine whether the current time is within the do-not-disturb period indicated by the user's profile data. If so, set the user's ordered channel sequence to empty.

[0041] The user-level frequency verification includes:

[0042] For users whose ordered channel sequence was not cleared by the user-level do-not-disturb verification, the frequency of receiving the same type of message within a preset time window is queried. If the frequency exceeds a preset frequency threshold, one or more channel identifiers are removed from the user's ordered channel sequence according to the predefined channel degradation rules.

[0043] In one possible implementation of the first aspect, the step of generating message text corresponding to different channels through the message text generation processor, based on the ordered channel sequence and message template parameters for each user, includes:

[0044] For each user, a matching message template is loaded from the template library based on the user's language preference attribute in the user profile and the message type of the message event.

[0045] The rendering engine is used to inject the message template parameters from the message event into the message template to generate basic text.

[0046] Traverse the user's ordered channel sequence, and for each channel in the ordered channel sequence, adapt and transform the basic text according to the preset content specifications of each channel to generate the message text corresponding to each channel.

[0047] In one possible implementation of the first aspect, the method further includes:

[0048] When the message event is consumed by the core service of the message center, a globally unique tracking ID is generated;

[0049] The tracking ID is injected into the message processing flow of the message event, so that it is passed between the processors of the chain of responsibility processing engine;

[0050] During the execution of each processor in the chain of responsibility processing engine, the link log of the current processor is captured and recorded; wherein the link log is associated with the trace ID and includes trace logs of processor identifier, execution status, execution time and input and output data snapshots.

[0051] Secondly, embodiments of this application provide a message processing system based on a rules engine, including:

[0052] The chain of responsibility processing engine is used to receive message events from the asynchronous message middleware after the chain of responsibility processing engine in the core service of the message center is started, and to drive the message processing flow containing multiple processors to be executed in a predetermined order; wherein, the chain of responsibility processing engine includes a receiver verification processor, a rule engine routing decision processor, a message text generation processor, and a sending task creation processor.

[0053] The receiver verification processor is used to determine the target receiving user list based on the message type and service identifier in the message event;

[0054] The rule engine routing decision processor is used to invoke the rule engine for each user in the target receiving user list, and generate an ordered channel sequence for each user based on the message event;

[0055] The message text generation processor is used to generate message texts corresponding to different channels based on each user's ordered channel sequence and message template parameters.

[0056] The sending task creation processor is used to create a sending task containing a channel identifier for each user based on the message text and the corresponding ordered channel sequence.

[0057] The channel adaptation layer is used to be invoked by the chain of responsibility processing engine to execute the sending task.

[0058] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the message processing method based on a rule engine as described in any of the first aspects above.

[0059] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the message processing method based on a rule engine as described in any of the first aspects above.

[0060] Fifthly, embodiments of this application provide a computer program product that, when run on a computer device, causes the computer device to execute the message processing method based on a rule engine as described in any of the first aspects above.

[0061] In this embodiment, by introducing a rule engine routing decision processor, the routing decision logic is completely decoupled from the business code. This allows for the independent generation of an ordered channel sequence for each user in the target user list through rule matching, improving message delivery success rate and user experience. Furthermore, a responsibility chain processing engine connects a series of single-responsibility processors, decomposing the originally complex and coupled message processing flow into a series of clear, independent, and pluggable components. Whether adding a verification step or replacing a decision algorithm, only adding, deleting, or replacing processors on the chain is required, without altering the main process. This reduces system maintenance costs and improves iteration efficiency and scalability.

[0062] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0064] Figure 1 This is a schematic diagram of the architecture of a message processing system based on a rule engine provided in an embodiment of this application;

[0065] Figure 2 This is a flowchart illustrating the message processing method based on a rule engine provided in an embodiment of this application;

[0066] Figure 3This is a schematic diagram of the chain of responsibility processing flow provided in the embodiments of this application;

[0067] Figure 4 This is a schematic diagram of the rule engine routing decision processor logic provided in an embodiment of this application;

[0068] Figure 5 This is a schematic diagram of the full-link tracing and query interaction process provided in the embodiments of this application;

[0069] Figure 6 This is a signaling interaction timing diagram of the message processing method based on a rule engine provided in the embodiments of this application;

[0070] Figure 7 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0071] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0072] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0073] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0074] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0075] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0076] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0077] This embodiment provides a specific implementation of a message processing method and system based on a rules engine. Please refer to [link / reference]. Figure 1 This is a schematic diagram of the overall system architecture provided in the embodiments of this application. Logically, the system architecture may include: a business trigger terminal 10, an asynchronous message middleware 20, a message center core service 30, and a channel adaptation layer 40.

[0078] The business trigger terminal 10, acting as the message source, can be any business system that needs to send notifications, such as an order management system, device monitoring system, or marketing campaign platform. When a specific business event (such as a user successfully placing an order, a device offline alarm, or the start of a marketing campaign) occurs, the business trigger terminal 10 is responsible for constructing a standardized message event and publishing it to the asynchronous message middleware 20.

[0079] An asynchronous message middleware 20, such as a Kafka message queue, acts as a buffer and decoupler between the business triggering end 10 and the message center core service 30. It receives message events from each business triggering end 10 and temporarily stores them according to a first-in, first-out (FIFO) principle, awaiting consumption by the downstream message center core service 30. This asynchronous architecture effectively handles the instantaneous high-concurrency traffic from upstream businesses, achieving peak shaving and valley filling, thereby improving the overall availability and robustness of the system.

[0080] The core service 30 of the message center is the central hub of the entire message processing flow. This service continuously subscribes to and consumes message events from the asynchronous message middleware 20. Internally, it implements a core component, namely the chain-of-responsibility processing engine 310. This engine is responsible for orchestrating and driving a series of predefined processors to perform pipelined processing of message events.

[0081] The channel adaptation layer 40, acting as the message sending execution layer, is responsible for receiving standardized sending tasks generated after processing by the message center core service 30, and distributing these tasks to specific channel senders for execution. In essence, this layer implements unified encapsulation and management of different message channels (such as in-app push notifications, SMS, email, and site messages).

[0082] Optionally, the system architecture may also include a full-link tracing module 50, which spans the entire message processing lifecycle to record detailed logs of every step from message event consumption to final sending, providing data support for system monitoring, debugging, and troubleshooting.

[0083] Based on the above system architecture, the message processing method of this application is executed in an orderly manner according to predetermined logic, specifically in combination with... Figure 2 The schematic flowchart of the message processing method based on the rule engine shown is explained in detail below.

[0084] S201, after the chain of responsibility processing engine in the core service of the message center is started, it receives message events from the asynchronous message middleware and drives the message processing process containing multiple processors to be executed in a predetermined order; wherein, the chain of responsibility processing engine includes a receiver verification processor, a rule engine routing decision processor, a message text generation processor, and a sending task creation processor.

[0085] Among them, message events are standardized data objects constructed by the business trigger end. They are the input basis for message processing and contain core fields such as message type (representing the business scenario), business identifier (associating with specific business entities), and template parameters (variables that dynamically fill in the text). They carry all the original information required for sending a message.

[0086] Chain of Responsibility Processing Engine: This is a scheduling platform based on the Chain of Responsibility design pattern. It has pre-configured the execution order of processors, can receive message events and drive each processor to execute in sequence, and maintains the processing context to enable data transfer between processors, supporting modular and scalable message processing flow.

[0087] Receiver verification processor: Based on the message type and business identifier in the message event, it parses and determines the list of target receiving users, thereby decoupling business logic from receiver filtering.

[0088] Rule Engine Routing Decision Processor: Invokes the rule engine for each user in the target receiving user list, dynamically generates a personalized ordered channel sequence based on message event attributes and user-related data, and defines the channel priority for message sending.

[0089] Message copy generation processor: Based on the user's ordered channel sequence and message template parameters, it generates message copy that is adapted to each channel according to the content specifications (length, format, etc.) of different channels, ensuring that the copy meets the display requirements.

[0090] Send Task Creation Processor: Encapsulates each user's channel identifier and corresponding message text into a standardized sending task, providing a unified data format for the channel adaptation layer to perform sending operations.

[0091] Asynchronous message middleware: A buffer and decoupling component located between the business triggering end and the core service of the message center. It is used to temporarily store message events published by the business triggering end and provide them to the core service of the message center for consumption according to the first-in-first-out principle, thereby smoothing out peaks and valleys and improving the system's ability to withstand high concurrency.

[0092] Message processing flow: Driven by the chain of responsibility processing engine, the complete business link is formed by the sequential execution of each processor, covering key links such as receiving messages, identifying users, decision-making channels, generating text, and creating tasks, ultimately realizing the full-process processing of messages from receipt to sending.

[0093] Optionally, after the chain of responsibility processing engine in the message center core service starts, receiving message events from the asynchronous message middleware, the process further includes: when a business event occurs, the business triggering end constructs the message event containing the message type, the business identifier, and the message template parameters, and publishes the message event to the asynchronous message middleware; the message event is consumed from the asynchronous message middleware based on the message center core service, and the chain of responsibility processing engine is triggered to start.

[0094] In this embodiment, when a specific business event (such as a user successfully placing an order, a device offline alarm, or the start of a marketing campaign) occurs, the business triggering end acts as the message generation source and constructs a message event in a standardized format. This event must include fields such as message type, business identifier, and message template parameters to ensure that the message data is unified and parsable. After construction, the message event is published to a preset topic through the client of the asynchronous message middleware. The publishing action adopts an asynchronous non-blocking mode, which does not affect the business process of the business triggering end itself, thereby decoupling the business system from the message processing system.

[0095] Subsequently, the core service of the message center, as the consumer of this topic, continuously subscribes to and consumes message events from the asynchronous message middleware through a pull model. The asynchronous message middleware ensures that messages are not lost through a multi-replica storage mechanism, so that even if the message center service is temporarily suspended or experiences a temporary failure, it can continue to consume messages after recovery. After the core service of the message center successfully consumes a message event, it immediately triggers the start of the internal chain of responsibility processing engine, which directly connects to the subsequent core processing flow, completing the closed loop of business event → message publishing → message consumption → engine start.

[0096] S202, the receiver verification processor determines the target receiving user list based on the message type and service identifier in the message event.

[0097] Specifically: The receiver verification processor queries the pre-configured mapping relationship according to the message type to obtain the corresponding business parser identifier; it calls the business parser corresponding to the business parser identifier and passes the business identifier to the business parser; the business parser executes the business query associated with the message type and returns the user identifier set obtained by parsing the business identifier to form the target receiving user list.

[0098] Among them, the business parser is a dedicated parsing component associated with a specific message type. It extracts a set of user identifiers associated with the business identifier from the business system by executing corresponding business queries (such as order queries and device queries).

[0099] User Identifier Set: A unique combination of user identifiers associated with the business identifier, returned by the business parser. It includes device associated party identifiers, order user identifiers, preset user group identifiers, etc., and is the raw data for forming the target receiving user list.

[0100] Target recipient list: The final set of user identifiers after deduplication and validity verification by the recipient verification processor. It is the specific target to which subsequent messages are sent, ensuring that messages are only sent to users who meet the conditions.

[0101] Pre-configured mapping relationship: The message type-business parser identifier correspondence is stored in the database or configuration file, and supports dynamic updates.

[0102] In this embodiment, the receiver verification processor first extracts the message type and business identifier from the message event, then queries the pre-configured message type-business parser mapping relationship to obtain the corresponding business parser identifier; it calls the business parser corresponding to the identifier through the dependency injection container, passing the business identifier to the parser; the business parser performs a business query associated with the message type (such as an order service query), and returns a set of user identifiers parsed based on the business identifier; after the receiver verification processor performs validity checks on the set of user identifiers, such as deduplication and removal of deregistered / frozen users, it forms a target receiving user list.

[0103] In one optional embodiment, the business query executed by the business parser includes at least one of the following:

[0104] If the message type indicates a device alarm, then query the device service to obtain the device associated party identifier corresponding to the service identifier;

[0105] If the message type indicates a change in order status, then query the order service to obtain the order user identifier corresponding to the business identifier;

[0106] If the message type represents a marketing campaign, then query the marketing platform to obtain the preset user group identifier corresponding to the business identifier;

[0107] The device associated party identifier, the order-placing user identifier, and the preset user group identifier constitute the user identifier set.

[0108] In this embodiment, if the message type represents a device alarm, the service parser calls the query interface of the device service, using the service identifier as the search condition, to query the relevant party identifiers associated with the device throughout its entire lifecycle. The device-related party identifiers specifically include the device's registered owner ID, daily maintenance engineer ID, device administrator ID, emergency contact ID, etc., covering the core related roles that need to be reached in a device alarm, ensuring that alarm information can be quickly transmitted to the responsible personnel.

[0109] If the message type indicates an order status change, the business parser accesses the order data storage module of the order service and uses the business identifier (usually a unique order identifier) ​​as the query key to extract the user identifier directly related to the order. The user identifier that placed the order includes not only the consumer user ID who initiated the order, but can also be expanded to include associated users based on the order type, such as the merchant user ID for e-commerce orders, the rider user ID for food delivery orders, and the service provider ID for service orders, ensuring that order status change information is synchronized to all relevant participants.

[0110] If the message type represents a marketing campaign, the business parser connects to the marketing platform's user selection service, using the business identifier (usually a unique identifier for the marketing campaign) as a parameter to obtain the preset target user group identifier for the campaign. The preset user group identifier is a set of users pre-selected by the marketing platform based on specific rules. Selection criteria may include user tags (such as high-frequency consumers, new users, and regions), historical consumption behavior (such as spending over 500 yuan in the past 3 months), and preference settings (such as subscribing to marketing notifications).

[0111] Among them, the device associated party identifier, the order-placing user identifier, and the preset user group identifier are all unique identity identifiers of users in the system (such as UUID format, auto-incrementing ID format). The three correspond to the core reach objects in different business scenarios, and together they constitute the user identifier set, providing complete and accurate raw data support for the receiver verification processor to generate the target receiving user list.

[0112] S203, the rule engine routing decision processor calls the rule engine for each user in the target receiving user list to generate an ordered channel sequence for each user based on the message event.

[0113] In an optional embodiment, the chain of responsibility processing engine further includes a user profile query processor; the method further includes: querying the profile data of each user in the target receiving user list in batches through the user profile query processor; then S203 includes: calling the rule engine for each user in the target receiving user list through the rule engine routing decision processor, and generating an ordered channel sequence for each user based on the message event and the profile data of each user.

[0114] Specifically: Based on the rule engine routing decision processor, a decision fact object containing the user's profile data and the message event is created for each user; decision fact objects for multiple users are provided to the rule engine; based on the rule engine, each decision fact object is matched with routing rules in the rule base, and the action defined in the corresponding routing rule is executed for each successfully matched decision fact object to determine its ordered channel sequence; based on the rule engine routing decision processor, the ordered channel sequences of all users are collected, and a mapping relationship between user identifiers and ordered channel sequences is generated.

[0115] The routing rules in the rule base include conditional rules and action rules; the conditional rules are configured to make logical judgments on message events and profile data in the decision fact object; the action rules are used to define an ordered channel sequence containing at least one channel identifier for the decision fact object when the conditional rules are satisfied.

[0116] Among them, the rule engine is a rule matching and execution engine that is independent of the business code. It can load routing rules from the rule library, perform pattern matching on decision fact objects and execute corresponding actions to realize dynamic configuration of routing logic.

[0117] Decision Fact Object: A POJO class that encapsulates all the information needed for routing decisions. It includes at least user profile data and raw message events and is the core data carrier for the rule engine to make matching decisions.

[0118] Rule base: A collection of routing rules, which consist of conditional rules and action rules.

[0119] Ordered channel sequence: A list of channels with sending priorities generated for each user, defining the degradation logic for message sending to ensure message delivery success rate.

[0120] Conditional rules: A component of routing rules, configured to make logical judgments on message events and profile data in decision fact objects.

[0121] Action rules: A component of routing rules, used to define an ordered sequence of channels containing at least one channel identifier for a decision fact object when a condition rule is met.

[0122] In this embodiment, the rule engine routing decision processor obtains the target receiving user list and user profile data from the processing context; creates a decision fact object for each user, which encapsulates user profile data and original message events; submits multiple user decision fact objects to the rule engine in batches, and the rule engine loads routing rules (composed of conditional rules and action rules) from the rule library; matches each decision fact object with the routing rules using a pattern matching algorithm, executes action rules for successfully matched objects, and determines their ordered channel sequence; finally, it collects the ordered channel sequences of all users, generates a user ID-ordered channel sequence mapping relationship, stores it in the processing context, and provides a channel priority basis for subsequent copy generation and task creation.

[0123] S204, the message text generation processor generates message text corresponding to different channels based on the ordered channel sequence and message template parameters of each user.

[0124] In this embodiment of the application, the message text generation processor generates message text corresponding to different channels based on each user's ordered channel sequence, profile data, and message template parameters.

[0125] Specifically, for each user, a matching message template is loaded from the template library based on the user's language preference attributes in the user profile and the message type of the message event; the message template parameters in the message event are injected into the message template using the rendering engine to generate basic text; the ordered channel sequence of the user is traversed, and for each channel in the ordered channel sequence, the basic text is adapted and converted according to the preset content specifications of each channel to generate the message text corresponding to each channel.

[0126] The adaptation and conversion includes at least one of the following: for push or SMS channels, content is truncated to meet length constraints; for email channels, rich text formatting is performed; for in-site messaging channels, a link to the details page is added.

[0127] The template library stores a collection of message templates for different message types and languages.

[0128] Rendering engine: A tool used to inject template parameters from message events into message templates to generate basic text, ensuring accurate integration of dynamic parameters and templates to generate personalized basic content.

[0129] Basic copy: The unified copy generated after injecting the message template parameters into the corresponding message template is the basis for subsequent channel adaptation and conversion. It contains the core message information but is not adapted to specific channel specifications.

[0130] Channel adaptation and conversion: Based on the preset content specifications of different channels (such as length limits, format requirements, and additional information requirements), the basic text is trimmed, packaged, and adjusted by adding links or unsubscribing prompts to ensure that the text meets the sending requirements and display effects of the corresponding channel.

[0131] Preset content specifications: The inherent sending standards for each message channel, including the length limit of the body (Push body ≤ 200 characters, SMS ≤ 70 characters, etc.), format requirements (SMS prohibits special characters), and additional information requirements (SMS must include an unsubscribe notice), etc.

[0132] Message template parameters: A dynamic collection of key-value pairs in the message event, containing personalized information required for copy generation (such as username, order ID, business status, etc.), used to populate the message template and generate copy that fits the specific business scenario.

[0133] In this embodiment, for each user, a uniquely matching message template is loaded from the template library based on the language preference attribute and message type of the message event in their profile data. The rendering engine injects the message template parameters into the matching template to generate a unified basic text. The user's ordered channel sequence is traversed, and the basic text is adapted to the preset content specifications (length limits, format requirements, additional information requirements) for each channel. Finally, the message text generation processor outputs the mapping relationship between user ID, channel, and text, storing it in the processing context to provide accurate text data for creating the sending task in S205.

[0134] S205, the sending task creation processor creates a sending task containing a channel identifier for each user based on the message text and the corresponding ordered channel sequence.

[0135] In this embodiment, for each user, the validated ordered channel sequence is traversed, and only valid channels whose channel identifiers correspond to text in the text mapping are retained, ensuring accurate matching between tasks and text. An atomic sending task is created for each valid channel. The task must include: a tracking ID (inherited from the process context and used for end-to-end tracking), a user ID (a unique identifier for the target user), a channel identifier (used for matching the sender in the channel adaptation layer), the message text, the task ID, and a creation timestamp (the system time when the task was generated). Multiple sending tasks for the same user are sorted according to the priority of the ordered channel sequence, and then all tasks are aggregated by user dimension to form a structured sending task list, which is stored in the processing context.

[0136] S206, Invoke the channel adaptation layer to execute the sending task.

[0137] During system initialization, a component scanning mechanism is used to identify all channel transmitter instances that implement predefined transmitter interfaces. For each identified channel transmitter instance, its channel identifier is extracted, and the mapping relationship between the channel identifier and the channel transmitter instance is cached in the registry.

[0138] S206 specifically includes: the channel adaptation layer retrieving the corresponding channel sender instance from the registry based on the channel identifier in the sending task; and invoking the channel sender instance to execute the sending task.

[0139] Specifically: During system initialization, a preset component scanning mechanism is triggered to scan all classes under the specified package path. The scanning rule is whether a predefined sender interface is implemented. This interface defines a unified sending method and a channel identifier acquisition method, serving as a standardized constraint for all channel senders. After scanning, all eligible channel sender classes are instantiated, generating singleton channel sender instances to ensure that only one sender instance exists for the same channel within the entire system, avoiding resource redundancy. Then, for each identified and instantiated channel sender instance, its getChannelId() method is called to extract a unique channel identifier. Subsequently, the key-value pair of the channel identifier and the sender instance is stored in the registry of the channel adaptation layer and cached in memory to avoid repeated scanning or instantiation each time a sending task is executed, thus improving the task execution efficiency of S206.

[0140] After receiving the list of sending tasks submitted by the chain of responsibility processing engine, the channel adaptation layer first extracts the core channel identifier for each sending task. Using this identifier as the search key, it quickly matches the corresponding channel sender instance in the registry. If the search fails, the task execution is marked as failed, an error log indicating that the channel sender associated with the global tracking ID was not found is recorded, and the task is terminated. After successfully obtaining the instance, the unified sending method of its predefined sender interface is called, and the sending task is passed in completely. The sender instance first converts the common fields of the task (user ID, text, etc.) into the specific protocol format of the corresponding channel, then calls the underlying sending capabilities (push SDK, SMS API, and in-site message database write) to execute the sending, and finally encapsulates a standardized result containing the execution status and channel receipt ID and returns it. The adaptation layer updates the task status and stores the associated tracking ID. If the sending fails and there are still alternative channels in the user's ordered channel sequence, the failover logic is triggered to repeat the search-call process until the sending is successful or all alternative channels have been tried, which ensures both the consistency of the call and the reliability of the reach.

[0141] The following will combine Figure 3Taking a specific business scenario as an example, this paper elaborates on the responsibility chain processing flow within the core service 30 of the message center. The scenario is as follows: After user A completes an order (business identifier "ORDER-123"), the order system (as the business trigger 10) needs to send a notification to user A who placed the order and the associated merchant user B.

[0142] Specifically, when a business event occurs, the order system, acting as the business trigger (10), constructs a message event. This message event is typically a structured data object (such as a JSON object) containing key information necessary for subsequent processing. In this scenario, this message event can be exemplified as follows:

[0143]

[0144] The `messageType` field defines the message type, used for subsequent logical dispatch; `businessId` is a unique identifier for the business entity associated with the message; and `templateParams` contains dynamic parameters used to populate the message text template. The order system publishes this message event to a specific topic in the asynchronous message middleware 20, such as `order-events`.

[0145] The message center core service 30, acting as a consumer, subscribes to the order-events topic. Upon receiving the aforementioned message events from the asynchronous message middleware 20, the message processing flow is initiated.

[0146] First, the system generates a globally unique trace ID (e.g., TRACE-XYZ-789) for this processing flow. This trace ID is injected into the context of the processing flow and passed between all subsequent processors to link the chain logs of the entire process. Subsequently, the chain of responsibility processing engine 310 is activated and begins to call its internally configured processors in a predetermined order.

[0147] The processing flow first enters the receiver verification processor 311. This processor is used to parse out all target users that the message needs to reach based on the incoming message event. To achieve decoupling from specific business logic, the receiver verification processor 311 internally maintains a mapping relationship configuration between message types and business resolvers. This configuration can be stored in a database or configuration file, for example: "ORDER_STATUS_CHANGE"->"orderBusinessResolver" "DEVICE_ALARM"->"deviceBusinessResolver". The receiver verification processor 311 queries this mapping relationship based on the messageType field value ORDER_STATUS_CHANGE in the message event to determine which business resolver, identified as orderBusinessResolver, needs to be called. Accordingly, the processor uses the businessId field value "ORDER-123" in the message event as a parameter and calls the orderBusinessResolver business resolver via remote procedure call or internal interface call. This business parser is a component specifically designed to handle order-related business logic. Upon receiving the order ID "ORDER-123", it executes a corresponding business query (e.g., accessing the order service's database or interface) to retrieve the ordering user ID and merchant user ID associated with the order. In this scenario, the query result is a set of identifiers for user A and user B. The business parser returns this set of user identifiers to the receiver verification processor 311. Finally, the receiver verification processor 311 stores this set as a target receiving user list in the process context for use by subsequent processors. In this way, the message center core service 30 does not need to concern itself with the specific implementation details of the order business; it only needs to interact with the pluggable business parser through a unified interface.

[0148] The process then flows to the user profile query processor 312. This processor retrieves the target recipient list [User A, User B] generated in the previous step from the context. To enable subsequent personalized decision-making and copy generation, the processor needs to obtain detailed profile data for these users.

[0149] As an optional implementation, it initiates batch queries to the user center service or user profile database to retrieve profile data for users A and B. Profile data typically includes users' static attributes and dynamic states. For example, for user A, the returned profile data might be: {"userId":"A","pushEnabled":true,"dndTime":"23:00-07:00","language":"en_US","tags":["VIP","tech_savvy"]}. For user B, the returned profile data might be: {"userId":"B","pushEnabled":false,"smsVerified":true,"language":"zh_CN","tags":["merchant"]}. The user profile query processor 312 associates the retrieved profile data for each user with the corresponding user ID and stores it in the process context.

[0150] Next, the process proceeds to the rules engine routing decision processor 313. (See also...) Figure 4 The processor integrates a rule engine 322, such as a rule engine based on Drools. The processor iterates through the target receiving user list and creates a decision fact object 321 for each user (user A and user B). This decision fact object 321 is an object encapsulating all the information needed for routing decisions, containing at least the current user's profile data and the original message event. For example, the decision fact object 321 created for user A contains user A's profile data and the message event ORDER_STATUS_CHANGE; while the decision fact object 321 created for user B contains user B's profile data and the same message event. Subsequently, the rule engine routing decision processor 313 submits these two decision fact objects 321 in batches to the rule engine 322. The rule engine 322 loads a series of predefined routing rules from the rule base 323. These routing rules consist of a condition part (WHEN) and an action part (THEN). Business or operations personnel can configure and modify these rules through a dedicated management interface without changing the code. Examples of rules in the rule base 323 are as follows:

[0151] Rule 1 (High-priority order notification - Push priority): WHEN Message.type = "ORDER_STATUS_CHANGE" User.profile.pushEnabled = true THEN Result.setChannelSequence(["Push","StationLetter","Sms"]).

[0152] Rule 2 (User disables Push-SMS priority): WHEN User.profile.pushEnabled = false User.profile.smsVerified = true THEN Result.setChannelSequence(["Sms","StationLetter"]).

[0153] Rule 3 (default fallback rule): WHEN (no other rules matched) THENResult.setChannelSequence(["StationLetter"]).

[0154] Rule engine 322 matches each decision fact object 321 against the rules in rule base 323. For user A's decision fact object, because pushEnabled is true in its profile data and the message type is ORDER_STATUS_CHANGE, rule 1 is successfully matched. The rule engine executes the action part of this rule, generating an ordered channel sequence 324 for user A, namely ["Push", "StationLetter", "Sms"]. This sequence defines the channel's sending priority: it first attempts to send via in-app push, if that fails, it downgrades to in-site messaging, and if that fails again, it finally attempts SMS. For user B's decision fact object, because pushEnabled is false but smsVerified is true in its profile data, rule 2 is successfully matched. After the rule engine executes, the ordered channel sequence 324 generated for user B is ["Sms", "StationLetter"]. The rule engine routing decision processor 313 collects the decision results of all users and generates a mapping relationship from user ID to ordered channel sequence, which is stored in the process context, for example: {user A:["Push","StationLetter","Sms"], user B:["Sms","StationLetter"]}.

[0155] Subsequently, the process enters the frequency and do-not-disturb verification processor 314 within the chain of responsibility processing engine. Specifically, before generating message text corresponding to different channels based on each user's ordered channel sequence and message template parameters, the process further includes: performing a transmission suppression verification on each user's ordered channel sequence through the frequency and do-not-disturb verification processor, and outputting the verified ordered channel sequence. The frequency and do-not-disturb verification processor 314 embodies the programmability of the processor.

[0156] The transmission suppression verification includes user-level do-not-disturb verification and user-level frequency verification.

[0157] The user-level do-not-disturb verification includes: for each user, determining whether the current time is within the do-not-disturb period indicated by the user's profile data; if so, setting the user's ordered channel sequence to empty.

[0158] The user-level frequency verification includes: for users whose ordered channel sequence has not been cleared by the user-level do-not-disturb verification, querying the frequency of receiving the same type of message within a preset time window; if the frequency exceeds a preset frequency threshold, removing one or more channel identifiers from the user's ordered channel sequence according to a predefined channel degradation rule.

[0159] In this embodiment, the frequency and do-not-disturb verification processor 314 is used to ensure that message sending is compliant and meets user expectations, thereby avoiding excessive harassment to users. It performs a sending suppression verification on the ordered channel sequence for each user in the context. The verification logic mainly includes two levels: First, user-level do-not-disturb verification. The processor obtains the current system time and compares it with the do-not-disturb period (dndTime) indicated in each user profile data. Assuming the current time is 3 PM, for user A (do-not-disturb period 23:00-07:00), the current time is not within their do-not-disturb period, and the verification passes. Second, user-level frequency verification. For users who pass the do-not-disturb verification, the processor checks the frequency with which they receive the same type of message within a preset time window. For example, the system can be configured to receive a maximum of one message of type ORDER_STATUS_CHANGE within one minute. The processor queries a counter in a caching system (such as Redis) using the user ID and message type as keys. Suppose user B has received an order-related SMS message within the past 30 seconds, with a frequency count of 1, reaching the threshold. At this point, the frequency and do-not-disturb verification processor 314 will remove the SMS channel identifier from user B's ordered channel sequence according to predefined channel degradation rules. After processing by this processor, the user channel sequence mapping relationship in the process context is updated to: {User A:["Push","StationLetter","Sms"], User B:["StationLetter"]}.

[0160] Then, the process enters the message copy generation processor 315. This processor is responsible for generating the final message copy for each user and each corresponding outbound channel. It traverses the user-channel sequence mapping after the previous step of verification. For user A, the channel sequence is ["Push", "StationLetter", "Sms"]. The processor first loads the corresponding English message template from the template library according to the language preference en_US and the message type ORDER_STATUS_CHANGE in user A's profile data. For example: Dear${userName}, your order${orderId}has been updated to${status}. Then, the processor uses a rendering engine (such as Thymeleaf) to inject the templateParams in the message event into this template to generate the basic copy: Dear user A, your order ORDER-123 has been updated to Completed. Next, the processor traverses the channel sequence of user A and adapts it according to the characteristics of different channels. For example, for the Push channel, the basic copy may be trimmed due to content length limitations; for the StationLetter channel, a link to the order details page may be appended at the end of the copy; for the Sms channel, in addition to length limitations, special characters may also need to be removed and an unsubscribe message may be appended. For user B, the remaining channel sequence is only ["StationLetter"]. The processor loads the Chinese template according to its language preference zh_CN and renders the Chinese copy, such as: Respected merchant, the status of order ORDER-123 has been updated to Completed, please process it in time. Finally, this processor outputs a complex structure containing each user, each channel, and their corresponding final copy, and stores it in the process context.

[0161] The last link in the chain of responsibility is the send task creation processor 316. This processor creates standardized send tasks for each user based on the copy results generated in the previous step. A send task is an atomic and independently executable data object, usually containing fields such as a tracking ID, user ID, channel identifier, message copy, etc. For example, for user A, three send tasks will be created: a Push task, a StationLetter task, and a Sms task. For user B, only one StationLetter task will be created. These tasks are organized into a list.

[0162] After the chain of responsibility processing engine 310 completes the calls to all processors, it passes the list of sending tasks created in the previous step to the channel adaptation layer 40. Upon receiving the tasks, the channel adaptation layer 40 iterates through the task list and, based on the channel identifier in each task, finds and calls the corresponding sender instance to execute the actual sending operation. This completes one full message processing flow.

[0163] In one optional embodiment, the technical implementation details of the end-to-end tracing module 50 and the channel adaptation layer 40 are mainly described.

[0164] First, the implementation method of end-to-end tracing is explained. As described in the above embodiment, when the message center core service 30 consumes a message event, it generates a globally unique tracing ID. The tracing ID is injected into the message processing flow of the message event, allowing it to be passed between the processors of the chain of responsibility processing engine. During the execution of each processor in the chain of responsibility processing engine, the current processor's link log is captured and recorded; the link log is associated with the tracing ID and includes the processor identifier, execution status, execution time, and snapshots of input and output data.

[0165] The tracking ID can be generated using various algorithms, such as the snowflake algorithm which combines timestamps, machine IPs, and serial numbers, to ensure its uniqueness in a distributed environment.

[0166] Once the trace ID is generated, it is stored in a context that spans the entire thread's lifecycle, such as using ThreadLocal or the MDC mechanism, which is more suitable for asynchronous programming scenarios. In this way, the trace ID corresponding to the currently being processed message can be obtained at any time within any processor of the chain of responsibility processing engine 310.

[0167] Link log recording can be implemented non-intrusively using aspect-oriented programming (AOP). Specifically, an aspect can be defined whose pointcut expression points to the execution methods of all classes that implement a predefined processor interface (such as the Processor interface). Then, an around advice is defined to wrap the execution of these methods.

[0168] Please refer to it again. Figure 3 AOP aspect 51 logically wraps all the processors (311 to 316) on the chain of responsibility. When the chain of responsibility processing engine 310 calls the execution method of the receiver verification processor 311, the AOP around advice is triggered.

[0169] In an optional implementation, the logic for the surrounding notification may include the following steps:

[0170] 1) Record a start timestamp before the target method is executed.

[0171] 2) Call the process() method to enable the original processor method (i.e., the business logic of receiver verification processor 311) to execute normally.

[0172] 3) After the target method is executed (whether successfully or in error), record an end timestamp and calculate the execution time.

[0173] 4) Capture the input parameters and return values ​​(or thrown exceptions) of the target method and serialize them into a JSON string as a snapshot of the input and output data.

[0174] 5) Assemble a trace log. This log is a structured object containing the following fields: traceId (trace ID obtained from the context), processorName (identifier of the current processor, such as ReceiverValidationProcessor), startTime (time stamp of start of execution), duration (execution time in milliseconds), status (execution status, such as SUCCESS or FAILURE), inputSnapshot (input data snapshot), and outputSnapshot (output data snapshot or exception information).

[0175] 6) Asynchronously send the trace log to log repository 52. ​​Log repository 52 can be a system specifically designed for log storage and retrieval, such as Elasticsearch. An index can be created for the traceId field to enable fast querying.

[0176] This process is repeated for each processor (312, 313, 314, 315, 316) in the chain of responsibility. Therefore, a complete message processing flow will generate a series of chain logs associated with the same trace ID, recording details of each processing step.

[0177] Next, these link logs can be used to achieve visual tracking and problem localization. The specific solution is as follows: obtain the tracking ID entered on the visual query interface; retrieve the link logs associated with the tracking ID from the log library; aggregate and reconstruct the retrieved link logs to generate the execution trajectory of the current message processing flow; and render the execution trajectory into a visual view for display.

[0178] In the embodiments of this application, please refer to Figure 5This document explains how to utilize these trace logs for visual tracing and problem localization. The system provides a visual query interface for developers and operations personnel. When a problem occurs online (e.g., a user reports not receiving an order notification), operations personnel can find the corresponding trace ID from the business logs based on information such as the order ID and input it into the visual query interface. The front-end interface sends a query request carrying this trace ID to the back-end service. Upon receiving the request, the back-end service queries the log database 52 (Elasticsearch), retrieving all trace log documents where the traceId field equals the given value, and sorting them in ascending order by the startTime field. After obtaining the log set, the back-end service aggregates and reconstructs these discrete logs, connecting them into an execution trajectory data structure that reflects the original execution flow and has a temporal order and hierarchical relationship. Finally, the back-end service returns the reconstructed execution trajectory data to the front-end. The visual query interface uses this data to render an intuitive visual view, such as a timeline view or a flame graph. This visualization clearly shows: the processors through which message processing occurs, the execution order of each processor, the start time and duration, the input and output of each processor, and which processor failed or experienced abnormal execution time. For example, by viewing this view, operations personnel may find that the ordered channel sequence for a user is empty in the output of the rule engine's routing decision processor 313. Further examination of its input snapshot will reveal that the user's profile data is incorrect, thus quickly locating the root cause of the problem.

[0179] Furthermore, this embodiment also describes the scalability design of the channel adaptation layer 40. During the system initialization phase (e.g., when an application based on the Spring framework starts), a component scanning mechanism is initiated. This mechanism scans all classes under a specified package path to find instances that implement a predefined sender interface (e.g., the Sender interface). The Sender interface can be defined as follows:

[0180]

[0181] All specific channel transmitters in the system, such as PushSender, SmsSender, and EmailSender, must implement this interface. For example:

[0182]

[0183]

[0184] Upon system startup, a registry (which can be a ConcurrentHashMap) within the channel adaptation layer 40 is populated. Each time the scanning mechanism discovers a Sender instance, it calls its getChannelType() method to obtain the channel identifier, then stores this channel identifier as the key and the sender instance as the value in the registry. After startup, the registry may contain the following mapping: {"Push":pushSenderInstance,"Sms":smsSenderInstance,"Email":emailSenderInstance}.

[0185] When the channel adaptation layer 40 receives a sending task from the chain of responsibility processing engine 310 and needs to execute it, it can directly retrieve the corresponding PushSender instance from the registry with a time complexity of O(1) based on the channel identifier (e.g., Push) in the task, and then call its send method.

[0186] By adopting this interface-based implementation and dynamic registration design, the system possesses excellent scalability. When a new messaging channel (such as WeChat Work) needs to be supported, developers only need to: 1) create a new WeComSender class, implement the Sender interface, and encapsulate the logic for calling the WeChat Work API within it; 2) add the @Component annotation to this class; 3) place this class in a scannable package. After completing these steps and redeploying the application, the new WeChat Work channel can be automatically registered and put into use without modifying any code in the channel adaptation layer 40 or the chain of responsibility processing engine 310.

[0187] It should be noted that the channel adaptation layer 40 is also responsible for implementing failover logic based on an ordered channel sequence. When it fails to send a message using the primary channel (e.g., Push in the ordered channel sequence ["Push", "StationLetter"]) (e.g., PushSender's send method throws an exception), it does not terminate immediately. Instead, it catches the exception, logs the failure, selects the next channel, StationLetter, from the ordered channel sequence, and attempts to retry sending using StationLetterSender. This process continues until the message is successfully sent or all alternative channels fail, thus significantly improving the reliability of message delivery.

[0188] Please see Figure 6 The technical solution of this application is summarized from the perspective of signaling interaction. Figure 6The document intuitively depicts the calling relationships and interaction order among the business trigger terminal 10, asynchronous message middleware 20, message center core service 30 (and the cyclic processing of its internal processors 311-316), and channel adaptation layer 40, fully presenting the dynamic execution process of the solution in this application.

[0189] 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.

[0190] Corresponding to the message processing method based on a rule engine described in the above embodiments, this application also provides a description of a message processing system based on a rule engine.

[0191] This rule-based message processing system includes:

[0192] The chain of responsibility processing engine is used to receive message events from the asynchronous message middleware after the chain of responsibility processing engine in the core service of the message center is started, and to drive the message processing flow containing multiple processors to be executed in a predetermined order; wherein, the chain of responsibility processing engine includes a receiver verification processor, a rule engine routing decision processor, a message text generation processor, and a sending task creation processor.

[0193] The receiver verification processor is used to determine the target receiving user list based on the message type and service identifier in the message event;

[0194] The rule engine routing decision processor is used to invoke the rule engine for each user in the target receiving user list, and generate an ordered channel sequence for each user based on the message event;

[0195] The message text generation processor is used to generate message texts corresponding to different channels based on each user's ordered channel sequence and message template parameters.

[0196] The sending task creation processor is used to create a sending task containing a channel identifier for each user based on the message text and the corresponding ordered channel sequence.

[0197] The channel adaptation layer is used to be invoked by the chain of responsibility processing engine to execute the sending task.

[0198] It should be noted that the information interaction and execution process between the above modules, processors, etc. are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0199] 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 merely 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 device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0200] This application also provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0201] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0202] This application provides a computer program product that, when run on a computer device, enables the computer device to execute the steps described in the various method embodiments above.

[0203] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 7 As shown, the computer device of this embodiment includes: at least one processor 70 ( Figure 7 (Only one is shown in the diagram), memory 71, and computer program 72 stored in the memory 71 and executable on the at least one processor 70, wherein the processor 70 executes the computer program 72 to implement the steps in any of the above-described embodiments of the rule engine-based message processing methods.

[0204] The computer device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 7The examples of computer devices are merely examples and do not constitute a limitation on computer devices. They may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.

[0205] The processor 70 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0206] In some embodiments, the memory 71 may be an internal storage unit of the computer device, such as a hard disk or memory. In other embodiments, the memory 71 may be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Furthermore, the memory 71 may include both internal and external storage units of the computer device. The memory 71 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 71 can also be used to temporarily store data that has been output or will be output.

[0207] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, 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 computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / computer equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0208] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0209] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0210] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0211] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0212] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A message processing method based on a rule engine, characterized in that, The method includes: After the chain of responsibility processing engine in the core service of the message center starts, it receives message events from the asynchronous message middleware and drives the message processing flow containing multiple processors to be executed in a predetermined order; wherein, the chain of responsibility processing engine includes a receiver verification processor, a rule engine routing decision processor, a message text generation processor, and a sending task creation processor. The receiver verification processor determines the target receiving user list based on the message type and service identifier in the message event. The rule engine routing decision processor invokes the rule engine for each user in the target receiving user list to generate an ordered channel sequence for each user based on the message event. The message text generation processor generates message texts corresponding to different channels based on each user's ordered channel sequence and message template parameters. The sending task creation processor creates a sending task containing a channel identifier for each user based on the message text and the corresponding ordered channel sequence. Invoke the channel adaptation layer to execute the sending task.

2. The method according to claim 1, characterized in that, After the chain of responsibility processing engine in the message center core service starts, it receives message events from the asynchronous message middleware. Prior to this, it also includes: When a business event occurs, the business triggering end constructs a message event containing the message type, the business identifier, and the message template parameters, and publishes the message event to the asynchronous message middleware; The message center core service consumes the message events from the asynchronous message middleware and triggers the chain of responsibility processing engine to start.

3. The method according to claim 1, characterized in that, The chain of responsibility processing engine also includes a user profile query processor; the method further includes: The user profile query processor can be used to query the profile data of each user in the target receiving user list in batches. The step of using the rule engine routing decision processor to invoke the rule engine for each user in the target receiving user list, and generating an ordered channel sequence for each user based on the message event, includes: The rule engine routing decision processor calls the rule engine for each user in the target receiving user list, and generates an ordered channel sequence for each user based on the message event and the profile data of each user. The step of generating message text corresponding to different channels through the message text generation processor, based on each user's ordered channel sequence and message template parameters, includes: The message copy generation processor generates message copy corresponding to different channels based on each user's ordered channel sequence, profile data, and message template parameters.

4. The method according to claim 3, characterized in that, The step of determining the target receiving user list through the receiver verification processor based on the message type and service identifier in the message event includes: The receiver verification processor queries the pre-configured mapping relationship based on the message type to obtain the corresponding business parser identifier. Invoke the service parser corresponding to the service parser identifier and pass the service identifier to the service parser; The service parser executes a service query associated with the message type and returns a set of user identifiers obtained based on the service identifier, thereby forming the target receiving user list.

5. The method according to claim 4, characterized in that, The business query executed by the business parser includes at least one of the following: If the message type indicates a device alarm, then query the device service to obtain the device associated party identifier corresponding to the service identifier; If the message type indicates a change in order status, then query the order service to obtain the order user identifier corresponding to the business identifier; If the message type represents a marketing campaign, then query the marketing platform to obtain the preset user group identifier corresponding to the business identifier; The device associated party identifier, the order-placing user identifier, and the preset user group identifier constitute the user identifier set.

6. The method according to claim 3, characterized in that, The step of using the rule engine routing decision processor to invoke the rule engine for each user in the target receiving user list, and generating an ordered channel sequence for each user based on the message event, includes: Based on the rule engine routing decision processor, a decision fact object containing the user's profile data and the message event is created for each user; The decision fact objects for multiple users will be provided to the rule engine; Based on the rule engine, each decision fact object is matched with the routing rules in the rule base, and the action defined in the corresponding routing rule is executed for each successfully matched decision fact object to determine its ordered channel sequence. Based on the rule engine routing decision processor, the ordered channel sequences of all users are collected, and a mapping relationship between user identifiers and ordered channel sequences is generated. The routing rules in the rule base include conditional rules and action rules; the conditional rules are configured to make logical judgments on message events and profile data in the decision fact object; the action rules are used to define an ordered channel sequence containing at least one channel identifier for the decision fact object when the conditional rules are satisfied.

7. The method according to claim 1, characterized in that, The chain of responsibility processing engine also includes a frequency and do-not-disturb verification processor; the step of generating message text corresponding to different channels through the message text generation processor based on each user's ordered channel sequence and message template parameters, previously included: The frequency and non-disturbance verification processor performs transmission suppression verification on the ordered channel sequence of each user and outputs the verified ordered channel sequence. The transmission suppression verification includes user-level do-not-disturb verification and user-level frequency verification. The user-level do-not-disturb verification includes: For each user, determine whether the current time is within the do-not-disturb period indicated by the user's profile data. If so, set the user's ordered channel sequence to empty. The user-level frequency verification includes: For users whose ordered channel sequence was not cleared by the user-level do-not-disturb verification, the frequency of receiving the same type of message within a preset time window is queried. If the frequency exceeds a preset frequency threshold, one or more channel identifiers are removed from the user's ordered channel sequence according to the predefined channel degradation rules.

8. The method according to claim 3, characterized in that, The step of generating message text corresponding to different channels through the message text generation processor, based on each user's ordered channel sequence and message template parameters, includes: For each user, a matching message template is loaded from the template library based on the user's language preference attribute in the user profile and the message type of the message event. The rendering engine is used to inject the message template parameters from the message event into the message template to generate basic text. Traverse the user's ordered channel sequence, and for each channel in the ordered channel sequence, adapt and transform the basic text according to the preset content specifications of each channel to generate the message text corresponding to each channel.

9. The method according to claim 1, characterized in that, The method further includes: When the message event is consumed by the core service of the message center, a globally unique tracking ID is generated; The tracking ID is injected into the message processing flow of the message event, so that it is passed between the processors of the chain of responsibility processing engine; During the execution of each processor in the chain of responsibility processing engine, the link log of the current processor is captured and recorded; wherein the link log is associated with the trace ID and includes trace logs of processor identifier, execution status, execution time and input and output data snapshots.

10. A message processing system based on a rules engine, characterized in that, include: The chain of responsibility processing engine is used to receive message events from the asynchronous message middleware after the chain of responsibility processing engine in the core service of the message center is started, and to drive the message processing flow containing multiple processors to be executed in a predetermined order; wherein, the chain of responsibility processing engine includes a receiver verification processor, a rule engine routing decision processor, a message text generation processor, and a sending task creation processor. The receiver verification processor is used to determine the target receiving user list based on the message type and service identifier in the message event; The rule engine routing decision processor is used to invoke the rule engine for each user in the target receiving user list, and generate an ordered channel sequence for each user based on the message event; The message text generation processor is used to generate message texts corresponding to different channels based on each user's ordered channel sequence and message template parameters. The sending task creation processor is used to create a sending task containing a channel identifier for each user based on the message text and the corresponding ordered channel sequence. The channel adaptation layer is used to be invoked by the chain of responsibility processing engine to execute the sending task.

Images