Message processing method and system

Abstract

The invention provides a message processing method and system, and the method comprises the steps: receiving a message processing instruction from a target channel, the message processing instruction comprising a message type identifier and a to-be-processed message; 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 responds to calling to perform service logic processing on the to-be-processed message, and converting the format of the processed to-be-processed message into an interface format of a target channel interface corresponding to the message type plug-in; calling a target channel interface to send the to-be-processed message after format conversion to a target channel; wherein the function application plug-in and the message type plug-in are obtained through registration based on a preset plug-in splitting principle. The function application plug-in and the message type plug-in registered based on the plug-in splitting principle are dynamically called through the message type to execute service processing and interface format conversion, modification of traditional core codes is avoided, and the problem that a traditional method is poor in expansibility and flexibility is solved.

Description

Technical Field

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

[0002] When traditional message processing systems face the expansion of diversified message channels, the following problems exist: 1) Each time a new channel is added, the core code needs to be modified, resulting in complex system maintenance and easy errors; 2) The interface protocols of different channels vary greatly, making adaptation difficult and increasing the development difficulty and time cost; 3) The business logic is tightly coupled with the channel processing, making it difficult to flexibly expand and reuse, seriously affecting the expansion efficiency and flexibility of the system. Therefore, there is an urgent need for a new message processing method to effectively solve the above problems and achieve efficient and flexible expansion and decoupling of message processing. Summary of the Invention

[0003] This 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 this application, a message processing method is provided, which is applied to the basic framework of a message processing system. The method includes: Receiving a message processing instruction from a target channel, where the message processing instruction includes a message type identifier and a message to be processed; Invoking a function application plugin and / or a message type plugin according to the message type identifier, so that the function application plugin and / or the message type plugin respond to the invocation to perform business logic processing on the message to be processed, and convert the format of the processed message to the interface format of the target channel interface corresponding to the message type plugin; Invoking the target channel interface to send the processed message with the converted format to the target channel; Wherein, the function application plugin and the message type plugin are registered based on a preset plugin splitting principle.

[0005] In an implementable embodiment, the preset plugin splitting principle includes: Obtaining a plugin code file to be registered; Classifying the plugin code file according to the business function domain and message type to obtain code files corresponding to each business function and code files corresponding to each message type; Creating an independent directory for each business function or message type; Stripping each code file by 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 general gateway in the code file in the corresponding independent directory, and the terminal processor and the general gateway interact with other plugins through a standardized interface; If the external entity object and the entity object have no external dependencies, directly add the code of the external entity object and the entity object to the corresponding independent directory; Register the function application plug-ins corresponding to each business function and the message type plug-ins corresponding to each message type through each independent directory, and package all independent directories into a plug-in directory.

[0006] In an implementable manner, the function application plug-in is a micro application unit that can be independently deployed and runs in an independent module or embedded manner, and is used to execute general business logic that has nothing to do with the message type plug-in; The message type plug-in depends on the function plug-in, and the message type plug-in is loaded through the module federation mechanism and is used to execute the differential logic of different message channels.

[0007] In an implementable manner, before receiving the message processing instruction from the target channel, the method further includes: Receive a login instruction, and obtain the currently supported message types in response to the login instruction; Read the configuration file of the message type in the configuration information directory according to the message type, and store the configuration file in the message service; Obtain the front-end component of the message type according to the message type, and store the front-end component and the corresponding configuration file in the message service in an associated manner; Obtain the terminal processor corresponding to the message type from the plug-in directory, and store the terminal processor and the corresponding configuration file in the message service in an associated manner; Wherein, the message service implements data storage based on the singleton mode of module federation and is configured with a standardized interface.

[0008] In an implementable manner, the plug-in is further configured with a plug-in interface unit, and the plug-in interface unit is stored separately from its independent directory. The plug-in interface unit includes the interface definition file and interface rules of the plug-in, and 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.

[0009] In an implementable manner, the basic framework and the plug-in interact through a standardized interface.

[0010] In an implementable manner, the basic framework and the plug-in perform information interaction based on the Spring subscription and publishing model.

