A message processing method and apparatus, an electronic device, and a storage medium

Abstract

This application provides a message processing method, apparatus, electronic device, and storage medium, relating to the field of communication technology. The method includes: obtaining a call message, generating a message identifier for the call message, generating a message event according to the message identifier, a business module identifier, and a method field, following an event bus communication mechanism; sending the message event to the message processor of the target business module via the event bus, obtaining the result message returned by the message processor, and, if the message identifiers match, returning the processing result to the triggerer of the call message. The message manager registers an event with the event bus for the business module, i.e., generates a message event. Message identifiers are dynamically generated based on business calls for message registration. The message event is sent and the processing result is obtained through the message identifier, instead of registering all the methods and functions of the business module into memory, thus significantly reducing resource waste while achieving reliable message delivery.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a message processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] During business processing, business modules that provide various business services need to pass messages to each other. In the HarmonyOS system, the process of business modules passing messages includes: registering the functions of the subscriber class to generate subscriber objects through reflection, adding the subscriber objects to memory, and then calling the corresponding business module's method functions through the subscriber objects in memory to obtain the processing results.

[0003] In this message processing method, all subscriber class functions of each business module are registered in memory. In actual business processing, most of these functions may not be called, and it is very likely that 90% of the functions will not be used. This message processing method will cause a waste of resources. Summary of the Invention

[0004] The purpose of this application is to provide a message processing method, apparatus, electronic device, and storage medium to reduce resource waste in the message processing process. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a message processing method applied to a pre-set message manager, the method comprising:

[0006] Upon receiving a call message, a message identifier for the call message is generated, wherein the call message includes at least a business module identifier and a method field corresponding to the method function to be called;

[0007] Based on the message identifier, the business module identifier, and the method field, a message event is generated according to the event bus communication mechanism;

[0008] The message event is sent to the message processor of the target service module based on the event bus, wherein the target service module is the service module corresponding to the service module identifier;

[0009] Obtain the result message returned by the message processor, wherein the result message includes at least the processing result obtained by calling the method function based on the method field to perform business processing and the message identifier;

[0010] If the message identifier included in the result message matches the generated message identifier, the processing result is returned to the triggerer of the call message.

[0011] Optionally, the step of generating the message identifier of the call message includes:

[0012] Generate a random number corresponding to the call message;

[0013] Based on the current timestamp and the random number, a message identifier for the call message is generated according to a preset format.

[0014] Optionally, after the step of generating the message identifier of the invocation message, the method further includes:

[0015] The message identifier is stored as registration information in a temporary cache;

[0016] Register a timer and a listener, and after sending the message event to the message processor of the target business module, record the waiting time of the listener through the timer, wherein the waiting time is the time to wait for the result message returned by the message processor;

[0017] If the listener detects a result message returned by the message processor and the waiting time has not reached the preset time, the step of obtaining the result message returned by the message processor is executed.

[0018] If the waiting time reaches the preset time, the registration information, the timer, and the listener are cleared.

[0019] Optionally, before the step of returning the processing result to the triggerer of the invocation message, the method further includes:

[0020] The listener parses the result message to determine the message identifier and processing result included in the result message;

[0021] If the listener determines that the parsed message identifier matches the registration information, it executes the step of returning the processing result to the triggerer of the call message;

[0022] If the listener determines that the parsed message identifier does not match the registration information, it continues to wait for the next result message. If the next result message is detected, it returns to the step of parsing the result message through the listener until the waiting time reaches the preset time.

[0023] Optionally, the step of sending the message event to the message processor of the target service module based on the event bus includes:

[0024] The business module identifier is used as the event routing identifier, and message distribution is performed based on the event bus to send the message event to the message processor of the target business module.

[0025] Optionally, the call message is generated by calling a method of the singleton class and passing in agreed parameters, wherein the agreed parameters include at least the business module identifier and the method field corresponding to the method function to be called; the message manager is a method instance of the singleton class.

[0026] Secondly, embodiments of this application provide a message processing method applied to a pre-set message processor in a business module, the method comprising:

[0027] Obtain message events sent by a pre-set message manager based on the event bus, wherein the message event includes at least a message identifier and a method field corresponding to the method function to be called;

[0028] Based on the method fields, the method function is called to perform business processing and obtain the processing result;

[0029] A result message is sent to the message manager, wherein the result message includes at least the processing result and a message identifier.

