A short message status automatic correction and RPA bottom system based on multi-source data checking

Abstract

The present application relates to a kind of short message state automatic correction and RPA bottom system based on multi-source data checking, it is related to data processing technical field, including by producer process periodic polling sending platform;The present application is by constructing producer, consumer, RPA bottom, verifier and adaptive scheduling of quota, realize the automatic correction of short message state and system high availability operation, producer is found by multi-source data cross comparison inconsistent state and generates correction task and enters queue, consumer module is by state pre-inspection and error code standardization after API interface is completed state automatic correction, when API continuous failure, RPA bottom module is by browser automation and identification Captcha takeover write back operation, ensure the continuity of system in interface invalid scene, by date grouping batch receipt query is independently secondly confirmed to the corrected state, form the system architecture of discovery, correction, bottom, verification.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an automatic SMS status correction and RPA fallback system based on multi-source data verification. Background Technology

[0002] Bulk SMS messages are a crucial channel for corporate marketing notifications, typically distributed centrally through commercial SMS sending platforms. A single marketing campaign often involves sending thousands to hundreds of thousands of SMS messages. Accurate verification and proactive correction of their final delivery status are core operational management requirements. Currently, the following are the mainstream technical solutions in the field of SMS delivery status verification and correction: single-source query method using the sending platform, one-way verification method based on cloud-based SMS service receipts, manual inspection method, asynchronous sending system based on message queues, and single-platform operation solution based on RPA. In summary, the existing technical solutions have the following shortcomings: The verification data source is singular: existing solutions typically rely solely on data from the sending platform or cloud service provider, failing to achieve cross-validation of status from both sides. When the sending platform and the operator's feedback data are inconsistent, the system lacks the ability to automatically identify inconsistent records, posing a risk of single point of false alarm.

[0003] Lack of a status correction mechanism: Even if a status mislabeling is detected on the sending platform through cloud receipts, the existing solution lacks an automated status write-back and correction loop. Status synchronization relies on manually exporting comparison results and then manually entering them into the sending platform, which is time-consuming and error-prone.

[0004] Lack of a dual-path disaster recovery mechanism for API and RPA collaboration: In existing solutions, the API interface and RPA methods are deployed independently, failing to form a mutually supportive collaborative architecture. When API write-back fails due to anomalies such as IP blocking, CAPTCHA interception, or interface rate limiting, the system cannot automatically switch to the RPA path to complete the state correction, lacking proactive detection and automatic recovery capabilities.

[0005] Quota management is inefficient: the daily call quota of the platform interface is consumed by disorderly competition among different operations, and there is a lack of dynamic scheduling mechanism based on quota balance. During peak periods, quota exhaustion is frequently triggered, causing critical correction tasks to fail to execute.

[0006] To address the aforementioned technical shortcomings, a solution is proposed. Summary of the Invention

[0007] The present invention adopts the following technical solution: an automatic SMS status correction and RPA fallback system based on multi-source data verification, including a data capture and task queuing module, which is used to automatically complete the capture of SMS records, status comparison and task queuing by periodically polling the sending platform through the producer process; The status correction and write-back module is used to retrieve tasks to be processed from the task queue through the consumer process, and write the status confirmed by the receipt interface back to the sending platform through the API interface to complete the status correction. The RPA fallback write-back module is used to automatically trigger the RPA fallback mechanism when the number of consecutive write-back operations fails due to an API interface exception reaches a preset threshold, and completes the status write-back by simulating manual operation. The status verification and final status confirmation module is used to independently confirm the status of tasks whose status has been updated through the verifier process. The tasks to be verified are grouped by submission date, and a mapping table between record ID and receipt status is built in memory for batch comparison. If the receipt status changes during the waiting period, the target status field is automatically corrected before writing is performed. The quota adaptive scheduling module is used to monitor the remaining quota for interface calls in real time and dynamically adjust the scanning strategy, polling interval, priority filtering conditions, and batch verification frequency according to the quota remaining level.

