Information processing method and electronic device

Abstract

The application discloses an information processing method and an electronic device, and particularly relates to the technical field of information processing, and comprises the following steps: in the case that a business event under a business platform meets a message notification condition, determining a visible state between a message type corresponding to the business event and a platform version of the business platform and a subscription state between the message type and associated users of the business platform based on a pre-configured message platform mapping relationship and a message user mapping relationship; performing pre-filtering analysis on the business event based on the visible state and the subscription state to determine whether the business event meets a message generation condition; and in the case that the business event meets the message generation condition, generating intranet letter data of the business event to display the intranet letter data to a target user in the associated users. Through two-dimensional accurate message management and control of the platform version and the user role, the generation and storage of redundant messages are avoided, and the intranet letter data is displayed on demand.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to an information processing method and an electronic device. Background Technology

[0002] In related technologies, in-site message management mainly adopts a push architecture, where the message sender determines the recipients. Specifically, the backend configures message templates and push rules, and after a message is generated, it is sent to the target client according to the push type configuration (specifying a single user or a selected group). However, this architecture generates messages first and then filters them, which is a post-filtering mode. User receiving preferences do not participate in the message generation decision and cannot be persistently saved. The granularity of the audience segmentation is coarse and not deeply coupled with the platform's role system. At the same time, under multi-version platforms, there is a lack of message type management mechanism. The message type sets corresponding to different versions are not distinguished by boundaries, resulting in cross-version message type mixing and messages from non-platform functional modules still being generated and displayed, causing platform data redundancy and wasted storage resources. Summary of the Invention

[0003] This application provides an information processing method and an electronic device to at least solve the technical problems in the related art, such as the redundancy of platform data and the waste of storage resources caused by the first generation and subsequent screening of messages, as well as the lack of boundary distinction of message types under multiple version platforms and the inability of users to persistently configure the message receiving range according to their roles.

[0004] This application provides an information processing method, including: When a business event on the business platform meets the message notification conditions, based on the pre-configured message platform mapping relationship and message user mapping relationship, the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform, are determined. Based on the visibility and subscription status, pre-filtering analysis is performed on business events to determine whether the business events meet the message generation conditions. If a business event meets the message generation conditions, the site message data for the business event is generated to be displayed to the target user among the associated users.

[0005] This application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described information processing method.

[0006] The information processing method and electronic device provided in this application, when a business event triggers the message notification condition, first determine the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform, through pre-configured message platform mapping relationships and message user mapping relationships. Based on this, pre-filtering analysis is performed. Only when both the availability status and subscription status meet the message generation conditions is internal message data generated and displayed as needed. This shifts the message filtering timing from after message generation to before message generation, avoiding the generation and storage of redundant messages. At the same time, based on the dual-dimensional precise message control of platform version and user role, it solves the problems of mixed message types under multiple platform versions and the inability of users with different roles to configure the message receiving range as needed. Attached Figure Description

[0007] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0008] Figure 1 A flowchart illustrating the first information processing method provided in this application embodiment; Figure 2 A flowchart illustrating the second information processing method provided in this application embodiment; Figure 3 A general flowchart illustrating a specific information processing method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application. Detailed Implementation

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

[0010] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0011] As enterprise software platforms expand in scale and increase in functional modules, they need to communicate various monitoring, task, service, and maintenance notifications to users. Internal messaging, as a platform-wide notification method, is widely used in the message center functions of various software platforms due to its advantages such as not relying on external operators, flexible configuration, and ability to support rich text content. Users can view relevant internal messages through the message center to obtain information such as task progress, service status, and system alarms.

[0012] In related technologies, in-site message management mainly adopts a push architecture, where the message sender determines the recipients. Specifically, the backend configures message templates and push rules, and after a message is generated, it is sent to the target client according to the push type configuration (specifying a single user or a selected group). Under this architecture, message generation and distribution are dominated by the sender, and users passively receive messages after they are generated. The message's reception range is determined by the sender selecting a single user or a selected group during the push process.

[0013] However, the above push architecture has the following structural flaws: Firstly, this architecture generates messages first and then filters them, which is a post-filtering mode. User receiving preferences do not participate in the message generation decision and cannot be persistently saved. Each time a message is sent, the recipient group needs to be re-determined, resulting in high system overhead and an inability to respond to dynamic adjustments in user message receiving preferences.

[0014] Secondly, the granularity of user segmentation is coarse, only supporting segmentation of single users or selected groups, and it is not deeply coupled with the platform's role system, so users with different roles cannot configure the message receiving range as needed.

[0015] Third, the lack of a message type management mechanism under the multi-version platform means that the message type sets corresponding to different versions are not distinguished by boundaries, resulting in mixed message types across versions and messages from non-platform functional modules still being generated and displayed, causing platform data redundancy and waste of storage resources.

[0016] To address the problems in related technologies, this application introduces a two-dimensional pre-filtering judgment based on "message platform mapping relationship" and "message user mapping relationship" before message generation. This pre-determines the availability status of the message type and platform version corresponding to the business event, as well as the subscription status of the message type and associated user. Internal message data is only generated when both statuses meet the message generation conditions, and displayed as needed. This shifts the filtering timing forward, eliminates redundant message generation and storage from the source, and enables boundary control of message types and fine-grained subscription configuration based on roles across multiple platform versions.

[0017] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] Figure 1 This is a flowchart illustrating the first information processing method provided in the embodiments of this application.

[0019] like Figure 1 As shown, the method includes the following steps: Step 101: When a business event under the business platform meets the message notification conditions, based on the pre-configured message platform mapping relationship and message user mapping relationship, determine the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform.

[0020] In the embodiments of this application, the business platform is a software platform that deploys an in-site message management system, such as an Artificial Intelligence (AI) platform, which includes multiple functional modules and a message center. The business platform exists in multiple versions (e.g., standard version, enterprise version), each with different user roles (e.g., super administrator, system administrator, ordinary user, group administrator). It integrates functional modules such as model development, model management, inference services, tool management, service aggregation, application marketplace, application development, and business data. The monitoring and management module includes a message center function to handle notifications for various monitoring, task, service, and maintenance messages within the platform.

[0021] Business events refer to events generated by various functional modules during the operation of the business platform that may trigger message notifications, such as task failure, service exception, operation and maintenance alarm, approval completion, etc.

[0022] Message notification conditions refer to pre-defined conditions used to determine whether a business event needs to trigger an in-site messaging process.

[0023] The message platform mapping relationship refers to the pre-configured mapping relationship used to represent the available relationships between different message types and different platform versions.

[0024] Message user mapping relationship refers to a pre-configured mapping relationship used to represent the subscription relationship between different users and different message types.

[0025] Message type refers to the classification identifier of business events in the message management system, such as task alarm, operation and maintenance alarm, application approval, etc.

[0026] The visible status, or version availability status, refers to whether the message type is available in the current platform version and whether it is allowed to be displayed and subscribed to.

[0027] Subscription status refers to whether the associated user (i.e., different user roles in the business platform) has subscribed to this message type.

[0028] When a business event on the business platform meets the message notification conditions, the system first determines the message type corresponding to the business event; then, based on the pre-configured message platform mapping relationship, it determines the visibility status between the message type and the current platform version; and simultaneously, based on the pre-configured message user mapping relationship, it determines the subscription status between the message type and the associated user of the business platform.

[0029] Step 102: Based on the visibility and subscription status, perform pre-filtering analysis on business events to determine whether the business events meet the message generation conditions.

[0030] In the embodiments of this application, pre-filtering analysis refers to the filtering analysis process that determines whether an in-site message needs to be generated based on the visibility and subscription status of the business event before the message is generated.

[0031] Based on the visibility and subscription status obtained in step 101, pre-filtering analysis is performed on business events: if the message type is unavailable in the current platform version, or the target user has not subscribed to the message type, the message generation process is terminated directly, and no in-site message data or storage records are generated. In-site message generation and storage operations are only performed when the message type passes the version-level pre-check and the target user has subscribed.

[0032] Compared to post-filtering architecture, pre-filtering architecture moves the filtering operation forward to before message generation, avoiding the generation and storage of invalid messages, and reducing database write pressure and storage space consumption. When none of the users of a certain message type have subscribed, no data will be generated for that type of message even if the triggering condition is met, thus achieving source governance of message redundancy.

[0033] Step 103: If the business event meets the message generation conditions, generate the in-site message data of the business event to display the in-site message data to the target user among the associated users.

