Message management methods, devices, electronic equipment and computer-readable storage media

Abstract

This application relates to the fields of IT applications and Java development, and provides a message management method, apparatus, electronic device, and computer-readable storage medium. The method includes: determining an access request and a pointcut method name for the access request; determining a platform identifier based on a URL placeholder parameter in the access request, and determining the platform to be accessed based on the platform identifier; determining the platform message definition class and platform message processor of the platform to be accessed based on the pointcut method name and the platform identifier; and serializing and deserializing the request message of the platform to be accessed based on the platform message definition class and platform message processor to generate a response message. The message management method provided in this application, by determining the platform message definition class and platform message processor of the platform to be accessed through the pointcut method name of the access request and the platform identifier of the platform to be accessed, can process the request message of the platform to be accessed, minimizing differences in processing and improving the efficiency of interfacing with various platforms to be accessed.

Description

Technical Field

[0001] This application relates to the fields of IT applications and Java development, and in particular to a message management method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Currently, smart phone recharge relies on provincial-level administrative regions' systems to provide functions such as balance alerts and reverse cancellation of phone number accounts. When the smart phone recharge platform interfaces with these provincial-level administrative regions, the differences in these systems lead to variations in the interface messages, making it impossible for the platform to connect with them using a unified interface. Most provincial-level administrative regions use JSON format for their interface messages, while a few use XML format. Even within the same format, there are differences in fields. Each time a new provincial-level administrative region connects, message parsing and response processing must be performed specifically for that region. This requires using FastJson for JSON message serialization and deserialization, or dom4j for reading and writing XML messages, tailored to the specific message characteristics of that province.

[0003] Therefore, in the current process of connecting with various provincial-level administrative regions through interfaces, the logic and flow of message processing for smart mobile phone top-up platforms are basically the same. The only difference is the different message formats of each provincial-level administrative region. However, existing technical solutions suffer from a large amount of duplicate code, low development efficiency, and inability to keep up with the speed of business development. Summary of the Invention

[0004] This application provides a message management method, apparatus, electronic device, and computer-readable storage medium, which aims to minimize discrepancies and improve the efficiency of interoperability with various platforms.

[0005] Firstly, this application provides a message management method, including: Determine the access request intercepted by the controller's cutoff point, and determine the cutoff method name of the access request; The platform identifier is determined based on the URL placeholder parameter in the access request, and the platform to be accessed is determined based on the platform identifier. Based on the point method name and the platform identifier, determine the platform message definition class and platform message processor of the platform to be accessed; Based on the platform message definition class and the platform message processor, the request message of the platform to be accessed is serialized and deserialized to generate a response message.

[0006] In one embodiment, determining the platform message definition class and platform message processor of the platform to be accessed based on the pointcut method name and the platform identifier includes: Determine whether there exists a target message definition class and a target message processor that match the pointcut method name and the platform identifier; If the target message definition class and the target message processor do not exist, then the preset message definition class and the preset message processor are determined. The preset message definition class and the preset message processor are determined as the platform message definition class and the platform message processor.

[0007] The step of serializing and deserializing the request message of the platform to be accessed, based on the platform message definition class and the platform message processor, to generate a response message includes: The request message is deserialized using the preset message definition class and the preset message processor to obtain a Java object of the request message; Determine the signature algorithm and signature key of the platform to be accessed, and determine the response message definition class of the platform to be accessed based on the pointcut method name and platform identifier; Configure the signature algorithm and the signature key into the data of the Java object of the request message; The response message is generated by serializing the signed request message Java object using the response message definition class.

[0008] The step of deserializing the request message using the preset message definition class and the preset message processor to obtain a Java object of the request message includes: Determine the message type of the request message, wherein the message type includes JSON message type and XML message type; Based on the message type, the preset message definition class, and the preset message processor, the request message is deserialized to obtain a Java object of the request message.

[0009] The step of deserializing the request message according to the message type, the preset message definition class, and the preset message processor to obtain a Java object of the request message includes: If the message type is JSON, the message string of the request message is converted into a Java object of the preset message definition class by the Gson message processor to obtain the Java object of the request message.

[0010] The step of deserializing the request message according to the message type, the preset message definition class, and the preset message processor to obtain a Java object of the request message includes: If the message type is an XML message type, then the XStream message processor converts the message string of the request message into a Java object of the preset message definition class to obtain the Java object of the request message.