[0008] Furthermore, the platform is used to periodically poll the producer process to automatically capture SMS records, compare their statuses, and enqueue tasks. The specific process is as follows: Upon startup, the producer process automatically logs in to the platform via the robotic process automation module. It calls an optical character recognition (OCR) library to automatically recognize the CAPTCHA image on the login page, submitting the recognition result along with the account credentials to the login interface to obtain session credentials. When a session expires, it automatically triggers a re-login, achieving unattended session maintenance and automatic renewal. The correction task is written to the task table using an ignored insertion method, and idempotency is guaranteed by a unique constraint. The producer process calls the sending platform record query interface to retrieve SMS sending records within a specified time window in a paginated manner, and writes the original records into the original record table in a full streaming manner. For each record retrieved from the sending platform, the system calls the third-party SMS service provider's receipt interface, which is independent of the sending platform, to query the corresponding carrier-level delivery status of the record. The system performs multi-source cross-comparison, generates correction tasks for records with inconsistent statuses, and writes them into the task table. Producer scanning strategy: Scan the daily records every 5 minutes during working hours, force a 3-day backtracking deep scan every 30 cycles, and perform a full deep scan during off-peak hours.

[0009] Furthermore, the consumer process retrieves tasks from the task queue and writes the confirmed status from the receipt interface back to the sending platform via the API interface, thus completing the status correction. The specific process is as follows: The consumer process executes statements to lock and retrieve a task from the task table in descending order of submission time, supporting non-blocking concurrent execution of multiple consumer processes without duplicate task processing. When the backlog of tasks exceeds a preset threshold, the consumer process automatically enters the high-speed mode, compresses the task polling interval from the normal value to the high-speed value, accelerates the digestion of backlog tasks, and automatically exits the high-speed mode after the backlog returns to normal. The status correction write-back module adopts a LIFO strategy, prioritizing the processing of the latest tasks in descending order of task submission time to ensure that real-time SMS status updates are visible first. Before performing the write-back operation, first call the platform status query interface to confirm the current record status. If the platform status is already in the final state, skip the write-back operation directly. When writing back error codes, if the length of the error code returned by the cloud receipt interface exceeds the field length limit of the sending platform, it will be uniformly replaced with the SMS industry's common undelivered code before writing.

[0010] Furthermore, when the number of consecutive write-back operations fails due to API anomalies reaches a preset threshold, an automated fallback mechanism is automatically triggered in the robotic process to simulate manual operation and complete the status write-back. The specific process is as follows: When the number of consecutive failed API write-back operations reaches a preset threshold, the controlled browser is automatically navigated to the sending platform login page, the graphic verification code recognition module is called to recognize the graphic verification code and submit the login form. After successful login, the session credentials are extracted and written to the shared cache file. The browser automatically navigates to the platform's record editing page, fills in the final status and error code fields one by one, and simulates the submission operation to write back the completed status. After the Robotic Process Automation (RPA) fallback is completed, an attempt is made to re-verify the availability of the Application Programming Interface (API). If the API returns to normal, the RPA mode is exited, and subsequent tasks return to the API processing path, achieving a smooth switch between RPA and API.

[0011] Furthermore, the status verification and final status confirmation module also includes a timeout failure identification submodule: The Timeout Non-Delivery Identification Submodule triggers the non-delivery judgment logic when the difference between the task creation time and the current time exceeds the 72-hour receipt window period and the task status is still "written back but not confirmed". If the number of receipts is less than or equal to the preset threshold and the status remains unchanged, it is determined to be a normal delay and marked as the first delay code. If the 72-hour response window has expired, it is determined to be completely undelivered, the target status is updated to undelivered, and the task is marked as completed.