[0030] Optionally, the step of calling a method function based on the method field to perform business processing and obtain the processing result includes:

[0031] The message event is parsed to obtain the method field;

[0032] The method function to be called is determined based on the method field, and the method function is called to perform business processing and obtain the processing result.

[0033] Thirdly, embodiments of this application provide a message processing apparatus applied to a pre-set message manager, the apparatus comprising:

[0034] A message identifier generation unit is used to generate a message identifier for a call message when a call message is obtained, wherein the call message includes at least a business module identifier and a method field corresponding to the method function to be called;

[0035] The message event generation unit is used to generate a message event according to the message identifier, the business module identifier, and the method field, in accordance with the event bus communication mechanism.

[0036] A message event sending unit is used to send the message event to the message processor of the target service module based on the event bus, wherein the target service module is the service module corresponding to the service module identifier;

[0037] The result message acquisition unit is used to acquire the result message returned by the message processor, wherein the result message includes at least the processing result obtained by calling the method function based on the method field to perform business processing and a message identifier;

[0038] The message identifier matching unit is used to return the processing result to the triggerer of the call message if the message identifier included in the result message matches the generated message identifier.

[0039] Fourthly, embodiments of this application provide a message processing apparatus, applied to a pre-set message processor in a business module, the apparatus comprising:

[0040] The message event receiving unit is used to acquire message events sent by the pre-set message manager based on the event bus, wherein the message event includes at least a message identifier and a method field corresponding to the method function to be called;

[0041] The message event processing unit is used to call the method function based on the method field to perform business processing and obtain the processing result;

[0042] The result message sending unit is used to send a result message to the message manager, wherein the result message includes at least the processing result and a message identifier.

[0043] Fifthly, embodiments of this application provide an electronic device, including:

[0044] Memory, used to store computer programs;

[0045] A processor, when executing a program stored in memory, implements the method described in either the first or second aspect above.

[0046] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in either the first or second aspect above.

[0047] Beneficial effects of the embodiments in this application:

[0048] In the solution provided in this application embodiment, a pre-set message manager, upon receiving a call message, can generate a message identifier for the call message. The call message includes at least a business module identifier and a method field corresponding to the method function to be called. Based on the message identifier, business module identifier, and method field, a message event is generated according to the event bus communication mechanism. The message event is sent to the message processor of the target business module, which is the business module corresponding to the business module identifier, via the event bus. The result message returned by the message processor is obtained. The result message includes at least the processing result obtained by calling the method function based on the method field and the message identifier. If the message identifier included in the result message matches the generated message identifier, the processing result is returned to the triggerer of the call message. When a call message is received, the message manager registers an event with the event bus for the business module, i.e., generates a message event, and dynamically generates a message identifier for message registration based on the business call. This allows the message event to be sent and the processing result to be obtained from the business module to be obtained through the message identifier, instead of registering all the method functions of the business module into memory. This significantly reduces resource waste while achieving reliable message transmission. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, 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 embodiments can be obtained based on these drawings.

[0050] Figure 1 A flowchart illustrating the first message processing method provided in this application embodiment;

[0051] Figure 2 For based on Figure 1 A flowchart of a memory resource management method according to the embodiment shown;

[0052] Figure 3 For based on Figure 1 A flowchart of a message identifier matching method in the embodiment shown;

[0053] Figure 4 A flowchart illustrating the second message processing method provided in this application embodiment;

[0054] Figure 5 for Figure 4 A specific flowchart of step S402 in the illustrated embodiment;

[0055] Figure 6 For based on Figure 1 A schematic diagram of the system architecture of the embodiment shown;

[0056] Figure 7 This is a schematic diagram of the structure of a first message processing device provided in an embodiment of this application;

[0057] Figure 8 This is a schematic diagram of the structure of a second message processing device provided in an embodiment of this application;

[0058] Figure 9 This is a schematic diagram of the structure of a first electronic device provided in an embodiment of this application. Detailed Implementation

[0059] 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 skilled in the art based on this application are within the scope of protection of this application.

[0060] During business processing, business modules may need to call each other's method functions, and other service modules may also need to call the business module's method functions. Modules need to pass messages to facilitate these method function calls. To reduce resource waste in message processing, embodiments of this application provide a message processing method, apparatus, electronic device, computer-sustainable storage medium, and computer program product.

[0061] First, the first message processing method provided in the embodiments of this application will be introduced. The first message processing method provided in the embodiments of this application can be applied to HarmonyOS, Android system, etc., and is not specifically limited here.