[0011] In an implementable manner, the plug-in supports plug-and-play operations, and the plug-and-play operations include: Receive a plug-in deletion instruction, and delete the independent directory and configuration file of the corresponding plug-in in response to the plug-in deletion instruction; Receive a plug-in insertion instruction, and add the independent directory and configuration file of the corresponding plug-in in response to the plug-in insertion instruction.

[0012] In one possible implementation, the method further includes: Receiving a transaction instruction sent by a user, where the transaction instruction carries a function requirement and a message type requirement; According to the function requirement and the message type requirement, filtering out an independent directory corresponding to the function application plugin and the message type plugin from the plugin directory; Packaging the filtered independent directory into a customer-customized source code package and sending it to the user.

[0013] According to a second aspect of the present application, there is provided a message processing system, the system includes: A plugin framework, including a plurality of pluggable function application plugins and message type plugins; A basic framework for executing the above message processing method.

[0014] The message processing method and system of the present application receive a message processing instruction from a target channel, where the message processing instruction includes a message type identifier and a message to be processed; calling a function application plugin and / or a message type plugin according to the message type identifier, so that the function application plugin and / or the message type plugin respond to the call to perform business logic processing on the message to be processed, and convert the processed message into a target channel interface format corresponding to the message type plugin; calling the target channel interface to send the message to be processed with the format converted to the target channel; wherein, the function application plugin and the message type plugin are registered based on a preset plugin splitting principle. By dynamically calling the function application plugin and the message type plugin registered based on the plugin splitting principle according to the message type to perform business processing and interface format conversion, it avoids modifying the traditional core code and solves the problems of poor scalability and flexibility of the traditional method.

[0015] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present application, nor is it used 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

[0016] By reading the following detailed description with reference to the accompanying drawings, the above and other objects, features, and advantages of the exemplary embodiments of the present application will become easily understood. In the drawings, several embodiments of the present application are shown in an exemplary and non-limiting manner, wherein: In the drawings, the same or corresponding reference numerals represent the same or corresponding parts.

[0017] Figure 1 Shows a schematic implementation flow diagram of the message processing method provided by the embodiment of the present application; Figure 2Shows the schematic implementation process of the plug-in initialization operation of the message processing method provided by the embodiments of the present application; Figure 3 Shows the schematic composition structure of the message processing system provided by the embodiments of the present application. Detailed implementation manners

[0018] To make the objectives, features, and advantages of the present application more obvious and understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts shall fall within the protection scope of the present application.

[0019] First, the application scenario of the present application is described. With the diversification of message channels, such as from traditional emails, text messages, voice to various current software that supports message processing, the connection between enterprises and users is becoming increasingly close. However, in the initial stage of enterprise development, the docking of message channels is relatively simple. But with the business expansion and the iteration of the integrated message platform, the existing message processing systems are difficult to cover all functions, and new functions need to be continuously iteratively developed or the existing functions need to be optimized, resulting in the system being difficult to cope with the rapid expansion of channels and the flexible combination requirements of functions. Among them, the following problems exist in the prior art: the functions of each message channel are different, and scalability is not fully considered in the design, resulting in a large amount of redundant code, insufficient optimization of code layering, prominent problems with shared verification interfaces, difficulties in combining function modules and message type channels, inability to effectively separate cross-application sharing problems, and performance problems. To solve these problems, the present application provides a message processing method and system.

[0020] Figure 1 Shows the schematic implementation process of the message processing method provided by the embodiments of the present application.

[0021] 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: Operation 101, receiving a message processing instruction from a target channel, where the message processing instruction includes a message type identifier and a message to be processed; Among them, the target channels include message channels such as text messages, emails, voice, and various software. The message type is used to distinguish message channels, and the message type can have the same meaning as the message channel, that is, each message type corresponds to a specific message channel. The message type identifier can be understood as the identifier of the message channel, which is used to uniquely identify the source and type of the message.