[0011] After determining whether there exists a target message definition class and target message processor that match the pointcut method name and the platform identifier, the method further includes: If a target message definition class and a target message processor exist, then the signature algorithm and signature key are configured for the request message through the target message definition class and the target message processor.

[0012] Secondly, this application provides a message management device, comprising: The first determining module is used to determine the access request intercepted by the controller's cutoff point and to determine the cutoff point method name of the access request; The second determining module is used to determine the platform identifier based on the URL placeholder parameter in the access request, and to determine the platform to be accessed based on the platform identifier. The third determining module is used to determine the platform message definition class and platform message processor of the platform to be accessed based on the point method name and the platform identifier. The message processing module is used to serialize and deserialize the request message of the platform to be accessed according to the platform message definition class and the platform message processor, and generate a response message.

[0013] Thirdly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the message management method described in the first aspect.

[0014] Fourthly, this application also provides a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium including a computer program, which, when executed by the processor, implements the message management method described in the first aspect.

[0015] Fifthly, this application also provides a computer program product, which includes a computer program that, when executed by the processor, implements the message management method described in the first aspect.

[0016] The message management method, apparatus, electronic device, and computer-readable storage medium provided in this application can directly determine the platform message definition class and platform message processor of the platform to be accessed by means of the pointcut method name of the access request and the platform identifier of the platform to be accessed during the message processing of the platform to be accessed. This enables the rapid processing of the request messages of the platform to be accessed by means of the platform message definition class and platform message processor, without the need to set up a large amount of repetitive code, thereby minimizing the difference processing and improving the efficiency of interfacing with each platform to be accessed. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the message management method provided in this application; Figure 2 This is a schematic diagram of the message processor provided in this application; Figure 3 This is a schematic diagram of the request message provided in this application; Figure 4 This is a schematic diagram of the response message provided in this application; Figure 5 This is a schematic diagram of the message management device provided in this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] Figures 1 to 6 This application describes the message management method, apparatus, electronic device, and computer-readable storage medium provided. Figure 1 This is a flowchart illustrating the message management method provided in this application; Figure 2 This is a schematic diagram of the message processor provided in this application; Figure 3 This is a schematic diagram of the request message provided in this application; Figure 4 This is a schematic diagram of the response message provided in this application; Figure 5This is a schematic diagram of the message management device provided in this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application.

[0021] This application provides an embodiment of a message management method. It should be noted that although the logical order is shown in the flowchart, under certain data conditions, the steps shown or described may be performed in a different order than that shown here.

[0022] Reference Figure 1 , Figure 1 This is a flowchart illustrating the message management method provided in this application. The message management method provided in this application includes: It should be noted that this application embodiment uses an electronic device as the execution subject for example. The execution subject in this application embodiment is determined by the application scenario, which includes, but is not limited to, mobile phone top-up application scenarios, data traffic top-up application scenarios, and service subscription application scenarios. The mobile phone top-up application scenario corresponds to an intelligent mobile phone top-up platform, the data traffic top-up application scenario corresponds to an intelligent data traffic top-up platform, and the service subscription application scenario corresponds to an intelligent service subscription platform. For ease of understanding, this application embodiment uses the mobile phone top-up application scenario as an example for illustration; therefore, this application embodiment uses an intelligent mobile phone top-up platform as the execution subject for limited illustration.

[0023] It should be further noted that the intelligent mobile phone top-up platform includes, but is not limited to, a controller and a message handler. The controller includes controller cutoffs, used to intercept access requests sent to the intelligent mobile phone top-up platform. The message handler has the functions of request message parsing, post-parsing processing, response pre-processing, and response message generation.

[0024] Step S10: Determine the access request intercepted by the controller's cutoff point, and determine the cutoff point method name of the access request.

[0025] The intelligent mobile phone top-up platform interfaces with various regional or enterprise platforms. These regional platforms include mobile platforms in provincial-level administrative regions and municipalities directly under the central government, such as the Guangdong, Beijing, and Shanghai mobile platforms; while enterprise platforms include Alipay and WeChat Pay. Furthermore, the intelligent mobile phone top-up platform relies on these regional or enterprise platforms to provide balance alerts and reverse cancellation / smart top-up functions for canceled accounts. Therefore, when a regional or enterprise platform needs to connect to the intelligent mobile phone top-up platform, it must send an access request to the platform.