[0062] See Figure 1A message processing method is applied to a pre-set message manager. The method includes: S101, upon receiving a call message, generating a message identifier for the call message, wherein the call message includes at least a business module identifier and a method field corresponding to the method function to be called; S102, generating a message event according to the message identifier, the business module identifier, and the method field, following an event bus communication mechanism; S103, sending the message event to the message processor of a target business module via the event bus, wherein the target business module is the business module corresponding to the business module identifier; S104, obtaining a result message returned by the message processor, wherein the result message includes at least a processing result obtained by calling the method function based on the method field and a message identifier; S105, if the message identifier included in the result message matches the generated message identifier, returning the processing result to the triggerer of the call message. When a call message is received, the message manager registers an event with the event bus for the business module, which generates a message event. It also dynamically generates a message identifier based on the business call for message registration. In this way, the message event is sent and the processing result is obtained from the business module through the message identifier, instead of registering all the methods and functions of the business module into memory. This greatly reduces resource waste while achieving reliable message passing.

[0063] During business processing, when a method function of a certain business module needs to be called, a trigger can initiate a call message. The trigger can be another business module, or a service module outside of that business module, etc., without specific limitations. The call message can be a cross-platform message or an internal system message; both are acceptable.

[0064] The call message includes at least a business module identifier and a method field corresponding to the method function to be called. The business module identifier can be information that uniquely identifies the business module, such as the business module name, and the method field can be information that uniquely identifies the method function, such as the method function name.

[0065] Upon receiving a call message, the message manager can generate a message identifier for that call message, which uniquely identifies the call message. Then, in step S102 above, a message event is generated based on the message identifier, the business module identifier, and the method field, according to the event bus communication mechanism.

[0066] In one implementation, the message manager can generate message events according to the event naming conventions specified by the native platform's event bus communication mechanism, based on the message identifier, business module identifier, and method field. This satisfies the requirements of the event bus communication mechanism and ensures that message events can be transmitted smoothly. For example, the event naming convention can be: ezp_native_message_{moduleName}.

[0067] After a message event is generated, the message manager can forward it, that is, send the message event to the message handler of the target business module via the event bus. The target business module is the business module corresponding to the business module identifier. Because the message event conforms to the requirements of the event bus communication mechanism, message event forwarding can be achieved through the event bus, replacing the traditional routing page redirection method.

[0068] After the message handler of the target business module listens for a message event, it can call the method function to perform business processing based on the method fields included in the message event, obtain the processing result, assemble the processing result and message identifier to obtain the result message, and return the result message to the message handler.

[0069] After receiving the result message returned by the message processor, the message manager can compare the message identifier included in the result message with the generated message identifier to determine if they match. For example, if the message identifier included in the result message is the same as the generated message identifier, then they can be determined to match.

[0070] If the message manager determines that the message identifier included in the result message matches the generated message identifier, it can execute step S105 above, that is, return the processing result to the triggerer of the call message. In this way, the triggerer of the call message can obtain the processing result required by the business process.

[0071] In this embodiment, a unified communication standard, namely the event bus communication mechanism, is provided. A unified API (Application Programming Interface) is provided to obtain call messages. All business modules follow the same communication standard, reducing learning costs and improving development efficiency. Furthermore, the event bus communication mechanism, being based on a publish-subscribe pattern, allows components (modules) to pass events and interact with data without direct dependencies. Module A only needs to publish events, and module B independently subscribes to events; message passing can be achieved without mutual references, thus achieving complete decoupling between business modules.

[0072] In one possible implementation, the step of generating the message identifier of the call message described above may include: generating a random number corresponding to the call message; and generating a message identifier of the call message according to a preset format based on the current timestamp and the random number. Since the current timestamp ensures the time-specificity of the message identifier, and the random number ensures the uniqueness of the message identifier even when multiple call messages are concurrent, this implementation can support accurate matching of message identifiers in the case of multiple concurrent call messages.

[0073] To uniquely identify each call message, the message manager can generate a unique identifier, or MessageID, for each call message. The MessageID can be generated by combining the current timestamp with a random number. Upon receiving a call message, the message manager can generate a corresponding random number. In one implementation, the message manager can call a random number generation function to generate the random number; however, other methods can also be used to generate random numbers, and no specific limitation is made here.