[0012] Furthermore, it is used to monitor the remaining API call quota in real time, and dynamically adjust the scanning strategy, polling interval, priority filtering conditions, and batch verification frequency according to the quota remaining level. The specific process is as follows: The quota adaptive scheduling module divides the quota surplus into several levels and executes differentiated scheduling strategies according to the level: When the quota is sufficient, the data capture and task queuing module, the status correction and write-back module, and the status verification and final state confirmation module all work at the highest frequency. When the quota is appropriate, each module maintains a normal frequency; When quotas are tight, the data capture and task queuing module is forcibly downgraded to only scan the records of the day, the status correction and write-back module only processes high-priority tasks, and the status verification and final status confirmation module skips the second confirmation. When the quota is exhausted, it will automatically switch to the backup account to continue processing high-priority tasks to prevent cascading exhaustion.

[0013] Furthermore, it also includes a fuse protection module: The fuse protection module includes a page-turning fuse, a retry fuse, and a task fuse; The page-turning circuit breaker is used to limit the maximum number of pages scanned per day by the data capture and task queuing module. If the limit is exceeded, scanning will stop immediately and an alarm will be triggered. The retry circuit breaker is used to limit the maximum number of retries for a single record retrieval operation by the data capture and task queuing module. If the maximum number of retries is exceeded, the module will be forced to exit. The task circuit breaker is used to limit the maximum number of failed verifications of a single task by the status verification and final status confirmation module. Once the limit is exceeded, the task is forcibly marked as a failure.

[0014] Furthermore, it also includes a dual-track audit and full reconciliation module, which is used to ensure the consistency of all data by using a real-time track and an audit track in parallel. The real-time track is a collaborative effort between the producer process, the consumer process, and the checker process, responsible for continuously monitoring the records of the day and recent times. The audit track performs a full reconciliation of historical data through monthly audit tools. When missing records are found in the database, intelligent filling is automatically performed, and batch filling is only performed during the low quota consumption period in the early morning. The audit track uses an independent backup account and a conservative frequency strategy to ensure that audit operations do not consume the main account quota or interfere with the normal operation of the real-time track. Trigger daily email reports via scheduled tasks and send comprehensive reports containing daily processing progress, percentage of each status, and historical details in a set format. The state correction write-back module also includes a backlog task fast processing mode: when the submission time of the current processing task is detected to exceed the preset time, the consumer process automatically enters the fast mode, and the polling interval is compressed from 3 seconds to 0.5 seconds to accelerate the digestion of backlog tasks. After returning to normal, it automatically exits.

[0015] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: This system, based on multi-source data verification, enables automatic SMS status correction and RPA fallback. By constructing a producer, consumer, RPA fallback, verifier, and quota adaptive scheduling mechanism, it achieves automatic SMS status correction and high system availability. The producer detects inconsistencies through cross-referencing of multi-source data and generates correction tasks, which are then queued. The consumer performs automatic status correction via API after status pre-checking and error code standardization. When the API fails consecutively, the RPA fallback module takes over the write-back operation through browser automation and CAPTCHA recognition, ensuring system continuity even in API failure scenarios. Batch receipt queries grouped by date independently reconfirm the corrected status, forming a system architecture of discovery, correction, fallback, and verification, effectively eliminating single-source data... To mitigate errors, an independent archiving process is used to migrate overdue historical tasks from the active table to the archive table using a small-batch, step-by-step transaction mode. This ensures that the data volume in the main task table remains within the incremental scale of the preset time window, preventing the linear degradation of database performance caused by continuous data accumulation. A dual historical data protection system is built through a full-scale deep scan mechanism during off-peak hours in the early morning and an independent reconciliation mechanism using monthly audit tools. This system systematically discovers and corrects historical records, achieving full lifecycle data governance from real-time monitoring to historical closed-loop. The quota adaptive scheduling module dynamically adjusts the producer scanning strategy, consumer polling interval and priority filtering conditions, and checker batch checking frequency based on the remaining quota for the day, ensuring that limited quotas are reasonably allocated under different load conditions. Attached Figure Description