[0022] The basic framework of the message processing system first receives the message to be processed and the corresponding message type identifier sent by the user through terminals such as mobile phones or computers. The user terminal can be any device capable of sending and receiving messages, such as smartphones, computers, tablets, etc. The message to be processed can be in various forms such as text messages, picture messages, video messages, etc., and the specific content depends on the target channel and business requirements.

[0023] Operation 102: Call the function application plugin and / or message type plugin according to the message type identifier, so that the function application plugin and / or message type plugin respond to the call to perform business logic processing on the message to be processed, 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 plugin.

[0024] The function application plugin is a basic component in the message processing flow, providing common support for different types of message processing, and is used to provide general business logic functions. These general business logic functions are independent of the specific message type, such as general format verification of messages, basic content processing, message queue management, etc.

[0025] The message type plugin is obtained by customizing the business logic for a specific message type. For example, the application message plugin processes the message format, protocol unique to the application, and business rules related to the application platform; the SMS plugin focuses on the specific format requirements of SMS and the transmission protocol of the SMS channel. These message type plugins are specialized components in the message processing flow, which can ensure that different types of messages are accurately processed according to their respective requirements.

[0026] When the basic framework of the message processing system identifies the message type identifier, it calls at least one function plugin and / or at least one message plugin required according to the message type identifier. Among them, the basic framework and plugins of this application embodiment are combined based on micro-isolation design. The basic framework only makes calls to the plugins and does not involve the specific implementation of the plugins. That is, after the basic framework calls the plugins, subsequent message processing is performed by the plugins themselves.

[0027] After the plugin is called, it processes the message to be processed according to the preset business logic. Among them, the processing process can include multiple aspects such as parsing of message content, format conversion, application of business rules, etc. After completing the business logic processing, to ensure that the format of the message meets the requirements of the target channel, the plugin will convert the format of the processed message to be processed into the interface format required by the target channel interface.

[0028] Among them, the target channel interfaces refer to the bridges for the message processing system to communicate with external message channels. These interfaces are usually defined and provided by the service providers of the message channels, or are developed by the message processing system itself according to the requirements of the message channels. The message to be processed after format conversion needs to comply with the specification requirements of the target channel interfaces, such as the data format, transmission protocol, and security requirements of the message.

[0029] Operation 103, call the target channel interface to send the message to be processed after format conversion to the target channel; among them, the function application plugin and the message type plugin are registered based on the preset plugin splitting principle.

[0030] The basic framework of the message processing system sends the processed message to be processed to the specified target channel by calling the target channel interface. For example, if the target channel is software, call the software interface to send the message to the software platform; if it is a short message, call the short message interface to send the message to the short message gateway.

[0031] Among them, in order to ensure that the plugin can be independently updated and extended without affecting the overall stability of the message processing system and the operation of other plugins, the plugins in the embodiments of the present application are registered based on the plugin splitting principle. The plugin splitting principle can be regarded as that by splitting and registering the plugins, each plugin focuses on the message processing of a specific channel, has independent internal functions, and standardized external interfaces.

[0032] Thus, the method in the embodiments of the present application divides the business functions and the channel-specific processing of the message types into function application plugins and message type plugins, and adopts the function application plugins and message type plugins registered based on the plugin splitting principle, and dynamically calls the corresponding plugins according to the message type to execute business processing and interface format conversion, avoiding the modification of traditional core code, effectively solving the adaptation difficulties and high coupling problems during channel protocol extension, thereby realizing the rapid access of the message processing system to new message channels and the corresponding business processing, improving the scalability and flexibility, reducing the development cost, and improving the maintenance efficiency.

[0033] In an embodiment of the present application, the preset plugin splitting principle includes: obtaining the plugin code file to be registered; classifying the plugin code file according to the business function domain and message type to obtain the code files corresponding to each business function and the code files corresponding to each message type; creating an independent directory for each business function or message type; stripping each code file into a resource layer, a service layer, and a data access layer, and storing them in the corresponding independent directory in layers; storing the code corresponding to the terminal processor and the general gateway in the code file in the corresponding independent directory, and the terminal processor and the general gateway interact with other plugins through a standardized interface; if there is no external dependency for the external entity object and the entity object, directly add the code of the external entity object and the entity object to the corresponding independent directory; register the function application plugins corresponding to each business function and the message type plugins corresponding to each message type through each independent directory, and package all the independent directories into a plugin directory.