[0074] After generating the random number corresponding to the call message, the message manager can generate the message identifier of the call message according to a preset format based on the current timestamp and the random number. For example, the preset format can be: {timestamp}_{random}, where timestamp is the current timestamp and random is the random number.

[0075] In one implementation, the message manager can generate the message identifier for the calling message using the following algorithm: Date.now().toString() + '_' + Math.floor(Math.random()×1000000).toString(). Here, Date.now().toString() is a function that retrieves the current timestamp and converts it to a string, and Math.floor(Math.random()×1000000).toString() is a function that retrieves a random number between 0 and 1000000 and converts it to a string.

[0076] One possible implementation, see Figure 2Following the step of generating the message identifier for the call message, the method further includes: S201, storing the message identifier as registration information in a temporary cache; S202, registering a timer and a listener, and after sending the message event to the message processor of the target business module, recording the waiting time of the listener through the timer, wherein the waiting time is the duration of waiting to receive the result message returned by the message processor; S203, if the result message returned by the message processor is detected by the listener and the waiting time has not reached the preset duration, executing the step of obtaining the result message returned by the message processor; S204, if the waiting time reaches the preset duration, clearing the registration information, the timer, and the listener. Clearing the registration information, timer, and listener when the waiting time reaches the preset duration—that is, automatically cleaning up the registration information, listener, and timer after timeout—prevents memory resource leaks and memory occupation issues, providing a robust resource management method, and automatically cleaning up timeout registration information, listeners, and timers, thereby improving system application stability.

[0077] After generating the message identifier for the call message, the message manager can perform the above step S201, which is to store the message identifier as registration information in the temporary cache, i.e. message registration. The message manager dynamically generates the message identifier according to the call message when the business call occurs, performs message registration, and stores the registration information in the temporary cache.

[0078] In step S202 above, the message manager can register timers and listeners. The timer records the duration of waiting for the result message returned by the message processor; that is, it starts counting from the time the message event is sent to the message processor of the target business module, recording the duration of waiting for the result message. The listener listens for the result message returned by the message processor, so the timer records the listener's waiting time.

[0079] If the listener detects a result message returned by the message processor, and the current waiting time recorded by the timer has not reached the preset time, it means that the message processor has returned a result message within the specified time, and then the result message returned by the message processor can be obtained.

[0080] If the waiting time recorded by the listener reaches the preset time, it means that the listener has not received the result message returned by the message processor within the specified time, and the business processing of the target business module has timed out. In this case, the registration information, timers and listeners in the temporary cache can be cleared to prevent memory leaks and release the resources occupied by the registration information, timers and listeners.

[0081] The above preset duration can be set according to the actual business module calling the method function to perform the business processing. For example, it can be 8 seconds, 10 seconds, 15 seconds, etc., without specific limitation here.

[0082] For example, with a preset duration of 10 seconds, after sending a message event to the message processor of the target business module, the timer starts recording the listener's waiting time. If the listener hears the result message returned by the message processor after a waiting time of 7 seconds, since the waiting time is less than the preset duration, the message manager can execute the step of obtaining the result message returned by the message processor and continue to process the result message.

[0083] If the listener has not received a result message from the message processor after a waiting period of 10 seconds, the message manager can clear the registration information, timers, and listeners from the temporary cache.

[0084] One possible implementation, see Figure 3 Before the step of returning the processing result to the trigger of the call message, the method may further include: S301, parsing the result message through the listener to determine the message identifier and processing result included in the result message; S302, if the listener determines that the parsed message identifier matches the registration information, executing the step of returning the processing result to the trigger of the call message; S303, if the listener determines that the parsed message identifier does not match the registration information, continuing to wait for the next result message, and if the next result message is detected, returning to step S301, until the waiting time reaches the preset time. The listener can parse the result message, determine the message identifier included in the result message, and compare the message identifier included in the result message with the registration information. If the parsed message identifier matches the registration information, the processing result is returned to the trigger of the call message, ensuring that the correct processing result is returned to the trigger and guaranteeing the accuracy of business processing.

[0085] Upon receiving a result message, in step S301 above, the listener can parse the result message to determine the message identifier and processing result included in the result message. In one embodiment, the message processor of the target service module assembles the result message according to the event bus communication mechanism, wherein the result event can be named: {eventId}_result. After the listener receives a result message named {eventId}_result, it can parse it to obtain the message identifier and processing result included therein.