[0026] Furthermore, the intelligent mobile phone top-up platform intercepts access requests sent by a regional platform or an enterprise platform in real time through the controller cutoff point in the controller, in order to determine the access requests intercepted by the controller cutoff point and the cutoff point method name of the access requests.

[0027] Step S20: Determine the platform identifier based on the URL placeholder parameter in the access request, and determine the platform to be accessed based on the platform identifier; It should be noted that the access request in this embodiment is represented in URL (Uniform Resource Locator) format.

[0028] Therefore, after determining the access request URL intercepted by the controller, the smart phone bill recharge platform needs to determine the URL placeholder parameter in the access request URL, and then determine the platform identifier based on the URL placeholder parameter. The URL placeholder parameter is the end of the access request URL, and can be further understood as the platform identifier. In one embodiment, an access request URL is https: / / ip:port / recharge / hunan. Therefore, determining the URL placeholder parameter of a certain access request as hunan means that the smart phone bill recharge platform determines the platform identifier of a certain access request URL as hunan.

[0029] Furthermore, the smart phone bill recharge platform searches its preset identifier platform lookup table for the platform to be accessed, based on the platform identifier. This preset identifier platform lookup table is set up by platform personnel according to actual conditions. Examples of preset identifier platform lookup tables include {Platform identifier is hunan, platform to be accessed is Hunan Mobile}, {Platform identifier is shanghai, platform to be accessed is Shanghai Mobile}, {Platform identifier is beijing, platform to be accessed is Beijing Mobile}, and {Platform identifier is guangdong, platform to be accessed is Guangdong Mobile}. Therefore, in the above embodiment, if the platform identifier of a certain access request URL is hunan, then the platform to be accessed sending that access request URL is Hunan Mobile.

[0030] Step S30: Determine the platform message definition class and platform message processor of the platform to be accessed based on the cut-off method name and the platform identifier.

[0031] Furthermore, after the intelligent mobile phone top-up platform determines the platform to be accessed via the URL to send the access request, it needs to determine the platform message definition class and platform message processor applicable to the platform to be accessed corresponding to the determined pointcut method name and platform identifier, as described in steps S301 to S303. The request message has a default definition class, and the message processor has a default implementation of the interface. When different regional platforms or enterprise platforms have special processing, they can be customized and identified through annotations.

[0032] Furthermore, referring to Figure 2 , Figure 2 This is a schematic diagram of the message processor provided in this application. The message processor includes a message processor interface, a JSON message processor, and an XML message processor. The XML and JSON message processors are mainly used for request message parsing and response message generation, while the message processor is mainly used for request message parsing, post-parsing processing, response pre-processing, and response message generation. Furthermore, the smart phone bill recharge platform supports JSON and XML message formats by default. Users can override the corresponding methods by inheriting the default message processor or reimplement the message processor interface to achieve special processing of messages. Post-parsing processing and response pre-processing are the default methods of the interface. Post-parsing processing can be used for special checks on messages from different access points, intercepting problematic messages; by default, no special processing is performed, and the parsed message object is returned directly. Response pre-processing can be used for the conversion processing of messages returned by different access points, such as the returned content.

[0033] Further, steps S301 to S303 are described as follows: Step S301: Determine whether there exists a target message definition class and a target message processor that match the pointcut method name and the platform identifier; Step S302: If the target message definition class and the target message processor do not exist, then determine the preset message definition class and the preset message processor. Step S303: Determine the preset message definition class and the preset message processor as the platform message definition class and the platform message processor.

[0034] Specifically, the smart phone bill recharge platform determines, based on the cutoff method name and platform identifier, whether there exists a platform message definition class and platform message processor applicable to both the cutoff method name and the platform identifier to be accessed. In other words, it determines whether a target message definition class and target message processor match the cutoff method name and platform identifier. If no target message definition class and target message processor match the cutoff method name and platform identifier, the smart phone bill recharge platform determines its own default preset message definition class and preset message processor, and sets these default preset message definition classes and preset message processors as the platform message definition classes and platform message processors for the platform to be accessed. If a target message definition class and target message processor match the cutoff method name and platform identifier, the smart phone bill recharge platform sets these target message definition classes and target message processors as the platform message definition classes and platform message processors for the platform to be accessed.

