Custom information message circulation method and device and storage medium

Abstract

The invention discloses a custom information message circulation method and device and a storage medium, and relates to the technical field of data processing, and the method comprises the steps: determining a message type and a display style corresponding to an initial message based on a predefined range of a receiving end and a preset type dictionary when the initial message sent by a service party is received; verifying a newly added service field in the initial message, and determining the newly added service field as expansion information when the newly added service field is verified to be qualified; generating a target message based on a necessary basic field, the message type, the display style, the expansion information and the control information; and routing the target message to a corresponding push channel based on the terminal type of the receiving end, and sending the target message to the receiving end through the push channel. According to the application, the field is dynamically expanded through the uniform interface, and the message format does not need to be redesigned when the service is newly added.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to a self-defined message packet flow conversion method, equipment and storage medium. BACKGROUND

[0002] The current message system design generally adopts a scene customization scheme, and a fixed field structure is fixed in advance for an initial business scene. The interface of the business only supports the transmission of fixed fields, such as message ID and text content. The request parameters and response format of the interface are bound to the fixed fields. When a new field is added, not only the request parameter definition of the interface needs to be modified, but also the parameter configuration of the new field needs to be added. In addition, the field parsing logic needs to be adjusted synchronously to adapt to the identification and processing of the new field and the storage and application. If a large number of new fields are added subsequently, the interface needs to go through the process of suspension, modification and restart repeatedly. Each modification will interrupt the normal operation of the existing business. If there is a deviation in the definition of the field during the modification process, such as the inconsistency of the field name and data type among the interface, the backend and the receiving end, it will directly lead to the failure of field parsing, and further cause message processing exception, which seriously affects the stability of the business.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a self-defined message packet flow conversion method, equipment and storage medium, which aims to solve the technical problem of poor expansibility caused by the scene customization scheme adopted in the current message system design.

[0005] In order to solve the above problems, the present application provides a self-defined message packet flow conversion method applied to a sending end, which comprises the following steps: When an initial message sent by a business party is received, the message type and display style corresponding to the initial message are determined based on the pre-defined range of the receiving end and the preset type dictionary; The new business field in the initial message is verified. When the verification is qualified, the new business field is determined as extension information; A target message is generated based on the mandatory basic field, the message type, the display style, the extension information and control information; The target message is routed to a corresponding push channel based on the terminal type of the receiving end, and the target message is sent to the receiving end through the push channel.

[0006] In an embodiment, before the step of determining the message type and display style corresponding to the initial message based on the predefined range of the receiving end and the preset type dictionary when the initial message sent by the business party is received, the custom message packet circulation method further comprises: replacing the general semantic information in the initial message with the corresponding standard field based on the preset semantic field mapping table; obtaining each field in the initial message, and comparing whether the preset mandatory basic field exists in the field; if the mandatory basic field exists and conforms to the preset verification rule, the message type determination process is performed; if the mandatory basic field does not exist, the message creation process is blocked, error information is generated and sent to the business party.

[0007] In an embodiment, before the step of generating the target message based on the mandatory basic field, the message type, the display style, the extended information and the control information, the custom message packet circulation method further comprises: determining the basic control field in the initial message; determining the notification display duration based on the priority information in the basic field, wherein the level of the priority information is directly proportional to the notification display duration; obtaining the terminal-specific field from the terminal-specific field mapping table based on the terminal type of the receiving end, wherein if the terminal type is an iOS terminal, the terminal-specific field includes a number of notations; and if the terminal type is an Android terminal, the terminal-specific field includes a notification channel; generating the control information according to the folding strategy, the basic control field, the notification display duration and the terminal-specific field.

[0008] In an embodiment, the step of verifying the new business field in the initial message and determining the new business field as the extended information when the verification is qualified comprises: obtaining each key name in the new business field, the key name including a business domain and a field name; when the business domain and the field name are consistent with the extension key of the preset extension field registration center, it is determined that the key name has been registered, and the new business field verification is qualified; if not, it is confirmed that the verification fails, the message creation process is blocked, error information is generated and sent to the business party.

[0009] In an embodiment, before the step of generating the target message based on the mandatory basic field, the message type, the display style, the extended information and control information, the custom message packet circulation method further comprises: When it is detected that there is a stripping field identifier in the extended information, it is determined that the initial message is a transparent message; Generating the target message based on the mandatory basic field, the message type and the extended information.

[0010] In addition, the present application provides a custom message packet circulation method applied to a receiving end, the custom message packet circulation method comprising: When receiving a target message sent by a sending end, parsing the target message based on a preset semantic field mapping table to obtain abstract information, text content, control information and a display style; Based on the priority information in the control information, determining a notification bar display mode of the target message on the receiving end; Mapping the abstract information to a conversation list title; According to the display style, calling a corresponding rendering template, and generating notification content based on the rendering template and the text content; Displaying the notification content and the conversation list title in the notification bar display mode.

[0011] In an embodiment, before the step of displaying the notification content and the conversation list title in the notification bar display mode, the custom message packet circulation method further comprises: Determining whether there is a transparent target module identifier in the target message; If there is, sending the notification content to a corresponding target module based on the transparent target module identifier; If there is not, displaying the notification content and the conversation list title in the notification bar display mode.

[0012] In an embodiment, before the step of displaying the notification content and the conversation list title in the notification bar display mode, the custom message packet circulation method further comprises: Determining extended information in the target message; Based on a preset extended field registration center of the receiving end, determining a business domain and a field name corresponding to the extended information; Based on the business domain and the field name, performing a corresponding business processing action.

[0013] In addition, to achieve the above-mentioned purpose, the application also provides a self-defined message packet flow transferring device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the self-defined message packet flow transferring method.

[0014] In addition, to achieve the above-mentioned purpose, the application also provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the self-defined message packet flow transferring method.

[0015] The application provides a self-defined message packet flow transferring method, which ensures that the initial message sent by a business party can be accurately classified as a corresponding message type through predefining a range and type dictionary at a receiving end, so as to avoid that the receiving end cannot recognize or show inconsistently due to business party definition confusion. Through checking a newly added business field, it is ensured that the field meets the processing specification of the receiving end before being included in the extension information, which not only allows the business party to flexibly add individualized fields, but also prevents irregular fields from interfering with the receiving end analysis process, and at the same time provides standardized extension data for subsequent differentiated processing. Based on the terminal type of the receiving end, the terminal is routed to a corresponding push channel, so as to ensure that the message can adapt to the push mechanism of different terminals, avoid that the message cannot be delivered or is delayed due to terminal differences, and ensure the stability and pertinence of message transmission. The newly added field does not need to modify the interface structure, and is dynamically carried through the extension information module, so that the interface remains uniform, reducing the development and maintenance cost of full-link interface modification. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the principles of the application.

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0018] Figure 1 The first flowchart provided by the self-defined message packet flow transferring method of the application; Figure 2 The second flowchart provided by the self-defined message packet flow transferring method of the application; Figure 3 The overall flowchart of message sending provided by the self-defined message packet flow transferring method of the application; Figure 4The overall flowchart of message receiving provided for the self-defined message packet flow method of the application; Figure 5 The structural schematic diagram of the hardware running environment involved in the self-defined message packet flow method in the embodiment of the application.