[0034] Among them, the preset plugin splitting principle aims to achieve the efficient registration and organization of plugins through the systematic management and classification of plugin code files. The preset plugin splitting principle can be specifically understood as delivering the message type function or other functions in the form of plugin functions and function extensions based on the needs of modularization and function delivery on demand, and supporting a pluggable method.

[0035] Specifically, first obtain the plugin code file to be registered, and conduct a detailed classification according to the business function domain and message type, so as to accurately identify the code files corresponding to each business function and message type.

[0036] Furthermore, to optimize the structure and management of plugins, create an independent directory for each business function or message type, strip each code file into a resource layer, a service layer, and a data access layer, and store them in the corresponding independent directory in layers. In addition, store the code corresponding to the terminal processor and the general gateway in the code file in the corresponding independent directory to ensure that the terminal processor and the general gateway can interact with other plugins through a standardized interface. For the external entity object and the entity object, if there is no external dependency, directly add its code to the corresponding independent directory. Finally, register the plugins for each business function and each message type through each independent directory, and integrate and package all the independent directories into a plugin directory for the unified management and invocation of plugins.

[0037] In this embodiment of the present application, corresponding to the part where each code file is stripped into a resource layer, a service layer, and a data access layer, and stored in the corresponding independent directory in layers; the code corresponding to the terminal processor and the general gateway in the code file is stored in the corresponding independent directory, and the terminal processor and the general gateway interact with other plugins through a standardized interface, the preset plugin splitting principle specifically includes: 1) The splitting principle of web - plugin (web plugin): 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; by encapsulating them into library files (lib packages), dynamic loading is achieved. When needed, the Java Virtual Machine (JVM) loads the entire library, and when not needed, the library file is directly removed.

[0038] Specifically, based on the split requirements of the business function list, the implementation from Resource (resource layer) -> Service (service layer) -> Repository (business access layer) is supported as an independent module. When needed, it is put into the lib package and supported by the overall loading of the JVM. When not needed, the lib package is removed without affecting other functions, and the stripping function is not supported individually.

[0039] 2) Splitting principle of mix - plugin: Taking the business filter chain as the horizontal core processing flow, during the execution of the business process, terminal processors (TerminalHelper) based on message types are inserted vertically; by splitting the implementations of terminal processors for each message type into independent plugin modules, the ability to handle business logic specific to message types is provided.

[0040] Specifically, mix is a processing flow centered around the business filter chain. During the horizontal process of business processing, TerminalHelper for handling specific message services is inserted vertically based on message types. Based on TerminalHelper, the implementations of each message handling are split and provided in the form of plugins.

[0041] 3) Splitting principle of channel - plugin: Taking the general channel processing service (ChannelServer) as the core carrier, standardize the communication ability based on the general channel interface (CommonGate); each message channel protocol encapsulates into an independent plugin module by implementing this interface, providing protocol adaptation capabilities for specific communication channels (such as SMS).

[0042] Specifically, ChannelServer is the general channel processing service. Based on CommonGate as the general channel interface, each message channel protocol implements the interface respectively and provides the final channel implementation docking in the form of plugins.

[0043] To further understand the splitting principle of mix - plugin, the following takes the splitting of application plugins as an example for illustration: 1) Separate the Resource layer independently, add the application package path, and migrate the Resource implementation to the application path. If a single Resource service contains multiple services to be separated, and the path already has a lower-layer routing distinction, directly separate a sub-Resource from the current Resource.

[0044] 2) Separate the Service layer. If the separated Service layer is dependent on by other services, when other service layers (Resource / Service) depend on it, an independent separation interface is made for the dependency, and the original interface implements the separation interface.

[0045] 3) Migration of the Repository layer. The migration of the Repository layer follows the same principle as the Service layer, that is, when other service layers (ServiceImpl) depend on it, an independent upper-layer service interface is created, and the separation interface is used for the dependency, and the original interface implements the separation interface.