[0086] After obtaining the message identifier included in the result message, the listener can compare whether the parsed message identifier matches the registration information. If they match, it means that the processing result included in the result message is the result that the trigger of the call message wants. Therefore, the above steps of returning the processing result to the trigger of the call message can continue to be executed.

[0087] If the parsed message identifier does not match the registration information, it means that the processing result included in the result message is not the result desired by the trigger of the call message. In this case, it can continue to wait and listen for the next result message, and if the next result message is heard, return to execute the above step S301. If a result message whose included message identifier matches the registration information is obtained before the waiting time reaches the preset time, the processing result is returned to the trigger of the call message. If a result message whose included message identifier matches the registration information is not obtained when the waiting time reaches the preset time, the call message times out, and the message manager can clear the registration information, timers, and listeners.

[0088] In one possible implementation, if multiple call messages occur concurrently, the message manager can register a listener for each call message and name the registered listeners based on the message identifier of the corresponding call message. After a registered listener hears a result message, it parses the message identifier, matches it with its own corresponding message identifier, determines its own processing result, and returns the processing result to the corresponding trigger.

[0089] One possible implementation is that the message manager in this embodiment supports the Promise asynchronous processing mechanism, using Promise objects to encapsulate the asynchronous message processing flow, supporting syntax such as `async` and `await`, improving code readability. It can also provide a unified error handling mechanism to automatically handle timeout scenarios, ensuring that Flutter can correctly receive processing results after calling native functions. In this case, after the listener determines that the parsed message identifier matches the registration information successfully, it can call the `resolve` function to change the state of the Promise object to `Fulfilled` and return the processing result to the triggerer. This ensures the correct correspondence between the call message and the processing result, supporting accurate matching of concurrent message requests.

[0090] One possible implementation, the step of sending the message event to the message processor of the target business module based on the event bus, may include: using the business module identifier as an event routing identifier, and distributing the message based on the event bus to send the message event to the message processor of the target business module. Since using the business module identifier as the event routing identifier for message distribution supports the dynamic expansion of new business modules, achieves modular message routing and processing, is easy to maintain and expand, and reduces code maintenance costs.

[0091] The message manager can use the event bus communication mechanism and the message distribution function of the event bus to forward call messages. In addition to one-to-one message distribution, it can also support one-to-many and many-to-many message distribution. That is, it can send a call message from one trigger to one business module, or send a call message from one trigger to multiple business modules, or send call messages from multiple triggers to multiple business modules.

[0092] In one implementation, the message manager can use the business module identifier as the event routing identifier, thus accurately sending message events to the message handler of the target business module. The message handler of the target business module can then receive the message events that need to be processed by the target business module.

[0093] In one possible implementation, the aforementioned call message is generated by calling a method of the singleton class and passing in agreed-upon parameters. These agreed-upon parameters include at least the business module identifier and the method field corresponding to the method function to be called. The message manager is an instance of the singleton class's method. The singleton class pattern involves a single class responsible for creating its own objects, ensuring that only a single object is created. It provides a global access point to access the method instance of the singleton class, enabling unified management of all message communication and achieving a unified, efficient, and reliable message communication mechanism between business modules.

[0094] As one implementation method, the business code uniformly calls the handleMessage method of the singleton class CommonMessageHandler, passing in the path parameter (business module identifier) ​​and the params parameter to generate a call message. The parameters include the func field representing the name of the call method. Then, it waits for the message to return the processing result.

[0095] A globally unique message handler instance is designed using the singleton class pattern to uniformly manage all cross-platform message communication, including the aforementioned processes of message reception and distribution, message identifier generation and management, timeout handling and resource cleanup, and result callback and matching.

[0096] Corresponding to the first message processing method described above, this application embodiment also provides a second message processing method, which will be introduced below.

[0097] See Figure 4 A message processing method is disclosed, applied to a pre-configured message processor in a business module. The method includes: S401, acquiring a message event sent by a pre-configured message manager via an event bus, wherein the message event includes at least a message identifier and a method field corresponding to the method function to be called; S402, calling the method function based on the method field to perform business processing and obtain a processing result; S403, sending a result message to the message manager, wherein the result message includes at least the processing result and the message identifier. The message processor of the business module receives message events via an event bus, uses the message identifier as a marker, performs business processing, and returns the processing result to the message manager. It works in conjunction with the message manager to complete business processing, eliminating the need to register all the method functions of the business module into memory, thus significantly reducing resource waste while achieving reliable message delivery.

[0098] If any business module has a method that needs to be called, it needs to implement a message handler. The message handler mainly provides message registration methods, message event listening methods, and message event parsing methods, and calls the corresponding method functions to perform business processing, assembles the result data interface, and returns the result message to the message manager.

[0099] One possible implementation, see Figure 5 The steps described above, which involve calling a method function based on the method field to perform business processing and obtain a processing result, include: S501, parsing the message event to obtain the method field; S502, determining the method function to be called based on the method field, and calling the method function to perform business processing to obtain a processing result. The message processor of the target business module can parse the message event to obtain the method field, and then call the method function corresponding to the method field to perform business processing and obtain a processing result, ensuring accurate method function calls and accurate processing results.

[0100] As one implementation method, the message handler of the target business module listens for message events. Upon detecting a message event, it parses the MessageEvent data within the message event, extracting the agreed-upon func method fields and MessageID. Then, it performs business logic processing based on the func method corresponding to the func method fields to obtain the result data. The result data is encapsulated using an event bus communication mechanism, and the result is processed by calling the CommonMessageHandler.getInstance().sendResult method.

[0101] One possible implementation, see Figure 6 In the system architecture of the message processing method provided in this application embodiment, the business modules may include a main project module (Entry), a service order module (Order), a message module (Message), and other business modules, i.e., other modules. The business module message processors include the main project module message processor (EntryFeaturelnit), the service order module message processor (OrderFeaturelnit), the message module message processor (MessageFeaturelnit), and other business module message processors, i.e., other module message processors.

[0102] The aforementioned business modules can exchange messages to perform business processing. When one or more business modules issue a call message (i.e., invoke the common method `CommonMessageHandler`), the system's message manager can forward the message. After the business module's message handler performs the corresponding business processing, it can return a result message, i.e., send the result message by calling the `CommonMessageHandler.getInstance().sendResult` method to callback the processing result. The message manager can then return the processing result to the business module that triggered the call message (i.e., result return), completing the message passing between business modules and realizing business processing.

[0103] One possible implementation method of the message processing method provided in this application embodiment may include several processes such as business call layer processing, general message forwarding layer processing, and business layer processing. Among them, the business call layer processing includes the business code uniformly calling the handleMessage method of the singleton class CommonMessageHandler, passing in the path parameter (business module identifier) ​​and the params parameter to generate a call message.

[0104] The general message forwarding layer handles the process by employing a singleton pattern to create a globally unique message handler instance, uniformly managing all message communication calls. This process defines standard TypeScript message event interfaces and result data interfaces based on an event bus communication mechanism. Each message event (MessageEvent) includes a path, params, and a MessageID (message identifier), with the path containing the business module identifier. Result data (ResultData) includes data (processing result) and the MessageID. Type checking can be performed during code compilation, enhancing code completion support and improving code quality and development efficiency.

[0105] In one implementation, if the business code calls the handleMessage method of CommonMessageHandler and passes in a MessageID, then the general message forwarding layer will use the passed MessageID as the message identifier. If no MessageID is passed in, the message identifier will be generated based on the timestamp and a random number.

[0106] Furthermore, message events can be assembled based on the path, i.e., the unified message event prefix ezp_native_message_{path}. Next, event data can be created, MessageEvent data can be encapsulated, and the path, parameters, and MessageID can be assigned to it to obtain the message event.

[0107] After a message event is sent to the corresponding business module's message handler, it enters the business layer processing procedure. Upon receiving the message event, the business module's message handler executes the corresponding business processing flow to obtain the processing result. Then, it assembles the processing result and message identifier to obtain the result message, which is returned to the general message forwarding layer. The general message forwarding layer matches the message identifier and returns the processing result to the business module that called the `handleMessage` method. This implements a unified, efficient, and reliable message communication mechanism between business modules, achieving decoupled communication between business modules and supporting accurate matching of asynchronous processing and concurrent requests.

[0108] Corresponding to the first message processing method described above, this application also provides a message processing device, which will be described below.

[0109] A message processing device, see Figure 7The device, applied to a pre-configured message manager, includes: a message identifier generation unit 710, configured to generate a message identifier for a call message upon receipt, wherein the call message includes at least a business module identifier and a method field corresponding to the method function to be called; a message event generation unit 720, configured to generate a message event according to the message identifier, the business module identifier, and the method field, following an event bus communication mechanism; a message event sending unit 730, configured to send the message event to a message processor of a target business module via an event bus, wherein the target business module is the business module corresponding to the business module identifier; a result message acquisition unit 740, configured to acquire a result message returned by the message processor, wherein the result message includes at least a processing result obtained by calling a method function based on the method field and a message identifier; and a message identifier matching unit 750, configured to return the processing result to the triggerer of the call message if the message identifier included in the result message matches the generated message identifier. When a call message is received, the message manager registers an event with the event bus for the business module, which generates a message event. It also dynamically generates a message identifier based on the business call for message registration. In this way, the message event is sent and the processing result is obtained from the business module through the message identifier, instead of registering all the methods and functions of the business module into memory. This greatly reduces resource waste while achieving reliable message passing.

[0110] In one possible implementation, the message identifier generation unit 710 may include: a random number generation subunit, used to generate a random number corresponding to the call message; and a message identifier generation subunit, used to generate a message identifier for the call message according to a preset format based on the current timestamp and the random number.

[0111] In one possible implementation, the above apparatus may further include: a message identifier storage unit, configured to store the message identifier as registration information in a temporary cache after generating the message identifier of the call message; a registration unit, configured to register a timer and a listener, and after sending the message event to the message processor of the target business module, record the waiting time of the listener through the timer, wherein the waiting time is the duration of waiting to receive the result message returned by the message processor; a result listening unit, configured to execute the step of obtaining the result message returned by the message processor when the result message returned by the message processor is detected by the listener and the waiting time has not reached a preset duration; and a clearing unit, configured to clear the registration information, the timer, and the listener when the waiting time reaches the preset duration.

[0112] In one possible implementation, the above apparatus may further include: a result parsing unit, configured to parse the result message through the listener before returning the processing result to the trigger of the call message, and determine the message identifier and processing result included in the result message; a message identifier matching unit, specifically configured to return the processing result to the trigger of the call message when the listener determines that the parsed message identifier matches the registration information; and a waiting unit, configured to continue waiting to listen for the next result message when the listener determines that the parsed message identifier does not match the registration information, and upon listening for the next result message, return to the process of parsing the result message through the listener until the waiting time reaches the preset time.

[0113] In one possible implementation, the message event sending unit 730 may include: a message event sending subunit, used to use the service module identifier as an event routing identifier, and to perform message distribution based on the event bus to send the message event to the message processor of the target service module.

[0114] In one possible implementation, the aforementioned call message is generated by calling a method of the singleton class and passing in agreed-upon parameters, wherein the agreed-upon parameters include at least the business module identifier and the method field corresponding to the method function to be called; the message manager is a method instance of the singleton class.

[0115] Corresponding to the second message processing method described above, this application embodiment also provides another message processing device, which will be described below.

[0116] A message processing device, see Figure 8 A pre-configured message processor for a business module is provided. The device includes: a message event receiving unit 810, used to acquire message events sent by a pre-configured message manager via an event bus, wherein the message event includes at least a message identifier and a method field corresponding to the method function to be called; a message event processing unit 820, used to call the method function based on the method field to perform business processing and obtain a processing result; and a result message sending unit 830, used to send a result message to the message manager, wherein the result message includes at least the processing result and the message identifier. The message processor of the business module receives message events via the event bus, uses the message identifier as a marker, performs business processing, and returns the processing result to the message manager. It works in conjunction with the message manager to complete business processing. This eliminates the need to register all the method functions of the business module into memory, significantly reducing resource waste while achieving reliable message transmission.

[0117] In one possible implementation, the message event processing unit 820 may include: an event parsing subunit, used to parse the message event to obtain the method field; and a method invocation subunit, used to determine the method function to be invoked based on the method field, and invoking the method function to perform business processing to obtain the processing result.

[0118] This application also provides an electronic device, see [link to relevant documentation] Figure 9 It includes: a memory 901 for storing computer programs; and a processor 902 for executing the program stored in the memory 901 to implement the message processing method steps described in any of the above embodiments.

[0119] The aforementioned electronic devices may also include a communication bus and / or a communication interface, through which the processor, communication interface, and memory communicate with each other.

[0120] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0121] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0122] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0123] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be 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, or discrete hardware components.

[0124] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the message processing method steps described in any of the above embodiments.

[0125] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform the message processing method steps described in any of the above embodiments.

[0126] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

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