[0016] Figure 1 A schematic diagram of the overall system flow structure of the present invention is shown; Figure 2 This diagram illustrates the overall structure of the fallback execution process of the present invention. Figure 3 A schematic diagram of the quota adaptive scheduling process structure of the present invention is shown. Detailed Implementation

[0017] 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.

[0018] Example: like Figure 1-3 As shown, an automatic SMS status correction and RPA fallback system based on multi-source data verification includes a data capture and task queuing module, which is used to automatically capture SMS records, compare statuses, and queue tasks by periodically polling the sending platform through the producer process. The status correction and write-back module is used to retrieve tasks to be processed from the task queue through the consumer process, and write the status confirmed by the receipt interface back to the sending platform through the API interface to complete the status correction. The RPA fallback write-back module is used to automatically trigger the RPA fallback mechanism when the number of consecutive write-back operations fails due to an API interface exception reaches a preset threshold, and completes the status write-back by simulating manual operation. The status verification and final status confirmation module is used to independently confirm the status of tasks whose status has been updated through the verifier process. The tasks to be verified are grouped by submission date, and a mapping table between record ID and receipt status is built in memory for batch comparison. If the receipt status changes during the waiting period, the target status field is automatically corrected before writing is performed. The quota adaptive scheduling module is used to monitor the remaining quota for interface calls in real time and dynamically adjust the scanning strategy, polling interval, priority filtering conditions, and batch verification frequency according to the quota remaining level.

[0019] This is used to periodically poll the platform via a producer process, automatically capturing SMS records, comparing their status, and queuing tasks. The specific process is as follows: Upon startup, the producer process automatically logs in to the platform via the robotic process automation module. It calls an optical character recognition (OCR) library to automatically recognize the CAPTCHA image on the login page, submitting the recognition result along with the account credentials to the login interface to obtain session credentials. When a session expires, it automatically triggers a re-login, achieving unattended session maintenance and automatic renewal. The correction task is written to the task table using an ignored insertion method, and idempotency is guaranteed by a unique constraint. The producer process calls the sending platform record query interface to retrieve SMS sending records within a specified time window in a paginated manner, and writes the original records into the original record table in a full streaming manner. For each record retrieved from the sending platform, the system calls the third-party SMS service provider's receipt interface, which is independent of the sending platform, to query the corresponding carrier-level delivery status of the record. The system performs multi-source cross-comparison, generates correction tasks for records with inconsistent statuses, and writes them into the task table. Producer scanning strategy: Scan the daily records every 5 minutes during working hours, force a 3-day backtracking deep scan every 30 cycles, and perform a full deep scan during off-peak hours.

[0020] The consumer process retrieves tasks from the task queue and writes the final state confirmed by the receipt interface back to the sending platform via the API interface, thus completing the state correction. The specific process is as follows: The consumer process executes statements to lock and retrieve a task from the task table in descending order of submission time, supporting non-blocking concurrent execution of multiple consumer processes without duplicate task processing. When the backlog of tasks exceeds a preset threshold, the consumer process automatically enters the high-speed mode, compresses the task polling interval from the normal value to the high-speed value, accelerates the digestion of backlog tasks, and automatically exits the high-speed mode after the backlog returns to normal. The status correction write-back module adopts a LIFO strategy, prioritizing the processing of the latest tasks in descending order of task submission time to ensure that real-time SMS status updates are visible first. Before performing the write-back operation, first call the platform status query interface to confirm the current record status. If the platform status is already in the final state, skip the write-back operation directly. When writing back error codes, if the length of the error code returned by the cloud receipt interface exceeds the field length limit of the sending platform, it will be uniformly replaced with the SMS industry's common undelivered code before writing.