[0046] 4) Migration of external entity objects (DTO). If there is no external service dependency, directly migrate them into the plugin package. If there is a usage dependency, do not migrate them temporarily.

[0047] 5) Migration of entity objects (Entity). If there is no external service dependency, directly migrate them into the plugin package. If there is a usage dependency, do not migrate them temporarily.

[0048] In an embodiment of the present application, the functional application plugin is an independently deployable micro-application unit, which runs in an independent module or embedded manner and is used to execute general business logic unrelated to the message type plugin; the message type plugin attaches to the functional plugin and is loaded through the module federation mechanism and is used to execute the differential logic of different message channels.

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

[0050] Among them, the functional application plugin can be started and packaged independently, or can be embedded in the basic framework (main application) in the form of a sub-project to start and deploy the functions of code commonality (code unrelated to specific message types). The message type plugin cannot be started independently and depends on the environment provided by the functional application plugin to start. Through the module federation mechanism, each message plugin will generate a separate JS (JavaScript) file and be loaded on demand. The message type plugin is used to write differential logic code related to specific message types (different logics for different message types).

[0051] Among them, the code files, data types, and configuration file parts of each plugin are stored highly independently. The code files are highly independent within the plugin directory. That is, all kinds of information, source code, and code files exclusive to the plugin exist independently within its own directory and are not scattered within other plugins or the basic framework.

[0052] In an embodiment of the present application, the function application plugins may include standard product plugins, control function plugins, short-chain value-added function plugins, patch function plugins, standard statistics function plugins, operation weekly and monthly report plugins, etc. The message type plugins may include SMS plugins, 5G message plugins, voice plugins, email plugins, video SMS plugins, and various application plugins, etc.

[0053] Figure 2 It shows a schematic diagram of the implementation process of the plugin initialization operation of the message processing method provided by the embodiment of the present application.

[0054] Refer to Figure 2 , in an embodiment of the present application, before receiving the message processing instruction from the target channel, the method further includes: Operation 201, receiving a login instruction and obtaining the currently supported message types in response to the login instruction; Operation 202, reading the configuration file under the configuration information directory according to the message type and storing the configuration file in the message service; Operation 203, obtaining the front-end component according to the message type and associating and storing the front-end component with the corresponding configuration file in the message service; Operation 204, obtaining the terminal processor corresponding to the message type from the plugin directory and associating and storing the terminal processor with the corresponding configuration file in the message service; wherein, the message service implements data storage based on the singleton pattern of module federation and is configured with a standardized interface.

[0055] Specifically, after receiving the login instruction and logging in successfully, call the backend interface in the startup service of the base (basic framework) to obtain the message types authorized by the current system. Subsequently, read the corresponding message types and configuration data, that is, the configuration file, under the configuration information directory, and save these data together with the message types in the message service. In the module federation mode, all service data is stored in singleton form, enabling other micro-applications to share these data. Next, according to the obtained message type data, read the components and configuration objects corresponding to the plugins message type and cache them.

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

[0057] In an embodiment of the present application, the plug-in is further configured with a plug-in interface unit, and the plug-in interface unit is separately stored in its independent directory. The plug-in interface unit includes the interface definition file and interface rules of the plug-in. 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.

[0058] Among them, the above interface configuration method of the plug-in is also applicable to the basic framework interface.

[0059] Specifically, the plug-in design emphasizes the standardization of the framework interface and the plug-in interface. The interface part of the plug-in or the basic framework should be independent as a unit file. The interface unit only retains the information related to the interface, that is, the interface definition file, and ensures to avoid cross-reference. That is, it is prohibited to directly reference the internal unit of the plug-in by skipping the interface unit.

[0060] The principle of prohibiting cross-reference of interfaces between plug-ins can be regarded as prohibiting plug-ins from directly referencing the interface definition files of each other. For example, plug-in A cannot directly reference the interface definition of plug-in B in the code, and vice versa. This is to avoid generating tight mutual dependence relationships between plug-ins and prevent the interface change of one plug-in from affecting multiple other plug-ins.