[0035] This application embodiment directly determines the platform message definition class and platform message processor of the platform to be accessed by using the pointcut method name of the access request and the platform identifier of the platform to be accessed. This enables the processing of the request message of the platform to be accessed, minimizing the difference processing and improving the docking efficiency with each platform to be accessed.

[0036] Step S40: Based on the platform message definition class and the platform message processor, serialize and deserialize the request message of the platform to be accessed to generate a response message.

[0037] It should be noted that in this embodiment, deserialization is the process of converting a request message into a message Java object, and serialization is the process of converting a message Java object into a message string.

[0038] Furthermore, for cases where the platform message definition class and platform message processor are preset message definition classes and preset message processors: The smart phone bill recharge platform determines the message type of the request message to be accessed. Since the smart phone bill recharge platform supports JSON and XML message formats by default, the message types include JSON and XML message types. Next, based on the message type of the request message, the smart phone bill recharge platform calls the preset message processor to deserialize the request message. This can be understood as calling the preset message processor to convert the request message into a Java object of the preset message definition class, thus obtaining the Java object of the request message.

[0039] Furthermore, the intelligent mobile phone top-up platform determines the signature algorithm and signature key of the platform to be accessed, and determines the response message definition class of the platform to be accessed based on the pointcut method name and the platform identifier of the platform to be accessed, and configures the signature algorithm and signature key for the data of the Java object of the request message.

[0040] Furthermore, if both request message parsing and post-parsing processing are successful, business processing is then performed. Finally, the intelligent mobile phone recharge platform serializes the signed request message Java object through the response message definition class. This can be understood as converting the signed request message Java object into a message string through the response message definition class, generating a response message to be accessed by the platform, as described in steps S401 to S404.

[0041] Furthermore, in the case where the platform message definition class and platform message processor are the target message definition class and target message processor: if the smart phone bill recharge platform determines that a target message definition class and target message processor exist, then the target message definition class and target message processor are used as the platform message definition class and platform message processor of the platform to be accessed. The platform directly configures the signature algorithm and signature key for the request message of the platform to be accessed through the target message definition class and target message processor, generating a response message, without needing to serialize and deserialize the request message of the platform to be accessed. This embodiment of the application flexibly handles the request message of the platform to be accessed according to the actual situation of the platform to be accessed and the smart phone bill recharge platform, minimizing differences in processing and improving the efficiency of interfacing with each platform to be accessed.

[0042] This embodiment provides a message management method. During the message processing of the platform to be accessed, the platform message definition class and platform message processor of the platform to be accessed can be determined directly through the pointcut method name of the access request and the platform identifier of the platform to be accessed. This enables the request messages of the platform to be accessed to be processed quickly through the platform message definition class and platform message processor, without setting up a large amount of repetitive code, minimizing differences in processing, improving the efficiency of docking with each platform to be accessed, and further increasing the stability of the platform.

[0043] Furthermore, referring to Figure 3 , Figure 3This is a schematic diagram of the request message provided in this application. The request message in this embodiment includes a reverse cancellation interface, a warning recharge interface, a 95% discount contract signing interface, a reverse cancellation function, a warning recharge function, a 95% discount contract signing function, and an access request generation function. Specifically, the reverse cancellation interface can obtain the protocol ID, mobile phone number, payment account, and payment account type; the warning recharge interface can obtain the protocol ID, warning balance, recharge amount, mobile phone number, and payment account; the 95% discount contract signing interface can obtain the mobile phone number, payment account, effective date, and expiration date; the reverse cancellation function is used to sign the obtained protocol ID, mobile phone number, and payment account; the warning recharge function is used to sign the obtained protocol ID, warning balance, recharge amount, mobile phone number, and payment account; the 95% discount contract signing function is used to sign the obtained mobile phone number, payment account, effective date, and expiration date; and the access request generation function is used to obtain the signature string and generate an access request.

[0044] Furthermore, the intelligent mobile phone top-up platform in this embodiment can provide a unified transaction access point for various regional platforms or enterprise platforms. It transmits the platform identifier of each regional or enterprise platform through URL placeholder parameters and transmits the message body via POST data. When a new regional or enterprise platform is connected, if the new platform uses a default message format, the intelligent mobile phone top-up platform only needs to configure parameters such as the signature key and signature algorithm for the new platform's messages. If the new platform has different requirements for the message format, in addition to the above configuration, the intelligent mobile phone top-up platform also needs to define a message implementation class for the new platform, specifying the corresponding new platform and transaction name through annotations.

[0045] Furthermore, for each type of message, a unified interface is defined according to business requirements. When a new regional platform or enterprise platform connects, a default message implementation class is used, or a message implementation class is defined according to the message specification of the new regional platform or enterprise platform, and the relevant interfaces for that type of message are implemented. The method for obtaining the signature string can use the default method or be overridden for personalized processing, depending on the message specification of the new regional platform or enterprise platform. Furthermore, for messages from each regional platform or enterprise platform, the signature rules for all interfaces are usually the same. The existing default method can be used to obtain the signature string, or the method for obtaining the signature string can be overridden for that regional platform or enterprise platform, or a method for obtaining the signature string can be overridden individually for a specific interface, to meet the processing needs of different signature rules for different interfaces on different regional platforms or enterprise platforms.

[0046] Furthermore, referring to Figure 4 , Figure 4This is a schematic diagram of the response message provided in this application. The response message includes an access return interface, a 5% discount order query interface, a protocol query interface, an access return function, a 5% discount order query function, and a protocol query function. The access return interface is used to set the return code and return information; the 5% discount order query interface is used to obtain the number of orders and the total order amount; the protocol query interface is used to obtain the protocol number, the warning amount, and the recharge amount; the access return function is used to return the return code and return information; the 5% discount order query function is used to return the number of orders and the total order amount; and the protocol query function returns the protocol number, the warning amount, and the recharge amount.

[0047] Furthermore, currently, the response message only indicates whether the response was successful for each regional platform or enterprise platform by default, and if so, if it failed, the reason for the failure. For some regional platforms or enterprise platforms that require more information, the message implementation class can be redefined for that specific regional platform or enterprise platform and the corresponding interface name, using annotations.

[0048] Further, steps S401 to S404 are described as follows: Step S401: Deserialize the request message using the preset message definition class and the preset message processor to obtain a Java object of the request message; Step S402: Determine the signature algorithm and signature key of the platform to be accessed, and determine the response message definition class of the platform to be accessed based on the cut-off method name and platform identifier; Step S403: Configure the signature algorithm and the signature key into the data of the Java object of the request message; Step S404: Serialize the Java object of the signed request message using the response message definition class to generate the response message.

[0049] Specifically, the intelligent mobile phone top-up platform calls a preset message processor to deserialize the request message, that is, to convert the request message into a Java object of a preset message definition class, thus obtaining the Java object of the request message, as described in steps S4011 to S4012. Further, the intelligent mobile phone top-up platform determines the signature algorithm and signature key of the platform to be accessed, and determines the response message definition class of the platform to be accessed based on the pointcut method name and the platform identifier of the platform to be accessed, and configures the signature algorithm and signature key for the data of the Java object of the request message. Finally, the intelligent mobile phone top-up platform serializes the signed Java object of the request message through the response message definition class, that is, to convert the signed Java object of the request message into a message string, generating the response message of the platform to be accessed.

[0050] This application embodiment performs special processing on the differences in request messages, such as deserialization, message encryption and decryption, and no signature during leased line access. These special differences are achieved through a custom message processor.

[0051] Further, steps S4011 to S4012 are described as follows: Step S4011: Determine the message type of the request message, wherein the message type includes JSON message type and XML message type; Step S4012: Deserialize the request message according to the message type, the preset message definition class, and the preset message processor to obtain a Java object of the request message.

[0052] Specifically, the smart phone bill recharge platform determines the message type of the request message to be accessed by the platform. Since the smart phone bill recharge platform supports JSON and XML message formats by default, the message types include JSON and XML message types. Next, the smart phone bill recharge platform deserializes the request message according to its message type, as well as the preset message definition class and preset message processor, to obtain the Java object of the request message, as described in steps S40121 to S40122.

[0053] The embodiments of this application can deserialize request messages in different formats according to the message type of the request message, thereby realizing flexible processing of request messages.

[0054] Further, steps S40121 to S40122 are described as follows: Step S40121: If the message type is a JSON message type, the message string of the request message is converted into a Java object of the preset message definition class by the Gson message processor to obtain the Java object of the request message. Step S40122: If the message type is an XML message type, the message string of the request message is converted into a Java object of the preset message definition class by the XStream message processor to obtain the Java object of the request message.

[0055] Specifically, if the message type is determined to be JSON, the smart phone bill recharge platform uses the Gson message processor to convert the request message string into a Java object of a predefined message class, thus obtaining the Java object of the request message. If the message type is determined to be XML, the smart phone bill recharge platform uses the XStream message processor to convert the request message string into a Java object of a predefined message class, thus obtaining the Java object of the request message. Furthermore, if the platform to be integrated performs special processing after message parsing, but this is not within the scope of business processing, it can be implemented by overriding the post-parsing processing method.

[0056] Furthermore, the deserialization and serialization of JSON message types correspond to each other, and the deserialization and serialization of XML message types correspond to each other, specifically: For JSON message serialization: If the message type is determined to be JSON, the smart phone bill recharge platform uses the Gson message processor to convert the Java object of the request message into a message string and generate a JSON message response.

[0057] For XML message serialization: If the message type is determined to be XML, the smart phone bill recharge platform uses the XStream message processor to convert the Java object of the request message into a message string and generate an XML message response message.

[0058] The embodiments of this application can serialize and deserialize request messages in different formats according to the message type of the request message, thereby realizing flexible processing of request messages.

[0059] Furthermore, the message management device provided in this application will be described below. The message management device described below can be referred to in correspondence with the message management method described above.

[0060] like Figure 5 As shown, Figure 5 This is a schematic diagram of the message management device provided in this application. The message management device includes: The first determining module 501 is used to determine the access request intercepted by the controller's cut-off point and to determine the cut-off point method name of the access request; The second determining module 502 is used to determine the platform identifier based on the URL placeholder parameter in the access request, and to determine the platform to be accessed based on the platform identifier. The third determining module 503 is used to determine the platform message definition class and platform message processor of the platform to be accessed based on the point method name and the platform identifier. The message processing module 504 is used to serialize and deserialize the request message of the platform to be accessed according to the platform message definition class and the platform message processor, and generate a response message.

[0061] Furthermore, the third determining module 503 is also used for: Determine whether there exists a target message definition class and a target message processor that match the pointcut method name and the platform identifier; If the target message definition class and the target message processor do not exist, then the preset message definition class and the preset message processor are determined. The preset message definition class and the preset message processor are determined as the platform message definition class and the platform message processor.

[0062] Furthermore, the message processing module 504 is also used for: The request message is deserialized using the preset message definition class and the preset message processor to obtain a Java object of the request message; Determine the signature algorithm and signature key of the platform to be accessed, and determine the response message definition class of the platform to be accessed based on the pointcut method name and platform identifier; Configure the signature algorithm and the signature key into the data of the Java object of the request message; The response message is generated by serializing the signed request message Java object using the response message definition class.

[0063] Furthermore, the message processing module 504 is also used for: Determine the message type of the request message, wherein the message type includes JSON message type and XML message type; Based on the message type, the preset message definition class, and the preset message processor, the request message is deserialized to obtain a Java object of the request message.

[0064] Furthermore, the message processing module 504 is also used for: If the message type is JSON, the message string of the request message is converted into a Java object of the preset message definition class by the Gson message processor to obtain the Java object of the request message.

[0065] Furthermore, the message processing module 504 is also used for: If the message type is an XML message type, then the XStream message processor converts the message string of the request message into a Java object of the preset message definition class to obtain the Java object of the request message.

[0066] Furthermore, the message processing module 504 is also used for: If a target message definition class and a target message processor exist, then the signature algorithm and signature key are configured for the request message through the target message definition class and the target message processor.

[0067] The specific embodiments of the message management device provided in this application are basically the same as the embodiments of the message management method described above, and will not be repeated here.

[0068] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include: a processor 610, a communications interface 620, a memory 630, and a communication bus 640, wherein the processor 610, the communications interface 620, and the memory 630 communicate with each other through the communication bus 640. The processor 610 can call logical instructions in the memory 630 to execute a message management method, which includes: Determine the access request intercepted by the controller's cutoff point, and determine the cutoff method name of the access request; The platform identifier is determined based on the URL placeholder parameter in the access request, and the platform to be accessed is determined based on the platform identifier. Based on the point method name and the platform identifier, determine the platform message definition class and platform message processor of the platform to be accessed; Based on the platform message definition class and the platform message processor, the request message of the platform to be accessed is serialized and deserialized to generate a response message.

