CN117119050A - Intermediate service processing method, device and storage medium for interfacing multiple message sources - Google Patents

Intermediate service processing method, device and storage medium for interfacing multiple message sources Download PDF

Info

Publication number
CN117119050A
CN117119050A CN202311185917.9A CN202311185917A CN117119050A CN 117119050 A CN117119050 A CN 117119050A CN 202311185917 A CN202311185917 A CN 202311185917A CN 117119050 A CN117119050 A CN 117119050A
Authority
CN
China
Prior art keywords
message
content
service
sending
channel
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311185917.9A
Other languages
Chinese (zh)
Inventor
屠鲁俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai E Car Technology Co ltd
Original Assignee
Shanghai E Car Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai E Car Technology Co ltd filed Critical Shanghai E Car Technology Co ltd
Priority to CN202311185917.9A priority Critical patent/CN117119050A/en
Publication of CN117119050A publication Critical patent/CN117119050A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The application relates to the technical field of data processing, and discloses an intermediate service processing method, device and storage medium for interfacing a plurality of message sources, wherein the method comprises the following steps: acquiring business content sent by a message sending service; checking service content according to a preset checking strategy, and if the checking is passed, generating message content and sending the message content to a message queue with data connected with various message channels; obtaining a message receipt returned by the message content in the message queue based on the message channel, converting the message receipt into an execution message according to a preset conversion strategy, and sending the execution message to the message queue; monitoring a message queue, if the message queue is put into an execution message, reading the execution message, analyzing the message state of the execution message according to a preset analysis strategy, and sending the message state to the message queue; the message sending service is not required to independently dock different message channels, and after the interfaces in the message channels are changed, the maintenance of the docking step can be completed only by modifying the verification strategy and the analysis strategy.

Description