[0128] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the second method, apparatus, electronic device, computer-sustainable storage medium, and computer program product embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0129] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A message processing method characterized by, Applied to a pre-configured message manager, the method includes: Upon receiving a call message, a message identifier for the call message is generated, wherein the call message includes at least a business module identifier and a method field corresponding to the method function to be called; Based on the message identifier, the business module identifier, and the method field, a message event is generated according to the event bus communication mechanism; The message event is sent to the message processor of the target service module based on the event bus, wherein the target service module is the service module corresponding to the service module identifier; Obtain the result message returned by the message processor, wherein the result message includes at least the processing result obtained by calling the method function based on the method field to perform business processing and the message identifier; If the message identifier included in the result message matches the generated message identifier, the processing result is returned to the triggerer of the call message.

2. The method of claim 1, wherein, The step of generating the message identifier for the call message includes: Generate a random number corresponding to the call message; Based on the current timestamp and the random number, a message identifier for the call message is generated according to a preset format.

3. The method of claim 1, wherein, After the step of generating the message identifier of the call message, the method further includes: The message identifier is stored as registration information in a temporary cache; Register a timer and a listener, and after sending the message event to the message processor of the target business module, record the waiting time of the listener through the timer, wherein the waiting time is the time to wait for the result message returned by the message processor; If the listener detects a result message returned by the message processor and the waiting time has not reached the preset time, the step of obtaining the result message returned by the message processor is executed. If the waiting time reaches the preset time, the registration information, the timer, and the listener are cleared.

4. The method of claim 3, wherein, Prior to the step of returning the processing result to the trigger of the invocation message, the method further includes: The listener parses the result message to determine the message identifier and processing result included in the result message; If the listener determines that the parsed message identifier matches the registration information, it executes the step of returning the processing result to the triggerer of the call message; If the listener determines that the parsed message identifier does not match the registration information, it continues to wait for the next result message. If the next result message is detected, it returns to the step of parsing the result message through the listener until the waiting time reaches the preset time.

5. The method of claim 1, wherein, The step of sending the message event to the message processor of the target service module based on the event bus includes: The business module identifier is used as the event routing identifier, and message distribution is performed based on the event bus to send the message event to the message processor of the target business module.

6. The method according to any one of claims 1 to 5, characterized in that, The invocation message is generated by invoking a method of the singleton class and passing in agreed-upon parameters. The agreed-upon parameters include at least the business module identifier and the method field corresponding to the method function to be invoked. The message manager is a method instance of the singleton class.

7. A message processing method, characterized in that, A pre-configured message processor applied to a business module, the method comprising: Obtain message events sent by a pre-set message manager based on the event bus, wherein the message event includes at least a message identifier and a method field corresponding to the method function to be called; Based on the method fields, the method function is called to perform business processing and obtain the processing result; A result message is sent to the message manager, wherein the result message includes at least the processing result and a message identifier.

8. The method according to claim 7, characterized in that, The step of calling a method function based on the method field to perform business processing and obtain the processing result includes: The message event is parsed to obtain the method field; The method function to be called is determined based on the method field, and the method function is called to perform business processing and obtain the processing result.

9. A message processing device, characterized in that, The device, applied to a pre-configured message manager, includes: A message identifier generation unit is used to generate a message identifier for a call message when a call message is obtained, wherein the call message includes at least a business module identifier and a method field corresponding to the method function to be called; The message event generation unit is used to generate a message event according to the message identifier, the business module identifier, and the method field, in accordance with the event bus communication mechanism. A message event sending unit is used to send the message event to the message processor of the target service module based on the event bus, wherein the target service module is the service module corresponding to the service module identifier; The result message acquisition unit is used to acquire the result message returned by the message processor, wherein the result message includes at least the processing result obtained by calling the method function based on the method field to perform business processing and a message identifier; The message identifier matching unit is used to return the processing result to the triggerer of the call message if the message identifier included in the result message matches the generated message identifier.

10. A message processing device, characterized in that, A pre-configured message processor applied to a business module, the device comprising: The message event receiving unit is used to obtain message events sent by the pre-set message manager based on the event bus, wherein the message event includes at least a message identifier and a method field corresponding to the method function to be called; The message event processing unit is used to call the method function based on the method field to perform business processing and obtain the processing result; The result message sending unit is used to send a result message to the message manager, wherein the result message includes at least the processing result and a message identifier.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-6 or 7-8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-6 or 7-8.

Images