Message processing method and system

Abstract

The present application provides a message processing method and system, the method comprising: receiving a message processing instruction from a target channel, the message processing instruction including a message type identifier and a message to be processed; calling a function application plug-in and / or a message type plug-in according to the message type identifier, so that the function application plug-in and / or the message type plug-in perform business logic processing on the message to be processed in response to the call, and convert the format of the processed message to be processed into the interface format of the target channel interface corresponding to the message type plug-in; calling the target channel interface to send the format-converted message to be processed to the target channel; wherein the function application plug-in and the message type plug-in are registered based on a preset plug-in splitting principle. By dynamically calling the function application plug-in and the message type plug-in registered based on the plug-in splitting principle through the message type to perform business processing and interface format conversion, the modification of the traditional core code is avoided, and the problem of poor scalability and flexibility of the traditional method is solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a message processing method and system. Background Art

[0002] Traditional message processing systems face the following challenges when expanding into diverse message channels: 1) Each new channel requires core code modifications, making system maintenance complex and error-prone; 2) The interface protocols of different channels vary significantly, making adaptation difficult and increasing development effort and time; 3) Business logic is tightly coupled with channel processing, making it difficult to flexibly expand and reuse, severely impacting the system's scalability and flexibility. Therefore, a new message processing approach is urgently needed to effectively address these issues and achieve efficient, flexible expansion and decoupling of message processing. Summary of the Invention

[0003] The present application provides a message processing method and system to at least solve the above technical problems existing in the prior art.

[0004] According to a first aspect of the present application, a message processing method is provided, which is applied to a basic framework of a message processing system, and the method includes:

[0005] receiving a message processing instruction from a target channel, wherein the message processing instruction includes a message type identifier and a message to be processed;

[0006] calling a function application plug-in and / or a message type plug-in according to the message type identifier, so that the function application plug-in and / or the message type plug-in performs business logic processing on the message to be processed in response to the call, and converts the format of the processed message to be processed into the interface format of the target channel interface corresponding to the message type plug-in;

[0007] Calling the target channel interface to send the format-converted message to be processed to the target channel;

[0008] The functional application plug-in and the message type plug-in are registered based on a preset plug-in splitting principle.

[0009] In one embodiment, the preset plug-in splitting principles include:

[0010] Get the plug-in code file to be registered;

[0011] Classify the plug-in code files according to business function domains and message types to obtain code files corresponding to each business function and code files corresponding to each message type;

[0012] Create separate catalogs for each business function or message type;

[0013] Separate each code file into resource layer, service layer, and data access layer, and store them in corresponding independent directories;

[0014] Store the codes corresponding to the terminal processor and the universal gateway in the code file into corresponding independent directories. The terminal processor and the universal gateway interact with other plug-ins through standardized interfaces.

[0015] If the external entity objects and entity objects have no external dependencies, add the external entity objects and entity object codes directly to the corresponding independent directories;

[0016] Register the function application plug-in corresponding to each business function and the message type plug-in corresponding to each message type through each independent directory, and package all independent directories into a plug-in directory.

[0017] In one possible implementation, the functional application plug-in is an independently deployable micro-application unit, which runs as an independent module or in an embedded manner and is used to execute general business logic unrelated to the message type plug-in;

[0018] The message type plug-in is attached to the function plug-in, and the message type plug-in is loaded through the module federation mechanism to execute differentiated logic for different message channels.

[0019] In one embodiment, before receiving the message processing instruction from the target channel, the method further includes:

[0020] receiving a login instruction, and acquiring currently supported message types in response to the login instruction;

[0021] Read the configuration file in the configuration information directory according to the message type and store the configuration file in the message service;

[0022] Get the front-end component based on the message type, associate the front-end component with the corresponding configuration file and store it in the message service;

[0023] Obtaining a terminal processor corresponding to a message type from the plug-in directory, and associating the terminal processor with a corresponding configuration file and storing it in the message service;

[0024] The message service implements data storage based on the singleton mode of module federation and is configured with a standardized interface.

[0025] In one embodiment, the plug-in is also configured with a plug-in interface unit, which is stored separately from its independent directory. The plug-in interface unit includes the plug-in interface definition file and interface rules. The interface rules include the principle of prohibiting cross-reference of interfaces between plug-ins, the principle of isolating data types between plug-ins, and the principle of unified access to interfaces.