Intermediate service processing method, device and storage medium for interfacing multiple message sources
Technical Field
The present application relates to the field of data processing, and in particular, to a method, an apparatus, and a storage medium for processing an intermediate service for interfacing with multiple message sources.
Background
With the maturity of communication technology, the variety of message channels is increasing, so that the variety of message channels related to a platform service system is also increasing, and therefore, a subsystem of the platform service system can interface with a plurality of different message channels. Based on the independence among the subsystems, each subsystem has independent message service to be in butt joint with one or more message channels, wherein the condition that a plurality of subsystems are in butt joint with the same message channel occurs in all the subsystems.
The existing subsystem and the existing message channel need to be independently subjected to butt joint debugging, complex and complicated butt joint work is not subjected to integrated intermediate business processing, when one message channel is subjected to interface change, all subsystems which are in communication with the message channel need to be subjected to interface upgrading, the upgrading workload is large, and the labor cost and the time cost are increased.
Disclosure of Invention
In order to perform integrated intermediate service processing on complex and tedious butt joint work between a subsystem of a platform service system and an existing message channel, the application provides an intermediate service processing method, an intermediate service processing device and a storage medium for butt joint of various message sources.
In a first aspect, the present application provides a method for processing an intermediate service for interfacing with multiple message sources, which adopts the following technical scheme:
an intermediate service processing method for interfacing with multiple message sources, comprising the steps of:
acquiring business content sent by a message sending service;
checking the service content according to a preset checking strategy, generating message content if the checking is passed, and sending the message content to a message queue with data connected with various message channels;
acquiring a message receipt returned by the message content in the message queue based on the message channel, converting the message receipt into an execution message according to a preset conversion strategy, and sending the execution message to the message queue;
monitoring the message queue, if the message queue is put into the execution message, reading the execution message, analyzing the message state of the execution message according to a preset analysis strategy, and sending the message state to the message queue.
By adopting the technical scheme, the service content is acquired and checked, the message content is sent to the message queue after the check, the messages of the message queue can be monitored by different message channels, and the execution message is returned to the message queue after the message content is received; analyzing and executing the message and sending the analyzed result to a message queue for inquiring or processing; the maintenance of the docking step can be completed by only modifying the verification strategy and the analysis strategy after the interface in the message channel is changed without independently docking different message channels by the message sending service, and each subsystem of the platform service system is not required to be independently maintained, so that the complex and complicated docking work between the subsystem and the existing message channels can realize integrated intermediate service processing.
Optionally, the verification policy includes the following steps:
extracting a message module in the service content, matching the message module with a preset built-in template, and returning first check information to the message sending service if the matching fails;
and/or extracting a message channel in the service content, matching the message channel with a preset channel template, and returning second check information to the message sending service if the matching fails.
By adopting the technical scheme, the message module can be matched to realize the pairing of the content formats corresponding to the message channels, and the message channel can be matched to realize the pairing of the connecting links corresponding to the message channels.
Optionally, the step of generating the message content if the verification is passed and sending the message content to the message queue further includes the steps of:
inquiring preset message template information from a database according to the service content to generate an inquiry result;
generating the message content according to the service content based on the query result;
inquiring a channel processor according to a message channel extracted from the message content;
generating a message execution state based on a transmission state created by the channel processor in response to a message channel query action, and transmitting the message execution state to the remote dictionary service;
generating a message record to be sent according to the message execution state, and sending the message record to be sent to the database;
and sending the message content to a theme unit of the message queue.
By adopting the technical scheme, the message content with higher matching certainty is obtained after the message template message is queried, the matched message content is sent to the message queue through the channel processor, and the message execution state is sent to the remote dictionary service, so that the sending of the message is managed in the content, the sending state and the recorded dimension, and the intermediate butt joint of various message channels is facilitated.
Optionally, the analysis strategy includes the following steps:
a calling process judging unit analyzes the executing message;
if the content of the execution message comprises incomplete state information, updating the state information to the remote dictionary service and/or the database;
if the content of the execution message comprises completed state information, updating the message state to the remote dictionary service and/or the database;
and if the content of the execution message comprises a callback opening interface instruction, sending the completed state information to the theme unit.
By adopting the technical scheme, the using process judging unit can link the state of the message with the selection of the calling interface, so that the state analysis can be realized when different message channels are docked, and the compatibility and the universality of intermediate docking are improved.
Optionally, the method further comprises the steps of:
after the message content is sent to a message queue, a log tracking message is generated and sent to the message queue;
returning message identity information corresponding to the message content to the message sending service according to the log tracking message; and/or storing the log trace message after the log trace message is monitored in the message pair column.
By adopting the technical scheme, the message sending service can inquire the message content by returning the message identity information, a feedback mechanism of the message sending process is provided, and the stored log tracking message can track and record each message.
In a second aspect, the present application provides an intermediate service processing method for interfacing with multiple message sources, which adopts the following technical scheme:
an intermediate service processing method for interfacing with multiple message sources, comprising the steps of:
monitoring a subject unit of a message queue;
if the topic unit is monitored to be placed with the message content, extracting the message content, and sending the message content to a message channel; receiving a return message returned by the message channel, and analyzing the return message according to a preset analysis strategy;
and if the completed message state is monitored to be put in the theme unit, returning a call interface notification corresponding to the completed message state to a message sending service, wherein the completed message state corresponds to the message channel to successfully send the message content.
By adopting the technical scheme, the message content is sent to the theme unit, the message content in the theme unit is sent to the corresponding message channel according to the recorded message channel, then the returned information returned by the message channel is analyzed, the content of the returned information corresponds to the calling interface, the message sending service is not required to independently dock different message channels, after the interface in the message channel is changed, the maintenance of the docking step can be completed only by modifying the analysis strategy and the conditions of the calling interface, and each subsystem of the platform service system is not required to be independently maintained, so that complex and complicated docking work between the subsystem and the existing message channel can realize integrated intermediate service processing.
Optionally, the parsing strategy includes the following steps:
a calling process judging unit analyzes the return message;
if the process judging unit judges that the call is successful and the content obtained by analyzing the return message comprises the successful sending state information and the tracking information, a callback interface closing instruction is generated;
if the process judging unit judges that the call is successful and the content obtained by analyzing the return message comprises the sending state information and the tracking information, generating a callback opening interface instruction;
if the process judging unit judges that the call fails, judging whether to retransmit the message content to the message channel according to a preset retransmission condition, and if the retransmission is judged, transmitting the message state of failed retry to the subject unit.
By adopting the technical scheme, the using process judging unit can link the state of the message with the selection of the calling interface, so that the state can be analyzed when different message channels are docked, and the compatibility and the universality of intermediate docking are improved.
Optionally, the method further comprises the steps of:
if the message state of failed retry is monitored, extracting the message content, and sending the message content to a message channel; and receiving a return message returned by the message channel, and analyzing the return message according to the analysis strategy.
By adopting the technical scheme, if the message channel fails to process the message content, the message retransmission is judged, if the message channel fails to retry, the message content is directly retransmitted, retransmission of the message transmission service is not needed, and new message content is not needed to be regenerated to the theme unit.
In a third aspect, the present application provides an intermediate service processing qualification for interfacing with multiple message sources, and adopts the following technical scheme:
the application provides an intermediate service processing device for interfacing multiple message sources, which comprises the following modules:
a message sending service for sending the service content to a message receiving service;
a message receiving service for acquiring the service content sent by the message sending service; checking the service content according to a preset checking strategy, generating message content if the checking is passed, and sending the message content to a message queue; obtaining a message receipt returned by the message content in the message queue based on a message channel, converting the message receipt into an execution message according to a preset conversion strategy, and sending the execution message to the message queue; monitoring the message queue, if the message queue is put into the execution message, reading the execution message, analyzing the message state of the execution message according to a preset analysis strategy, and sending the message state to the message queue;
the message pushing service is used for monitoring the subject unit of the message queue; if the topic unit is monitored to be placed with the message content, extracting the message content, and sending the message content to a message channel; receiving a return message returned by the message channel, and analyzing the return message according to a preset analysis strategy; and if the completed message state is monitored to be put in the theme unit, returning a call interface notification corresponding to the completed message state to the message sending service, wherein the completed message state corresponds to the message channel to successfully send the message content.
In a fourth aspect, the present application provides a storage medium, which adopts the following technical scheme:
the present application provides a storage medium storing the program of the above-described intermediate service processing method for interfacing with a plurality of message sources.
In summary, the present application includes at least one of the following beneficial technical effects: acquiring service content and checking the service content, sending the message content to a message queue after checking, wherein different message channels can monitor the messages of the message queue, and returning execution messages to the message queue after receiving the message content; analyzing and executing the message and sending the analyzed result to a message queue for inquiring or processing; the maintenance of the docking step can be completed by only modifying the verification strategy and the analysis strategy after the interface in the message channel is changed without independently docking different message channels by the message sending service, and the independent maintenance of each subsystem of the platform service system is not required, so that the complex and complicated docking work between the subsystem and the existing message channels can realize integrated intermediate service processing;
and after the interface in the message channel is changed, the maintenance of the docking step can be completed by only modifying the analysis strategy and the conditions of the calling interface, and each subsystem of the platform service system is not required to be maintained independently, so that complex and complicated docking work between the subsystem and the existing message channel can realize integrated intermediate service processing.
Drawings
FIG. 1 is a schematic diagram of a message channel in an embodiment of the application;
FIG. 2 is a flow chart of a method for performing steps in a message receiving service in an intermediate service processing method for interfacing with multiple message sources according to an embodiment of the present application;
FIG. 3 is a flow chart of a method for processing a message in a message receiving service in an intermediate service processing method for interfacing with multiple message sources according to an embodiment of the present application;
FIG. 4 is a flow chart of a method for message receiving service storage log to track messages and to convert message returns in an intermediate service processing method for interfacing with multiple message sources according to an embodiment of the present application;
FIG. 5 is a flow chart of a method for message receiving service processing execution message in an intermediate service processing method for interfacing with multiple message sources according to an embodiment of the present application;
FIG. 6 is a flowchart illustrating a method for performing steps in a message push service in an intermediate business processing method for interfacing multiple message sources according to an embodiment of the present application;
FIG. 7 is a flow chart of a method for processing a message in a message push service in an intermediate service processing method for interfacing multiple message sources according to an embodiment of the present application;
FIG. 8 is a flow chart of a method for retransmitting message content in an intermediate service processing method for interfacing with multiple message sources according to an embodiment of the present application;
fig. 9 is a block diagram of an intermediate service processing apparatus interfacing with a plurality of message sources according to an embodiment of the present application.
Reference numerals: 1. a message channel; 2. a message sending service; 3. a message receiving service; 4. a remote dictionary service; 5. a database; 6. a message queue; 7. message push services.
Detailed Description
The present application will be described in further detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
As shown in fig. 1, there are various message channels 1 or message providers of the existing message notification, and the message channels 1 or message providers are put into use in the social chat tools, such as, for example, flybooks, nails, APP messages, mails, sms messages, weChat messages, etc. on the business. Wherein the message channel 1 is the message source. In the process of developing service systems, in order to realize communication with external clients, it is necessary to realize information interfacing and tone between each service system and different message channels 1. At present, the conventional development thinking is to enable each subsystem of the service system to realize docking and joint debugging with all the message channels 1. If the interface and the docking requirement of one of the message channels 1 are changed, each sub-service system docked with the message channel 1 needs to be changed, which tends to bring about an increase in labor cost and time cost for the company. In order to enhance the effect of the enterprise, a message center integrating all message channels 1 is needed, namely, the message center is an intermediate service for butting various message channels, so that complex and complicated butting work is integrated into the message center or the intermediate service. The message center or the intermediate service provides a corresponding self-defined interface or is used for the sub-service system to dock in a mode of putting corresponding messages in the message queue 6, so that the complex and tedious docking work is limited in the message center or the intermediate service, the difficulty of joint debugging of the service system is reduced, the research and development efficiency is improved, and the research and development period is shortened.
To achieve the above object, this embodiment discloses an intermediate service processing method for interfacing with multiple message sources, as shown in fig. 2 and 3, based on a message sending service 2, a message receiving service 3, a remote dictionary service 4, a database 5, a message queue 6, and a message pushing service 7, the method includes the following steps:
the message receiving service 3 acquires the service contents transmitted by the message transmitting service 2. The service content is a message sent by a user to the message receiving service 3 through the message sending service 2 in the sub-service system, or the sub-service system can automatically send the message with the preset content to the message receiving service 3 under the condition of meeting the preset requirement, or the sub-service system can forward the received message meeting the preset requirement to the message receiving service 3 under the condition of meeting the preset requirement. The business content at least comprises a message template and a message channel which meet the requirement of a preset format. The message template is self-defined attribute content or content of the attribute of the source of the message, and can be a dynamic verification code used when the user logs in, wherein the dynamic verification code is uniquely corresponding to the user and can be automatically disabled after the user logs out, and the dynamic verification code can be used as mark information of the message related to the user. The message channel represents the message channel 1 needed by the message, which can be a flybook, a mail, a short message, an HTTP/HTTPS and the like, and the short message can be divided into an AWS, an Ary, a Tencer, a telecom operator and the like.
The service content is checked according to a preset check strategy, and the check strategy comprises the following steps:
extracting a message module in the service content, matching the message module with a preset built-in template, and returning first verification information to the message sending service 2 if the matching fails. The first check message may be that the message template exists or that the message template does not exist, if the first check message is that the message template exists, the step of processing the service content may be continuously executed for successful matching, if the first check message is that the message template does not exist, the message receiving service 3 returns the first check information that the message template does not exist to the message sending service 2 for failed matching. The message module matching enables pairing with the content format corresponding to the message channel 1.
The message receiving service 3 can also extract a message channel in the service content, match the message channel with a preset channel template, and if the matching fails, return second check information to the message sending service 2. The second check message may be that a message channel exists or a message template does not exist, if the second check message is that the message channel exists, the step of processing the service content may be continuously performed for successful matching, and if the second check message is that the message channel does not exist, the message receiving service 3 returns the second check information that the message channel does not exist to the message sending service 2 for failed matching. Message channel matching enables pairing of corresponding connection links with message channel 1.
If the message receiving service 3 only checks the message template, when the content of the first check information is that the message template exists, checking the message template; if the message receiving service 3 only checks the message channel, when the content of the second check information is that the message channel exists, checking the message channel; if the message receiving service 3 needs to check the message template and the message channel, when the content of the first check information is that the message template exists and the content of the second check information is that the message channel exists, the check is passed.
And if the verification is passed, inquiring the preset message template information from the database 5 according to the service content, and generating an inquiry result.
And generating message content according to the service content based on the query result. Specifically, the database 5 may be a mongo db, a cloud table, or other storage modules, where preset message template information is stored in the database 5, and if the query result is that the message template information corresponding to the message template in the service content can be queried in the database 5, the message content is generated according to the content format built in the message receiving service 3.
The message receiving service 3 queries the channel handler based on the message channel extracted from the transmitted message. The channel processor includes a plurality of processors corresponding to a plurality of message channels one by one, also called handers, and the handers are mainly used for processing asynchronous messages, when a message is sent, a message queue 6 is first entered, a function for sending the message returns immediately, and another part fetches the messages one by one in the message queue 6, and then processes the messages, that is, processes that the sent message and the received message are not synchronous. Handler is typically used to handle relatively time consuming message processing steps. The call interface of the channel processor is built in the message receiving service 3.
In this embodiment, the message queue 6 may adopt RocketMQ, rocketMQ as an open source message middleware with characteristics of pure java, distributed, queue model, etc., and supports the main stream message queue 6 of transaction messages, sequence messages, batch messages, timing messages, message backtracking, etc.
Based on the transmission state created by the channel processor in response to the message channel inquiry action, a message execution state is generated, and the content of the message execution state is a state to be transmitted. In this step the channel processor plays the role of adding and processing messages to the message queue 6, only processing messages sent by itself, i.e. informing the message queue 6 that it is to perform a task and that it is to perform the task while looping to the current channel processor, sending the message execution status to the remote dictionary service 4. Remote dictionary service 4 may employ Redis, which is a key-value storage system that, like Memcached, supports relatively more value types stored, including strings, linked lists, collections, ordered collections, and hash types. These data types all support push/pop, add/remove, and pick intersection union and difference and richer operations, and these operations are all atomic. On the basis, redis supports sorting in a plurality of different modes, and like Memcached, data are cached in a memory for ensuring efficiency, except that Redis can periodically write updated data into a disk or write modification operation into an additional record file, and master-slave synchronization is realized on the basis.
The message receiving service 3 generates a message record to be transmitted according to the message execution state, and transmits the message record to be transmitted to the database 5.
The message receiving service 3 then sends the message content to the Topic unit of the message queue 6, topic unit, topic, also called message Topic, which is a message delivery model in which a message publisher publishes messages to a specific message Topic, at least one message reader interested in this message Topic and in an active state or a message subscriber who has established a persistent subscription can only receive the published messages. Under this model, publishers and subscribers do not know each other, and this model can be compared to an anonymous bulletin board. The model includes both message handling approaches, for non-persistent subscriptions and persistent subscriptions, i.e., message consumers have registered specific topic targets.
After inquiring the message template message, obtaining the message content with higher matching certainty, then sending the message content which is matched to the message queue 6 through the channel processor, and sending the message execution state to the remote dictionary service 4, thereby managing the sending of the message in the content, the sending state and the recorded dimension, and being beneficial to realizing the intermediate butt joint of various message channels 1.
As shown in fig. 3 and 4, after the message receiving service 3 sends the message content to the message queue 6, a log trace message is generated and sent to the subject unit of the message queue 6. The message receiving service 3 monitors the change condition of the log tracking message in the subject unit, and the message receiving service 3 returns the message identity information corresponding to the message content to the message sending service 2 after sending the log tracking message. In addition, the message receiving service 3 can store the log trace message after monitoring the change of the log trace message in the message pair column. The return of the message identity information enables the message sending service 2 to inquire the message content, provides a feedback mechanism of the message sending process, and the stored log tracking message can track and record each message.
The message content in the message queue 6 is sent to the message channel 1 or sent to the message channel 1 through the message pushing service 7, the message channel 1 receives the message content and returns a corresponding message receipt, after the message receiving service 3 receives the message receipt, the message receipt is converted into an execution message according to a preset conversion policy, and the message receiving service 3 sends the execution message to the message queue 6 for reading by a required subscriber. The transformation policy may be to extract the required parts of the contents of the message receipt and then reassemble the required parts into the execution message according to a preset format.
As shown in fig. 5, the message receiving service 3 listens to the message queue 6, if the message queue 6 is put into the execution message, reads the execution message, analyzes the message status of the execution message according to a preset analysis policy, and then sends the message status to the message queue 6 for the required subscriber to read. The analysis strategy comprises the following steps:
message receiving service 3 invokes a procedure decision unit, ALT, to analyze the execution message. The process judging unit executes a preset analysis judging step, and different execution actions are made according to different scenes.
In this embodiment, the message status includes incomplete status information and completed status information. If the content of the execution message includes incomplete status information, the message receiving service 3 updates the status information to the remote dictionary service 4 and/or the database 5. If the content of the executing message includes completed status information, the message receiving service 3 updates the message status to the remote dictionary service 4 and/or the database 5. And if the executing message content comprises a callback opening interface instruction, sending the completed state information to the theme unit. In this embodiment, the operation steps corresponding to the instruction for opening the callback interface include opening the interface for calling the message queue to the message sending service and returning the interface, so that the user does not need to directly get familiar with the operation instruction of the message queue, but can indirectly operate the message queue through the interface.
Acquiring and checking the service content, and sending the message content to the message queue 6 after checking, wherein different message channels 1 can monitor the messages of the message queue 6, and return execution messages to the message queue 6 after receiving the message content; the execution message is then analyzed and the results of the analysis are sent to the message queue 6 for querying or processing. The using process judging unit can be used for linking the state of the message with the selection of the calling interface, so that the state analysis can be realized when different message channels 1 are docked, and the compatibility and the universality of intermediate docking are improved. The message sending service 2 is not required to independently butt-joint different message channels 1, and after the interfaces in the message channels 1 are changed, the maintenance of the butt-joint step can be completed only by modifying the verification strategy and the analysis strategy, and each subsystem of the platform service system is not required to be independently maintained, so that the complex and complicated butt-joint work between the subsystem and the existing message channels 1 realizes integrated intermediate service processing.
The embodiment also discloses an intermediate service processing method for interfacing with multiple message sources, as shown in fig. 6 and 7, based on a message sending service 2, a message receiving service 3, a remote dictionary service 4, a database 5, a message queue 6 and a message pushing service 7, comprising the following steps:
the message push service 7 listens to the subject units in the message queue 6.
If the message content is monitored to be put in the subject unit, the message pushing service 7 extracts the message content and sends the message content to the message channel 1. The message channel 1 comprises an alicloud and communication short message channel, an alicloud and communication mail channel, an aurora and alicloud APP message channel 1, a book flying message channel 1, a nail message channel 1, a WeChat notification channel, a WeChat and payment treasury applet channel and the like.
The message push service 7 receives the return message returned by the message channel 1 and analyzes the return message according to a preset analysis strategy. The resolution strategy comprises the following steps:
the message push service 7 invokes a procedure decision unit, ALT, to analyze the return message. After analyzing the returned message, a status message is obtained, wherein the content of the status message comprises a status message to be sent, a status message in the middle of sending, a sent status message, a status message successful in sending and a status message failed in sending.
If the process judging unit judges that the call is successful and the content obtained by analyzing the returned message comprises the successful sending state information and the tracking information, a callback interface closing instruction is generated and the successful sending state information is sent to the message queue 6. The call success realizes the interfacing with the required message channel 1 for the message push service 7 successfully, and the message channel 1 completes at least the initial preparation of the message content to be sent. Failure to invoke is that the message push service 7 cannot interface with the desired message channel 1, and the message channel 1 does not complete the initial preparation for sending the message content.
If the process judging unit judges that the call is successful and the content obtained by analyzing the returned message comprises the sending state information and the tracking information, a callback opening interface command is generated and the sending state information is sent to the message queue 6.
In this embodiment, the operation steps corresponding to the opening callback interface instruction include returning an interface for calling the message queue to the message sending service, so that the user does not need to directly get familiar with the operation instruction of the message queue, but indirectly operates the message queue through the interface. The operation steps corresponding to the instruction of closing the callback interface include closing the interface for calling the message queue to the message sending service, and the user needs to be familiar with the operation instruction of the message queue instead of indirectly operating the message queue through the interface.
If the process judging unit judges that the call fails, judging whether to retransmit the message content to the message channel 1 according to a preset retransmission condition, if the retransmission is judged, transmitting the message state of failed retry to the subject unit, and if the retransmission is judged, transmitting the message of failed state to the message queue 6. As shown in fig. 7 and fig. 8, when the message push service 7 monitors the message status of the failed retry in the subject unit, it extracts the corresponding message content, resends the message content to the message channel 1, waits for the return message sent by the message channel 1, and continues to parse the return message by using the parsing policy after receiving the return message. If the retransmission is judged, the transmission fails. The using process judging unit can be used for linking the state of the message with the selection of the calling interface, so that the state can be analyzed when different message channels 1 are docked, and the compatibility and the universality of intermediate docking are improved.
Successful delivery of the message content within the message channel 1 will generate a message receipt, which the message receipt service 3 will receive and generate a corresponding message status, which will be sent by the message receipt service 3 to the subject unit of the message queue 6.
If the message push service 7 monitors that the completed message state is put in the theme unit, a call interface notification corresponding to the completed message state is returned to the message sending service 2, wherein the completed message state corresponds to that the message channel 1 successfully sends the message content.
If the message push service 7 monitors the message state of the failed retry in the subject unit, extracting the message content and sending the message content to the message channel 1; and receiving a return message returned by the message channel 1, and analyzing the return message according to the analysis strategy.
The embodiment can combine the intermediate service processing method for interfacing a plurality of message sources in the previous embodiment, and can obtain better effect in the intermediate service processing for interfacing a plurality of message sources. For example, the subsystem simply depends on the success rate of sending the message channel 1 when the message channel 1 cannot guarantee that the message is sent successfully, so that the success rate of sending the message by the subsystem service cannot be maximized, and after the combination of the intermediate service processing methods for interfacing multiple message sources in multiple embodiments, the intermediate service processing for interfacing multiple message sources can be realized, the joint debugging difficulty is reduced, and the success rate of sending the message can be maximized.
The message content is sent to the theme unit, the message content in the theme unit is sent to the corresponding message channel 1 according to the recorded message channel, then the returned information returned by the message channel 1 is analyzed, the content of the returned information is corresponding to the calling interface, the message sending service 2 is not required to be independently connected with different message channels 1, after the interface in the message channel 1 is changed, the maintenance of the connection step can be completed only by modifying the analysis strategy and the condition of the calling interface, and each subsystem of the platform service system is not required to be independently maintained, so that the complex and complicated connection work between the subsystem and the existing message channel 1 can realize integrated intermediate service processing. If the message channel 1 fails to process the message content successfully, the message is judged to be retransmitted, if the message channel 1 fails to retry, the message content is directly retransmitted, retransmission of the message service 2 is not needed, and new message content is not needed to be regenerated to the subject unit.
The embodiment also discloses an intermediate service processing device for interfacing with multiple message sources, as shown in fig. 9, comprising the following modules:
a message sending service 2 for sending the service content to a message receiving service 3.
A message receiving service 3, configured to obtain the service content sent by the message sending service 2; checking service content according to a preset checking strategy, if the checking is passed, generating message content, and sending the message content to a message queue 6; based on the message channel 1, obtaining a message receipt returned by the message content in the message queue 6, converting the message receipt into an execution message according to a preset conversion strategy, and sending the execution message to the message queue 6; and monitoring the message queue 6, if the message queue 6 is put into the execution message, reading the execution message, analyzing the message state of the execution message according to a preset analysis strategy, and sending the message state to the message queue 6.
A message push service 7 for listening to a subject unit of the message queue 6; if the message content is monitored to be put into the theme unit, extracting the message content, and sending the message content to the message channel 1; receiving a return message returned by the message channel 1, and analyzing the return message according to a preset analysis strategy; if the completed message state is monitored to be put in the subject unit, a call interface notification corresponding to the completed message state is returned to the message sending service 2, wherein the completed message state corresponds to the message channel 1 successfully sending the message content.
The embodiment also discloses a storage medium, which stores the program of the intermediate service processing method for interfacing with a plurality of message sources.
The above embodiments are not intended to limit the scope of the present application, so: all equivalent changes in structure, shape and principle of the application should be covered in the scope of protection of the application.