[0019] The purpose implementation, functional features and advantages of the application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0020] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the application, and are not used to limit the application.

[0021] In order to better understand the technical solutions of the application, the following will be described in detail in combination with the drawings of the specification and specific embodiments.

[0022] In order to achieve the above-mentioned purpose, the application provides a self-defined message packet flow method, when receiving an initial message sent by a business party, determining the message type and display style corresponding to the initial message based on the pre-defined range of the receiving end and the pre-set type dictionary; verifying the new business field in the initial message, and when the verification is qualified, determining the new business field as extension information; generating a target message based on the mandatory basic field, the message type, the display style, the extension information and control information; routing the target message to a corresponding push channel based on the terminal type of the receiving end, and sending the target message to the receiving end through the push channel.

[0023] The current message system design generally adopts a scene customization scheme, which fixes the field structure in advance for the initial business scene, and the interface of the business only supports the transmission of fixed fields, such as message ID, text content, interface request parameters and response format are all bound with fixed fields; when a new field is added, not only the request parameter definition of the interface needs to be modified, but also the parameter configuration of the new field needs to be adjusted, and the field parsing logic needs to be adjusted synchronously to adapt to the identification and processing of the new field, as well as the storage and application. If the number of newly added fields is large in the future, the interface needs to go through the process of suspension, modification and restart repeatedly, and each modification will interrupt the normal operation of the existing business; if there is a deviation in the field definition during the modification process, such as the inconsistency of field name and data type between the interface, the backend and the receiving end, it will directly lead to field parsing failure, and further cause message processing exception, which seriously affects the business stability.

[0024] In addition, the message structures of different scenarios are incompatible with each other, and multiple encoding and decoding and format conversion are required for cross-system message flow, thereby increasing the time delay; the field redundancy is high, and unnecessary fields are forced to be included, thereby causing the fragmentation of the format and wasting bandwidth in a light scenario. The key control logic, such as whether to be transparent or a storage strategy, is implemented by each business system, and cannot dynamically adapt to the multi-system connection requirements.

[0025] By receiving the predefined range and type dictionary of the receiving end, it is ensured that the initial message sent by the business party can be accurately classified as the corresponding message type, and the receiving end cannot be identified or inconsistent due to the confusion of the business party definition. By checking the new business field, it is ensured that it meets the processing specification of the receiving end before being included in the extension information, which allows the business party to flexibly add individualized fields, prevents irregular fields from interfering with the receiving end analysis process, and provides standardized extension data for subsequent differentiated processing. Based on the terminal type of the receiving end, the corresponding push channel is routed to ensure that the message can adapt to the push mechanism of different terminals, avoid the situation that the message cannot be delivered or the delivery is delayed due to terminal differences, and ensure the stability and pertinence of message transmission. The newly added field does not need to modify the interface structure, and is dynamically carried by the extension information module, so that the interface remains uniform, and the development and maintenance cost of the whole link interface modification is greatly reduced.

[0026] It should be noted that the execution subject of the embodiment can be a computing service device with network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, or an electronic device or device capable of realizing the above functions. The following will take the self-defined message message flow device as an example to illustrate the embodiment and the following embodiments.

[0027] Based on this, the embodiment of the present application provides a self-defined message message flow method, which refers to Figure 1 , Figure 1 The flowchart of the first embodiment of the self-defined message message flow method of the present application is shown.

[0028] In the embodiment, the self-defined message message flow method is applied to a sending end, and the method comprises steps S10-S40: Step S10, when receiving an initial message sent by a business party, based on the predefined range and the preset type dictionary of the receiving end, determining the message type and display style corresponding to the initial message.

[0029] In this embodiment, the service party transmits the original information to the sending end to trigger the message sending process through interface calling, form submission and the like. Each receiving party sets a pre-defined type range to identify the specific message type of the message, such as a text message, a picture message, an order notification and a meeting reminder, for the receiving party to quickly identify the message category. 0-100 is a system built-in type, and 101+ is a business custom type; a pre-defined range associated type dictionary is provided, such as 1 = text message and 2 = picture message. A preset display style enumeration library includes optional styles and corresponding UI template IDs, for example, selected from enumeration values of normal text, large card, list item and picture-text mixed layout, and the corresponding UI rendering template ID is bound, the large card corresponds to template ID = 2, and the parsing cost of the receiving end is reduced.

[0030] When the sending end receives the request information of the service party, if the service party has specified the message type in the message, it is directly verified whether it is within the preset type dictionary range, if it is out of range, it is determined as an error and blocked; if it is not specified, it can be automatically inferred according to the message content, such as containing a product ID extension field, which is inferred as a product notification, corresponding to msgType: 3. The service party can explicitly specify the display style, if it is not specified, the default style is automatically matched according to the message type, such as the default large card for product notification. The template ID corresponding to the selected style is queried from the display style enumeration library, if the style is not in the enumeration library, it is determined as an error and blocked, prompting the service party to use the preset style.

[0031] Step S20, verifying the new business field in the initial message, and when the verification is qualified, determining the new business field as the extension information.

[0032] In this embodiment, the extension information is used to store custom information in specific scenarios, such as product ID, price, etc. of e-commerce messages, task deadline, responsible person, etc. of office messages; the extension information adopts a key-value pair form and supports flexible expansion. The new business field needs to be implemented through the key-value pair of the extension information, and the key name needs to follow the business domain_field name format, such as e-commerce_product ID and office_task ID. An extension field registration center is established, and the service party needs to register the extension key containing the field type and description in advance, and the sending end interface layer verifies whether the key in the new business field has been registered in real time, and refuses to send if it is not registered to avoid illegal expansion.

[0033] In a possible implementation, step S20 can include steps S21-S23: Step S21, acquiring each key name in the new business field, the key name including a business domain and a field name.

[0034] Step S22, when the business domain and the field name are consistent with the preset extension field registration center extension key, it is determined that the key name is registered, and the new business field check is qualified.

[0035] Step S23, if not consistent, it is confirmed that the check fails, the message creation process is blocked, error information is generated and sent to the business party.

[0036] In the embodiment, all key names of the new business field in the initial message are traversed to check whether they conform to the business domain_field name format. If there is a format error, the process is blocked and a prompt is returned, such as: the extension field 'product ID' format error, which needs to conform to 'business domain_field name'. If the format is correct, it is further checked whether the extension field is registered. The check interface of the extension field registration center is called, the business party identifier and the extracted field name list are packaged into a request according to the format specified by the registration center, and the request is sent to the check interface of the registration center through the network.

[0037] After the registration center receives the request, first, it verifies whether the business party has the permission to call the interface; second, it checks whether the field name is in the registered field library one by one. If all the fields are registered, it returns that the check is passed; if there is an unregistered field, it returns that the check fails, and the unregistered field, such as: e-commerce_discount is not registered, please complete the registration first.

[0038] If the check is passed, the message continues to flow to the next stage, and the extension field remains unchanged; if the check fails, the message sending process is blocked, and specific error information is returned to the business party, such as: e-commerce_discount is not registered, which requires it to complete the registration of the field in the registration center first and then resubmit.

[0039] In a feasible embodiment, version control of the extension field is supported, such as: e-commerce_price_v2; For the extension field with version, the version number is extracted and marked separately. If the business party simultaneously transmits multiple version fields, all versions are retained, but the highest version is marked for the receiving end to prioritize parsing; the version compatibility rule is recorded, such as: v2 is compatible with v1, and the old terminal can ignore the v2 field, and the message is transmitted to the receiving end.

[0040] Step S30, generating a target message based on the mandatory basic field, the message type, the display style, the extension information and the control information.

[0041] In this embodiment, the message type, display style, attachment information and text content are checked. For the message type and display style, it is checked whether they are within the preset enumeration range. The message type field and display style field are extracted, and the enumeration range is compared one by one. If the code of the message type field is not within the key value range of the message type enumeration, it is determined that the message type is invalid, and an error message type is returned. The range is not within the agreement; if the name of the display style is not in the key name of the display style enumeration, or the code of the display style is not within the key value range of the message type enumeration, it is determined that the display style is invalid, and an error display style is returned. The range is not within the agreement.

[0042] For the check of the attachment information metadata, for the attachments in the message, such as pictures, files, etc., a list of mandatory metadata is preset in advance, for example: the URL format must start with http: / / or https: / / , conform to the general URL format, contain domain name, path, etc.; the file size must contain the fileSize field, and the value is a positive integer; the picture attachment must contain the width (width) and height (height) fields. The attachment metadata is extracted from the attachment information field, and the mandatory metadata is checked one by one. If the url format does not conform to the rule, it is determined that the URL format is invalid; if the fileSize field is missing or the value is not a positive integer, it is determined that the file size information is incomplete; if it is a picture attachment but width or height is missing, it is determined that the picture size information is missing.

[0043] For the check of the text content, if the text content is JSON, it needs to conform to the Json Scheme (JSON structure specification) predefined by the business party. Different JSON structure specifications corresponding to different message types are predefined, and the JSON structure specification is stored in the content format library, and is associated with the corresponding message type, such as msgType: 2 binding the JSON structure specification of the picture message. Exemplarily, the JSON structure specification of the text content of the picture message must contain url (string, URL format), width and height, and is not allowed to contain additional unrelated fields; the JSON structure specification of the text content of the product message must contain productName (string), price (number), and can optionally contain discount (number). If the first and last characters of the text content field are preset symbols, such as containing {} or [], it is determined to be a JSON format, the corresponding JSON structure specification is obtained from the content format library, and whether all mandatory fields are included and the field types are matched are compared. When all checks are passed, the next stage of message delivery is entered; if any item fails, the process is blocked and error information is collected, and an error prompt is returned to the business party.

[0044] In this embodiment, a Protocol Buffer (PB) file matching the message structure is defined in advance, which is used to convert structured data (such as objects and messages) into a compact binary format for efficient transmission and storage. The PB serialization tool is called to convert the key-value pairs in the JSON format message that has passed the format check into binary data according to the schema rule, and the field name is compressed into a digital identifier to reduce the transmission bandwidth consumption.

[0045] Optionally, the large file URL in the attachment information is transmitted in the form of a base URL and a segment index. When a single file is larger than a preset threshold, such as larger than 100 MB, it is considered that the attachment information contains a large file. The sender extracts the URL from the attachment metadata, divides the file into multiple segments according to a preset segment size, and only transmits the base URL and the total number of segments in the message. The receiver requests the corresponding segment according to the index as needed and records the downloaded segment index. If the transmission is interrupted, the remaining segments can be requested from the breakpoint without the need to download the complete file again.

[0046] In a feasible implementation, before step S30, the method can further include: when it is detected that there is a stripping field identifier in the extension information, determining that the initial message is a transparent transmission message; and generating the target message based on the mandatory base field, the message type, and the extension information.

[0047] In this embodiment, the message packet can contain an isTransparentTransmission field, which is used to identify whether the message is directly delivered to the application non-chat module for processing, such as system instructions, data synchronization status, etc. The isTransparentTransmission field is not dependent on a chat session and generally does not need to be displayed on the UI.

[0048] In this embodiment, after the format check, the isTransparentTransmission field is extracted from the initial message. If isTransparentTransmission: true, the transparent transmission standardization process is triggered, and a stripping field list is marked, including UI-related fields such as display style, summary information, and notification control information, which are stripped in the subsequent transmission stage. If isTransparentTransmission: false, the process is skipped.

[0049] If isTransparentTransmission: false, the message is considered a non-transparent message, and the redundant key-value pairs in the extension information that are not registered are cleared to avoid storing invalid data. If isTransparentTransmission: true, the message is considered a transparent message, and the list of fields to be stripped is loaded. The list of fields to be stripped is preset with all UI-related redundant fields, such as display style and notification control information. Next, it is verified whether the transparent message carries a transparent target module identifier, such as "system_sync" and "data_backup". The transparent target module identifier is stored in the extension information field, guiding the receiving end to forward to a specific business module. If it is not included or the field value is empty, the process is blocked and an error prompt is returned.

[0050] In step S40, the target message is routed to a corresponding push channel based on the terminal type of the receiving end, and the target message is sent to the receiving end through the push channel.

[0051] In this embodiment, after converting JSON to Protocol Buffer binary format, the target message is routed to a corresponding push channel based on the terminal type of the receiving end. The terminal attributes of the recipient are queried from the user device information library to determine the terminal type, which can be iOS, Android, or Harmony, etc. The sending end is pre-set with a mapping table of terminal types and push channels, such as: iOS corresponds to the APNS push channel, Android corresponds to the FCM push channel, and Harmony corresponds to the Huawei push channel. According to the terminal type, the corresponding push channel is matched, and the PB format message is encapsulated according to the channel requirements, such as: APNS needs to add device token deviceToken, and FCM needs to add registration token registrationId. The API interface of the corresponding channel is called, and the encapsulated message is sent to the receiving end.