[0034] In the embodiments of this application, "internal messaging" refers to message notification data generated and stored within the business platform and displayed to the target user within the platform's message center. Unlike external communication methods such as SMS, email, and third-party push notifications, internal messaging does not rely on external operators or third-party channels; instead, message generation, storage, and display are completed within the platform itself.

[0035] Internal message data refers to message data displayed to target users, including title, content, and target user identifier. Target users are those among the associated users who have subscribed to this internal message data.

[0036] When a business event meets the message generation conditions, the system generates internal message data for that business event and associates the internal message data with the target user to display the internal message data to the target user among the associated users. Since the internal message data is generated only after pre-filtering analysis, messages that do not meet the message generation conditions will not generate data, thus achieving source control of message redundancy.

[0037] In summary, this application, when a business event triggers message notification conditions, first determines the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform, through pre-configured message platform mapping relationships and message user mapping relationships. Based on this, pre-filtering analysis is performed. Only when both the availability status and subscription status meet the message generation conditions is internal message data generated and displayed as needed. This shifts the message filtering timing from after message generation to before message generation, avoiding the generation and storage of redundant messages. At the same time, based on the dual-dimensional precise message control of platform version and user role, it solves the problems of mixed message types under multiple platform versions and the inability of users with different roles to configure the message receiving range as needed.

[0038] The following provides a further explanation of the message platform mapping relationship and message user mapping relationship in this application.

[0039] In some embodiments, based on pre-configured message platform mapping relationships and message user mapping relationships, the visibility status between the message type corresponding to a business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform, are determined. Before this, the message platform mapping relationships and message user mapping relationships need to be constructed. The process of constructing the message platform mapping relationships is as follows: (1) Determine the platform version of the business platform based on the deployment configuration file of the business platform.

[0040] In the embodiments of this application, the deployment configuration file is a configuration file used when the business platform is deployed, which includes a version identifier field.

[0041] Specifically, during the platform deployment phase, the system reads the deployment configuration file inais.yml, extracts the version identifier field install_method, and determines the platform version of the current business platform based on the value of this field.

[0042] (2) Based on the version identifier and message type definition information of the platform version, determine the set of message types and the set of message type groups supported by the platform version, and store the set of message types and the set of message type groups in the message type table and the message type group table respectively.

[0043] Among them, message type definition information refers to metadata that is pre-maintained and records the available relationships between each message type and each platform version.

[0044] The message type set refers to the set of all message types supported by the current platform version. The message type group set refers to the set of all message type groups supported by the current platform version.

[0045] The system determines the platform version identifier based on the value of the version identifier field in the deployment configuration file. Based on the version identifier, it filters the message types and message type groups supported by the platform version from the message type definition information, writes the determined message type data into the message type table (defined as the t_mo_message_type table in this application), and writes the message type group data into the message type group table (defined as the t_mo_message_group table in this application), thus completing the initialization of the version-adaptive message space.

[0046] In some embodiments, the message type table includes at least one of the following fields: business event identifier field, message type group identifier field, message type name field, and version visibility field.

[0047] The business event identifier (id) field uniquely identifies the business event. The message type group identifier (group_id) field identifies the message type group to which the message type belongs. The message type name (name) field records the name of the message type. The version visibility field (epai_visible / mix_visible / train_visible) indicates whether the message type is available in different platform versions. This application uses E... Taking versions (epai), enterprise versions (mix), and training versions (train) as examples, the display and subscription permissions of different types of messages in specific versions are controlled through the version visibility field. The message type t_mo_message_type table records the metadata of all message types in the platform.

[0048] For example, the field definitions of the message type t_mo_message_type table are shown in Table 1: Table 1 t_mo_message_type

[0049] The `id` field serves as the primary key, uniquely identifying a business event; the `group_id` field is used to associate with the message type group `t_mo_message_group` table, determining the message type group to which the message type belongs; the `name` field records the name of the message type; and the `epai_visible`, `mix_visible`, and `train_visible` fields are used to identify the message type in E... Whether it is available in the version, enterprise edition, and training edition. A value of 1 indicates that it is available, and a value of 0 indicates that it is not available.

[0050] In some embodiments, the message type group table includes at least one of the following fields: business event identifier field, message type group name field, and version visibility field.

[0051] The "name" field records the name of the message type group. The "t_mo_message_group" table records the grouping information for message types, supporting the organization and management of message types according to business dimensions.

[0052] For example, the field definitions of the message type group t_mo_message_group table are shown in Table 2: Table 2 t_mo_message_group

[0053] (3) Integrate the message type table and the message type group table to obtain the message platform mapping relationship.

[0054] In the embodiments of this application, the message type table is used to record each message type and its version visibility, and the message type group table is used to record each message type group and its version visibility. The two are associated through the message type group identifier field, and together they constitute the available relationship between message type and platform version, that is, the message platform mapping relationship.

[0055] By defining message type tables and message type group tables, each platform version only displays and provides message types belonging to the functional modules of its own version; message types not belonging to this version do not appear in the user subscription interface. For example, E The agent, knowledge base, and application approval message types in the version will not be displayed in the Enterprise and Standard editions; the workflow message types in the Enterprise and Standard editions will not be displayed in E. As shown in the version, it achieves adaptive matching between the message type space and the platform version, so that the message center of each version only displays the message types corresponding to the functional modules of this version, avoiding cross-version message type mixing, reducing the user's filtering cost, and providing a version-level usability basis for subsequent pre-filtering judgment.

[0056] In some embodiments, the process of constructing message user mapping relationships is as follows: (1) In response to the associated user's subscription configuration instructions for different message types, obtain the associated user's message subscription data.

[0057] In the embodiments of this application, associated users refer to users with different roles in the business platform (such as super administrators, system administrators, ordinary users, group administrators), that is, users within the platform who may receive in-site messages.

[0058] This application provides message subscription management functionality in the message center module, allowing users with different roles to independently configure the message types they are authorized to subscribe to. Specifically, a new message subscription management entry point is added to the message center module. Users can view all subscribing message types in the current platform version through this entry point. The subscribing message types are constrained by the version dimension of the message platform mapping relationship, meaning only message types belonging to the functional modules of the current platform version are displayed. Users can set whether to receive each message type, thus generating subscription configuration instructions for different message types.

[0059] In some embodiments, the business platform presets differentiated default subscription configurations for different roles. For example, the default configuration for system administrators includes subscriptions to operation and maintenance alarm messages, while the default configuration for ordinary users does not include operation and maintenance alarm messages. Associated users can make personalized adjustments based on the default configurations, and the adjusted configurations override the default settings. The system then obtains the final message subscription data for each associated user accordingly.

[0060] (2) Store the message subscription data in the user subscription configuration table to obtain the message user mapping relationship based on the user subscription configuration table.

[0061] In the embodiments of this application, the system writes message subscription data into the user subscription configuration table (defined as the t_mo_user_message table in this application) through a predefined interface. The table records key fields such as user ID, message type ID, and whether the message has been received, forming a persistently stored user-message type subscription relationship. This subscription record serves as the core judgment basis for the pre-filtering mechanism and is queried and referenced during the internal message generation stage.

[0062] In some embodiments, the user subscription configuration table includes at least one of the following fields: business event identifier field, user identifier field, message type identifier field, subscription status field, creation time field, and update time field.

[0063] The subscription configuration includes the following fields: User ID (user_id) identifies the associated user; Message Type ID (message_type_id) identifies the message type for which the subscription configuration is applied; Subscription Status (is_receive) indicates whether the associated user receives the message type; Creation Time (created_at) records the creation time of the subscription configuration; and Update Time (updated_at) records the update time of the subscription configuration.

[0064] For example, the field definitions of the user subscription configuration t_mo_user_message table are shown in Table 3: Table 3 t_mo_user_message

[0065] Through the above methods, the system completes the construction of message user mapping relationships, enabling persistent storage of user subscription preferences, which serve as the basis for user subscription status in subsequent pre-filtering judgments, thereby realizing a message management mechanism driven by the receiving end's subscription configuration to generate messages.

[0066] Figure 2 A flowchart illustrating the second information processing method provided in this application embodiment is further shown. Based on Figure 1 The illustrated embodiment further defines steps 101, 102, and 103, wherein step 101 includes steps 201, 202, and 203; step 102 includes steps 204 and 205; and step 103 includes steps 206 and 207, as shown. Figure 2 As shown, the method includes the following steps.

[0067] Step 201: Determine the message type corresponding to the business event.

[0068] In the embodiments of this application, after a business event triggers the message notification condition, the system determines the message type corresponding to the business event from the pre-configured correspondence between events and message types based on the business event identifier carried by the business event.

[0069] In some embodiments, the message platform mapping relationship includes a version visibility field for different message types under different platform versions, and the message user mapping relationship includes a subscription status field for different message types under different users. That is, the message platform mapping relationship records the version visibility of each message type in the form of "message type - platform version", and the message user mapping relationship records the subscription status of each user for each message type in the form of "message type - user".

[0070] Step 202: Determine the visibility status from the version visibility field based on the message type identifier and platform version of the message type.

[0071] In the embodiments of this application, the message type identifier is used to uniquely identify the message type. The platform version refers to the current version of the business platform, which is determined according to the deployment configuration file of the business platform.

[0072] The system determines the visibility status of a message type based on the message type identifier and the current platform version, from the version visibility field of the complete message type table (including the message type table and the message type group table). For example, when the current platform version is Enterprise Edition, the system reads the mix_visible field from the message type record; if the value of this field is 1, the visibility status is visible; if it is 0, the visibility status is invisible.

[0073] Step 203: Determine the subscription status from the subscription status field based on the message type identifier and the associated user identifier of the associated user.

[0074] In embodiments of this application, the system queries the subscription status of a message type from the subscription status field of the user subscription configuration table, based on the message type identifier and the associated user identifier. For example, the system searches for records in the t_mo_user_message table where both user_id and message_type_id match, and reads their is_receive field; if the value of this field is 1, the subscription status is subscribed; if it is 0, the subscription status is not subscribed. Since the user subscription configuration table is stored in the form of a user-message type subscription relationship matrix, this subscription status represents the associated user's willingness to subscribe to the message type.

[0075] Step 204: If the visibility status indicates that the message type is not visible in the platform version, or the subscription status indicates that the target user has not subscribed to the message type, determine that the business event does not meet the message generation conditions.

[0076] In the embodiments of this application, for an in-system message to reach a target user, two conditions must be met simultaneously: the message type belongs to the complete set of message types for the current platform version, and the target user's role has subscribed to that message type. If either condition is not met, the message is intercepted during the pre-filtering stage.

[0077] Specifically, business events are pre-filtered based on visibility and subscription status: if the visibility status is invisible, meaning the message type is unavailable in the current platform version, then regardless of the subscription status, the current business event is determined not to meet the message generation conditions; if the subscription status is unsubscribed, meaning the target user has not subscribed to the message type, then regardless of the visibility status, the business event is determined not to meet the message generation conditions.

[0078] In this case, the system terminates the process of generating internal message data, neither generating internal message data nor writing it into the internal message storage table, thereby achieving pre-filtering before message generation and eliminating redundant data from the source.

[0079] Step 205: If the visibility status indicates that the message type is visible in the platform version and the subscription status indicates that the target user has subscribed to the message type, then determine that the business event meets the message generation conditions.

[0080] In the embodiments of this application, when the visibility status is visible and the subscription status is subscribed, it is determined that the business event meets the message generation conditions, and the subsequent in-site message generation step is initiated. At this time, the message type is both within the functional scope of the current platform version and subscribed to by the target user, satisfying the cross-constraint of the two-dimensional subscription space.

[0081] Step 206: Generate the site message data for the business event and store the site message data in the site message storage table.

[0082] In the embodiments of this application, new in-site data for business events is generated only if both version-level pre-check (whether the message type is available in the current version) and role-level pre-check (whether the target user has subscribed to the message type) are simultaneously satisfied. Furthermore, only in-site message data that passes the pre-filtering is written to the in-site message storage table (defined as the t_mo_mail table in this application). The in-site message storage table establishes the association between in-site messages and target users through user identifiers. Messages that do not pass the pre-filtering are not stored, achieving precise pruning at the storage level.

[0083] In some embodiments, the internal message storage table includes at least one of the following fields: business event identifier field, user identifier field, message type identifier field, internal message title field, internal message content field, and creation time field.

[0084] The internal message is uniquely identified by the following fields: Business Event Identifier (id); User Identifier (user_id); Message Type Identifier (message_type_id); Internal Message Title (title); Internal Message Content (content); and Creation Time (created_at).