Claims (10)

1. An intermediate service processing method for interfacing with multiple message sources, comprising the steps of:
acquiring business content sent by the message sending service (2);
checking the service content according to a preset checking strategy, generating message content if the checking is passed, and sending the message content to a message queue (6);
based on a message channel (1), obtaining a message receipt returned by the message content in the message queue (6), converting the message receipt into an execution message according to a preset conversion strategy, and sending the execution message to the message queue (6);
monitoring the message queue (6), if the message queue (6) is put into the execution message, reading the execution message, analyzing the message state of the execution message according to a preset analysis strategy, and sending the message state to the message queue (6).
2. The method for processing intermediate services interfacing with multiple message sources according to claim 1, wherein the verification policy comprises the steps of:
extracting a message module in the service content, matching the message module with a preset built-in template, and returning first verification information to the message sending service (2) if the matching fails;
and/or extracting a message channel in the service content, matching the message channel with a preset channel template, and returning second check information to the message sending service (2) if the matching fails.
3. The method for processing an intermediate service for interfacing with multiple message sources according to claim 1, wherein the step of generating message contents if the verification passes and transmitting the message contents to a message queue (6) further comprises the steps of:
inquiring preset message template information from a database (5) according to the service content to generate an inquiry result;
generating the message content according to the service content based on the query result;
inquiring a channel processor according to a message channel extracted from the message content;
generating a message execution state based on a transmission state created by the channel handler in response to a message channel query action, transmitting the message execution state to the remote dictionary service (4);
generating a message record to be sent according to the message execution state, and sending the message record to be sent to the database (5);
-sending said message content to a subject unit of said message queue (6).
4. The method of processing an intermediate service interfacing with multiple message sources according to claim 1, wherein the analysis strategy comprises the steps of:
invoking a database (5) proxy service to analyze the execution message;
if the content of the execution message comprises incomplete status information, updating the status information to the remote dictionary service (4) and/or the database (5);
updating the message status to the remote dictionary service (4) and/or the database (5) if the content of the execution message includes completed status information;
and if the content of the execution message comprises a callback opening interface instruction, sending the completed state information to the theme unit.
5. The method of intermediate service processing for interfacing with multiple message sources according to claim 1, further comprising the steps of:
after the message content is sent to a message queue (6), a log tracking message is generated and sent to the message queue (6);
returning message identity information corresponding to the message content to the message sending service (2) according to the log tracking message; and/or storing the log trace message after the log trace message is monitored in the message pair column.
6. An intermediate service processing method for interfacing with multiple message sources, comprising the steps of:
a subject unit of the listening message queue (6);
if the topic unit is monitored to be put into the message content, extracting the message content, and sending the message content to a message channel (1); receiving a return message returned by the message channel (1), and analyzing the return message according to a preset analysis strategy;
and if the completed message state is monitored to be put in the theme unit, returning a call interface notification corresponding to the completed message state to a message sending service (2), wherein the completed message state corresponds to the message channel (1) to successfully send message content.
7. The method for processing intermediate services for interfacing with multiple message sources according to claim 6, wherein the parsing strategy comprises the steps of:
invoking a database (5) proxy service to analyze the return message;
if the database (5) proxy service is successfully invoked and the content obtained by analyzing the return message comprises successful sending state information and tracking information, a callback interface closing instruction is generated;
if the database (5) proxy service is successfully invoked and the content obtained by analyzing the return message comprises sending state information and tracking information, generating a callback opening interface instruction;
if the database (5) proxy service call fails, judging whether to retransmit the message content to the message channel (1) according to a preset retransmission condition, and if so, transmitting a message state of failed retry to the subject unit.
8. The method of intermediate service processing for interfacing with multiple message sources according to claim 6, further comprising the steps of:
if the message state of failed retry is monitored, extracting the message content, and sending the message content to a message channel (1); and receiving a return message returned by the message channel (1), and analyzing the return message according to the analysis strategy.
9. An intermediate service processing device for interfacing with multiple message sources, comprising:
a message sending service (2) for sending the business content to a message receiving service (3);
a message receiving service (3) for acquiring the service content transmitted by the message transmitting service (2); checking the service content according to a preset checking strategy, generating message content if the checking is passed, and sending the message content to a message queue (6); based on a message channel (1), obtaining a message receipt returned by the message content in the message queue (6), converting the message receipt into an execution message according to a preset conversion strategy, and sending the execution message to the message queue (6); monitoring the message queue (6), if the message queue (6) is put into the execution message, reading the execution message, analyzing the message state of the execution message according to a preset analysis strategy, and sending the message state to the message queue (6);
a message push service (7) for listening to a subject unit of the message queue (6); if the topic unit is monitored to be put into the message content, extracting the message content, and sending the message content to a message channel (1); receiving a return message returned by the message channel (1), and analyzing the return message according to a preset analysis strategy; and if the completed message state is monitored to be put in the theme unit, returning a call interface notification corresponding to the completed message state to the message sending service (2), wherein the completed message state corresponds to the message channel (1) to successfully send message content.
10. A storage medium storing a program of an intermediate service processing method according to any one of claims 1 to 8 for interfacing with a plurality of message sources.
CN202311185917.9A 2023-09-13 2023-09-13 Intermediate service processing method, device and storage medium for interfacing multiple message sources Pending CN117119050A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311185917.9A CN117119050A (en) 2023-09-13 2023-09-13 Intermediate service processing method, device and storage medium for interfacing multiple message sources

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311185917.9A CN117119050A (en) 2023-09-13 2023-09-13 Intermediate service processing method, device and storage medium for interfacing multiple message sources