[0021] This mechanism is used to automatically trigger a fallback mechanism in the robotic process when the number of consecutive write-back operations fails due to an API exception reaches a preset threshold. It simulates manual operation to complete the status write-back, as follows: When the number of consecutive failed API write-back operations reaches a preset threshold, the controlled browser is automatically navigated to the sending platform login page, the graphic verification code recognition module is called to recognize the graphic verification code and submit the login form. After successful login, the session credentials are extracted and written to the shared cache file. The browser automatically navigates to the platform's record editing page, fills in the final status and error code fields one by one, and simulates the submission operation to write back the completed status. After the Robotic Process Automation (RPA) fallback is completed, an attempt is made to re-verify the availability of the Application Programming Interface (API). If the API returns to normal, the RPA mode is exited, and subsequent tasks return to the API processing path, achieving a smooth switch between RPA and API.

[0022] The status verification and final status confirmation module also includes a timeout failure identification submodule: The Timeout Non-Delivery Identification Submodule triggers the non-delivery judgment logic when the difference between the task creation time and the current time exceeds the 72-hour receipt window period and the task status is still "written back but not confirmed". If the number of receipts is less than or equal to the preset threshold and the status remains unchanged, it is determined to be a normal delay and marked as the first delay code. If the 72-hour response window has expired, it is determined to be completely undelivered, the target status is updated to undelivered, and the task is marked as completed.

[0023] This is used to monitor the remaining API call quota for the day in real time, and dynamically adjust the scanning strategy, polling interval, priority filtering conditions, and batch verification frequency according to the quota remaining level. The specific process is as follows: The quota adaptive scheduling module divides the quota surplus into several levels and executes differentiated scheduling strategies according to the level: When the quota is sufficient, the data capture and task queuing module, the status correction and write-back module, and the status verification and final state confirmation module all work at the highest frequency. When the quota is appropriate, each module maintains a normal frequency; When quotas are tight, the data capture and task queuing module is forcibly downgraded to only scan the records of the day, the status correction and write-back module only processes high-priority tasks, and the status verification and final status confirmation module skips the second confirmation. When the quota is exhausted, it will automatically switch to the backup account to continue processing high-priority tasks to prevent cascading exhaustion.

[0024] It also includes a fuse protection module: The fuse protection module includes a page-turning fuse, a retry fuse, and a task fuse; The page-turning circuit breaker is used to limit the maximum number of pages scanned per day by the data capture and task queuing module. If the limit is exceeded, scanning will stop immediately and an alarm will be triggered. The retry circuit breaker is used to limit the maximum number of retries for a single record retrieval operation by the data capture and task queuing module. If the maximum number of retries is exceeded, the module will be forced to exit. The task circuit breaker is used to limit the maximum number of failed verifications of a single task by the status verification and final status confirmation module. Once the limit is exceeded, the task is forcibly marked as a failure.

[0025] It also includes a dual-track audit and full reconciliation module, which is used to ensure the consistency of full data through the parallel operation of the real-time track and the audit track; The real-time track is a collaborative effort between the producer process, the consumer process, and the checker process, responsible for continuously monitoring the records of the day and recent times. The audit track performs a full reconciliation of historical data through monthly audit tools. When missing records are found in the database, intelligent filling is automatically performed, and batch filling is only performed during the low quota consumption period in the early morning. The audit track uses an independent backup account and a conservative frequency strategy to ensure that audit operations do not consume the main account quota or interfere with the normal operation of the real-time track. Trigger daily email reports via scheduled tasks and send comprehensive reports containing daily processing progress, percentage of each status, and historical details in a set format. The state correction write-back module also includes a backlog task fast processing mode: when the submission time of the current processing task is detected to exceed the preset time, the consumer process automatically enters the fast mode, and the polling interval is compressed from 3 seconds to 0.5 seconds to accelerate the digestion of backlog tasks. After returning to normal, it automatically exits.

[0026] The size of the interval and threshold is set to facilitate comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data; as long as it does not affect the ratio between the parameter and the quantized value.

[0027] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation. In the two embodiments provided in this application, it should be understood that the disclosed apparatus and system can be implemented in other ways; for example, the apparatus embodiments described above are merely illustrative, and the division of modules is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed; furthermore, the coupling or direct coupling or communication connection between the shown or discussed mutuals can be through some interfaces, and the indirect coupling or communication connection between the apparatus or modules can be electrical, mechanical or other forms. 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 short message status automatic correction and RPA bottoming-out system based on multi-source data checking, characterized in that, It includes a data capture and task queuing module, which is used to automatically capture SMS records, compare statuses, and enqueue tasks by periodically polling the sending platform through the producer process; The status correction and write-back module is used to retrieve tasks to be processed from the task queue through the consumer process, and write the status confirmed by the receipt interface back to the sending platform through the API interface to complete the status correction. The RPA fallback write-back module is used to automatically trigger the RPA fallback mechanism when the number of consecutive write-back operations fails due to an API interface exception reaches a preset threshold, and completes the status write-back by simulating manual operation. The status verification and final status confirmation module is used to independently confirm the status of tasks whose status has been updated through the verifier process. The tasks to be verified are grouped by submission date, and a mapping table between record ID and receipt status is built in memory for batch comparison. If the receipt status changes during the waiting period, the target status field is automatically corrected before writing is performed. The quota adaptive scheduling module is used to monitor the remaining quota for interface calls in real time and dynamically adjust the scanning strategy, polling interval, priority filtering conditions, and batch verification frequency according to the quota remaining level.

2. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, This is used to periodically poll the platform via a producer process, automatically capturing SMS records, comparing their status, and queuing tasks. The specific process is as follows: Upon startup, the producer process automatically logs in to the platform via the robotic process automation module. It calls an optical character recognition (OCR) library to automatically recognize the CAPTCHA image on the login page, submitting the recognition result along with the account credentials to the login interface to obtain session credentials. When a session expires, it automatically triggers a re-login, achieving unattended session maintenance and automatic renewal. The correction task is written to the task table using an ignored insertion method, and idempotency is guaranteed by a unique constraint. The producer process calls the sending platform record query interface to retrieve SMS sending records within a specified time window in a paginated manner, and writes the original records into the original record table in a full streaming manner. For each record retrieved from the sending platform, the system calls the third-party SMS service provider's receipt interface, which is independent of the sending platform, to query the corresponding carrier-level delivery status of the record. The system performs multi-source cross-comparison, generates correction tasks for records with inconsistent statuses, and writes them into the task table. Producer scanning strategy: Scan the daily records every 5 minutes during working hours, force a 3-day backtracking deep scan every 30 cycles, and perform a full deep scan during off-peak hours.

3. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, The consumer process retrieves tasks from the task queue and writes the final state confirmed by the receipt interface back to the sending platform via the API interface, thus completing the state correction. The specific process is as follows: The consumer process executes statements to lock and retrieve a task from the task table in descending order of submission time, supporting non-blocking concurrent execution of multiple consumer processes without duplicate task processing. When the backlog of tasks exceeds a preset threshold, the consumer process automatically enters the high-speed mode, compresses the task polling interval from the normal value to the high-speed value, accelerates the digestion of backlog tasks, and automatically exits the high-speed mode after the backlog returns to normal. The status correction write-back module adopts a LIFO strategy, prioritizing the processing of the latest tasks in descending order of task submission time to ensure that real-time SMS status updates are visible first. Before performing the write-back operation, first call the platform status query interface to confirm the current record status. If the platform status is already in the final state, skip the write-back operation directly. When writing back error codes, if the length of the error code returned by the cloud receipt interface exceeds the field length limit of the sending platform, it will be uniformly replaced with the SMS industry's common undelivered code before writing.

4. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, This mechanism is used to automatically trigger a fallback mechanism in the robotic process when the number of consecutive write-back operations fails due to an API exception reaches a preset threshold. It simulates manual operation to complete the status write-back, as follows: When the number of consecutive failed API write-back operations reaches a preset threshold, the controlled browser is automatically navigated to the sending platform login page, the graphic verification code recognition module is called to recognize the graphic verification code and submit the login form. After successful login, the session credentials are extracted and written to the shared cache file. The browser automatically navigates to the platform's record editing page, fills in the final status and error code fields one by one, and simulates the submission operation to write back the completed status. After the Robotic Process Automation (RPA) fallback is completed, an attempt is made to re-verify the availability of the Application Programming Interface (API). If the API returns to normal, the RPA mode is exited, and subsequent tasks return to the API processing path, achieving a smooth switch between RPA and API.

5. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, The status verification and final status confirmation module also includes a timeout failure identification submodule: The Timeout Non-Delivery Identification Submodule triggers the non-delivery judgment logic when the difference between the task creation time and the current time exceeds the 72-hour receipt window period and the task status is still "written back but not confirmed". If the number of receipts is less than or equal to the preset threshold and the status remains unchanged, it is determined to be a normal delay and marked as the first delay code. If the 72-hour response window has expired, it is determined to be completely undelivered, the target status is updated to undelivered, and the task is marked as completed.

6. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, This is used to monitor the remaining API call quota for the day in real time, and dynamically adjust the scanning strategy, polling interval, priority filtering conditions, and batch verification frequency according to the quota remaining level. The specific process is as follows: The quota adaptive scheduling module divides the quota surplus into several levels and executes differentiated scheduling strategies according to the level: When the quota is sufficient, the data capture and task queuing module, the status correction and write-back module, and the status verification and final state confirmation module all work at the highest frequency. When the quota is appropriate, each module maintains a normal frequency; When quotas are tight, the data capture and task queuing module is forcibly downgraded to only scan the records of the day, the status correction and write-back module only processes high-priority tasks, and the status verification and final status confirmation module skips the second confirmation. When the quota is exhausted, it will automatically switch to the backup account to continue processing high-priority tasks to prevent cascading exhaustion.

7. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, It also includes a fuse protection module: The fuse protection module includes a page-turning fuse, a retry fuse, and a task fuse; The page-turning circuit breaker is used to limit the maximum number of pages scanned per day by the data capture and task queuing module. If the limit is exceeded, scanning will stop immediately and an alarm will be triggered. The retry circuit breaker is used to limit the maximum number of retries for a single record retrieval operation by the data capture and task queuing module. If the maximum number of retries is exceeded, the module will be forced to exit. The task circuit breaker is used to limit the maximum number of failed verifications of a single task by the status verification and final status confirmation module. Once the limit is exceeded, the task is forcibly marked as a failure.

8. The SMS status automatic correction and RPA fallback system based on multi-source data verification according to claim 1, characterized in that, It also includes a dual-track audit and full reconciliation module, which is used to ensure the consistency of full data through the parallel operation of the real-time track and the audit track; The real-time track is a collaborative effort between the producer process, the consumer process, and the checker process, responsible for continuously monitoring the records of the day and recent times. The audit track performs a full reconciliation of historical data through monthly audit tools. When missing records are found in the database, intelligent filling is automatically performed, and batch filling is only performed during the low quota consumption period in the early morning. The audit track uses an independent backup account and a conservative frequency strategy to ensure that audit operations do not consume the main account quota or interfere with the normal operation of the real-time track. Trigger daily email reports via scheduled tasks and send comprehensive reports containing daily processing progress, percentage of each status, and historical details in a set format. The state correction write-back module also includes a backlog task fast processing mode: when the submission time of the current processing task is detected to exceed the preset time, the consumer process automatically enters the fast mode, and the polling interval is compressed from 3 seconds to 0.5 seconds to accelerate the digestion of backlog tasks. After returning to normal, it automatically exits.

Images