[0026] In one possible implementation, the basic framework and the plug-in interact with each other through a standardized interface.

[0027] In one possible implementation, the basic framework and the plug-in perform information exchange based on the Spring subscription and publication model.

[0028] In one embodiment, the plug-in supports plug-in and unplug-out operations, and the plug-in and unplug-out operations include:

[0029] receiving a plug-in deletion instruction, and deleting the independent directory and configuration file of the corresponding plug-in in response to the plug-in deletion instruction;

[0030] A plug-in insertion instruction is received, and in response to the plug-in insertion instruction, an independent directory and configuration file corresponding to the plug-in are added.

[0031] In one embodiment, the method further comprises:

[0032] Receive transaction instructions sent by users, which carry functional requirements and message type requirements;

[0033] According to the functional requirements and message type requirements, separate directories of corresponding functional application plug-ins and message type plug-ins are selected from the plug-in directory;

[0034] The filtered independent directories are packaged into a customized source code package and sent to the user.

[0035] According to a second aspect of the present application, a message processing system is provided, the system comprising:

[0036] Plug-in framework, including multiple functional application plug-ins and message type plug-ins that support plug-in and unplug;

[0037] The basic framework is used to execute the above message processing methods.

[0038] The message processing method and system of the present application receive a message processing instruction from a target channel, the message processing instruction including a message type identifier and a message to be processed; call a function application plug-in and / or a message type plug-in according to the message type identifier, so that the function application plug-in and / or the message type plug-in perform business logic processing on the message to be processed in response to the call, and convert the processed message into the target channel interface format corresponding to the message type plug-in; call the target channel interface to send the format-converted message to be processed to the target channel; wherein the function application plug-in and the message type plug-in are registered based on a preset plug-in splitting principle. By dynamically calling the function application plug-in and the message type plug-in registered based on the plug-in splitting principle through the message type to perform business processing and interface format conversion, the modification of the traditional core code is avoided, and the problem of poor scalability and flexibility of the traditional method is solved.

[0039] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The above and other objects, features and advantages of the exemplary embodiments of the present application will become readily understood by reading the detailed description below with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present application are shown in an illustrative and non-limiting manner, in which:

[0041] In the drawings, the same or corresponding reference numerals denote the same or corresponding parts.

[0042] Figure 1 The following is a schematic diagram showing an implementation flow of a message processing method provided in an embodiment of the present application;

[0043] Figure 2 A schematic diagram illustrating an implementation flow of a plug-in initialization operation of a message processing method provided in an embodiment of the present application is shown;

[0044] Figure 3 A schematic diagram of the composition structure of the message processing system provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0045] In order to make the purpose, features, and advantages of this application more obvious and easy to understand, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of this application.

[0046] First, the application scenario of the present application is explained. With the diversification of message channels, such as from traditional emails, text messages, and voice to various software that support message processing today, the connection between enterprises and users is becoming increasingly close. However, it is relatively simple for enterprises to connect to message channels in the early stages of development, but with the expansion of business and the iteration of integrated message platforms, it is difficult for existing message processing systems to cover all functions. It is necessary to continuously iterate and develop new functions or optimize existing functions, which makes it difficult for the system to cope with the rapid expansion of channels and the flexible combination of functions. Among them, the existing technology has the following problems: the functions of various message channels are different, and scalability is not fully considered during the design, resulting in a lot of redundant code, insufficient code layering optimization, prominent verification interface sharing problems, difficulty in combining functional modules and message type channels, and the inability to effectively separate cross-application common problems, and there are performance problems. In order to solve these problems, the present application provides a message processing method and system.

[0047] Figure 1 A schematic diagram of the implementation flow of the message processing method provided in an embodiment of the present application is shown.

[0048] refer to Figure 1 The present application provides a message processing method, which is applied to the basic framework of a message processing system. The method includes:

[0049] Operation 101: receiving a message processing instruction from a target channel, the message processing instruction including a message type identifier and a message to be processed;

[0050] Target channels include SMS, email, voice, and major software platforms. Message types are used to distinguish message channels. They can be synonymous with message channels, meaning each message type corresponds to a specific message channel. The message type identifier can be understood as the identifier of the message channel, uniquely identifying the source and type of the message.