[0069] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0070] On the other hand, this application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer is able to execute the message management method provided by the methods described above. This method includes: Determine the access request intercepted by the controller's cutoff point, and determine the cutoff method name of the access request; The platform identifier is determined based on the URL placeholder parameter in the access request, and the platform to be accessed is determined based on the platform identifier. Based on the point method name and the platform identifier, determine the platform message definition class and platform message processor of the platform to be accessed; Based on the platform message definition class and the platform message processor, the request message of the platform to be accessed is serialized and deserialized to generate a response message.

[0071] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the message management methods provided above, the method comprising: Determine the access request intercepted by the controller's cutoff point, and determine the cutoff method name of the access request; The platform identifier is determined based on the URL placeholder parameter in the access request, and the platform to be accessed is determined based on the platform identifier. Based on the point method name and the platform identifier, determine the platform message definition class and platform message processor of the platform to be accessed; Based on the platform message definition class and the platform message processor, the request message of the platform to be accessed is serialized and deserialized to generate a response message.

[0072] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0073] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

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

Claims

1. A message management method characterized by comprising: include: Determine the access request intercepted by the controller's cutoff point, and determine the cutoff method name of the access request; The platform identifier is determined based on the URL placeholder parameter in the access request, and the platform to be accessed is determined based on the platform identifier. Based on the point method name and the platform identifier, determine the platform message definition class and platform message processor of the platform to be accessed; Based on the platform message definition class and the platform message processor, the request message of the platform to be accessed is serialized and deserialized to generate a response message, including: The request message is deserialized using a preset message definition class and a preset message processor to obtain a Java object of the request message; Determine the signature algorithm and signature key of the platform to be accessed, and determine the response message definition class of the platform to be accessed based on the pointcut method name and platform identifier; Configure the signature algorithm and the signature key into the data of the Java object of the request message; The response message is generated by serializing the signed request message Java object using the response message definition class.

2. The message management method according to claim 1, characterized in that, The step of determining the platform message definition class and platform message processor of the platform to be accessed based on the point method name and the platform identifier includes: Determine whether there exists a target message definition class and a target message processor that match the pointcut method name and the platform identifier; If the target message definition class and the target message processor do not exist, then the preset message definition class and the preset message processor are determined. The preset message definition class and the preset message processor are determined as the platform message definition class and the platform message processor.

3. The message management method according to claim 1, characterized in that, The step of deserializing the request message using a preset message definition class and a preset message processor to obtain a Java object of the request message includes: Determine the message type of the request message, wherein the message type includes JSON message type and XML message type; Based on the message type, the preset message definition class, and the preset message processor, the request message is deserialized to obtain a Java object of the request message.

4. The message management method according to claim 3, characterized in that, The step of deserializing the request message according to the message type, the preset message definition class, and the preset message processor to obtain a Java object of the request message includes: If the message type is JSON, the message string of the request message is converted into a Java object of the preset message definition class by the Gson message processor to obtain the Java object of the request message.

5. The message management method according to claim 3, characterized in that, The step of deserializing the request message according to the message type, the preset message definition class, and the preset message processor to obtain a Java object of the request message includes: If the message type is an XML message type, then the XStream message processor converts the message string of the request message into a Java object of the preset message definition class to obtain the Java object of the request message.

6. The message management method according to claim 2, characterized in that, After determining whether there exists a target message definition class and target message processor that match the pointcut method name and the platform identifier, the method further includes: If a target message definition class and a target message processor exist, then the signature algorithm and signature key are configured for the request message through the target message definition class and the target message processor.

7. A message management device, characterized in that, For performing the message management method of claim 1, comprising: The first determining module is used to determine the access request intercepted by the controller's cutoff point and to determine the cutoff point method name of the access request; The second determining module is used to determine the platform identifier based on the URL placeholder parameter in the access request, and to determine the platform to be accessed based on the platform identifier. The third determining module is used to determine the platform message definition class and platform message processor of the platform to be accessed based on the point method name and the platform identifier. The message processing module is used to serialize and deserialize the request message of the platform to be accessed according to the platform message definition class and the platform message processor, and generate a response message.

8. An electronic device, the electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the message management method according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the message management method according to any one of claims 1 to 6.

Images