[0052] In this embodiment, the message packet can contain a landing field, which is used to identify whether the message needs to be stored in the terminal for a long time. It is generally used for messages with high security requirements, such as the “burn after reading” scenario, or part of the session transmission scenario is not displayed in the chat. If the landing is true, the sending end writes the message ID, message status and other information into the local message log library while calling the push channel; the log synchronously records the return of the push channel, which is used for subsequent tracking of whether the message reaches the terminal; the business party can query the historical message, trigger the retransmission or trace operation through the log. If the landing is false, the message is not written into the persistent log library, but only temporarily stored in the memory cache, which contains the complete PB message and the push state, and can be used for retry when the push fails, such as temporary caching for 24 hours, network fluctuation leading to the first push failure, automatic retry based on the preset time interval, until success or cache expiration. After the message delivery is completed, the result returned by the push channel is updated to the message status in real time, and the message status includes: sent, failed to send, received confirmation, which can be used to query the real-time state. Through serialization optimization to reduce transmission cost, combined with the delivery strategy and differentiated storage scheme adapted by the terminal, efficient and reliable message delivery is realized.

[0053] In this embodiment, by receiving the pre-defined range and type dictionary, it is ensured that the initial message sent by the business party can be accurately classified as the corresponding message type, avoiding the situation that the receiving end cannot recognize or exhibit inconsistently due to the confusion of the business party definition. Through the verification of the newly added business field, it is ensured that it meets the processing specification of the receiving end before being included in the extension information, which allows the business party to flexibly add personalized fields, prevents irregular fields from interfering with the receiving end analysis process, and provides standardized extension data for subsequent differentiated processing. Based on the terminal type of the receiving end, the corresponding push channel is routed to ensure that the message can adapt to the push mechanism of different terminals, avoid the situation that the message cannot be delivered or the delivery is delayed due to terminal differences, and ensure the stability and pertinence of message transmission. The newly added field does not need to modify the interface structure, and is dynamically carried through the extension information module. The interface remains uniform, which greatly reduces the development and maintenance cost of the whole link interface modification.

[0054] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and will not be described in detail. On this basis, before step S10, steps S01-S04 can also be included: Step S01, based on the preset semantic field mapping table, the general semantic information in the initial message is replaced by the corresponding standard field.

[0055] In this embodiment, the content generated by the business party according to its own needs is taken as the initial message, and the initial message contains the basic information such as the sender ID, the receiver ID, the text of the body, and the business party's self-defined fields such as the product introduction and the order status. The business party transmits the original information to the sending end to trigger the message sending process through interface calling, form submission and other ways. The sending end is built-in with a semantic field mapping table, which clearly defines the unique fields corresponding to all general semantics, such as: the message summary is only allowed to use the "msgSummary" field, and the business party is prohibited from defining synonymous fields such as "msgAbstract" and "contentBrief".

[0056] When the sending end receives the request information of the business party, it extracts all field names from the original message to form a list of fields to be checked. For each field name in the list of fields to be checked, the standard field name in the semantic field mapping table is traversed. If the original field name in the initial message completely matches the standard field name, it is marked as a compliant field, and the field and its value are retained. If the original field name does not match the standard field, the semantic field mapping table is traversed to check all synonymous blacklists. If a field in the blacklist is matched, it is determined to be a synonymous redundancy error, and the error information is recorded, for example: the field "msgAbstract" is a redundant field of the message summary, which needs to be replaced by the standard field "msgSummary". If the original field name is neither a standard field nor in any blacklist, it is determined to be an undefined error, and the error information is recorded, for example: the field "customField" is not defined in the specification table, and is not allowed to be used.

[0057] If all fields are compliant, the compliant fields in the original fields are retained. If there are redundant fields or undefined fields, all subsequent processing steps are terminated, and a structured error response is generated, which contains the specific problems of all error fields; the error response is returned to the business party through the interface. By automatically checking the field naming, if a synonymous redundant field is detected, an error is reported and the standard field is prompted to be replaced, which can solve the problem of format fragmentation caused by using different fields to represent the same semantics, and ensure the consistency of the understanding of the fields in all subsequent processing links.

[0058] Step S02, obtaining each field in the initial message, and comparing whether there is a preset mandatory basic field in the field.

[0059] Step S03, if the mandatory basic field exists and the mandatory basic field meets the preset verification rule, the message type determining process is performed.

[0060] Step S04, if the mandatory basic field does not exist, the message creation process is blocked, and error information is generated and sent to the business party.

[0061] In this embodiment, the basic fields are checked, including message ID, sender, receiver, message status, message time, and general information, as well as the content of the text. The pre-set mandatory field rule list is loaded from the local configuration, including mandatory field name and field attribute. According to the mandatory field rule list, each field is traversed to check whether the mandatory field is complete. The fields in the mandatory field rule list are checked one by one to see if they exist in the field set of the current message. If the field name does not appear, it is determined that the field is missing; if the field name exists but the value is empty, it is also determined that the field is missing. All fields that do not pass the detection are formed into an error list, triggering the process termination mechanism to ensure that incomplete messages cannot continue to flow.

[0062] In the above basic information verification stage, when a mandatory field that cannot be automatically supplemented is detected to be missing, an error state object is generated, including error type, specific missing field, and error description information; at the same time, the stage state of the current process is marked as failed. Based on the process scheduler, the processing functions of each stage are called in sequence. The scheduler has a stage execution list inside, which records the stages and order that need to be executed currently. When the basic information verification stage returns a failure state, the scheduler removes all subsequent stages from the stage execution list, so that they will not be scheduled again; and triggers the error handling process to generate error feedback and record logs; finally, the process of the entire message processing is terminated to avoid wasting resources.

[0063] Optionally, for the message ID, if the message ID exists, it is further verified by regular expression matching whether the format conforms to the UUID v4 standard; if it does not exist, a UUID generation algorithm can be called, such as Java's UUID.randomUUID(), to automatically generate a message ID that conforms to the format.

[0064] For the sender ID, if it already exists, it is checked whether it is a non-empty string, excluding invalid content such as empty values and spaces; if it does not exist, an error is recorded for the missing mandatory field senderId (unique identifier of the sender). For the receiver ID, if it already exists, it is checked whether it is a non-empty string or a non-empty array; if it does not exist, an error is recorded for the missing mandatory field receiverId (unique identifier of the receiver).

[0065] For the message time, if it already exists, it is checked whether it is a pre-set array bit number, for example, a millisecond-level timestamp corresponds to 13 digits, September 18, 2023 corresponds to 1695000000000; if it does not exist, a current time interface is called to generate a millisecond-level timestamp.

[0066] For the content of the text, if it already exists, it is checked whether it is non-empty, for example: the length of the string is greater than 0, or the JSON structure is non-empty; if it does not exist, an error is recorded for the missing mandatory field content (message content).