Publications (1)

Publication Number Publication Date
CN117119050A true CN117119050A (en) 2023-11-24

Family

ID=88812789

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311185917.9A Pending CN117119050A (en) 2023-09-13 2023-09-13 Intermediate service processing method, device and storage medium for interfacing multiple message sources

Country Status (1)

Country Link
CN (1) CN117119050A (en)

Similar Documents

Publication Publication Date Title
US7958188B2 (en) Transaction-initiated batch processing
US6041365A (en) Apparatus and method for high performance remote application gateway servers
US6753889B1 (en) Platform independent business to business messenger adapter generation tool
US8136127B1 (en) System and method for linearly managing client-server communication
CN113630372A (en) Cloud edge coordination system for edge computing
US8726079B2 (en) Handling of messages in a message system
RU2382402C2 (en) Flexible context control for listing sessions using context exchange
US7954112B2 (en) Automatic recovery from failures of messages within a data interchange
US7007088B1 (en) Method and apparatus for providing an E-business audit trail in a distributed computing system
CN110430126A (en) Instant communication message processing method, device, system, equipment and storage medium
US20040057572A1 (en) Using information about software events to route contacts in a contact center
CN115622906A (en) Application log capturing system and method
CN111611094A (en) Monitoring and managing method for abnormal MQ information
US20090271466A1 (en) Data logging with network interfacing feature
CN110620819B (en) Block chain interaction method and device, computer equipment and readable storage medium
CN117119050A (en) Intermediate service processing method, device and storage medium for interfacing multiple message sources
WO1998056024A1 (en) Translation of messages to and from secure swift format
CN112511636B (en) Data transmission system, method, device, computer equipment and storage medium
CN111182047B (en) Method and system for transferring files between large data platforms across a network
CN112866268A (en) Message processing method and system
US11836550B2 (en) Systems and methods for moving, reconciling, and aggregating data from mainframe computers to hybrid cloud
CN107608804B (en) Task processing system and method
CN111552907A (en) Message processing method, device, equipment and storage medium
CN117354400B (en) Acquisition and analysis service system for Beidou short message
CN112671822B (en) Service request processing method, device, storage medium, server and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination