MMS multi-channel information model transmission scheduling system based on file IO stream

Abstract

The invention discloses an MMS multichannel information model transmission scheduling system based on a file IO stream, and relates to the technical field of system architecture design. According to the method, the file content in the MMS model is transmitted in an IO stream format, and the file content information is converted into the Base64 code to be encrypted, so that the limitation of a system UI visual submission model is solved; after the content submitted by the MMS model is obtained and analyzed, a server connection object is created through an SFTP protocol, and connection login is remotely carried out on the file server through an account, an IP, a port and a password; after the file server is logged in based on the SFTP protocol, the file information is converted into the File object and is stored in the formulated path under the file server in a cross-server manner, so that the problem that the memory of the database is occupied when the file is stored in the database is relieved, the controllability of file management is improved, only one model corresponds to multi-channel reporting through a multi-channel concurrent reporting model, and the reliability of file management is improved. Therefore, the model reporting efficiency is improved, and the success rate of issuing the short message by the user is improved.

Description

Technical Field

[0001] This invention relates to the field of system architecture design technology, specifically to a file I / O stream-based MMS multi-channel information model transmission scheduling system. Background Technology

[0002] Traditionally, mobile phones are used for basic voice communication and simple text interaction, while MMS is used to transmit color video. Its biggest feature is that it supports multimedia functions and can transmit information in various multimedia formats such as text, images, sound, and data. In fact, MMS has nothing to do with SMS. It uses the Wireless Application Protocol (WAP) under the support of GPRS network to transmit information services such as text, pictures, sound, and animation. Of course, it can also be transmitted using the original CSD method, but the speed is slow. MMS usually consists of an MMS header and multiple video clips, which can contain pictures / text / sound.

[0003] MMS can essentially be understood as an email with many attachments; it's a standardized form of email. These attachments include images, text, and audio, all named according to certain rules. When a mobile phone receives an MMS email, it can then extract the videos from the attachments.

[0004] Generally speaking, an MMS system includes the following network elements: MMS terminal, multimedia messaging service center, MMS user database, external application server, value-added application server, and MMS application support system. It is much more complex than SMS and belongs to WAP service, so the price is much higher than SMS. You don't need to worry about the composition of the MMS service system; the key is how to use it well.

[0005] Our focus with this scheduling system is to obtain the MMS content submitted by users without loss of quality. We first conduct a single-mechanism review, and after the review is approved, we transmit the data as a file I / O stream through the operator's HTTP / HTTPS interface. This pushes the model created by MMS to the operator for review and ensures that the mobile phone number submitted by the user can receive the MMS content normally.

[0006] This application is mainly for a file I / O stream-based MMS multichannel information model transmission scheduling system. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a file I / O stream-based MMS multi-channel information model transmission scheduling system. This system enables multiple users to concurrently create an index structure for the information model; MMS information models are asynchronously pushed to channels via HTTP / HTTPS based on file I / O stream transmission; the system proactively and periodically acquires the results of the model review mechanism from multiple channels or has multiple channels proactively push the results to the storage medium; users push a set of numbers to be sent and cache it in a message queue; the system proactively allocates and saves these numbers to the message queue to be sent based on number attributes and the channels whose models have passed review; a timer periodically scans and acquires message queue data, and reads the channel's flow rate for batch message submission or single message submission; after a channel sends an SMS, it returns the message status, and by periodically receiving or acquiring the status, this system improves the efficiency of sending and model reporting in MMS SMS messages.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a file I / O stream-based MMS multi-channel information model transmission scheduling system, which includes the following components: Step S1: Transmitting the MMS information model based on file I / O streams is more in line with user needs than operating on the UI page. By developing a specified HTTP / HTTPS protocol interface, users can seamlessly connect with the system and transmit the MMS information model material in Base64 code as a stream through the UI visualization page on the user's end, which improves the compatibility between the user system and the system. Step S2: SFTP is a secure file transfer protocol based on SSH. Using the SFTP protocol, a secure network encryption algorithm is provided during file transfer, which effectively prevents threats during the transmission process and ensures the secure transmission of data. This method will replace the original method of storing MMS model material files in the data storage medium. By remotely connecting to the server through SFTP, and verifying the server IP, port, account and password through SSH, the material files are directly stored in the specified path of the corresponding remote server in the form of IO stream, thereby saving storage memory resources. Step S3: Based on the MMS information model instance data review operation, perform topology optimization based on multi-channel compatibility and optimize backup channel reporting to obtain the optimized model reporting success rate; After the MMS information model is submitted by the user through the network protocol interface or UI visualization tool according to the user's unique ID, the system will first conduct a preliminary review of its model content. After the preliminary review is passed, the system will bind the model ID to the operator gateway that the user ID needs to submit to, and distinguish between the main channel and backup channel according to the stability and cost-effectiveness of the gateway. The channel with higher stability and cost-effectiveness will be reported as the main channel, and the other channels will be reported as backup channels. This fully solves the scalability and compatibility of an information model reporting gateway and improves the success rate of model reporting. Step S4: Following step S3, the same MMS information model ID is simultaneously reported to multiple gateways, effectively improving the success rate of model reporting. Currently, the system's sending mechanism depends on the status of multiple gateways. Users can only send the model ID and number binding after waiting for the reporting status of all submitted gateways to return. Due to the inconsistent return time of multiple gateway reports, some gateways have faster review efficiency and can quickly return the reporting status, while others have slower review speeds. This leads to a decrease in user delivery efficiency. The MMS model reporting scheduling system needs to be optimized. Instead of waiting for the status of all reporting gateways to return before delivery, the system should be optimized so that as long as the corresponding gateway's review status returns, users can submit the number and send it according to the number operator supported by the reporting gateway. This improves user delivery efficiency and reduces dependence on model status. Step S5: Based on the process of receiving or actively acquiring the MMS sending status returned by the gateway, and performing parallel high-performance receiving efficiency analysis, the operation of data storage after acquiring the status through multi-channel concurrent push leads to slow database update performance, affecting the efficiency of gateway status push and user status acquisition. By storing the status data in an intermediate cache, after the gateway status data is pushed and acquired, it is first stored in the intermediate storage medium, and the gateway response is immediately returned. At the same time, a scheduled task is started to convert the status data stored in the intermediate medium into a JSON string using a JSONObject object and perform a one-to-one matching with the GUID or MSGID of the original data in the system. After matching the original SMS, the status of the original SMS is modified, and the user status is encapsulated according to the system status format and stored in the middleware for scheduled push to the customer. This effectively solves the problem of low system gateway status reception rate and slow user status reception.

[0009] Further, step S1 includes the following steps: Step S11: Receive user-submitted data via HTTPS / HTTPS protocol interface, verify whether the account and password are correct, whether the signature format is correct and whether it has been reported, and whether the model content is required. Step S12: Encapsulate the MMS model object and assign values ​​to the object fields. Parse the data to obtain the model title, model text content, and video, audio, and image information of the model. Step S13: Convert the Base64 code of the file content in the model into a temporary file, remotely log in to the file server via the SFTP protocol, generate a unique file path, transfer the temporary file to the file server for storage via the IO stream method, and close the SFTP connection. Step S14: Save the encapsulated model object and model content object to the storage database, and notify the staff to conduct the initial review in the form of a message notification; Step S15: Encapsulate the interface response data and send it to the user in JSON format.

[0010] Furthermore, step S14 includes the following steps: Step S141: Encapsulate a video_template object based on the basic data submitted by the user; Step S142: Encapsulate the video_template_content object according to the type of the saved video_template object and content to obtain entity mapping association data; Step S143: The message management data is encapsulated and stored. The system will notify the message management module to notify the staff for preliminary review. Step S144: Request data according to the HTTPS / HTTPS protocol interface, receive and process the data, and then send a system response to the requester.

[0011] Furthermore, step S2 includes the following steps: Step S21: Create an object using FtpJSch and call the Connect method through that object; Step S22: After creating the jsch object, use the file server's IP address, username, and port to create a session object using the getSession method of the jsch object; Step S23: The session object identifies the password, and after a strict host key check, the sshSession connection is opened to obtain the SFTP tunnel; Step S24: Based on the parsed temporary file storage path, create a File object on the file server, convert the file object into a file input stream object FileInputStream, and convert the file stream object into a MultipartFile object; Step S25: Use ftpJSch's upload function to store the MultipartFile object in the file server.

[0012] Furthermore, step S3 includes the following steps: Step S31: The user encapsulates the MMS model information and submits the MMS information model through a network protocol interface or UI visualization tool; Step S32: The management system will notify relevant personnel to conduct an initial review of the model via system messages, reviewing the model's signature, text content, video content, image content, and audio content; Step S33: If the model information is not up to standard, the model will be rejected; if the content is up to standard, then select the gateway that needs to be reported through the UI visualization platform. Multiple gateways can be selected to achieve parallel review of multiple gateways. Step S34: The model is transmitted to the gateway in the form of an IO stream through the scheduling system. The gateway will return a corresponding MSGID. The scheduling platform parses the returned information and stores the MSGID corresponding to the unique ID of the model. Step S35: After the gateway reviews the application, there will be two states: review passed or review failed. The status can be actively pushed to the scheduling platform by the gateway or obtained by the scheduling platform periodically. Step S36: Based on the obtained model status JSON string, parse the string and perform a unique match between the MSGID in the status data and the MSGID in the data repository. If the match is successful, modify the model reporting status of the gateway. Step S37: The scheduled task in the scheduling system will periodically obtain the model status of all reported gateways. Based on the status, it will determine whether the reported gateway status of China Mobile, China Unicom, and China Telecom for the model has been fully entered into the database. If the status has been fully entered into the database, the reported status of the model will be modified.

[0013] Furthermore, step S37 includes the following steps: Step S371: Obtain data in the model table with status 3 that is in the reporting stage; Step S372: Obtain the reporting status data of each model, including the review status data returned by the gateway, the corresponding unique matching model ID data, and the bound channel ID data; Step S373: Perform channel type status matching analysis based on the channel operator type of each reported status data to obtain the reported status data of the three major operators; Step S374: Based on the state Map set encapsulated by the operators, define the states of the three major operators as boolean type, and determine the boolean value by matching the state data.

[0014] Furthermore, step S4 includes the following steps: Step S41: Based on the single MMS model reporting multi-gateway scheduling, it is necessary to wait for the review status of all gateway models to return and integrate the model status before the user can use the model ID to send the submission number; Step S42: Discuss the issue of reduced service delivery rate in the above steps. Instead of integrating multiple gateway states into a model state, the state returned by each gateway will be encapsulated and stored separately. Step S43: The scheduling system scans the returned gateway status data, uniquely matches the stored status data with the model ID, and then displays the model's reporting status to the user. Step S44: Users can see the reporting status of the model immediately through the UI visualization page, so they no longer have to wait for all gateways to return before they can submit the number. They can send the SMS as soon as a gateway from a single operator returns.

[0015] Furthermore, step S5 includes the following steps: Step S51: After the user submits the mobile phone number through the model ID, it is sent to the corresponding gateway that has passed the filing and review. After the gateway sends the mobile phone number, it will return the status of each mobile phone number to the scheduling system. At this time, the scheduling system needs an API with HTTP / HTTPS protocol to receive the status. Step S52: The status includes successful and failed transmission. After receiving the status through the interface, the status object is encapsulated by decryption or direct parsing of the JSON string. Step S53: Save the parsed state object to the cache middleware Redis, then encapsulate the response data and return it to the gateway; Step S54: The scheduling system's timed service will periodically retrieve data from the storage status KEY, read the data, and delete it to prevent the cache memory from continuously increasing; Step S55: Using the MSGID or other unique identifier ID in the status data, query the MSGID or other unique identifier ID returned when submitted to the gateway for matching. After matching the original SMS, modify the state field of the original SMS to indicate success or failure. Step S56: Then, by obtaining the original SMS, encapsulate the user ID, state, mobile number, batch number, description, and report time from the original SMS into a JSON string and save it to the cache middleware Redis; Step S57: The scheduled task in the scheduling system will periodically obtain the status data from the status KEY + user ID, read the status receiving API bound to each user, and push the status receipt data sent by the user to you.

[0016] Furthermore, step S55 includes the following steps: Step S551: Obtain the unique matching identifier MSGID field through status data parsing; Step S552: Retrieve the original SMS data from the cache using MSGID; Step S553: ​​After matching the original SMS message, modify the state field of the original SMS message.

[0017] Compared with existing technologies, this MMS multi-channel information model transmission scheduling system based on file I / O streams has the following advantages: First, this system transmits file content in the MMS model using IO stream format and encrypts the file content information using Base64 encoding, thus overcoming the limitations of the system's UI-based visual submission model. After acquiring and parsing the MMS model submission content, it creates a server connection object via the SFTP protocol and remotely connects to the file server using an account, IP address, port, and password. After logging into the file server via the SFTP protocol, the file information is converted into File objects and stored across servers in a specified path under the file server, thereby alleviating the problem of file storage occupying database memory and improving the controllability of file management. Through a multi-channel concurrent reporting model, one model corresponds to multiple channels for reporting, thereby increasing the efficiency of model reporting, improving the success rate of users sending SMS messages, and adopting asynchronous processing of status data, which enhances the scheduling system's ability to receive status and the performance of pushing status.

[0018] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram illustrating the creation of a network architecture based on a file I / O stream transmission MMS information model, as well as the signal transmission processing mechanism and scheduling system of the present invention. Figure 2 for Figure 1 A detailed flowchart of step S1; Figure 3 for Figure 1 A detailed flowchart of step S2; Figure 4 for Figure 1 A detailed flowchart of step S3; Figure 5 for Figure 1 A detailed flowchart of step S4; Figure 6 for Figure 1 A detailed flowchart of step S5. Detailed Implementation

[0021] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0022] To achieve the above objectives, please refer to Figures 1 to 6 This invention provides a network architecture creation mechanism and signal transmission processing mechanism and scheduling system based on the file I / O stream transmission MMS information model. The method includes the following steps: Step S1: Transmitting the MMS information model based on file I / O streams is more in line with user needs than operating on the UI page. By developing a specified HTTP / HTTPS protocol interface, users can seamlessly connect with the system and transmit the MMS information model material in Base64 code as a stream through the UI visualization page on the user's end. Step S2: SFTP is a secure file transfer protocol based on SSH. Using the SFTP protocol, a secure network encryption algorithm is provided during file transfer. This method will replace the original method of storing MMS model material files in the data storage medium. By remotely connecting to the server through SFTP, and verifying the server IP, port, account and password through SSH, the material files will be directly stored in the specified path of the corresponding remote server in the form of IO stream. Step S3: Based on the MMS information model instance data review operation, perform topology optimization based on multi-channel compatibility and optimize the backup channel reporting to obtain the optimized model reporting success rate; After the MMS information model is submitted by the user through the network protocol interface or UI visualization tool according to the user's unique ID, the system will first conduct a preliminary review of its model content. After the preliminary review is passed, the system will bind the model ID to the operator gateway that the user ID needs to submit, and distinguish between the main channel and the backup channel according to the stability and cost-effectiveness of the gateway. The channel with higher stability and cost-effectiveness will be reported as the main channel, and the remaining channels will be reported as backup channels; Step S4: According to step S3, the same MMS information model ID is reported to multiple gateways at the same time, which effectively improves the success rate of model reporting. At present, the system's sending mechanism depends on the status of multiple gateways. Users can only send the model ID and number binding after all submitted gateway reporting statuses have returned. Since there is an inconsistency in the return status time of multiple gateway reporting, the MMS model reporting scheduling system needs to be optimized. Step S5: Based on the process of receiving or actively acquiring the MMS sending status returned by the gateway, and performing parallel high-performance receiving efficiency analysis, the status is acquired through multi-channel concurrent push and then the data storage is operated. The status data is stored in an intermediate cache. After the gateway status data is pushed and acquired, it is first stored in the intermediate storage medium. At the same time, the gateway response is immediately returned, and a scheduled task is started. The status data stored in the intermediate medium is converted into a JSON string through a JSONObject object and matched one-to-one with the GUID or MSGID of the original data in the system. After matching the original SMS, the status of the original SMS is modified, and the user status is encapsulated according to the system status format and stored in the middleware for scheduled push to the customer.

[0023] In this embodiment of the invention, reference is made to Figure 1 The above is a flowchart illustrating the steps of creating a network architecture and processing and scheduling system for signal transmission based on a file I / O stream transmission MMS information model according to the present invention. In this example, the network architecture creation and signal transmission processing and scheduling system for the MMS information model includes the following steps: Step S1: Transmitting the MMS information model based on file I / O streams better meets user needs than operating on the UI page. By developing a designated HTTP / HTTPS protocol interface, users can seamlessly integrate with the system. Furthermore, the MMS information model materials are converted into a stream and transmitted using Base64 encoding via a visual UI page on the user's end, improving compatibility between the user system and this system. This invention uses file operation I / O streams to transmit MMS model attachment content via HTTPS / HTTPS protocol interfaces. I / O streams are a solution for storing and retrieving data, encompassing Input (data flowing from the outside into your program) and Output (data flowing from your program to the outside). Streams are Java's abstraction of different types of I / O operations. You can think of it as a water pipe connecting a program and a data source; data flows unidirectionally through the pipe like water. This includes: Input streams (data flowing from the source to the program) and Output streams (data flowing from the program to the destination). Byte streams vs. character streams: These are two types of pipes handling different data types. Byte streams are used to handle all types of files, especially binary files, where the data unit for reading and writing is bytes. Character streams are specifically designed for handling text files, where the data unit for reading and writing is characters. They automatically handle character encoding at the underlying level, simplifying text operations.

[0024] Step S2: SFTP is a secure file transfer protocol based on SSH. Using SFTP provides a secure network encryption algorithm during file transfer, effectively preventing threats during transmission and ensuring secure data transmission. This method replaces the original method of storing MMS model source files in a data storage medium. By remotely connecting to the server via SFTP, and after successful SSH authentication using the server IP, port, username, and password, the source files are directly stored as I / O streams to the specified path on the remote server, thus saving storage memory resources. This invention utilizes the Secure File Transfer Protocol (SFTP) to provide a secure connection for file transfer, enabling cross-server file transfer and file traversal / query functionality. SFTP works by using a secure shell data stream. It first establishes a secure connection and then provides enhanced protection during data transfer. SFTP operates in a client-server architecture. Under normal server conditions, data typically resides on the server. Although this server may be in a different location, the client can easily save or access data by sending a request. When a user needs to save a file across servers, after creating an SFTP protocol object and verifying the server's IP address, username, password, and port, the corresponding folder path is created for the attachment via the protocol object, and the file is then sent to the file server. The user eventually receives the file and can modify it as needed.

[0025] Step S3: Based on the MMS information model instance data review operation, perform topology optimization based on multi-channel compatibility and optimize backup channel reporting to obtain the optimized model reporting success rate. After the MMS information model is submitted by the user through the network protocol interface or UI visualization tool using the unique user ID, the system will first conduct a preliminary review of its model content. After the preliminary review is passed, the system will bind the unique model ID to the operator gateway that the user ID needs to submit to, and distinguish between the primary channel and the backup channel based on the stability and cost-effectiveness of the gateway. The channel with higher stability and cost-effectiveness is reported as the primary channel, and the other channels are reported as backup channels, which fully solves the scalability and compatibility of an information model reporting gateway and improves the success rate of model reporting. This invention optimizes the topology based on multi-channel compatibility and backup channel reporting by performing review operations on MMS information model instance data. Existing thread pool management methods can be used to optimize the model submission channel steps. First, after initial review, the channels to be reported are selected and bound. At this point, the bound channel ID is a comma-separated string. A fixed-size thread pool object, FixedThreadPool, is created using Executors. The number of threads is defined based on the number of server cores. A Scheduled timer periodically retrieves the data to be reviewed from the model table. By traversing the list of reporting channel IDs, the model is submitted to the channel for reporting concurrently using the thread pool. Furthermore, by extending the backup channel functionality, lower-priority channels are used as backup channels for reporting. This effectively improves the efficiency of model reporting and ensures that models can be sent normally on China Mobile, China Unicom, and China Telecom channels.

[0026] Step S4: Following step S3, the same MMS information model ID is simultaneously reported to multiple gateways. While this effectively improves the success rate of model reporting, the current system's sending mechanism is dependent on the status of multiple gateways. Users must wait for the reporting status of all submitted gateways to return before they can bind and send the model ID and number. Due to the inconsistent return times of multiple gateway reports, some gateways have faster review efficiency and can quickly return the reporting status, while others have slower review speeds, resulting in reduced user delivery efficiency. Therefore, the MMS model reporting scheduling system needs to be optimized. Instead of waiting for all reporting gateways to return their status before delivery, the system should allow users to submit numbers and send them as soon as a corresponding gateway's review status returns, based on the number operators supported by the reporting gateway. This improves user delivery efficiency and reduces dependence on model status. This invention, based on collaborative optimization of the reporting status structure and optimization of model status integration, eliminates the need for separate integration of model states. According to the received gateway reporting model status, a unique match is performed between the unique MSGID in the gateway reporting status and the reported return data. This unique match is then stored as a separate state in the database. The model's operator status is then modified according to the gateway's operator structure. This eliminates the requirement to integrate and modify the model's operator status only after all gateway reporting statuses have returned. Storing gateway states as independent states effectively solves the limitation that users must wait for all gateway reporting statuses to return before sending messages. Users can send messages to the corresponding successfully reported operator number only when a relevant operator gateway returns a successful reporting status, improving the efficiency of sending MMS messages and enhancing the system experience.

[0027] Step S5: Based on the process of receiving or actively acquiring MMS status returned by the gateway, and performing parallel high-performance reception efficiency analysis, the operation of directly manipulating the data storage repository after obtaining the status through multi-channel concurrent push leads to slow database update performance, affecting the efficiency of gateway status push and user status acquisition. By storing the status data in an intermediate cache, after the gateway status data is pushed and obtained, it is first stored in the intermediate storage medium, and a gateway response is immediately returned. At the same time, a scheduled task is started to convert the status data stored in the intermediate medium into a JSON string using a JSONObject object, and perform a one-to-one matching with the GUID or MSGID of the original data in the system. After matching the original SMS, the status of the original SMS is modified, and the user status is encapsulated according to the system status format and stored in the middleware for scheduled push to the customer. This method effectively solves the problems of low system gateway status reception rate and slow user status reception. This invention constructs a status reception model based on MMS message sending status data. Based on the success or failure status data returned by the asynchronous MMS message transmission channel, corresponding status reception models are established, such as a reception model, a status update model, and a status push model. Parallel high-performance data processing and analysis are performed to temporarily store and match the raw status data of the status reception model, obtaining valid data capable of updating the status of the raw data and encapsulating it into result data that can be pushed to the user. The MSGID, mobile phone number, GUID, submission time, and user ID from the user-submitted raw SMS data are temporarily stored in the Redis cache middleware. After obtaining the gateway's sending receipt through an asynchronous program, the status data is parsed using a JSONObject, and a unique match is performed between the MSGID in the status and the MSGID in the raw data. Upon successful matching, the corresponding SMS status data (Update) database's raw SMS state field is generated. Then, the MSGID, mobile phone number, user ID, SMS status, submission time, and report time from the raw SMS are encapsulated into a JSON string, and the encapsulated data is stored in the corresponding user ID's KEY. Finally, a Scheduled timer pushes the status data to the user every five seconds. It accelerated the gateway status reception performance and prevented status reception congestion; it also improved the efficiency of pushing user status data.

[0028] This invention utilizes a file I / O stream transmission method to display the MMS information model content of the system on a UI visualization interface, improving system observability and enhancing secure access to the storage server. By optimizing the transmission of model content via HTTP / HTTPS protocols, images, videos, and audio within the model content are converted to Base64 encoding for transmission. The Base64 encoding is then converted into temporary files for local server storage, improving the ease of user integration and system coherence. The SFTP protocol provides a secure network encryption algorithm during file transfer, ensuring secure data transmission. It offers a secure connection for file transfer and traverses the file system on both local and remote systems. This invention addresses the issue of excessive memory consumption in the database storage due to file streams. By using cross-server connections, files are converted into file formats as I / O streams and stored on the file server, improving the efficiency of file storage and retrieval between servers.

[0029] The MMS information model reporting function has been optimized. After a single model passes initial review, the gateways to be reported are configured via a visual UI. The system concurrently executes the reporting operation, submitting the network transmission of a single model to multiple gateways for reporting. A backup gateway mechanism is also employed, effectively addressing the limitation of reporting a single model to a single gateway and improving the efficiency and compatibility of model reporting. Based on the analysis of the concurrent reporting multi-channel model status pushback and integration scheduling, optimization and rectification are needed for the integration of multi-channel reporting return statuses. Currently, the scheduling system pushes a single MMS model to multiple gateways for review in parallel. The different review timelines of each gateway result in different review status return timelines, thus affecting the user's sending progress.

[0030] After rectification, the system effectively obtains the gateway that returns the status first, eliminating the step of collecting and integrating all gateway review statuses. It then pushes the approved gateway status back to the user, allowing the user to submit an approved carrier number even before other carrier gateways have returned their review statuses. This effectively reduces the time users spend waiting for all gateway statuses, improves the efficiency of sending MMS messages, and reduces system coupling. Through parallel high-performance MMS message sending status data analysis, optimizations can be made to the gateway's message sending status reception and push to the user. Instead of directly updating the database after obtaining the gateway status, the system first obtains the received gateway status data, caches it without operation, stores it in the middleware Redis, and promptly responds to the gateway, returning a reception response. Then, a scheduled task in the scheduling system retrieves the status data, uniquely matches it with the original SMS message using a unique GUID or MSGID, modifies the original data status, and pushes the status to the user. This optimization improves the performance and reliability of receiving gateway status and pushing user status.

[0031] Preferably, step S1 includes the following steps: Step S11: Receive user-submitted data via HTTPS / HTTPS protocol interface, verify whether the account and password are correct, whether the signature format is correct and whether it has been reported, and whether the model content is required. Step S12: Encapsulate the MMS model object and assign values ​​to the object fields. Parse the data to obtain the model title, model text content, and video, audio, and image information of the model. Step S13: Convert the Base64 code of the file content in the model into a temporary file, remotely log in to the file server via the SFTP protocol, generate a unique file path, transfer the temporary file to the file server for storage via the IO stream method, and close the SFTP connection. Step S14: Save the encapsulated model object and model content object to the storage database, and notify the staff to conduct the initial review in the form of a message notification; Step S15: Encapsulate the interface response data and send it to the user in JSON format.

[0032] As an embodiment of the present invention, reference Figure 2 As shown, Figure 1 A detailed flowchart of step S1 is shown below. In this embodiment of the invention, step S1 includes the following steps: Step S11: Receive user-submitted data via HTTPS / HTTPS protocol interface, verify whether the account and password are correct, whether the signature format is correct and whether it has been reported, and whether the model content is required. This invention submits MMS model content via an HTTP / HTTPS protocol interface to improve the integration rate with users and avoid the limitation of model submission only through a UI visual interface, ensuring seamless integration with the user system. The interface uses HTTP / HTTPS, and the model submission fields include: username, password, signature, template title, video Base64 encoding, image Base64 encoding, audio Base64 encoding, and text content as basic information for model interface submission. This information is encapsulated as a JSON string and sent to the system's API service for processing via a POST request.

[0033] Step S12: Encapsulate the MMS model object and assign values ​​to the object fields. Parse the data to obtain the model title, model text content, and video, audio, and image information of the model. In this embodiment of the invention, the model content obtained from the POST request is converted into a content receiving object using a JSONObject. All submitted parameter values ​​are retrieved, an MMS model object is created, the corresponding parameter values ​​are assigned to the model object, and the remaining fields in the model object are also assigned values.

[0034] Step S13: Convert the Base64 code of the file content in the model into a temporary file, remotely log in to the file server via the SFTP protocol, generate a unique file path, transfer the temporary file to the file server for storage via the IO stream method, and close the SFTP connection. This invention parses the video, audio, and images in user-submitted models and saves them to a file server. By obtaining the Base64 encoded content of the file, it converts the Base64 code into a File object and stores it on the local disk. Then, by creating an SFTP protocol object, it connects to the file server by verifying the file server's IP address, port, username, and password. Simultaneously, the local File object is converted into a FileInputStream, which is then converted into a MultipartFile object and uploaded to the corresponding path on the file server via the connection object. This solves the problems of cross-server file transfer and excessive memory usage when storing data in the database.

[0035] Step S14: Save the encapsulated model object and model content object to the storage database, and notify the staff to conduct the initial review in the form of a message notification; This invention stores MMS model objects. Basic information of the encapsulated MMS model object is saved to the `video_template` table via a MySQL database. After obtaining the saved data ID through an SQL add-and-return ID process, the text content, title, and file are saved to the `video_template_content` table. A `video_template_content` object is created, with unique objects categorized by text content, model title, video, audio, and image. An `index` field is generated based on the content display order of the model; this field uses a pure numeric type, and values ​​are assigned to the `index` field according to the element order. Simultaneously, a `news` message object is created to push the message content to staff for preliminary review.

[0036] Step S15: Encapsulate the interface response data and send it to the user in JSON format.

[0037] This invention, based on the concepts and relationships of the HTTP response protocol and the usage of the Response object, stipulates that after receiving data reported by the model, the HTTP / HTTPS protocol interface needs to promptly return a response to the gateway; otherwise, the gateway interface will experience data push timeouts, hindering data transmission. This is achieved by creating a Response object, setting the data format and encoding of the response information, then creating a PrintWriter object to encapsulate the required response data into a JSON string format for the gateway. Finally, the PrintWriter object is closed to release resources.

[0038] This invention achieves seamless integration between the user system and the system via HTTP / HTTPS protocol interfaces, overcoming the limitations of submitting MMS models only through a visual UI. Through a custom interface, after validating required parameters, users can submit models with high performance. Using JSONObject conversion, the acquired user-submitted data is parsed, and the parsed fields are saved to a temporary object. Then, using Base64 encoding conversion, the submitted file information is converted to File format and saved to the local server. This solves the problem of users transmitting video, audio, and images via API integration, improving the reliability and stability of the user system's integration with the system.

[0039] By using the SFTP protocol to remotely connect to a file server, and upon successful connection, the locally stored file is converted into a FileInputStream file input stream. Then, the MockMultipartFile method is used to convert the FileInputStream into a MultipartFile object. Finally, the upload method is called to transfer the MultipartFile file across servers for storage. This effectively solves the problem of cross-server file transfer and reduces excessive memory consumption caused by saving files to the database. Finally, the model object is encapsulated, and basic model data and content information are saved to a MySQL database. A PrintWriter object is then created to generate a JSON string and respond to the user interface.

[0040] Preferably, step S14 includes the following steps: Step S141: Encapsulate a video_template object based on the basic data submitted by the user; In this embodiment of the invention, a video_template object is first created. After saving the video, images, and audio, the file storage path will be returned. The path data information is saved into the video_template object. At the same time, other values ​​of the video_template object are assigned by the system, and the video_template object is saved to the MySQL database.

[0041] Step S142: Encapsulate the video_template_content object according to the type of the saved video_template object and its content to obtain entity mapping association data; This invention, based on the `video_template` object model data, saves content information according to the file content type in the model. After saving the basic information of the model through the `video_template` object, a unique ID with a primary key is returned. Then, the content array is traversed to obtain five types of content from the model content: text information, video path, image path, audio path, and template title. The `index` field is defined according to these five different types of content and the index order defined in the interface submission. Finally, a `video_template_content` object is encapsulated, saving the template primary key ID, content category, content information, path, and file size into the `video_template_content` object.

[0042] Step S143: The message management data is encapsulated and stored. The system will notify the message management module to notify the staff for preliminary review. This invention uses a message notification module to connect business notifications in the system to staff for review. By creating a system message object `news`, encapsulating the `news` object, assigning the message type and content to the `news` object, and saving it to MySQL, the system UI will periodically retrieve the message information and display warnings in the UI.

[0043] Step S144: Request data according to the HTTPS / HTTPS protocol interface. After receiving and processing the data, a system response needs to be sent to the requester in a timely manner. In this embodiment of the invention, after creating an HttpServletResponse object, the contenttype and characterencoding of the response information are set. Simultaneously, a PrintWriter object is created to output the response information, and a data Map is created. The response information is encapsulated in the Map using key-value pairs. The Map object is then converted into a JSON string and output using the PrintWriter object.

[0044] This invention converts interface-submitted model data into JSON format, ensuring the data conforms to a standard semantic representation format and improving data interoperability and scalability. By analyzing and comparing standard JSON model data, elements representing the same entity in different models are mapped and associated, establishing links between different data tables, enabling consistent access and querying of data across different tables. Analysis and comparison of the mapping and association data of entity objects detects unique matching between basic information objects and content objects in the model, such as inconsistent attribute values ​​and duplicate associations, improving data consistency and accuracy. Based on the data source credibility rules, conflict detection data is fused to resolve conflicts and contradictions, obtaining consistent data results and improving data credibility and reliability. According to MMS model storage rules, data that does not conform to the model rules is validated to ensure data correctness and rationality, adhering to predefined specifications and requirements. Validated data can be considered MMS model fusion data, possessing consistency, accuracy, and credibility, providing a reliable foundation for further analysis and application.

[0045] Preferably, step S2 includes the following steps: Step S21: Create an object using FtpJSch and call the Connect method through that object; Step S22: After creating the jsch object, use the file server's IP address, username, and port to create a session object using the getSession method of the jsch object; Step S23: The session object identifies the password, and after a strict host key check, the sshSession connection is opened to obtain the SFTP tunnel; Step S24: Based on the parsed temporary file storage path, create a File object on the file server, convert the file object into a file input stream object FileInputStream, and convert the file stream object into a MultipartFile object; Step S25: Use ftpJSch's upload function to store the MultipartFile object in the file server; As an embodiment of the present invention, reference Figure 3 As shown, Figure 1 A detailed flowchart of step S2 is shown below. In this embodiment of the invention, step S2 includes the following steps: Step S21: Create an object using FtpJSch and call the Connect method through that object; The JSCH library used in this invention is a pure Java implementation of the SSH2 protocol library. It provides complete SSH client functionality, including: SFTP (Secure File Transfer Protocol); SCP (Secure Copy Protocol); SSH remote command execution: executing commands on a remote server; port forwarding: local and remote port forwarding; public key authentication: supporting various public key authentication methods. SFTP is a file transfer protocol based on SSH and has the following characteristics: high security: all data transmission is encrypted; cross-platform: supports file transfer between different operating systems; rich functionality: supports file upload, download, deletion, renaming, etc.; strong reliability: supports breakpoint resumption and integrity verification. By creating an object using FtpJSch and using the Connect method to obtain server parameters (IP, port, username, and password) for verification, a remote connection to the file server is established. This solves the problem of data transmission between servers.

[0046] Step S22: After creating the jsch object, use the file server's IP address, username, and port to create a session object using the getSession method of the jsch object; This invention provides the functionality for SSH clients to connect to remote servers using the protocol library methods provided by JSCH. A JSCH object is created, a session object is created based on the file server's IP address, port, and account, a password is passed in, and the password is converted to its corresponding binary format.

[0047] Step S23: The session object identifies the password, and after a strict host key check, the sshSession connection is opened to obtain the SFTP tunnel; This invention provides a cross-server password verification method, employing a Properties object for rigorous host key checks. Upon successful password verification, an SSHSession connection is established using a session object, and an SFTP channel object (Channel) is obtained. The connect method within the Channel is then used to formally establish a connection to the remote server. This method enables secure and convenient cross-server operations, effectively improving the efficiency of server access.

[0048] Step S24: Based on the parsed temporary file storage path, create a File object on the file server, convert the file object into a file input stream object FileInputStream, and convert the file stream object into a MultipartFile object; This invention acquires locally temporary files, creates a File object based on the temporary file's path, converts the File object into a FileInputStream object, and then converts it into a MultipartFile object using the MockMultipartFile method. MultipartFile automatically binds file data from HTTP multipart requests to the object, eliminating the need for manual request body parsing and reducing development complexity. It is compatible with both memory and disk temporary storage, automatically cleans up resources after request processing, and can be integrated with different storage media, adapting to various application scenarios. It enhances development efficiency and stability: combined with SpringMVC configuration optimization and global exception handling, it can build a robust file upload system, supporting advanced features such as large file chunked transmission.

[0049] Step S25: Use ftpJSch's upload function to store the MultipartFile object on the file server. The invention embodiments utilize the upload method of the ftpJSch object to perform cross-server uploads. It effectively parses and processes video, image, and audio files in the MMS information model, and through cross-server connection operations, uploads and saves the files intact to the file server without loss of data, thereby improving file data storage performance and file data security.

[0050] This invention utilizes JSCH, a pure Java implementation of the SSH2 protocol library, which provides complete SSH client functionality. Through the SFTP file transfer protocol, all data transmission between different operating systems is encrypted, and operations such as file upload, download, deletion, and renaming are supported, improving the security and reliability of file data transmission across servers. Temporary files are converted to the final MultipartFile format for transmission because the MultipartFile object simplifies the file upload process; it automatically binds file data from HTTP multipart requests to the object, eliminating the need for manual request body parsing and reducing development complexity. A unified API is provided to easily obtain information such as file content, original name, and size, and it is compatible with both memory and disk temporary storage. Resources are automatically cleaned up after request processing, and it can be integrated with different storage media, adapting to various application scenarios and improving the flexible storage and adaptability of file transmission across servers. Combined with SpringMVC configuration optimization and global exception handling, a robust file upload system can be built, supporting advanced features such as large file chunk transmission, enhancing development efficiency and stability. It also avoids the problem of excessive memory consumption during file storage.

[0051] Preferably, step S3 includes the following steps: Step S31: The user encapsulates the MMS model information and submits the MMS information model through a network protocol interface or UI visualization tool; Step S32: The management system will notify relevant personnel to conduct an initial review of the model via system messages, reviewing the model's signature, text content, video content, image content, and audio content; Step S33: If the model information is not up to standard, the model will be rejected; if the content is up to standard, then select the gateway that needs to be reported through the UI visualization platform. Multiple gateways can be selected to achieve parallel review of multiple gateways. Step S34: The model is transmitted to the gateway in the form of an IO stream through the scheduling system. The gateway will return a corresponding MSGID. The scheduling platform parses the returned information and stores the MSGID corresponding to the unique ID of the model. Step S35: After the gateway reviews the application, there will be two states: review passed or review failed. The status can be actively pushed to the scheduling platform by the gateway or obtained by the scheduling platform periodically. Step S36: Based on the obtained model status JSON string, parse the string and perform a unique match between the MSGID in the status data and the MSGID in the data repository. If the match is successful, modify the model reporting status of the gateway. Step S37: The scheduled task in the scheduling system will periodically obtain the model status of all reported gateways. The status will be used to determine whether the reported gateway status of China Mobile, China Unicom, and China Telecom for the model has been fully entered into the database. If the status has been fully entered into the database, the reported status of the model will be modified. As an embodiment of the present invention, reference Figure 4 As shown, Figure 1 A detailed flowchart of step S3 is provided. In this embodiment of the invention, step S3 includes the following steps: Step S31: The user encapsulates the MMS model information and submits the MMS information model through a network protocol interface or UI visualization tool; This invention, based on MMS model instance data, uses interface protocols and UI visual interfaces, such as HTTP / HTTPS protocol interfaces and platforms, to submit model account data, template title data, and template content data. Through data analysis and parsing, the mandatory and regular nature of the analysis parameters are verified. Finally, the models with correct data are stored in the MySQL tables `video_template` and `video_template_content` for review.

[0052] Step S32: The management system will notify relevant personnel to conduct an initial review of the model via system messages, reviewing the model's signature, text content, video content, image content, and audio content; This invention, based on audit model data, uses a platform UI interface to audit content and signatures. It audits the correctness of signature format and content, and displays the model title and text content to ensure they meet requirements and contain any blocked or sensitive words. Users can click to view images, videos, and audio within the content to check for prohibited content. If prohibited content or non-compliant text content is found, the model must be immediately rejected to improve the efficiency of user model audits and the security and reliability of model content.

[0053] Step S33: If the model information is not up to standard, the model will be rejected; if the content is up to standard, then select the gateway that needs to be reported through the UI visualization platform. Multiple gateways can be selected to achieve parallel review of multiple gateways. This invention is based on adjusting the model review business logic for multi-channel reporting; adjusting the thread distribution of the code structure within the reporting business design to maximize reporting performance and accuracy; and distinguishing between primary and backup reporting channels by comparing the distribution stability and cost of different channels until optimal reporting performance data is achieved.

[0054] Step S34: The model is transmitted to the gateway in the form of an IO stream through the scheduling system. The gateway will return a corresponding MSGID. The scheduling platform parses the returned information and stores the MSGID corresponding to the unique ID of the model. This invention, based on gateway reporting response data processing, uses JSON string format response data and parses the MMS model reporting submission result. The MSGID from the response data is obtained as the model reporting ID, encapsulated in a `video_template_report` object, and the model ID, MSGID, and `state` fields are assigned as basic data for storage. The `state` reporting status enumeration values ​​are: 1. Not reported; 2. Reported successfully; 3. Reporting in progress; 4. Reported failed; 5. Generation failed. This ensures that the model review result can be uniquely matched with the model in the system when returned.

[0055] Step S35: After the gateway reviews the application, there will be two states: review passed or review failed. The status can be actively pushed to the scheduling platform by the gateway or obtained by the scheduling platform periodically. This invention, based on received model status data, obtains model reporting status through two methods: either by requesting the gateway's status acquisition interface via a Scheduled timer to capture the reporting status, or by providing the gateway with a specified status receiving API from the scheduling system, allowing the gateway to proactively push the reporting status. This effectively solves the problem of interfacing with the gateway system and improves the performance of obtaining model status data.

[0056] Step S36: Based on the obtained model status JSON string, parse the string and perform a unique match between the MSGID in the status data and the MSGID in the data repository. If the match is successful, modify the model reporting status of the gateway. Based on the principle of model state data matching, this embodiment of the invention establishes a state uniqueness matching model based on the reported attribute data and the original basic data of the model; it obtains the MSGID from the data by using JSON conversion, performs unique matching by associating structured data with database tables, and modifies the returned state.

[0057] Step S37: The scheduled task in the scheduling system will periodically obtain the model status of all reported gateways. The status will be used to determine whether the reported gateway status of China Mobile, China Unicom, and China Telecom for the model has been fully entered into the database. If the status has been fully entered into the database, the reported status of the model will be modified. This invention, based on model reporting results data, uses an integrated status matching algorithm to index and integrate the returned model reporting status; defines optimization objectives and constraints, such as the status attributes of each channel of China Mobile, China Unicom, and China Telecom, and the distinction between primary and backup channels; and gradually integrates channels that have successfully reported and those that have failed to report by gradually traversing and comparing the status process to obtain the final reporting status of China Mobile, China Unicom, and China Telecom.

[0058] This invention submits MMS models to the platform via an HTTP / HTTPS protocol interface, effectively overcoming the limitations of user-submitted submissions through a UI visual interface and enhancing the scalability and flexibility of the customer integration system. The platform's initial review verifies the model content information and its legality, improving data security and the success rate of model registration. To further improve the success rate of model registration with operators, the research employs multi-channel asynchronous reporting and backup channels as reserve resources. The primary and backup channels are differentiated based on the gateway's stability and cost-effectiveness. Channels with higher stability and cost-effectiveness are used as the primary channel for registration, while the remaining channels serve as backup channels. This effectively addresses the scalability and compatibility of an information model registration gateway, improving the success rate of model registration.

[0059] Preferably, step S37 includes the following steps: Step S371: Obtain data in the model table with status 3 that is in the reporting stage; This embodiment of the invention uses conditional querying, with the index condition being state=3, to query data rows in the video_template model table whose reporting status is "in progress". The retrieved data from the reporting process is then iterated through.

[0060] Step S372: Obtain the reporting status data of each model, including the review status data returned by the gateway, the corresponding unique matching model ID data, and the bound channel ID data; In this embodiment of the invention, the reporting status data in the video_template_report table is indexed by the model ID. The reporting status is converted into a string separated by English commas by the grouping GROUP_CONCAT concatenation function. It is then determined whether the string contains the status 3 reported. If it contains the status reported, then this model reporting status has not been fully returned and is not processed. Otherwise, the status is integrated.

[0061] Step S373: Perform channel type status matching analysis based on the channel operator type of each reported status data to obtain the reported status data of the three major operators; This invention embodiment creates channel ID storage strings for the three major telecom operators (China Mobile, China Telecom, and China Unicom), iterates through the reporting status set data, and stores the channel IDs and reporting statuses of the three operators through the reporting status field "state". Finally, it stores these in a Map in the format of key-value pairs (KEY, VALUE).

[0062] Step S374: Based on the state Map set encapsulated by the operators, define the states of the three major operators as boolean type, and determine the boolean value by matching the state data; This embodiment of the invention retrieves the status strings of China Mobile, China Unicom, and China Telecom from a Map collection. It then determines whether the status string contains the failure identifier 2. If it does, the operator's status is 2 (failure), and the defined boolean value is false; otherwise, it is 1 (success), and the defined boolean value is true. Finally, the success or failure of the registration is determined based on the boolean value of the registration status of the three major operators.

[0063] This invention performs topology optimization based on multi-channel compatibility during the MMS information model instance data review operation, and optimizes backup channel reporting. It binds a system-unique model ID to the operator gateway that requires user ID submission, and distinguishes between primary and backup channels based on gateway stability and cost-effectiveness. Channels with higher stability and cost-effectiveness are reported as primary channels, while the remaining channels are used as backup channels. This effectively addresses the scalability and compatibility issues of an information model reporting gateway, improving the success rate of model reporting.

[0064] As an embodiment of the present invention, reference Figure 5 As shown, Figure 1 A detailed flowchart of step S4 is shown below. In this embodiment of the invention, step S4 includes the following steps: Step S41: Based on the single MMS model reporting multi-gateway scheduling, it is necessary to wait for the review status of all gateway models to return and integrate the model status before the user can use the model ID to send the submission number; Step S42: Discuss the issue of reduced service delivery rate in the above steps. Instead of integrating multiple gateway states into a model state, the state returned by each gateway will be encapsulated and stored separately. Step S43: The scheduling system scans the returned gateway status data, uniquely matches the stored status data with the model ID, and then displays the model's reporting status to the user. Step S44: Users can see the reporting status of the model immediately through the UI visualization page, so they no longer have to wait for all gateways to return before they can submit the number. They can send the SMS as soon as a single operator's gateway returns. Preferably, step S4 includes the following steps: Step S41: Based on the single MMS model reporting multi-gateway scheduling, it is necessary to wait for the review status of all gateway models to return and integrate the model status before the user can use the model ID to send the submission number; In this embodiment of the invention, when the scheduling system submits an MMS model report, the corresponding relationship is that a single model corresponds to multiple channels for reporting. At this time, the scheduling system needs to collect and integrate the review status of all channels to generate a complete reporting status. Users can only submit the number to send based on whether the status is successful or failed. To address this issue, the summarization of model status needs to be optimized.

[0065] Step S42: Discuss the issue of reduced service delivery rate in the above steps. Instead of integrating multiple gateway states into a model state, the state returned by each gateway will be encapsulated and stored separately. This invention, based on the channel reporting model review status data, no longer uses the status integration timed task logic in the scheduling system, and directly saves the parsed JSON-formatted reporting status to the database.

[0066] Step S43: The scheduling system scans the returned gateway status data, uniquely matches the stored status data with the model ID, and then displays the model's reporting status to the user. This invention, based on model reporting status data, uses a scheduled task in the scheduling system to obtain the reported status of channels that have already been returned. If China Mobile, China Unicom, or China Telecom have returned successful reporting statuses, the status of the three major operators in the model is directly modified. This eliminates the need to wait for all channels to return statuses before integrating and modifying the model status, thus improving the efficiency of model reporting and reducing the cost of waiting for channel reporting time for users.

[0067] Step S44: Users can see the reporting status of the model immediately through the UI visualization page, so they no longer have to wait for all gateways to return before they can submit the number. They can send the SMS as soon as a single operator's gateway returns. In this embodiment of the invention, after the model status is successfully reported, the system matches and sends an SMS message according to the returned successful channel. After the user submits the number, the sending system performs channel matching and submits the number to the channel where the model was successfully reported.

[0068] This invention coordinates the MMS model reporting status, storing the gateway reporting status data after independent parsing and processing, effectively solving the latency issue of model reporting status integration. Simultaneously, a scheduled task periodically scans successful reporting statuses to obtain the corresponding channel ID, thereby encapsulating the model status and channel ID and updating the model reporting status, significantly improving the efficiency of model reporting. Once a user receives a successful model reporting status, they can submit their mobile phone number. The system matches successfully reported channels based on the mobile phone number's carrier attribute, eliminating the need to wait for other channels to return status, thus improving model reporting performance and user experience.

[0069] As an embodiment of the present invention, reference Figure 6 As shown, Figure 1 A detailed flowchart of step S5 is provided. In this embodiment of the invention, step S5 includes the following steps: Step S51: After the user submits the mobile phone number through the model ID, it is sent to the corresponding gateway that has passed the filing and review. After the gateway sends the mobile phone number, it will return the status of each mobile phone number to the scheduling system. At this time, the scheduling system needs an API with HTTP / HTTPS protocol to receive the status. Step S52: The status includes successful and failed transmission. After receiving the status through the interface, the status object is encapsulated by decryption or direct parsing of the JSON string. Step S53: Save the parsed state object to the cache middleware Redis, then encapsulate the response data and return it to the gateway; Step S54: The scheduling system's timed service will periodically retrieve data from the storage status KEY, read the data, and delete it to prevent the cache memory from continuously increasing; Step S55: Using the MSGID or other unique identifier ID in the status data, query the MSGID or other unique identifier ID returned when submitted to the gateway for matching. After matching the original SMS, modify the state field of the original SMS to indicate success or failure.

[0070] Step S56: Then, by obtaining the original SMS, encapsulate the user ID, state, mobile number, batch number, description, and report time from the original SMS into a JSON string and save it to the cache middleware Redis.

[0071] Step S57: The scheduled task in the scheduling system will periodically obtain the status data from the status KEY + user ID, read the status receiving API bound to each user, and push the status receipt data sent by the user to you.

[0072] Preferably, step S5 includes the following steps: Step S51: After the user submits the mobile phone number through the model ID, it is sent to the corresponding gateway that has passed the filing and review. After the gateway sends the mobile phone number, it will return the status of each mobile phone number to the scheduling system. At this time, the scheduling system needs an API with HTTP / HTTPS protocol to receive the status. In this embodiment of the invention, after the submitted mobile phone number is sent to the gateway, the gateway determines whether the MMS message delivery to the mobile phone number was successful or failed based on the status of the received MMS message. This receipt status reflects the sending status of the message and is also used as a standard for user billing. The sending scheduling system obtains receipt data from the gateway based on a scheduled task or by providing a dedicated receipt receiving API.

[0073] Step S52: The status includes successful and failed transmission. After receiving the status through the interface, the status object is encapsulated by decryption or direct parsing of the JSON string. This invention describes the process of parsing and encapsulating receipt data into object information for storage. Only receipt data pushed by the gateway is transmitted as a plaintext JSON string or encrypted using a corresponding encryption method. After the scheduling system receives the receipt information, it decrypts and parses the JSON string, creates a status receiving object, and then uses the JSONobject object to convert the JSON string into a status receiving object. This effectively solves the problem of reading and processing JSON format data.

[0074] Step S53: Save the parsed state object to the cache middleware Redis, then encapsulate the response data and return it to the gateway; This invention stores state object data to improve state reception performance and accelerate the response rate to the gateway. If the state reception processing time is too long, it can lead to congestion in the gateway's state push, resulting in slow state pushes. Therefore, after the scheduling system parses and encapsulates the state object, it converts the state object into a JSON format string and directly stores it in the cache middleware, awaiting processing by a scheduled task. After being stored in the middleware, the response data is immediately encapsulated and returned to the gateway.

[0075] Step S54: The scheduling system's timed service will periodically retrieve data from the storage status KEY, read the data, and delete it to prevent the cache memory from continuously increasing; This invention embodiment is based on a scheduled task of a scheduling system. The state storage object is read from the Redis middleware through a scheduled task, and then the state data in Redis is deleted. This effectively improves the availability of Redis and prevents Redis from consuming too much memory.

[0076] Step S55: Using the MSGID or other unique identifier ID in the status data, query the MSGID or other unique identifier ID returned when submitted to the gateway for matching. After matching the original SMS, modify the state field of the original SMS to indicate success or failure.

[0077] In this embodiment of the invention, based on the data in the status object, the MSGID in the status data is used as a unique identifier to read the original SMS information stored in the middleware Redis. The original SMS and the MSGID in the status data are uniquely matched, so the success or failure in the status represents the status of the original SMS. Based on the judgment of success or failure, the state field is encapsulated as 10 or 11, and the state field and the current time of obtaining the status are used as the receipt time to modify the row data in the database where the original SMS is located.

[0078] Step S56: Then, by obtaining the original SMS, encapsulate the user ID, state, mobile number, batch number, description, and report time from the original SMS into a JSON string and save it to the cache middleware Redis.

[0079] In this embodiment of the invention, after obtaining the status data from the original SMS message, once the original SMS message receipt is received and successfully modified, a receipt push object needs to be encapsulated. The data of this object will be pushed to the user as status matching data on the user's end. After encapsulating the fields in the original SMS message into a JSON string, the string is saved in a queue with the user ID as the key, pending status push.

[0080] Step S57: The scheduled task in the scheduling system will periodically obtain the status data from the status KEY + user ID, read the status receiving API bound to each user, and push the status receipt data sent by the user to you.

[0081] In this embodiment of the invention, the status receipt data is stored in the cache middleware, and the scheduling system periodically retrieves the data by a scheduled task, requests the receipt receiving API bound to the user's account, and pushes the status receipt data to the user via a POST request.

[0082] This invention improves receiving and status push processing performance by asynchronously processing status data through a receipt status acquisition mechanism. It employs a multi-API gateway status reception method, load balancing across multiple servers to alleviate the pressure on the status processing server. By parsing JSON-formatted string status data, it converts it into an easily readable indented format and provides advanced features such as syntax highlighting and error checking. Directly manipulating the data repository after receiving status data via multi-channel concurrent pushes leads to slow database update performance, impacting gateway status push efficiency and user status retrieval efficiency. Asynchronous storage of receipt information and reading and matching of original SMS messages significantly improves the processing capacity and response performance of the status receiving and processing interface, effectively alleviating the pressure of direct database operations and concurrency-induced blocking.

[0083] Preferably, step S55 includes the following steps: Step S551: Obtain the unique matching identifier MSGID field through status data parsing; In this embodiment of the invention, after obtaining status data using the status receiving API, data is read from the status object, and the MSGID field is obtained. This field is the field that the gateway responds to after the scheduling system submits an SMS message. When the gateway sends an SMS message successfully or unsuccessfully, and pushes back a status receipt to the scheduling system, this field exists in the status data and needs to be used to match it with the original SMS message.

[0084] Step S552: Retrieve the original SMS data from the cache using MSGID; In this embodiment of the invention, the original SMS message is stored in the cache middleware in key-value pair format, with MSGID+mobile as the key and the original SMS message data as the value. After the original SMS message data is directly obtained through MSGID+mobile in the status data, the original data is encapsulated into an object, and the information content of the original SMS message object can be modified.

[0085] Step S553: ​​After matching the original SMS message, modify the state field of the original SMS message; In this embodiment of the invention, the original SMS message is updated based on the value of the determined state field. The success or failure status in the receipt is determined according to the corresponding rules of the gateway. These rules are defined by the gateway, and the corresponding values ​​are different for each gateway. However, the final parsed and matched state field will show 10 for success and 11 for failure. The state and receipt time of the original SMS message are then modified using the primary key guid field of the original SMS message, thus completing the process.

[0086] This invention addresses the pressure on the database caused by directly modifying the database upon receiving status updates by asynchronously processing gateway receipts. Load balancing scheduling of the receiving API improves the speed at which the gateway pushes and the scheduling system receives status data. Matching the original SMS content using a caching middleware based on the unique identifier in the status data reduces queries to large MySQL tables, decreases the number of direct database operations, and maintains database stability. Using status storage and asynchronous processing for storage and push improves the efficiency of user status reception and prevents delays caused by slow pushes. Furthermore, parallel computing significantly reduces computation time and improves computational efficiency.

[0087] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0088] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A file I / O stream-based MMS multi-channel information model transmission scheduling system, characterized in that, The system includes the following components: Step S1: Transmitting the MMS information model based on file I / O streams is more in line with user needs than operating on the UI page. By developing a specified HTTP / HTTPS protocol interface, users can seamlessly connect with the system and transmit the MMS information model material in Base64 code as a stream through the UI visualization page on the user's end. Step S2: SFTP is a secure file transfer protocol based on SSH. It provides a secure network encryption algorithm during file transfer. By remotely connecting to the server via SFTP, and verifying the server IP, port, account and password via SSH, the media files are directly stored in the specified path of the corresponding remote server in the form of IO streams. Step S3: Based on the MMS information model instance data review operation, perform topology optimization based on multi-channel compatibility and optimize the backup channel reporting to obtain the optimized model reporting success rate; After the MMS information model is submitted by the user through the network protocol interface or UI visualization tool according to the user's unique ID, the system will first conduct a preliminary review of its model content. After the preliminary review is passed, the system will bind the model ID to the operator gateway that the user ID needs to submit, and distinguish between the main channel and the backup channel according to the stability and cost-effectiveness of the gateway. The channel with higher stability and cost-effectiveness will be reported as the main channel, and the remaining channels will be reported as backup channels; Step S4: According to step S3, the same MMS information model ID is reported to multiple gateways at the same time, which effectively improves the success rate of model reporting. At present, the system's sending mechanism depends on the status of multiple gateways. Users can only send the model ID and number binding after all submitted gateway reporting statuses have returned. Since there is an inconsistency in the return status time of multiple gateway reporting, the MMS model reporting scheduling system needs to be optimized. Step S5: Based on the process of receiving or actively acquiring the MMS sending status returned by the gateway, and performing parallel high-performance receiving efficiency analysis, the status is acquired through multi-channel concurrent push and then the data storage is operated. The status data is stored in an intermediate cache. After the gateway status data is pushed and acquired, it is first stored in the intermediate storage medium. At the same time, the gateway response is immediately returned, and a scheduled task is started. The status data stored in the intermediate medium is converted into a JSON string through a JSONObject object and matched one-to-one with the GUID or MSGID of the original data in the system. After matching the original SMS, the status of the original SMS is modified, and the user status is encapsulated according to the system status format and stored in the middleware for scheduled push to the customer.

2. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: Receive user-submitted data via HTTPS / HTTPS protocol interface, verify whether the account and password are correct, whether the signature format is correct and whether it has been reported, and whether the model content is required. Step S12: Encapsulate the MMS model object, assign values ​​to the object fields, parse the data, and obtain the model title, model text content, and video, audio, and image information of the model. Step S13: Convert the Base64 code of the file content in the model into a temporary file, remotely log in to the file server via the SFTP protocol, generate a unique file path, transfer the temporary file to the file server for storage via the IO stream method, and close the SFTP connection. Step S14: Save the encapsulated model object and model content object to the storage database, and notify the staff to conduct the initial review in the form of a message notification; Step S15: Encapsulate the interface response data and send it to the user in JSON format.

3. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 2, characterized in that, Step S14 includes the following steps: Step S141: Encapsulate a video_template object based on the basic data submitted by the user; Step S142: Encapsulate the video_template_content object according to the type of the saved video_template object and content to obtain entity mapping association data; Step S143: The message management data is encapsulated and stored. The system will notify the message management module to notify the staff for preliminary review. Step S144: Request data according to the HTTPS / HTTPS protocol interface, receive and process the data, and then send a system response to the requester.

4. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 1, characterized in that, Step S2 includes the following steps: Step S21: Create an object using FtpJSch and call the Connect method through that object; Step S22: After creating the jsch object, use the file server's IP address, username, and port to create a session object using the getSession method of the jsch object; Step S23: The session object identifies the password, and after a strict host key check, the sshSession connection is opened to obtain the SFTP tunnel; Step S24: Based on the parsed temporary file storage path, create a File object on the file server, convert the file object into a file input stream object FileInputStream, and convert the file stream object into a MultipartFile object; Step S25: Use ftpJSch's upload function to store the MultipartFile object in the file server.

5. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 1, characterized in that, Step S3 includes the following steps: Step S31: The user encapsulates the MMS model information and submits the MMS information model through a network protocol interface or UI visualization tool; Step S32: The management system will notify relevant personnel to conduct an initial review of the model via system messages, reviewing the model's signature, text content, video content, image content, and audio content; Step S33: If the model information is not up to standard, the model will be rejected; if the content is up to standard, then select the gateway to be reported through the UI visualization platform, which supports selecting multiple gateways. Step S34: The model is transmitted to the gateway in the form of an IO stream through the scheduling system. The gateway will return a corresponding MSGID. The scheduling platform parses the returned information and stores the MSGID corresponding to the unique ID of the model. Step S35: After the gateway reviews the application, there will be two states: review passed or review failed. The status can be actively pushed to the scheduling platform by the gateway or obtained by the scheduling platform periodically. Step S36: Based on the obtained model status JSON string, parse the string and perform a unique match between the MSGID in the status data and the MSGID in the data repository. If the match is successful, modify the model reporting status of the gateway. Step S37: The scheduled task in the scheduling system will periodically obtain the model status of all reported gateways. Based on the status, it will determine whether the reported gateway status of China Mobile, China Unicom, and China Telecom for the model has been fully entered into the database. If the status has been fully entered into the database, the reported status of the model will be modified.

6. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 5, characterized in that, Step S37 includes the following steps: Step S371: Obtain data in the model table with status 3 that is in the reporting stage; Step S372: Obtain the reporting status data of each model, including the review status data returned by the gateway, the corresponding unique matching model ID data, and the bound channel ID data; Step S373: Perform channel type status matching analysis based on the channel operator type of each reported status data to obtain the reported status data of the three major operators; Step S374: Based on the state Map set encapsulated by the operators, define the states of the three major operators as boolean type, and determine the boolean value by matching the state data.

7. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 1, characterized in that, Step S4 includes the following steps: Step S41: Based on the single MMS model reporting multi-gateway scheduling, it is necessary to wait for the review status of all gateway models to return and integrate the model status before the user can use the model ID to send the submission number; Step S42: Discuss the issue of reduced service delivery rate in the above steps. Instead of integrating multiple gateway states into a model state, the state returned by each gateway will be encapsulated and stored separately. Step S43: The scheduling system scans the returned gateway status data, uniquely matches the stored status data with the model ID, and then displays the model's reporting status to the user. Step S44: Users can see the reporting status of the model immediately through the UI visualization page, so they no longer have to wait for all gateways to return before they can submit the number. They can send the SMS as soon as a gateway from a single operator returns.

8. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 1, characterized in that, Step S5 includes the following steps: Step S51: After the user submits the mobile phone number through the model ID, it is sent to the corresponding gateway that has passed the filing and review. After the gateway sends the mobile phone number, it will return the status of each mobile phone number to the scheduling system. At this time, the scheduling system needs an API with HTTP / HTTPS protocol to receive the status. Step S52: The status includes successful and failed transmission. After receiving the status through the interface, the status object is encapsulated by decryption or direct parsing of the JSON string. Step S53: Save the parsed state object to the cache middleware Redis, then encapsulate the response data and return it to the gateway; Step S54: The scheduling system's timed service will periodically retrieve the data from the storage status KEY, read the data, and delete it; Step S55: Using the MSGID or other unique identifier ID in the status data, query the MSGID or other unique identifier ID returned when submitted to the gateway for matching. After matching the original SMS, modify the state field of the original SMS to indicate success or failure. Step S56: Then, by obtaining the original SMS, encapsulate the user ID, state, mobile number, batch number, description, and report time from the original SMS into a JSON string and save it to the cache middleware Redis; Step S57: The scheduled task in the scheduling system will periodically obtain the status data from the status KEY + user ID, read the status receiving API bound to each user, and push the status receipt data sent by the user to you.

9. The MMS multi-channel information model transmission scheduling system based on file I / O streams according to claim 8, characterized in that, Step S55 Includes the following steps: Step S551: Obtain the unique matching identifier MSGID field through status data parsing; Step S552: Retrieve the original SMS data from the cache using MSGID; Step S553: ​​After matching the original SMS message, modify the state field of the original SMS message.

Images