[0051] The basic framework of the message processing system first receives pending messages and their corresponding message type identifiers from users via mobile phones or computers. User terminals can be any device capable of sending and receiving messages, such as smartphones, computers, and tablets. Messages can be in various formats, including text messages, image messages, and video messages, depending on the target channel and business needs.

[0052] Operation 102, calling the function application plug-in and / or the message type plug-in according to the message type identifier, so that the function application plug-in and / or the message type plug-in performs business logic processing on the message to be processed in response to the call, and converts the format of the processed message to be processed into the interface format of the target channel interface corresponding to the message type plug-in.

[0053] Functional application plug-ins are basic components in the message processing process. They provide common support for different types of message processing and are used to provide general business logic functions. These general business logic functions are independent of the specific message type, such as general message format verification, basic content processing, and message queue management.

[0054] Message type plugins, on the other hand, customize the business logic for specific message types. For example, application message plugins handle application-specific message formats, protocols, and platform-specific business rules; SMS plugins focus on the specific format requirements and transmission protocols of SMS channels. These message type plugins are specialized components of the message processing pipeline, ensuring that different message types are accurately processed according to their respective requirements.

[0055] After the basic framework of the message processing system identifies the message type identifier, it calls at least one required functional plug-in and / or at least one message plug-in based on the message type identifier. In the embodiment of the present application, the basic framework and plug-ins are combined based on a micro-isolation design. The basic framework only calls the plug-in and does not involve the specific implementation of the plug-in. That is, after the basic framework calls the plug-in, subsequent message processing is performed by the plug-in itself.

[0056] Once invoked, the plug-in processes the pending message according to the pre-defined business logic. This processing may include parsing the message content, converting the format, and applying business rules. After completing the business logic processing, the plug-in converts the pending message to the interface format required by the target channel to ensure that the message format meets the requirements of the target channel.

[0057] The target channel interface is the bridge between the message processing system and the external message channel. These interfaces are typically defined and provided by the message channel's service provider, or developed by the message processing system based on the channel's requirements. After format conversion, the message to be processed must conform to the target channel interface's specifications, such as the message's data format, transmission protocol, and security requirements.

[0058] Operation 103 : calling the target channel interface to send the format-converted message to be processed to the target channel; wherein the function application plug-in and the message type plug-in are registered based on the preset plug-in splitting principle.

[0059] The message processing system's infrastructure calls the target channel interface to send processed messages to the designated target channel. For example, if the target channel is software, the software interface is called to send the message to the software platform; if it is an SMS message, the SMS interface is called to send the message to the SMS gateway.

[0060] To ensure that plug-ins can be independently updated and expanded without affecting the overall stability of the message processing system and the operation of other plug-ins, the plug-ins in the embodiments of this application are registered based on the plug-in splitting principle. The plug-in splitting principle can be seen as splitting the plug-in registration so that each plug-in focuses on specific channel message processing, has independent internal functions, and has a standardized external interface.

[0061] Therefore, the method of the embodiment of the present application divides the channel-specific processing of business functions and message types into functional application plug-ins and message type plug-ins, and adopts functional application plug-ins and message type plug-ins registered based on the plug-in splitting principle, and dynamically calls the corresponding plug-ins using message types to perform business processing and interface format conversion, avoiding the modification of traditional core codes, and effectively solving the adaptation difficulties and high coupling problems when the channel protocol is expanded, thereby realizing the rapid access of the message processing system to the new message channel and the corresponding business processing, improving scalability and flexibility, reducing development costs, and improving maintenance efficiency.

[0062] In one embodiment of the present application, the preset plug-in splitting principle includes: obtaining the plug-in code file to be registered; classifying the plug-in code file according to the business function domain and message type to obtain the code file corresponding to each business function and the code file corresponding to each message type; creating an independent directory for each business function or message type; stripping each code file according to the resource layer, service layer, and data access layer, and storing them in layers in the corresponding independent directory; storing the code corresponding to the terminal processor and the universal gateway in the code file in the corresponding independent directory, and the terminal processor and the universal gateway interact with other plug-ins through standardized interfaces; if there is no external dependency on the external entity object and the entity object, the code of the external entity object and the entity object is directly added to the corresponding independent directory; registering the functional application plug-in corresponding to each business function and the message type plug-in corresponding to each message type through each independent directory, and packaging all independent directories into a plug-in directory.

[0063] The preset plug-in splitting principle aims to achieve efficient plug-in registration and organization through systematic management and classification of plug-in code files. Specifically, the preset plug-in splitting principle can be understood as delivering message-type functions or other functions as plug-in functions and function extensions based on the needs of modularization and on-demand function delivery, and supporting a pluggable approach.

[0064] Specifically, first obtain the plug-in code file to be registered, and carefully classify it according to the business function domain and message type, so as to accurately identify the code file corresponding to each business function and message type.

[0065] Furthermore, in order to optimize the structure and management of plug-ins, an independent directory is set up for each business function or message type, and each code file is stripped according to the resource layer, service layer, and data access layer, and stored in layers in the corresponding independent directory. In addition, the corresponding codes of the terminal processor and universal gateway in the code file are also stored in the corresponding independent directory to ensure that the terminal processor and universal gateway can interact with other plug-ins through standardized interfaces. For external entity objects and entity objects, if there is no external dependency, their code is directly added to the corresponding independent directory. Finally, each business function and each message type plug-in is registered through each independent directory, and all independent directories are integrated and packaged into a plug-in directory to facilitate unified management and calling of plug-ins.

[0066] This embodiment of the present application corresponds to separating each code file according to the resource layer, service layer, and data access layer, and storing them in corresponding independent directories; storing the terminal processor and universal gateway corresponding codes in the code file in corresponding independent directories, and the terminal processor and universal gateway interact with other plug-ins through standardized interfaces. The preset plug-in splitting principles specifically include:

[0067] 1) Web-plugin splitting principles:

[0068] According to the modular requirements of the business function list, the implementation codes of the resource layer (Resource), service layer (Service), and data access layer (Repository) are split into independent functional modules; dynamic loading is achieved by encapsulating them into library files (lib packages). The Java virtual machine (JVM) loads the library as a whole when needed and directly removes the library file when not needed.

[0069] Specifically, the requirements are split from the business function list, and the implementation of Resource (resource layer) -> Service (service layer) -> Repository (business access layer) is supported as an independent module. When needed, it is placed in the lib package and supported by the JVM as a whole. When not needed, the lib package is removed without affecting other functions. The stripping function is not supported separately.

[0070] 2) Mix-plugin splitting principles:

[0071] With the business filter chain as the horizontal core processing flow, a terminal handler (TerminalHelper) based on the message type is inserted vertically during the execution of the business process. By splitting the terminal handler of each message type into independent plug-in modules, it provides message type-specific business logic processing capabilities.

[0072] Specifically, Mix is ​​a processing flow centered around the service filter chain. Within the horizontal process of service processing, TerminalHelpers are inserted vertically, based on message types, to handle specific message service processing. Based on TerminalHelpers, each message processing implementation is split and provided as a plug-in.

[0073] 3) Channel-plugin splitting principles:

[0074] With the general channel processing service (ChannelServer) as the core carrier, it abstracts and standardizes communication capabilities based on the channel common interface (CommonGate); each message channel protocol implements this interface and is encapsulated as an independent plug-in module to provide protocol adaptation capabilities for specific communication channels (such as SMS).

[0075] Specifically, channelServer is a universal channel processing service based on CommonGate as the universal channel interface. Each message channel protocol implements its own interface and provides the final channel implementation connection in the form of a plug-in.

[0076] To further understand the principles of mix-plugin splitting, let's take the splitting of application plug-ins as an example:

[0077] 1) Separate the Resource layer, add an application package path, and migrate the Resource implementation to the application path. If a single Resource service contains multiple services that need to be separated, and the path already has a distinct lower-level routing, directly separate the sub-resources from the current resource.

[0078] 2) Strip the Service layer. If the stripped Service layer is relied upon by other businesses, when other business layers (Resource / Service) depend on it, independently strip the interface as a dependency, and implement the stripped interface with the original interface.

[0079] 3) Migration of the Repository layer. The migration of the Repository layer follows the same principles as the Service layer. That is, when other business layers (ServiceImpl) depend on it, the upper-layer service interface is separated, the interface is stripped as a dependency, and the stripped interface is implemented by the original interface.

[0080] 4) For external entity object (DTO) migration, if there is no external business dependency, it will be directly migrated into the plug-in package. If there is a usage dependency, it will not be migrated for the time being.

[0081] 5) Entity object (Entity) migration: if there is no external business dependency, it will be directly migrated into the plug-in package. If there is usage dependency, it will not be migrated for the time being.

[0082] In one embodiment of the present application, the functional application plug-in is an independently deployable micro-application unit that runs as an independent module or in an embedded manner and is used to execute general business logic that is unrelated to the message type plug-in; the message type plug-in is attached to the functional plug-in, and the message type plug-in is loaded through the module federation mechanism and is used to execute differentiated logic for different message channels.

[0083] Specifically, two types of channel plug-ins can be designed for the current message processing system. The two plug-in types include functional application plug-ins (micro-applications) and message type plug-ins (Angular Library).

[0084] Functional application plugins can be launched independently, packaged, and deployed, or embedded as subprojects within the base framework (main application) to launch and deploy common code (code unrelated to specific message types). Message type plugins, on the other hand, cannot be launched independently; they rely on the environment provided by the functional application plugin to launch. Through the module federation mechanism, each message plugin generates a separate JS (JavaScript) file and loads it on demand. Message type plugins are used to write differentiated logic code related to specific message types (different message types handle different logic).

[0085] Each plugin's code files, data types, and configuration files are stored independently within the plugin directory. This means that all plugin-specific information, source code, and code files are stored independently within their own directory and are not scattered across other plugins or the underlying framework.

[0086] In one embodiment of the present application, functional application plug-ins may include standard product plug-ins, management and control function plug-ins, short-chain value-added function plug-ins, patch function plug-ins, standard statistics function plug-ins, and weekly and monthly operation report plug-ins. Message type plug-ins may include SMS plug-ins, 5G message plug-ins, voice plug-ins, email plug-ins, video SMS plug-ins, and various application plug-ins.

[0087] Figure 2 A schematic diagram of the implementation flow of the plug-in initialization operation of the message processing method provided in an embodiment of the present application is shown.

[0088] refer to Figure 2 In one embodiment of the present application, before receiving the message processing instruction from the target channel, the method further includes:

[0089] Operation 201: receiving a login instruction, and obtaining currently supported message types in response to the login instruction;

[0090] Operation 202: Read the configuration file in the configuration information directory according to the message type, and store the configuration file in the message service;

[0091] Operation 203: obtaining the front-end component according to the message type, and associating the front-end component with the corresponding configuration file and storing it in the message service;

[0092] Operation 204 , obtains a terminal processor corresponding to the message type from the plug-in directory, and associates the terminal processor with the corresponding configuration file and stores it in the message service; wherein the message service implements data storage based on the singleton mode of module federation and is configured with a standardized interface.

[0093] Specifically, after receiving the login command and successfully logging in, the startup service in the base framework calls a backend interface to obtain the currently authorized message types. Subsequently, the corresponding message type and configuration data (i.e., the configuration file) are read from the configuration information directory and saved along with the message type in the message service. In module federation mode, all service data is stored as a singleton, allowing other microapps to share this data. Next, based on the obtained message type data, the components and configuration objects corresponding to the plugins message type plugin are read and cached.

[0094] Among them, other parts of the system can obtain these cached message type data through the message service.

[0095] In one embodiment of the present application, the plug-in is also configured with a plug-in interface unit, which is stored separately from its independent directory. The plug-in interface unit includes the plug-in interface definition file and interface rules. The interface rules include the principle of prohibiting cross-reference of interfaces between plug-ins, the principle of isolating data types between plug-ins, and the principle of unified access to interfaces.

[0096] The above plug-in interface configuration method is also applicable to the basic framework interface.

[0097] Specifically, plug-in design emphasizes the standardization of framework and plug-in interfaces. The interface portion of a plug-in or base framework should be a separate unit file. The interface unit only contains interface-related information, namely the interface definition file, and ensures that cross-references are avoided. In other words, it is prohibited to skip the interface unit and directly reference the plug-in internal unit.

[0098] The principle of prohibiting cross-references between plugin interfaces can be seen as prohibiting plugins from directly referencing each other's interface definition files. For example, plugin A cannot directly reference plugin B's interface definition in its code, and vice versa. This prevents close interdependencies between plugins and prevents changes to one plugin's interface from affecting multiple others.

[0099] The principle of data type isolation between plugins can be seen as follows: data type definitions within each plugin should be as independent as possible, avoiding direct use of data types defined by other plugins. For example, if plugin A uses the interface of plugin B, but plugin B also references the data type of plugin C, plugin B should alias plugin C's type to ensure that plugin A can complete its operations on plugin B with a single reference to the unit file. This prevents data type changes from causing chain reactions between plugins.

[0100] The unified interface access principle means that all calls to plugin functionality must be made through a unified interface. For example, if plugin A wants to use plugin B's functionality, it must do so through plugin B's interface definition file. Direct access to plugin B's internal implementation code or other unspecified entry points is prohibited. This ensures controlled and consistent access to plugin functionality and facilitates plugin version updates and maintenance.

[0101] In one embodiment of the present application, the basic framework and the plug-ins are designed based on the separation principle. The basic framework and the plug-ins interact through a standardized interface, which can be understood as the interface unit between the framework and the plug-ins.

[0102] Specifically, the dominant factor in the framework prototype is not the technical foundation, but requirements management. Given the ever-changing nature of business requirements, the ability to respond to change calmly and quickly is a core management issue. In real-world projects, whether in the early stages of development, during maintenance, or during later version iterations, business modules are often the source of change. Therefore, management requirements dictate that only the changed components be modified or removed.

[0103] Based on the needs of business modules, they can be divided into basic frameworks and functional modules. Basic modules contain nearly unchanging business logic, while functional modules address the more variable aspects of business requirements. Plugins typically operate on functional modules. By extracting different plugins from functional modules and applying different processing methods, each plugin can handle different demand scenarios.

[0104] In one embodiment of the present application, information exchange is performed between the basic framework and the plug-in based on the Spring subscription and publishing model.

[0105] The Spring subscription and publication model is an event-driven programming model used for decoupled communication between various components within the system. Given its decoupling capabilities, this application uses the Spring subscription and publication model to communicate between the basic framework and plug-ins to avoid mutual references between plug-in units and achieve decoupling requirements.

[0106] Specifically, a plugin subscribes to specific messages from the underlying framework, which then pushes the corresponding messages to the plugin. During this process, exposed interfaces are abstracted through inheritance or composition to ensure that the passed messages contain complete parameters. If the message parameters don't fully convey the required information, the plugin has the right to request more detailed message content from the underlying framework and extract the appropriate parameters based on its needs to implement different business logic.

[0107] In one embodiment of the present application, the plug-in supports plug-in and unplug-in operations, which include: receiving a plug-in deletion instruction, and deleting the independent directory and configuration file of the corresponding plug-in in response to the plug-in deletion instruction; receiving a plug-in insertion instruction, and adding the independent directory and configuration file of the corresponding plug-in in response to the plug-in insertion instruction.

[0108] Specifically, the plug-ins in the embodiments of the present application support plug-in and unplug-in. When a plug-in needs to be deleted, a single click removes both the plug-in's code and configuration files, achieving a complete, residue-free uninstall. Inserting a new plug-in is also very simple; simply add the plug-in's independent directory to the plug-in directory. This plug-in modular framework significantly improves development efficiency and effectively shortens the entire development cycle.

[0109] In one embodiment of the present application, transaction services are also provided externally based on the message processing system, specifically including: receiving transaction instructions sent by users, the transaction instructions carrying functional requirements and message type requirements; based on the functional requirements and message type requirements, filtering out independent directories of corresponding functional application plug-ins and message type plug-ins from the plug-in directory; packaging the filtered independent directories into customer-customized source code packages and sending them to users.

[0110] Specifically, in actual projects, the message processing system can flexibly combine functional application plug-ins, message type plug-ins, and message type channels within functional modules according to customer needs, and package them as source code for customers. The source code provided to customers is limited to the functional modules and message type channels they have purchased, and must be able to operate normally, be packaged and deployed, and support functional expansion.

[0111] Figure 3 A schematic diagram of the composition architecture of the message processing system provided in an embodiment of the present application is shown.

[0112] refer to Figure 3 Based on the above message processing method, the embodiment of the present application further provides a message processing system, which includes a basic framework 301 and a plug-in framework 302. The basic framework 301 is used to execute the above message processing method, and the plug-in framework 302 includes multiple functional application plug-ins and message type plug-ins that support plug-in and unplug.

[0113] It should be noted that the description of the system in the embodiment of the present application is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment, so it will not be described in detail. Figures 1 to 2 The present invention shall be understood by reference to the description of any of the accompanying drawings.

[0114] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this application can be achieved. This is not a limitation herein.

[0115] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0116] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A message processing method, characterized in that: The basic framework applied to the message processing system includes: receiving a message processing instruction from a target channel, the message processing instruction including a message type identifier and a message to be processed; the message type identifier is used to distinguish the message channel; calling a function application plug-in and / or a message type plug-in according to the message type identifier, so that the function application plug-in and / or the message type plug-in performs business logic processing on the message to be processed in response to the call, and converts the format of the processed message to be processed into the interface format of the target channel interface corresponding to the message type plug-in; Calling the target channel interface to send the format-converted message to be processed to the target channel; The functional application plug-in and the message type plug-in are registered based on a preset plug-in splitting principle; The principles for splitting preset plug-ins include: Get the plug-in code file to be registered; Classify the plug-in code files according to business function domains and message types to obtain code files corresponding to each business function and code files corresponding to each message type; Create separate catalogs for each business function or message type; Separate each code file into resource layer, service layer, and data access layer, and store them in corresponding independent directories; Store the codes corresponding to the terminal processor and the universal gateway in the code file into corresponding independent directories. The terminal processor and the universal gateway interact with other plug-ins through standardized interfaces. If the external entity objects and entity objects have no external dependencies, add the external entity objects and entity object codes directly to the corresponding independent directories; Register the function application plug-in corresponding to each business function and the message type plug-in corresponding to each message type through each independent directory, and package all independent directories into a plug-in directory; Functional application plug-ins are independently deployable micro-application units that run as independent modules or embedded systems and are used to execute common business logic that is unrelated to message type plug-ins. The message type plug-in is attached to the function plug-in. The message type plug-in is loaded through the module federation mechanism and is used to execute differentiated logic for different message channels.

2. The method according to claim 1, characterized in that Before receiving the message processing instruction from the target channel, the method further includes: receiving a login instruction, and acquiring currently supported message types in response to the login instruction; Read the configuration file in the configuration information directory according to the message type and store the configuration file in the message service; Get the front-end component based on the message type, associate the front-end component with the corresponding configuration file and store it in the message service; Obtaining a terminal processor corresponding to a message type from the plug-in directory, and associating the terminal processor with a corresponding configuration file and storing it in the message service; The message service implements data storage based on the singleton mode of module federation and is configured with a standardized interface.

3. The method according to claim 1, characterized in that The plug-in is also configured with a plug-in interface unit, which is stored separately from its independent directory. The plug-in interface unit includes the plug-in interface definition file and interface rules. The interface rules include the principle of prohibiting cross-reference of interfaces between plug-ins, the principle of isolating data types between plug-ins, and the principle of unified interface access.

4. The method according to claim 1, wherein The basic framework and the plug-ins interact with each other through standardized interfaces.

5. The method according to claim 1, wherein The basic framework and the plug-in exchange information based on the Spring subscription and publishing model.

6. The method according to claim 1, characterized in that The plug-in supports plug-in and unplug-out operations, which include: receiving a plug-in deletion instruction, and deleting the independent directory and configuration file of the corresponding plug-in in response to the plug-in deletion instruction; A plug-in insertion instruction is received, and in response to the plug-in insertion instruction, an independent directory and configuration file corresponding to the plug-in are added.

7. The method according to claim 1, characterized in that The method further comprises: Receive transaction instructions sent by users, which carry functional requirements and message type requirements; According to the functional requirements and message type requirements, separate directories of corresponding functional application plug-ins and message type plug-ins are selected from the plug-in directory; The filtered independent directories are packaged into a customized source code package and sent to the user.

8. A message processing system, characterized in that: The system comprises: Plug-in framework, including multiple functional application plug-ins and message type plug-ins that support plug-in and unplug; A basic framework for executing the method according to any one of claims 1 to 7.

Images