[0061] The principle of isolating data types between plug-ins can be regarded as that the data type definitions within each plug-in should be as independent as possible, and avoid directly using the data types defined by other plug-ins. For example, if plug-in A uses the interface of plug-in B, but plug-in B also references the data type of plug-in C, then plug-in B should alias the type of plug-in C to ensure that plug-in A can complete the operation of using plug-in B by directly referencing the unit file once. This is to prevent the change of data types from causing a chain reaction between plug-ins.

[0062] The principle of unified access to interfaces can be regarded as that all calls to the functions of the plug-in must be made through a unified interface. For example, if plug-in A wants to use the function of plug-in B, it must be called through the interface definition file of plug-in B, and cannot directly access the internal implementation code of plug-in B or other non-specified entrances. This ensures that the access to the functions of the plug-in is controllable, consistent, and convenient for version update and maintenance of the plug-in.

[0063] In an embodiment of the present application, the basic framework and the plug-in are designed based on the separation principle. The basic framework and the plug-in interact through a standardized interface, and the standardized interface can be understood as the interface unit of the above framework and plug-in.

[0064] Specifically, the dominant factor of the framework prototype is not the technical foundation, but requirement management. Because in the case of ever-changing business requirements, being able to respond to changes calmly and quickly is the core issue of management. In actual projects, whether in the initial development stage, the maintenance period, or the later version iteration, business modules are often the source of changes. Therefore, the requirements put forward in management are to only change or delete the parts that have changed.

[0065] According to the requirements of business modules, they can be divided into a basic framework and functional modules. Among them, the basic module contains almost unchanged business logic, while the functional module is the more changeable part of business requirements. Plugins usually act on functional modules. By extracting different plugins from functional modules and adopting different processing methods, each plugin can handle different requirement scenarios.

[0066] In an embodiment of the present application, information interaction between the basic framework and plugins is based on the Spring subscription and publishing model.

[0067] The Spring subscription and publishing model is an event-driven programming model used for decoupled communication between various components within a system. Given its decoupling ability, the present application conducts communication between the basic framework and plugins based on the Spring subscription and publishing model to avoid mutual reference between plugin units and meet the decoupling requirements.

[0068] Specifically, a plugin needs to subscribe to specific messages from the basic framework, and then the basic framework pushes corresponding messages to the plugin. During this process, through inheritance or composition, etc., the exposed interfaces are abstracted to ensure that the transmitted messages contain complete parameters. If the message parameters cannot fully convey the required information, the plugin has the right to obtain more detailed message content from the basic framework and extract the parameters it belongs to according to its own needs to implement different business logics.

[0069] In an embodiment of the present application, plugins support plug-and-play operations, and the plug-and-play operations include: receiving a plugin deletion instruction and deleting the independent directory and configuration file of the corresponding plugin in response to the plugin deletion instruction; receiving a plugin insertion instruction and adding the independent directory and configuration file of the corresponding plugin in response to the plugin insertion instruction.

[0070] Specifically, the plugins in the embodiments of the present application support plug-and-play. When a certain plugin needs to be deleted, with just one key operation, the code files and configuration files of the plugin can be removed simultaneously, thus achieving a complete residue-free uninstallation. The process of inserting a new plugin is also very simple. Just add the independent directory of the plugin to the plugin directory. In this way, through this plugin-based modular framework, the efficiency of the development process is greatly improved, and the entire development cycle is effectively shortened.

[0071] In an embodiment of the present application, transaction services are also provided externally based on the message processing system, specifically including: receiving a transaction instruction sent by a user, where the transaction instruction carries functional requirements and message type requirements; screening out the independent directories corresponding to the functional application plug-ins and message type plug-ins from the plug-in directory according to the functional requirements and message type requirements; and packaging the screened independent directories into a customer-customized source code package and sending it to the user.

[0072] Specifically, in an actual project, based on the message processing system, the functional application plug-ins, message type plug-ins, and message type channels within the functional module can be flexibly combined according to customer requirements and packaged into source code for the customer. Among them, the source code provided to the customer is limited to the functional modules and message type channels that the customer has purchased, and can run normally, be packaged and deployed, and support functional expansion.

[0073] Figure 3 The composition architecture diagram of the message processing system provided by the embodiment of the present application is shown.

[0074] Reference Figure 3 Based on the above message processing method, an embodiment of the present application also provides a message processing system, which includes a basic framework 301 and a plug-in framework 302. Among them, the basic framework 301 is used to execute the above message processing method, and the plug-in framework 302 includes a plurality of pluggable functional application plug-ins and message type plug-ins.

[0075] 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 to the method embodiment, so it will not be repeated. For the technical details not described in the message processing device provided by the embodiment of the present application, they can be understood according to the description of any one of the drawings in Figures 1 to 2 Any one of the drawings in

[0076] It should be understood that various forms of processes shown above can be used, steps can be reordered, added, or deleted. For example, the steps recorded in the present disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present application can be achieved, and no limitations are made herein.

[0077] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the present application, "a plurality of" means two or more, unless otherwise specifically defined.

[0078] As described above, it is only the specific implementation manner of the present application. However, the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of changes or substitutions, which should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims described above.

Claims

1. A message processing method, characterized in that, A basic framework applied to a message processing 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; Invoking a function application plugin and / or a message type plugin according to the message type identifier, so that the function application plugin and / or the message type plugin perform business logic processing on the message to be processed in response to the invocation, and convert the format of the processed message to the interface format of the target channel interface corresponding to the message type plugin; Invoking the target channel interface to send the message to be processed with the format converted to the target channel; Wherein, the function application plugin and the message type plugin are registered based on a preset plugin splitting principle.

2. The method according to claim 1, characterized in that, The preset plugin splitting principle includes: Obtaining a plugin code file to be registered; Classifying the plugin code file according to the business function domain and the message type to obtain code files corresponding to each business function and code files corresponding to each message type; Creating an independent directory for each business function or message type; Stripping each code file by 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 general gateway in the code file in the corresponding independent directory, and the terminal processor and the general gateway interact with other plugins through a standardized interface; If the external entity object and the entity object have no external dependencies, directly add the code of the external entity object and the entity object to the corresponding independent directory; Registering the function application plugins corresponding to each business function and the message type plugins corresponding to each message type through each independent directory, and packaging all independent directories into a plugin directory.

3. The method according to claim 2, wherein The function application plugin is a micro application unit that can be independently deployed and runs in an independent module or embedded manner, and is used to execute general business logic independent of the message type plugin; The message type plugin depends on the function plugin, and the message type plugin is loaded through a module federation mechanism and is used to execute the differential logic of different message channels.

4. The method according to claim 2, wherein Before receiving the message processing instruction from the target channel, the method further includes: Receiving a login instruction, and obtaining the currently supported message types in response to the login instruction; Reading the configuration file of the message type in the configuration information directory according to the message type, and storing the configuration file in the message service; Obtaining the front-end component of the message type according to the message type, and associating and storing the front-end component with the corresponding configuration file in the message service; Obtaining the terminal processor corresponding to the message type from the plugin directory, and associating and storing the terminal processor with the corresponding configuration file in the message service; Wherein, the message service realizes data storage based on the singleton mode of module federation and is configured with a standardized interface.

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

6. The method according to claim 1, wherein The basic framework and the plugin interact through a standardized interface.

7. The method according to claim 1, wherein The basic framework and the plugin perform information interaction based on the Spring subscription and publishing model.

8. The method according to claim 3, wherein The plug-in supports plugging and unplugging operations, and the plugging and unplugging operations 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.

9. The method according to claim 2, wherein The method further includes: Receiving a transaction instruction sent by a user, where the transaction instruction carries a function requirement and a message type requirement; According to the function requirement and the message type requirement, screening out the independent directories of the corresponding function application plug-ins and message type plug-ins from the plug-in directory; Packaging the screened independent directories into a customer-customized source code package and sending it to the user.

10. A message processing system, characterized in that, The system includes: A plug-in framework, including multiple function application plug-ins and message type plug-ins that support plugging and unplugging; A basic framework for executing the method according to any one of claims 1-9.

Images