[0085] For example, the field definitions of the t_mo_mail table in the site's internal mail storage are shown in Table 4: Table 4 t_mo_mail table

[0086] The user_id field is used to associate internal messages with target users, so that when a user logs into the message center, the internal message data associated with them can be displayed.

[0087] It's understandable that the internal message data stored in the internal message storage table has all passed the message generation condition check. That is, only business events that pass both version-level and role-level pre-checks and meet the message generation conditions will have their internal message data written to the internal message storage table; internal message data that fails the message generation condition check will not be written to the table. Therefore, there is no redundant data in the internal message storage table. When a user logs into the message center, the system can directly display the associated internal message data based on their user identifier without further filtering.

[0088] Step 207: In response to the target user logging into the message center, based on the target user's target user identifier, display the internal message data associated with the target user identifier stored in the internal message storage table to the target user.

[0089] In the embodiments of this application, the message center refers to the functional module in the business platform used to display internal messages.

[0090] When a target user logs into the message center, the system uses the target user's identifier as a basis to query the internal message storage table for internal message data associated with that identifier and displays it to the target user. Since the internal message storage table stores internal message data that has already passed pre-filtering and has been accurately associated with the target user's identifier, there is no need for further filtering during the display stage; internal message data within the target user's subscription range can be directly displayed.

[0091] Furthermore, to help better understand the information processing methods provided in this application, such as Figure 3 As shown, Figure 3This is a general flowchart of a specific information processing method provided in an embodiment of this application. The general process includes a platform deployment stage, a subscription configuration stage, a pre-filtering judgment stage, a precise storage stage, and an on-demand display stage.

[0092] Reference Figure 3 During the platform deployment phase, the system reads the deployment configuration file inais.yml of the business platform and extracts the value of the install_method field (version identifier field) as the platform version identifier. Based on the platform version identifier, it initializes the t_mo_message_type table (message type table) and the t_mo_message_group table (message type group table), marking the version visibility of each message type and message type group. This completes the construction of the version message type set V (corresponding to the message platform mapping relationship, including the t_mo_message_type table and the t_mo_message_group table). This set V limits the range of message types available under the current platform version; message types from functional modules outside this version are not included.

[0093] During the subscription configuration phase, users configure message subscriptions in the message center, independently selecting the message types they wish to receive and setting the receiving status (is_receive) for each message type. The subscription configuration is written to the t_mo_user_message table (user subscription configuration table), forming a "role-message type" subscription matrix S. Since the message types that users can subscribe to are constrained by the complete set V of version message types, the subscription matrix S is a subset of the complete set V.

[0094] During the pre-filtering and judgment phase, when a business event triggers the message notification condition, the system sequentially performs version-level pre-checks and role-level pre-checks: the version-level pre-check determines whether the message type belongs to the complete message type set V of the current platform version; if not, generation is terminated. The role-level pre-check determines whether the target role user has subscribed to the message type, i.e., whether it belongs to the subscription matrix S; if not, generation is terminated. If either dimension pre-check fails, the internal message is neither generated nor stored.

[0095] During the precise storage phase, the system generates internal message data only when both version-level and role-level pre-checks pass. The generated content includes the title, content, and target user ID. The generated internal message data is written to the `t_mo_mail` table (internal message storage table) and associated with the target user through the target user identifier. Since messages that fail the pre-filtering are not written to the storage table, this phase achieves precise storage, and there is no redundant data in the storage table.

[0096] During the on-demand display phase, when a user logs into the message center, the system queries the t_mo_mail table for the internal messages associated with that user and displays them. Since precise pruning has been completed during the storage phase, the displayed data is the internal messages within the user's subscription range, and no further filtering is required.

[0097] In summary, the technical effects of the information processing method of this application are as follows: 1) This application realizes the transformation of the message management architecture from a push architecture to a subscription architecture. It uses user subscription configuration as a pre-driving factor for message generation, enabling persistent storage of user receiving preferences and their participation in message generation decisions. This achieves a shift from sender-driven to receiver-driven mode, overcoming the shortcomings of related technologies where user receiving preferences cannot be persisted and the recipient group needs to be re-evaluated for each transmission.

[0098] 2) The filtering timing is shifted from after message generation to before message generation. This application performs version-level and role-level pre-checks in the internal message generation interface, and generates internal message data only when both states meet the message generation conditions; messages that fail the pre-filtering are not generated or stored, thereby eliminating the generation and storage of redundant messages from the source, reducing database write pressure and storage space usage.

[0099] 3) Implement adaptive boundary control of message types across multiple platform versions. This application constrains the availability relationship between message types and platform versions through message platform mapping relationships, ensuring that each platform version only generates and displays message types belonging to the functional modules of its own version. Message types from other versions do not appear in the user subscription interface, thus solving the problem of mixed message types across multiple platform versions.

[0100] 4) Implement role-based fine-grained message subscription management. This application establishes a subscription relationship matrix between users and message types through message user mapping, supporting users with different roles to configure the message receiving range as needed within the available range of this version, thus solving the problems of coarse-grained user segmentation and lack of deep coupling with the role system in related technologies.

[0101] 5) Achieve persistent subscription configuration: User subscription preferences are persistently stored and can be modified at any time through the message center, with the modified configuration taking effect immediately. Compared to the push architecture, which re-determines the target audience every time a message is sent, the subscription architecture offers more efficient and flexible configuration management.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0103] Embodiments of this application also provide an information processing device 400. Figure 4 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application, as shown below. Figure 4 As shown, it includes: The determination module 410 is used to determine the visibility status between the message type corresponding to the business event and the platform version of the business platform, and the subscription status between the message type and the associated user of the business platform, based on the pre-configured message platform mapping relationship and message user mapping relationship, when the business event under the business platform meets the message notification conditions. Analysis module 420 is used to perform pre-filtering analysis on the business event based on the visibility state and the subscription state to determine whether the business event meets the message generation conditions; The display module 430 is used to generate in-site message data of the business event when the business event meets the message generation conditions, so as to display the in-site message data to the target user among the associated users.

[0104] In some embodiments, the message platform mapping relationship includes a version visibility field for different message types under different platform versions, and the message user mapping relationship includes a subscription status field for different message types under different users. The determining module 410 is used to: determine the message type corresponding to the business event; determine the visibility status from the version visibility field based on the message type identifier and platform version; and determine the subscription status from the subscription status field based on the message type identifier and the associated user identifier of the associated user.

[0105] In some embodiments, the apparatus further includes: a configuration module, configured to determine the visibility status between the message type corresponding to a business event and the platform version of the business platform, and the subscription status between the message type and the associated user of the business platform, based on pre-configured message platform mapping relationships and message user mapping relationships. Prior to this, the platform version of the business platform is determined based on the deployment configuration file of the business platform; the set of message types and the set of message type groups supported by the platform version are determined based on the version identifier of the platform version and the message type definition information, and the set of message types and the set of message type groups are stored in the message type table and the message type group table, respectively; and the message type table and the message type group table are integrated to obtain the message platform mapping relationship.

[0106] In some embodiments, the message type table includes at least one of the following fields: business event identifier field, message type group identifier field, message type name field, and version visibility field; the message type group table includes at least one of the following fields: business event identifier field, message type group name field, and version visibility field.

[0107] In some embodiments, the configuration module is configured to: determine the visibility status between the message type corresponding to the business event and the platform version of the business platform, and the subscription status between the message type and the associated user of the business platform, based on the pre-configured message platform mapping relationship and message user mapping relationship; prior to this, in response to the subscription configuration instructions of the associated user for different message types, obtain the message subscription data of the associated user; and store the message subscription data in the user subscription configuration table to obtain the message user mapping relationship based on the user subscription configuration table.

[0108] In some embodiments, the user subscription configuration table includes at least one of the following fields: business event identifier field, user identifier field, message type identifier field, subscription status field, creation time field, and update time field.

[0109] In some embodiments, the analysis module 420 is configured to: determine that a business event meets the message generation conditions when the visibility status indicates that the message type is visible in the platform version and the subscription status indicates that the target user has subscribed to the message type; and determine that a business event does not meet the message generation conditions when the visibility status indicates that the message type is not visible in the platform version or the subscription status indicates that the target user has not subscribed to the message type.

[0110] In some embodiments, the display module 430 is configured to: generate intra-site message data of a business event when the business event meets the message generation conditions, and store the intra-site message data in an intra-site message storage table; and, in response to a target user logging into the message center, display the intra-site message data stored in the intra-site message storage table and associated with the target user identifier to the target user based on the target user identifier of the target user.

[0111] In some embodiments, the internal message storage table includes at least one of the following fields: business event identifier field, user identifier field, message type identifier field, internal message title field, internal message content field, and creation time field.

[0112] For a description of the features in the embodiment corresponding to the information processing device, please refer to the relevant description in the embodiment corresponding to the information processing method, which will not be repeated here.

[0113] Embodiments of this application also provide an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps in any of the above-described information processing method embodiments.

[0114] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described information processing method embodiments when it is run.

[0115] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0116] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described information processing method embodiments.

[0117] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described information processing method embodiments.

[0118] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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.

[0119] The foregoing has provided a detailed description of an information processing method, apparatus, electronic device, storage medium, and product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An information processing method, characterized in that, The method includes: When a business event on the business platform meets the message notification conditions, based on the pre-configured message platform mapping relationship and message user mapping relationship, the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform are determined. Based on the visibility state and the subscription state, the business event is pre-filtered and analyzed to determine whether the business event meets the message generation conditions. If the business event meets the message generation conditions, the site message data for the business event is generated to be displayed to the target user among the associated users.

2. The method according to claim 1, characterized in that, The message platform mapping relationship includes a version visibility field for different message types across different platform versions, and the message user mapping relationship includes a subscription status field for different message types across different users. The determination of the visibility status between the message type corresponding to the business event and the platform version of the business platform, and the subscription status between the message type and the associated user of the business platform, based on the pre-configured message platform mapping relationship and message user mapping relationship, includes: Determine the message type corresponding to the business event; Based on the message type identifier of the message type and the platform version, the visibility status is determined from the version visibility field; The subscription status is determined from the subscription status field based on the message type identifier and the associated user identifier of the associated user.

3. The method according to claim 1, characterized in that, The method, based on pre-configured message platform mapping relationships and message user mapping relationships, determines the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform. Prior to this, the method includes: Based on the deployment configuration file of the business platform, determine the platform version of the business platform; Based on the version identifier and message type definition information of the platform version, determine the set of message types and the set of message type groups supported by the platform version, and store the set of message types and the set of message type groups in the message type table and the message type group table, respectively. By integrating the message type table and the message type group table, the message platform mapping relationship is obtained.

4. The method according to claim 3, characterized in that, The message type table includes at least one of the following fields: business event identifier field, message type group identifier field, message type name field, and version visibility field; The message type group table includes at least one of the following fields: business event identifier field, message type group name field, and version visibility field.

5. The method according to claim 1, characterized in that, The method, based on pre-configured message platform mapping relationships and message user mapping relationships, determines the visibility status between the message type corresponding to the business event and the platform version of the business platform, as well as the subscription status between the message type and the associated user of the business platform. Prior to this, the method includes: In response to the associated user's subscription configuration instructions for different message types, obtain the associated user's message subscription data; The message subscription data is stored in the user subscription configuration table to obtain the message user mapping relationship based on the user subscription configuration table.

6. The method according to claim 5, characterized in that, The user subscription configuration table includes at least one of the following fields: Business event identifier field, user identifier field, message type identifier field, subscription status field, creation time field, and update time field.

7. The method according to claim 1, characterized in that, The step of performing pre-filtering analysis on the business event based on the visibility state and the subscription state to determine whether the business event meets the message generation conditions includes: If the visibility status indicates that the message type is visible in the platform version and the subscription status indicates that the target user has subscribed to the message type, then the business event is determined to meet the message generation conditions. If the visibility status indicates that the message type is not visible in the platform version, or the subscription status indicates that the target user has not subscribed to the message type, it is determined that the business event does not meet the message generation conditions.

8. The method according to claim 1, characterized in that, When the business event meets the message generation conditions, generating in-site message data for the business event to display the in-site message data to the target user among the associated users includes: If the business event meets the message generation conditions, the internal message data of the business event is generated and stored in the internal message storage table. In response to the target user logging into the message center, based on the target user's target user identifier, the site message data associated with the target user identifier stored in the site message storage table is displayed to the target user.

9. The method according to claim 8, characterized in that, The internal message storage table includes at least one of the following fields: The fields include: Business Event Identifier, User Identifier, Message Type Identifier, Internal Message Title, Internal Message Content, and Creation Time.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the information processing method according to any one of claims 1-9.

Images