[0067] In the third embodiment of the present application, the same or similar contents as the above-mentioned first embodiment can be referred to the above description, and the subsequent description will not be repeated. On this basis, before step S40, steps A10-A40 can also be included: Step A10, determining the basic control field in the initial message.

[0068] In this embodiment, the initial message contains the basic control field: whether to display the notification bar, notification priority, whether to support in-application notification, etc., which is explicitly set by the business party. The basic control field can also supplement other optional fields: folding strategy, in-application notification display time, and terminal-specific field; among them, the folding strategy is defaulted to be grouped by application, and the time folding or message type folding can be selected; in the in-application notification display time, the priority greater than the preset level is an important message, and the notification display time is the first time length; the priority less than or equal to the preset level is a normal message, and the notification display time is the second time length, the first time length is greater than the second time length, for example: priority>3 is an important message, and the default notification display time is 10 seconds, and the notification display time of the normal message is 5 seconds by default. The message downlink service automatically fills in the adaptive field of the corresponding terminal according to the receiver and the terminal type, to ensure consistent cross-terminal display. The terminal-specific field can be badgeNumber (badge number) of iOS and channelId (notification channel) of Android.

[0069] Step A20, determining the notification display time based on the priority information in the basic field, wherein the level of the priority information is directly proportional to the notification display time.

[0070] Step A30, obtaining the terminal-specific field from the terminal-specific field mapping table based on the terminal type of the receiving end, wherein if the terminal type is an iOS terminal, the terminal-specific field includes a badge number; if the terminal type is an Android terminal, the terminal-specific field includes a notification channel.

[0071] In this embodiment, the basic control field explicitly set by the business party is extracted, including: whether to display the notification, notification priority, whether to support in-application notification, etc. The notification display time is determined according to the priority information.

[0072] The user equipment information library interface is called to query the terminal attributes of the recipient, including terminal type, terminal version, device identifier, etc. The corresponding terminal adaptation rule is matched according to the terminal type, and special fields are supplemented. Exemplarily, the iOS terminal fills in badgeNumber (badge number) and supplements sound (notification sound effect). The Android terminal fills in channelId and supplements vibrationPattern (vibration pattern). The Harmony terminal fills in notificationSlotType (notification slot type).

[0073] In step A40, the control information is generated according to the folding strategy, the basic control field, the notification display duration, and the terminal specific field.

[0074] In this embodiment, after the control information is completed and the terminal is adapted, message checking and redundancy cleaning are performed. Whether the message type and display style are within the agreed enumeration range, whether the attachment information metadata is complete, and whether the text content format conforms to the business party's pre-defined Json Scheme are checked. For transparent messages, the UI-related fields are deleted according to the field list, and only the necessary fields such as message ID, sender, recipient, text content, and extension information containing the transparent target are retained; for non-transparent messages, the unregistered redundant key-value pairs in the extension information are removed. The folding strategy, the basic control field, the notification display duration, and the terminal specific field are serialized and delivered.

[0075] For transparent messages, the message text is directly forwarded to the specified non-chat module through the target module identifier and the UI process is skipped. There is no need to adjust the core processing logic for the newly added module. Only the target module identifier needs to be configured to realize the transmission of new business instructions. For non-transparent messages, based on the locally cached and regularly synchronized extension field registration center metadata, the extension information is dynamically parsed according to the message type. When a new business type is added, only the corresponding field rules and associated operations need to be supplemented in the registration center, without the need to modify the terminal parsing framework. At the same time, unregistered extension keys are automatically ignored, avoiding exceptions in old terminals due to the addition of new fields. This not only supports the rapid access of new businesses, but also ensures the compatibility of old systems, breaking through the limitation of extensibility from the aspects of module adaptation and field parsing.

[0076] Through cross-terminal adaptation, the basic control capability of the business party on the notification is retained, and through automatic supplementation and terminal adaptation, the notification display effect on different devices is ensured to meet the expectations, while reducing the adaptation cost of the business party to the terminal differences. For example, the iOS terminal displays a notification with a strong reminder sound effect, with a badge number + 1; the Android terminal vibrates and displays through the marketing channel, and both the in-app notifications of the two terminals are displayed for 10 seconds, realizing consistent importance expression across terminals.

[0077] The embodiment of the application provides a custom message packet flow conversion method Figure 2 , Figure 2 The flowchart of the fourth embodiment of the custom message packet flow conversion method.

[0078] In the embodiment, the custom message packet flow conversion method is applied to a receiving end, and the method comprises the following steps B10-B50: Step B10, when a target message sent by a sending end is received, the target message is parsed based on a preset semantic field mapping table to obtain abstract information, text content, control information and display style.

[0079] In the embodiment, after the receiving end receives the binary target message, the target message is deserialized into a JSON format, and the uniqueness of a message ID and the legality of a sender are checked. For the message ID, whether the message ID exists is checked by querying a local cache or a database primary key, and if the message ID is repeated, the message is directly intercepted to avoid repeated processing. A sender identifier is extracted, compared with a local blacklist library and checked for sending permission, and if the sender is illegal, the message is discarded and an exception log is recorded, so that only legal and unique messages enter a subsequent process.

[0080] A semantic field mapping table consistent with the sending end is loaded, fields in the JSON data are directionally parsed and converted, and the abstract information, the text content, the control information and the display style and the like are obtained.

[0081] Step B20, based on priority information in the control information, a notification bar display mode of the target message on the receiving end is determined.

[0082] Step B30, the abstract information is mapped into a session list title.

[0083] Step B40, a corresponding rendering template is called according to the display style, and notification content is generated based on the rendering template and the text content.

[0084] Step B50, the notification content and the session list title are displayed in the notification bar display mode.

[0085] In the embodiment, an abstract information field in the JSON is obtained, and a value corresponding to the abstract information field is written into a subtitle data area of a terminal session list component. Priority information in notification control information is obtained, priority conversion rules are queried according to a terminal type, high priority is converted into a terminal corresponding trigger behavior, for example, a high priority of Android corresponds to a system pop-up window, and a priority of iOS corresponds to a banner and a sound. The conversion result is written into a control variable of a notification manager.

[0086] For the parsed display style field, first, the field value is extracted to determine the rendering type and the required data. According to the display style query mapping table, the corresponding rendering component is determined, such as the large card matching the ImageCardRenderer component. Second, the original data is formatted. The ordinary text directly converts the content string into a text format recognizable by the component; the large card parses the image URL from the content and takes the summary content as the title text, combining it into structured data of {"title": "New product recommendation", "imageUrl": "https: / / example.com / img.jpg"}. The formatted rendering data and target component identifier are obtained. The target component is called to execute the rendering logic. For example, the text component calls the system TextView control, sets the text content, font size, and color; the large card component first calls the network module to download the image, and then loads it through the ImageView control, while displaying the title text at the top of the card. The displayable UI elements in the terminal interface, such as text blocks and image cards, are obtained, and the visual presentation of the message is completed.

[0087] In a feasible implementation, before step B50, it can also include: determining whether there is a transparent target module identifier in the target message; if there is, sending the notification content to the corresponding target module based on the transparent target module identifier; if there is not, displaying the notification content and the conversation list title according to the notification bar display mode.

[0088] In this embodiment, the message extension information (extensions field), notification content (content), conversation list title (msgSummary), and notification bar display parameters (notificationControl) parsed in the pre-stage are queried from the message extension information to determine whether there is a transparent target module identifier. If there is, the text content is directly forwarded to the corresponding non-chat module, such as the system instruction module, for processing. The UI rendering process is skipped, and the processed state is returned to the sending end after processing. If there is no transparent target module identifier, the list rendering component is called, the msgSummary is set as the main title of the list item, the content summary is set as the subtitle, the fixed height and font style are set, the list item view data is generated, and the conversation list adapter is submitted to trigger the list local refresh. If it is a large card style, the card component is called in advance to load the image and cache, the detail page complete view is generated, and it is directly reused when the user clicks on the list item to reduce the loading delay. The message item view visible in the conversation list and the pre-cached detail page view are obtained. Based on the notification bar display mode, the notification displayed according to the rules and the responsive interaction behavior are generated in the notification bar.

[0089] Specifically, the terminal is locally provided with a module routing table recording the correspondence between the identification and the module, the module routing table containing module ID, running process, communication port, required permission and the like. If there is a transparent target module identification, the transparent target module identification is taken as a keyword to quickly match and query in the module routing table to find the corresponding target module information. The module routing table is converted into a hash table data structure, the transparent target module identification is taken as a key of the hash table, and the target module information is taken as a value. The transparent identification is calculated through a preset hash function to generate a fixed-length hash value as a storage location index of the key in the hash table, and the hash function can be MD5, SHA-1 or the like. If different transparent target module identifications calculate the same hash value, the conflicting key-value pairs are stored in the same index position in the form of a linked list through the chain address method to ensure that each transparent target module identification can be correctly mapped to obtain a directly accessible hash table, for example: hash index value: 156, key: "system_sync", value: {"module ID": "m1", "process name": "SyncService",...}. The same hash function is called to calculate the transparent target module identification to obtain the corresponding hash index value, and the storage location in the hash table is located according to the hash index value. If there is a hash conflict (i.e. there are multiple key-value pairs in the linked list) at the location, the keys in the linked list are compared with the transparent identification one by one to find a completely matched key. The hash index position corresponding to the transparent target module identification and the key-value pair stored at the position are obtained.

[0090] The value part, i.e. the target module information, is extracted from the located key-value pair, and the complete target module information is returned; if no match is found, an empty result without a corresponding module is returned.

[0091] Optionally, it can also be verified whether the terminal meets the permission requirements of the target module, and if the permission is insufficient, the permission refusal log is directly recorded and the transparent transmission is terminated; if the permission is passed, the communication parameters of the module such as the process name, the port and the like are extracted.

[0092] According to a preset transparent transmission instruction protocol, the original content is packaged into a standardized format, including: message type, original message ID, sender ID, timestamp, core instruction content. A signature is added to the packaged message, such as the hash value of the terminal device identification, to prevent tampering during transmission and ensure the legality of the message. The standardized instruction message with the signature is obtained, the format is uniform and can be verified by the target module. The inter-process communication interface is called to connect the corresponding process through the target port, and if the target module is not started, its background start is automatically triggered; if the connection is timed out, the log is recorded and retried once. After successful connection, the instruction message is sent through an encrypted channel to ensure transmission safety. The processing return of the target module is received, and the local message state table is updated after analysis to mark that the message transparent transmission is successful, and the message does not enter the UI rendering process throughout the whole process, but is only processed in the business module.

[0093] In this embodiment, by defining the mapping table of control instructions and terminal behaviors in advance and synchronizing with the sending end, the abstract control instructions of the sending end are converted into specific rules executable by the terminal, such as the components, layouts, elements and specific behaviors corresponding to different display styles and priorities, and the terminal automatically adapts to its hardware capabilities when loading the mapping table to ensure that the rules are executable, thereby solving the technical problem that different terminals have different understandings of display styles and notification behaviors, such as different performances of high priority on different devices, which causes the control intention of the sending end to be unable to be consistently landed.

[0094] In the fifth embodiment of the present application, the same or similar contents as or to the above-mentioned fourth embodiment can be referred to the above introduction, and will not be described in detail hereinafter. On this basis, before step B50, the above-mentioned self-defined message packet circulation method further includes: determining the extension information in the target message; determining the business domain and the field name corresponding to the extension information based on the extension field registration center preset by the receiving end; and performing a corresponding business processing action based on the business domain and the field name.

[0095] In this embodiment, for the extension information, the receiving end locally caches the metadata of the extension field registration center, and dynamically parses the extension information according to the message type. The metadata of the extension field registration center is classified according to the message type, and each type records all legal field identifiers and the corresponding business processing actions of each identifier, such as which module to call and what action to perform. The message type value is extracted from the message as a query keyword, and the corresponding extension field rule is located through the message type index. If the message type is not registered in the metadata, it is marked as no rule matching, and its extension information is not parsed. If the message type is registered in the metadata, each field is compared with the field identifier of the extension field registration center to determine the matching field, and the specified business processing action in the rule is called for processing, for example, for e-commerce messages, e-commerce_goods ID and e-commerce_price are extracted to supplement information from the local goods library; for office messages, office_deadline is extracted to trigger local calendar reminders. The unregistered extension key is automatically ignored.

[0096] In the metadata of the registration center, each field identifier is bound with an explicit operation description, including the associated business module, the specific action to be executed and the output result of the operation. According to the business module specified in the operation definition, the corresponding interface of the module is called, and the field value parsed is transmitted as a parameter to trigger the module to execute the preset action. The business module returns the processing result after executing the action, and the result is processed according to the requirement of the output result in the operation definition, and finally the processed information is applied to the subsequent link, such as supplementing the output result to the message content for UI display.

[0097] Exemplarily, after the e-commerce_goods_ID and e-commerce_price fields are extracted from the message extension information, a comparison is made with the registration center metadata. When the e-commerce_goods_ID is matched, an operation definition is read from the metadata to obtain a local commodity library query module associated with the e-commerce_goods_ID. The action is to query the name and picture URL of the commodity by inputting the commodity ID, and the output result needs to be supplemented to the commodity information area of the message content. When the e-commerce_price is matched, the operation definition is read as an associated price formatting module, the action is to convert the numerical price into a string with a currency symbol, and the output result needs to replace the original price field in the message.

[0098] According to the whether landed field obtained by analysis, the storage strategy of the message is determined. If whether landed=true, all fields are stored in the terminal database, such as SQLite, and indexed according to the message time+recipient to support historical message query; if whether landed=false, only saved in memory or temporary storage, deleted immediately after the user views, and the message state=destroyed feedback is triggered. The message state is returned to the sending end in real time, which can be received, read, destroyed, etc. Through persistent or temporary differential storage, the data retention demand and resource occupation are balanced; through real-time state feedback, the sending end can accurately know the processing state of the message in the receiving end, and realize the whole link traceability.

[0099] In the sixth embodiment of the present application, an overall look flow of message receiving and sending is provided.

[0100] In the present embodiment, the general message packet structure includes the following fields: field name, message type, display style, text content, attachment information, extension information, abstract information, notification control information, whether to pass through information, and whether to land information. Among them, the field name, message type, display style and text content are mandatory fields.

[0101] The basic information is of JSON type, and includes general information such as message ID, sender, recipient, message state, and message time.

[0102] The message type is an integer, and the value range is defined by each interface party. It identifies the specific message type of the message, such as text message, picture message, order notification, meeting reminder, etc., which is used for the receiving party to quickly identify the message category.

[0103] The display style is enumerated, which defines the display form of the message in the interface, such as normal text, large card, list item, and picture-text mixed layout, etc. The receiving party can call the corresponding UI rendering logic according to the field.

[0104] The text content is a string or JSON, which stores the core information of the message, such as the content of a text message, the URL of a picture message, the title and text of a notification message. Generally, a custom Json Scheme is used, and business parties can further extend it according to their own needs.

[0105] The attachment information is in JSON format, used to store the attachments associated with the message, such as documents, compressed packages, and audio files, containing metadata such as attachment name, size, format, and download URL.

[0106] The extension information is in JSON format, used to store custom information for specific scenarios, such as the product ID and price for e-commerce messages, and the task deadline and responsible person for office messages. The extension information uses a key-value pair format and supports flexible expansion.

[0107] The abstract information is in JSON format, which is a brief summary of the message content, such as the first 20 characters of a long text or the core summary of a complex message. It is used in scenarios such as chat list and notification bar default subtitle for thumbnail display.

[0108] The notification control information is in JSON format, which controls the behavior of the message in the system notification bar, including whether to display notifications, notification priority, prompt sound, vibration switch, jump link, and whether to support in-app notifications.

[0109] The whether to pass-through is a boolean type, with a default value of false. It is used to identify whether the message is directly passed to the application non-chat module for processing, such as system instructions and data synchronization status, which do not depend on chat sessions and generally do not require UI display.

[0110] The whether to land is a boolean type, with a default value of true. It is used to identify whether the message needs to be long-term persistent storage on the terminal. It is generally used for messages with high security requirements, such as "read and burn" scenarios, or some in-session pass-through scenarios that do not display in chat.

[0111] Please refer to Figure 3 , Figure 3An overall flowchart of message sending is provided, the original message submitted by a sending and receiving business party is sent, first, field forced mapping is performed, all fields are checked and standardized according to a built-in semantic field mapping table, synonymous redundant fields are replaced, and uniformity of field naming is ensured; then, basic information checking is performed, optional fields such as message ID, sender ID, receiver ID and the like are checked and supplemented, missing fields that cannot be automatically supplemented are blocked in time and an error is returned; then, a business information filling and expansion management stage is entered, core business fields such as message type and display style are filled according to preset rules, and the format and registration state of the expansion field are checked, to ensure that the expansion field conforms to the specification and has been registered; then, notification control information enhancement is performed, optional fields such as folding strategy and display duration are supplemented based on the basic control field set by the business party, and terminal-specific fields are automatically filled according to the terminal type of the receiver, to ensure consistent cross-terminal display; if it is a transparent message, UI-related redundant fields will also be marked and stripped, and the transparent target module identifier is forced to be carried; in the final stage, serialization optimization is performed, the message is converted into ProtocolBuffer binary format to compress the volume, finally, the message is routed to the corresponding push channel according to the terminal type of the receiver, and the storage strategy of the message is determined according to whether the landing identifier, to complete the final delivery of the message.

[0112] Please refer to Figure 4 , Figure 4A whole flowchart of message receiving is provided, the receiving end directly parses core fields based on a semantic field mapping table consistent with the sending end, directly maps summary information into a session list subtitle, uniformly converts the priority in notification control information into a priority recognizable by the terminal locally to adapt the display behavior of different systems, rejects to parse non-standard synonymous fields, avoids storing redundancy, ensures the uniformity of message field formats in different sending scenarios, and eliminates the parsing exception caused by format disorder. For transparent message, the text of the transparent message is directly forwarded to the corresponding non-chat module and the UI process is skipped according to whether the transparent identifier and the transparent target module identifier, and the new module can be adapted without adjusting the core logic; with the help of the metadata of the local cache extension field registration center, the extension information is dynamically parsed according to the message type, and the unregistered extension key is automatically ignored, which supports the rapid access of new business and guarantees the compatibility of old terminals, and breaks through the limitation of business extension on the terminal framework. When rendering the UI, the corresponding module and template are called according to the display style to adapt the visual presentation of different message types; according to the notification control information, the corresponding behavior is performed according to the folding strategy, prompt sound, display time length and other parameters, so as to ensure that the control intention of the sending end is consistently landed on the terminal, and the difference between different terminals in display and interaction is avoided. Finally, according to whether the landing identifier is adopted, a differentiated storage strategy is adopted, the message is stored in the database and an index is established to support historical query, the temporary message is stored in the memory or temporary storage and is destroyed after being viewed; at the same time, the sending end is fed back in real time the states of received, read and destroyed, so as to ensure that the sending end can master the message processing progress in real time, and realize the whole link traceability and controllable of the message from sending to processing. Finally, the message format is unified, the business extension is flexible, the terminal control is accurate, and the whole link state is transparent, so as to meet the message processing needs in different business scenarios.

[0113] The application provides a self-defined message packet flow conversion device, comprising at least one processor and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the self-defined message packet flow conversion method in the embodiment I.

[0114] Reference will be made to the accompanying drawings Figure 5 which shows a structural schematic diagram of a self-defined message packet flow conversion device suitable for being used to implement the embodiments of the application. The self-defined message packet flow conversion device in the embodiments of the application can include but is not limited to mobile terminals such as mobile phones, notebook computers, personal digital assistants (PDA), tablet computers (PAD), vehicle-mounted terminals (for example, vehicle-mounted navigation terminals) and the like, and fixed terminals such as digital TVs, desktop computers and the like. Figure 5The custom message routing device shown is merely an example and should not bring any limitation to the function and scope of use of the embodiments of the present application.

[0115] As shown in Figure 5 The custom message routing device can include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. In the random access memory 1004, various programs and data required for operation of the custom message routing device are also stored. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the custom message routing device to communicate wirelessly or by wire with other devices to exchange data. Although the custom message routing device with various systems is shown in the figure, it should be understood that all the systems shown are not required to be implemented or possessed. More or fewer systems can be alternatively implemented or possessed.

[0116] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication device, or installed from the storage device 1003, or installed from the read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are performed.

[0117] The custom message packet flow conversion device provided in the application adopts the custom message packet flow conversion method in the above embodiment, and can solve the technical problem of poor expansibility caused by the scene customization scheme adopted in the design of the current message system. Compared with the prior art, the beneficial effects of the custom message packet flow conversion device provided in the application are the same as those of the custom message packet flow conversion method provided in the above embodiment, and other technical features in the custom message packet flow conversion device are the same as those disclosed in the previous embodiment method, and thus are not described herein.

[0118] It should be understood that parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0119] The above is merely specific implementation of the present application, but the protection scope of the present application is not limited thereto, any person skilled in the art can easily think of changes or replacements within the technical range disclosed in the present application, which should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0120] The present application provides a computer readable storage medium having computer readable program instructions (i.e. computer programs) stored thereon, the computer readable program instructions being used to execute the custom message packet flow conversion method in the above embodiment.

[0121] The computer readable storage medium provided in the application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system or device, or any combination of the above. More specific examples of the computer readable storage medium may include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM or flash memory), an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiment, the computer readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, a radio frequency (RF), and the like, or any suitable combination of the above.

[0122] The computer readable storage medium described above may be contained in the custom message packet transfer device, or may exist separately without being assembled into the custom message packet transfer device. The computer readable storage medium carries one or more programs, which, when executed by the custom message packet transfer device, cause the custom message packet transfer device to: when receiving an initial message sent by a business party, determine a message type and a display style corresponding to the initial message based on a predefined range of a receiving end and a preset type dictionary; verify a new business field in the initial message, and when the verification is qualified, determine the new business field as extension information; generate a target message based on mandatory basic fields, the message type, the display style, the extension information, and control information; route the target message to a corresponding push channel based on a terminal type of the receiving end, and send the target message to the receiving end through the push channel.

[0123] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0124] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0125] The modules involved in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0126] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., computer programs) for executing the above-mentioned custom message packet flow method, and can solve the technical problem of poor expansibility caused by the scene customization scheme adopted in the design of the current message system. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the custom message packet flow method provided by the above-mentioned embodiments, and will not be described here.

[0127] The above merely provides part of embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structure transformation, direct / indirect application in other related technical fields, or the like, which is made based on the technical concept of the present application, and based on the content of the present application specification and drawings, is included in the patent protection scope of the present application.

Claims

1. A method for custom message packet flow conversion, applied to a sending end, characterized in that, The custom message packet flow conversion method comprises: When receiving an initial message sent by a business party, determining a message type and a display style corresponding to the initial message based on a pre-defined range of a receiving end and a preset type dictionary; Verifying a new business field in the initial message, and determining the new business field as extension information when the verification is qualified; Generating a target message based on the optional basic field, the message type, the display style, the extension information, and control information; Routing the target message to a corresponding push channel based on a terminal type of the receiving end, and sending the target message to the receiving end through the push channel.

2. The method of claim 1, wherein, Before the step of determining the message type and the display style corresponding to the initial message based on the pre-defined range of the receiving end and the preset type dictionary when receiving the initial message sent by the business party, the custom message packet flow conversion method further comprises: Replacing general semantic information in the initial message with a corresponding standard field based on a preset semantic field mapping table; Obtaining each field in the initial message, and comparing whether a preset optional basic field exists in the field; If the optional basic field exists and conforms to a preset verification rule, a process of determining the message type is performed; If the optional basic field does not exist, a message creation process is blocked, error information is generated, and the error information is sent to the business party.

3. The method of claim 1, wherein the custom message flow is defined by a user. Before the step of generating the target message based on the optional basic field, the message type, the display style, the extension information, and the control information, the custom message packet flow conversion method further comprises: Determining a basic control field in the initial message; Determining a notification display duration based on priority information in the basic field, wherein the priority information is directly proportional to the notification display duration; Obtaining a terminal-specific field from a terminal-specific field mapping table based on the terminal type of the receiving end, wherein if the terminal type is an iOS terminal, the terminal-specific field includes a number of notations, and if the terminal type is an Android terminal, the terminal-specific field includes a notification channel; Generating the control information according to a folding strategy, the basic control field, the notification display duration, and the terminal-specific field.

4. The method of claim 1, wherein the custom message flow is defined by a user. The step of verifying the new business field in the initial message, and determining the new business field as extension information when the verification is qualified, comprises: Obtaining each key name in the new business field, wherein the key name includes a business domain and a field name; When the business domain and the field name are consistent with an extension key of a preset extension field registration center, it is determined that the key name is registered, and the new business field is verified to be qualified; If the business domain and the field name are not consistent with the extension key of the preset extension field registration center, it is determined that the verification fails, a message creation process is blocked, error information is generated, and the error information is sent to the business party.

5. The method of custom message flow routing of claim 1, wherein, Before the step of generating the target message based on the optional basic field, the message type, the display style, the extension information, and the control information, the custom message packet flow conversion method further comprises: When it is detected that there is a stripping field identifier in the extension information, it is determined that the initial message is a transparent message; The target message is generated based on the mandatory basic field, the message type and the extension information.

6. A method for custom message packet flow conversion, applied to a receiving end, comprising the steps of: The custom message packet flow conversion method comprises: When receiving the target message sent by the sending end, the target message is parsed based on a preset semantic field mapping table to obtain abstract information, text content, control information and display style; Based on the priority information in the control information, the notification bar display mode of the target message on the receiving end is determined; The abstract information is mapped as a session list title; According to the display style, a corresponding rendering template is called, and notification content is generated based on the rendering template and the text content; The notification content and the session list title are displayed in the notification bar display mode.

7. The method of claim 6, wherein, Before the step of displaying the notification content and the session list title in the notification bar display mode, the custom message packet flow conversion method further comprises: Determining whether there is a transparent target module identifier in the target message; If there is, the notification content is sent to the corresponding target module based on the transparent target module identifier; If there is not, the notification content and the session list title are displayed in the notification bar display mode.

8. The method of claim 6, wherein the custom message flow is converted by: The custom message packet flow conversion method further comprises: Determining the extension information in the target message; Based on a preset extension field registration center of the receiving end, the business domain and the field name corresponding to the extension information are determined; Based on the business domain and the field name, a corresponding business processing action is performed.

9. A custom message flow switching device, comprising: The device comprises a memory, a processor and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the custom message packet flow conversion method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the custom message packet flow conversion method according to any one of claims 1 to 8.

Images