Serial task number-based communication number card attribute asynchronous modification method and system

Abstract

The application relates to a serial task number-based communication number card attribute asynchronous modification method and system, and belongs to the technical field of computers.The method comprises the following steps: receiving a number card attribute modification request, generating a unique task ID and a serial task number of the number card attribute modification request; detecting whether an executing state or a to-be-executed state exists in a task state corresponding to the serial task number; if not, extracting a target subtask from all to-be-executed tasks under the serial task number, and sending a request to a communication server based on the target subtask; periodically inquiring about all task records with a non-completed state in a request information table, obtaining a current execution state of the non-completed task record based on a calling interface, and performing an operation corresponding to the current execution state; periodically inquiring about a task table, and determining that all subtasks under the same serial task number are in a completed state, terminating a modification process, and performing cleaning work. The method improves the automation, reliability and efficiency of task execution.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a method and system for asynchronously modifying the attributes of a communication card based on a serial task number. Background Technology

[0002] In the field of asynchronous task scheduling, existing technologies mainly rely on simple queues or manual scheduling mechanisms to handle SIM card attribute modification requests. These methods have significant limitations when handling multi-interface asynchronous operations: they cannot automatically detect changes in task status, requiring manual intervention to query the execution status; concurrent task submissions easily trigger interface errors, as the system prohibits new requests when the same SIM card has incomplete tasks; furthermore, state management lacks atomicity, leading to inconsistent updates, and retry strategies are rigid, unable to adapt to diverse failure scenarios such as network timeouts or interface errors, reducing system reliability and efficiency. To address these issues, existing technologies typically employ task orchestration and dependency relationships to construct serial task chains, supporting synchronous and asynchronous task issuance, or parallel task processing methods based on single-threaded asynchronous frameworks, or distributed file asynchronous processing services, utilizing a command terminal to construct executable sequence objects to schedule subtasks, thus achieving asynchronous task scheduling. However, these methods suffer from the inability to automatically detect changes in task status, relying on periodic scanning or manual queries, resulting in response delays, low operational efficiency, and a lack of effective serialization control for concurrent task submissions. Therefore, how to better implement SIM card attribute modification requests has become an urgent problem to be solved. Summary of the Invention

[0003] In view of the shortcomings of the prior art, the purpose of the invention is to provide a method and system for asynchronous modification of communication card attributes based on serial task number.

[0004] In a first aspect, the present invention proposes a method for asynchronous modification of SIM card attributes based on a serial task number, comprising: S1, receiving a SIM card attribute modification request, generating a unique task ID and a serial task number for the SIM card attribute modification request and recording the task information in a task table, and simultaneously marking the status of the task corresponding to the SIM card attribute modification request as pending execution, wherein all attribute modification tasks for the same SIM card share the same serial task number; S2, detecting the task status corresponding to the serial task number, and if it is determined that there is no executing or pending execution status in the task status, extracting a target subtask from all pending execution tasks under the serial task number, and based on the target subtask... S3. Periodically query all task records in the request information table whose task status is not completed, obtain the current execution status of the non-completed task records based on the calling interface, and perform corresponding operations based on the current execution status, which includes executing, executing successfully, and executing failed; S4. Periodically query the task table, and if it is determined that the status of all subtasks under the same serial task number is completed, terminate the modification process and perform cleanup work. The status update operations of the task table and the request information table are both executed in the same database transaction.

[0005] Further, generating the unique task ID and serial task number of the SIM card attribute modification request includes: generating the unique task ID based on a first preset format; generating the serial task number based on a second preset format; wherein, the task table includes the unique task ID, task name, the communication server corresponding to the SIM card attribute modification request, the request parameters of the SIM card attribute modification request, the request order of the SIM card attribute modification request, the serial task number, and the task status.

[0006] Furthermore, if it is determined that the task status includes either the executing state or the pending state, the status of the task corresponding to the SIM card attribute modification request is kept marked as the pending state.

[0007] Further, extracting the target subtask from all tasks to be executed under the serial task number includes: obtaining all tasks to be executed under the serial task number; determining the request order field carried by the corresponding request in all tasks to be executed, and taking the subtask with the smallest value corresponding to the request order field as the target subtask; wherein, based on the target subtask, sending a request to the communication server includes: based on the target subtask, sending an HTTP or HTTPS request to the attribute modification interface of the communication server, wherein the HTTP or HTTPS request carries the unique task ID and modification parameters; wherein, the request information table includes the unique task ID of the task, request time, initial status, and number of retries, wherein the initial status is set to executing, and the initial value of the number of retries is zero.

[0008] Further, performing corresponding operations based on the current execution state includes: if the current execution state is execution failure, determining whether the number of retries for the task corresponding to the non-completed task record exceeds a preset threshold; if not, determining the type of execution failure; if the type is network timeout or connection failure, resending the request to the communication server using an exponential backoff retry mechanism; if the type is an interface returning a preset error code, resending the request to the communication server using a fixed interval retry mechanism, wherein the higher the priority of the preset error code, the shorter the fixed interval; if yes, marking the current execution state of the task corresponding to the non-completed task record as final failure, and no longer retrying.

[0009] Further, based on the current execution status, the corresponding operation is performed, including: if the current execution status is "execution successful", updating the non-completed task records in the task table to "completed" status, and querying under the same serial task number whether there is a subtask with the smallest value corresponding to the request order field and whose current status is "not executed"; if there is, sending a request to the communication server and synchronously updating the request information table and the task status in the task table; if there is no subtask, periodically querying the task table, and if it is determined that the status of all subtasks under the same serial task number is "completed", terminating the modification process and performing cleanup work.

[0010] Furthermore, performing corresponding operations based on the current execution status includes: if the current execution status is "in execution", then skipping this polling and waiting for the next periodic query.

[0011] A second aspect of the present invention proposes an asynchronous modification system for SIM card attributes based on a serial task number, comprising: a generation module, configured to receive a SIM card attribute modification request, generate a unique task ID and a serial task number for the SIM card attribute modification request, record the task information in a task table, and mark the status of the task corresponding to the SIM card attribute modification request as pending execution, wherein all attribute modification tasks for the same SIM card share the same serial task number; and a sending module, configured to detect the task status corresponding to the serial task number, and, if it is determined that there is no executing or pending execution status among the task statuses, extract a target subtask from all pending execution tasks under the serial task number, and based on the target subtask... The system sends a request to the communication server and records the request information in the request information table. The execution module periodically queries all task records in the request information table whose status is not "completed," obtains the current execution status of the non-completed task records based on the calling interface, and performs corresponding operations based on the current execution status, which includes "in execution," "execution successful," and "execution failed." The query module periodically queries the task table, and if it determines that all subtasks under the same serial task number are in a "completed" state, it terminates the modification process and performs cleanup work. The status update operations of the task table and the request information table are both executed within the same database transaction.

[0012] A third aspect of the present invention provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method described in any one aspect of the present invention.

[0013] A fourth aspect of the present invention provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described in any one of the first aspects of the present invention.

[0014] The beneficial effects of this invention are as follows: The asynchronous modification method and system for communication card attributes based on serial task numbers described in this invention receives a card attribute modification request, generates a unique task ID and serial task number for the card attribute modification request, records the task information in a task table, and marks the status of the task corresponding to the card attribute modification request as pending execution. All attribute modification tasks for the same card share the same serial task number. The system detects the task status corresponding to the serial task number. If no task status is found to be in progress or pending execution, a target subtask is extracted from all pending tasks under the serial task number. Based on the target subtask, a request is sent to the communication server, and the request information is recorded in a request information table. The system periodically queries all task records in the request information table whose status is not completed. The system obtains the current execution status of these non-completed task records based on an interface call and performs corresponding operations based on the current execution status, which includes in progress, successful execution, and failed execution. Finally, the system periodically queries the task table. If all subtasks under the same serial task number are found to be completed, the modification process is terminated, and cleanup work is performed. The status update operations of the task table and the request information table are both executed within the same database transaction. This method introduces a serial task number to achieve sequential execution of multiple attribute modification requests for the same SIM card. Combined with a two-layer state management system of task table and request record table and database transaction protection, it effectively avoids concurrency conflicts and state inconsistency issues. At the same time, by utilizing periodic polling and state-driven mechanisms, it can asynchronously perceive the task execution progress and automatically trigger subsequent task flows. While ensuring the correctness of the SIM card attribute modification process sequence, it improves the system's high-concurrency processing capability and resource utilization efficiency. Furthermore, by determining the completion status, it ensures the reliable termination of the entire serial process. This method improves the automation, reliability, and efficiency of task execution. Attached Figure Description

[0015] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0016] Figure 1 This is a flowchart of a method for asynchronously modifying the attributes of a communication card based on a serial task number according to an embodiment of the present invention; Figure 2 This is a flowchart of a method for asynchronously modifying the attributes of a communication card based on a serial task number according to a specific embodiment of the present invention; Figure 3 This is a schematic diagram of an asynchronous modification system for communication card attributes based on a serial task number according to an embodiment of the present invention; Figure 4This is a structural block diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0019] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0021] In the field of asynchronous task scheduling, existing technologies mainly rely on simple queues or manual scheduling mechanisms to handle card attribute modification requests. These methods have significant limitations when handling asynchronous operations across multiple interfaces: they cannot automatically detect changes in task status, requiring manual intervention to query the execution status; concurrent task submissions are prone to triggering interface errors, as the system prohibits new requests when there are incomplete tasks for the same card; furthermore, state management lacks atomicity, leading to inconsistent updates, and retry strategies are rigid, unable to adapt to diverse failure scenarios such as network timeouts or interface errors, thus reducing system reliability and efficiency.

[0022] To address the aforementioned issues, common approaches include constructing a serial task chain through task orchestration and dependencies, supporting both synchronous and asynchronous task delivery; however, these approaches still suffer from limitations such as the inability to automatically poll the interface status and the lack of a concurrency control mechanism specifically for SIM card-specific interfaces; alternatively, parallel task processing methods based on single-threaded asynchronous frameworks encapsulate instruction tasks and generate chained task flows, but fail to address the need for serialized task execution under high concurrency, easily leading to interface conflicts; distributed file asynchronous processing services utilize a command-line interface to construct executable sequence objects to schedule subtasks, but lack an integrated status polling mechanism, making it impossible to perceive task status changes in real time; and message queues are used to schedule tasks, supporting sequential execution and rollback operations, but retry strategies are not dynamically optimized based on failure types (such as network errors), and there is a lack of two-layer state management to ensure atomicity.

[0023] However, none of these solutions systematically address the core issues, and they mainly suffer from the following technical defects: 1. They cannot automatically detect changes in task status, relying on periodic scanning or manual queries, resulting in response delays and low operational efficiency; 2. Concurrent task submissions lack effective serialization control, and multiple requests from the same SIM card can easily trigger interface errors, affecting system stability; 3. The status update mechanism is not atomic, and the lack of database transactions can lead to data inconsistency risks; 4. The retry strategy is simplistic and does not distinguish between failure types (such as timeouts and interface errors), reducing error handling efficiency; 5. No request frequency control is designed, and in high-concurrency scenarios, there is a tendency to over-call operator interfaces, resulting in resource waste.

[0024] To address this, the present invention proposes a method, system, and related equipment for asynchronously modifying the attributes of a communication card based on a serial task number. Specifically, the following description of the embodiment of the present invention, including the method, system, and related equipment for asynchronously modifying the attributes of a communication card based on a serial task number, is provided with reference to the accompanying drawings.

[0025] Figure 1This is a flowchart of a method for asynchronously modifying communication card attributes based on a serial task number according to an embodiment of the present invention. It should be noted that the method for asynchronously modifying communication card attributes based on a serial task number according to this embodiment of the present invention can be applied to a system for asynchronously modifying communication card attributes based on a serial task number according to this embodiment of the present invention. This system for asynchronously modifying communication card attributes based on a serial task number can be configured on an electronic device or in a server. This application does not limit the scope of this method.

[0026] like Figure 1 As shown, the asynchronous modification method for communication card attributes based on serial task number includes: S110: Receive SIM card attribute modification request, generate a unique task ID and serial task number for the SIM card attribute modification request, record the task information in the task table, and mark the status of the task corresponding to the SIM card attribute modification request as pending execution. Among them, all attribute modification tasks of the same SIM card share the same serial task number.

[0027] In an embodiment of the present invention, a unique task ID can be generated based on a device receiving a card attribute modification request, and a serial task number can be generated based on a first preset format and a second preset format.

[0028] For example, the first preset format is TASK-YYYYMMDD-XXX, and the second preset format is SERIAL-TASK-YYYYMMDD-XXX. The serial task number can be understood as a shared identifier for all attribute modification tasks on the same card, in the format SERIAL-TASK-YYYYMMDD-XXX, used to associate the task with the card it belongs to and specify the execution order.

[0029] In embodiments of the present invention, when a unique task ID and a serial task number are generated, the task information corresponding to the SIM card attribute modification request can be recorded in the task table. The status of the task corresponding to the SIM card attribute modification request (i.e., the task status corresponding to the SIM card attribute modification request) is marked as pending execution. This ensures the persistence and consistency of task metadata, supports the sequential execution of tasks for the same SIM card, and avoids data loss.

[0030] The task table includes a unique task ID, task name, the communication server corresponding to the SIM card attribute modification request, the request parameters for the SIM card attribute modification request, the request order for the SIM card attribute modification request, the serial task number, and the task status. The request parameters include the order value (i.e., numerical value) of the request order.

[0031] S120: Detect the task status corresponding to the serial task number. If it is determined that there is no running or pending task status, extract the target subtask from all pending tasks under the serial task number, and send a request to the communication server based on the target subtask, while recording the request information in the request information table.

[0032] In an embodiment of the present invention, a status check is performed on the serial task number, that is, to detect whether there are any tasks under the serial task number that are in execution or pending execution. If none are found, it means that the card is currently idle. Then, all pending tasks under the serial task number are obtained, and the processing priority of each pending task is determined according to the order indication information carried by each pending task. The pending tasks whose processing priorities meet the preset conditions are determined as target subtasks. Then, based on the target subtasks, a request is sent to the communication server, and the request information is recorded in the request information table. For specific implementation methods, please refer to the following embodiments.

[0033] The request information table includes the task's unique task ID, request time, initial status, and number of retries. The initial status is set to "in execution," and the initial value of the number of retries is zero.

[0034] S130: Periodically query all task records in the request information table whose task status is not completed. Obtain the current execution status of the non-completed task records based on the API call, and perform the corresponding operation based on the current execution status. The current execution status includes executing, successful execution, and failed execution.

[0035] In other words, the system periodically queries the request information table for all task records whose status is not "completed." For each task record, it calls the query interface to obtain the latest execution status (i.e., the current execution status) of that task record. Then, it performs the corresponding operation based on the current execution status. For specific implementation details, please refer to the following embodiments.

[0036] S140: Periodically query the task table. If it is determined that all subtasks under the same serial task number are in the completed state, terminate the modification process and perform cleanup work. The status update operations of the task table and the request information table are all executed in the same database transaction.

[0037] In other words, the task table is periodically queried to check whether the status of all subtasks under the same serial task number is marked as completed. If so, the entire modification process for that card number is terminated, and cleanup work is performed. This cleanup work includes releasing the serial task number resource and clearing related temporary states or placeholders.

[0038] According to an embodiment of the present invention, an asynchronous modification method for communication card attributes based on a serial task number is provided. The method receives a card attribute modification request, generates a unique task ID and a serial task number for the card attribute modification request, and records the task information in a task table. Simultaneously, the status of the task corresponding to the card attribute modification request is marked as pending execution. All attribute modification tasks for the same card share the same serial task number. The method detects the task status corresponding to the serial task number. If no task status is found to be in progress or pending execution, a target subtask is extracted from all pending tasks under the serial task number. Based on the target subtask, a request is sent to the communication server, and the request information is recorded in a request information table. The method periodically queries all task records in the request information table whose status is not completed. The method obtains the current execution status of the non-completed task records based on the calling interface and performs corresponding operations based on the current execution status, which includes in progress, successful execution, and failed execution. The method periodically queries the task table. If all subtasks under the same serial task number are found to be completed, the modification process is terminated, and cleanup work is performed. The status update operations of the task table and the request information table are both executed within the same database transaction. This method introduces a serial task number to achieve sequential execution of multiple attribute modification requests for the same SIM card. Combined with a two-layer state management system of task table and request record table and database transaction protection, it effectively avoids concurrency conflicts and state inconsistency issues. At the same time, by utilizing periodic polling and state-driven mechanisms, it can asynchronously perceive the task execution progress and automatically trigger subsequent task flows. While ensuring the correctness of the SIM card attribute modification process sequence, it improves the system's high-concurrency processing capability and resource utilization efficiency. Furthermore, by determining the completion status, it ensures the reliable termination of the entire serial process. This method improves the automation, reliability, and efficiency of task execution.

[0039] To enable those skilled in the art to more readily understand the present invention, Figure 2 This is a method for asynchronously modifying communication card attributes based on a serial task number according to a specific embodiment of the present invention, such as... Figure 2 As shown, the asynchronous modification method for communication card attributes based on serial task number includes: S210: Receive the SIM card attribute modification request, generate a unique task ID and serial task number for the SIM card attribute modification request, record the task information in the task table, and mark the status of the task corresponding to the SIM card attribute modification request as pending execution. Among them, all attribute modification tasks of the same SIM card share the same serial task number.

[0040] In embodiments of the present invention, step S210 can be implemented with reference to the implementation of step S110 described above. Further details will not be provided here.

[0041] S220, detect the task status corresponding to the serial task number, and determine whether there is no running status or pending execution status in the task status.

[0042] In an embodiment of the present invention, when generating a unique task ID and a serial task number for a card attribute modification request, a status check is performed on the serial task number, that is, to detect whether there is a task under the serial task number with a status of executing or pending execution.

[0043] S230, if it is determined that there is an in-process or pending state in the task status, keep the status mark of the task corresponding to the card attribute modification request as pending state.

[0044] In an embodiment of the present invention, if it is determined that there is an in-processing state or a pending state in the task status, it means that there is already a task being processed or pending under the serial task number. In this case, the current scan is skipped, and the status of the task corresponding to the current card attribute modification request remains pending to avoid concurrent conflicts.

[0045] S240, if it is determined that there is no running state or pending state in the task status, extract the target subtask from all pending tasks under the serial task number.

[0046] In an embodiment of the present invention, if it is determined that there is no running state or pending state in the task status, all pending tasks under the serial task number are obtained; the request order field (i.e., order indication information) carried by the corresponding request in all pending tasks is determined, and the subtask with the smallest value corresponding to the request order field is taken as the target subtask.

[0047] S250 sends a request to the communication server based on the target sub-task and records the request information in the request information table.

[0048] In embodiments of the present invention, upon extracting a target subtask, an HTTP or HTTPS request is sent to the attribute modification interface of the communication server based on the target subtask. The HTTP or HTTPS request carries a unique task ID and modification parameters. This avoids concurrent conflicts, ensures orderly task startup, and prevents duplicate execution.

[0049] The request information table includes the task's unique task ID, request time, initial status, and number of retries. The initial status is set to "in execution," and the initial value of the number of retries is zero.

[0050] In embodiments of the present invention, since both the task table and the request information table are executed within the same database transaction, state consistency is guaranteed. Therefore, while recording the request information in the request information table, the status of the target subtask in the task table is updated to "in execution." This achieves a two-layer atomic state update, enhancing state consistency, reducing the risk of data inconsistency, and simplifying fault recovery.

[0051] In one embodiment of the invention, using Redis atomic operations (Lua script), the number of newly generated tokens is first calculated based on the time difference between the current timestamp and the last replenishment time (wherein, Redis records the last replenishment time). That is, the number of tokens = time difference * generation rate (wherein, the generation rate can be determined based on the number of tokens added to the token bucket per unit time (e.g., per second) historically), and stored in the bucket (not exceeding a preset capacity limit). When the target subtask is obtained, instead of sending an HTTP or HTTPS request to the attribute modification interface of the communication server, a token is first retrieved from Redis. If there are enough tokens (i.e., not less than 1), one token is retrieved, and the request is sent. If there are insufficient tokens (the bucket is empty): no error is reported, and the task is not discarded; instead, the next step is executed. When no tokens can be retrieved, the target subtask is not discarded but temporarily stored in an asynchronous queue (such as a Redis List or BlockingQueue). Simultaneously, a scheduled task is started to periodically check the token bucket in Redis. Once token recovery is detected (i.e., a new token is generated), the waiting task is immediately retrieved from the head of the queue, and tokens are acquired and requests are sent in a first-in-first-out (FIFO) order.

[0052] S260: Periodically query the request information table for all task records whose task status is not completed, and obtain the current execution status of the non-completed task records based on the API call.

[0053] In embodiments of the present invention, a scheduled Spring Boot task can be used, for example, to query the request information table every 5 seconds for all task records whose task status is not completed. For each task record, the query interface is called to obtain the latest execution status (i.e., the current execution status) of that task record. This achieves automatic monitoring and processing of task status.

[0054] Among them, scheduled tasks in Spring Boot can be understood as periodic tasks implemented based on the Spring Boot framework. They are enabled by the @EnableScheduling annotation and are used to scan the request record table and poll the task status.

[0055] The current status is either executing, failing to execute, or succeeding to execute.

[0056] In embodiments of the present invention, when an anomaly is detected in the calling interface, such as due to a power outage or database crash, meaning the current execution status of non-completed task records cannot be obtained, the obtained status remains stuck at "in execution." Therefore, a timeout threshold mechanism is introduced. For example, when 30 minutes have elapsed, instead of directly marking it as a final failure, the task status is updated to "execution failed." The task is then retried using an exponential backoff retry mechanism or a fixed-interval retry mechanism. If the retried task is successful, the next process is executed; if the retried task fails, the status of this SIM card attribute modification request is marked as a final failure. This prevents the task from being permanently suspended.

[0057] S270, Execute the corresponding operation based on the current execution state.

[0058] In one embodiment of the present invention, if the current execution status is execution failure, it is determined whether the number of retries for the task corresponding to the non-completed task record exceeds a preset threshold; if not, the type of execution failure is determined. If the type is network timeout or connection failure, an exponential backoff retry mechanism is used to resend the request to the communication server; if the type is an interface returning a preset error code, a fixed interval retry mechanism is used to resend the request to the communication server, wherein the higher the priority of the preset error code, the shorter the fixed interval; if yes, the current execution status of the task corresponding to the non-completed task record is marked as final failure, and no further retries are made.

[0059] In cases of network timeout or connection failure, an adaptive backoff algorithm is used to resend the request to the communication server. This means that the retry interval is dynamically adjusted based on the historical failure rate, thereby further improving the processing efficiency in network timeout scenarios.

[0060] The exponential backoff retry mechanism can be understood as a failure retry strategy where the waiting time increases exponentially with the number of retries. For example, with a retry threshold of 3 times and a base interval of 1 second, the execution process is as follows: First failure: Wait Retry in seconds (plus random jitter, e.g., 0~0.5 seconds). Second failure: Wait. Retry in seconds (plus random jitter). 3rd failure: Wait. Retry after 3 seconds (plus random jitter). If it fails on the 3rd attempt, it is considered a final failure and will not be retried.

[0061] The priority of the preset error codes can be determined based on a preset mapping table, which includes the correspondence between preset error codes and priorities. Higher priority preset error codes are used at shorter fixed intervals, thus enhancing robustness.

[0062] In other words, when the current execution status is "execution failed," the retry count for the task corresponding to the incomplete task record is checked. If the retry count does not exceed a preset threshold (e.g., 3 times), a retry is performed based on the type of failure. Specifically, if the type is determined to be network timeout or connection failure, an exponential backoff retry mechanism is used to resend the request to the communication server; if the type is determined to be an interface returning a preset error code, a fixed-interval retry mechanism is used to resend the request to the communication server. If the retry count exceeds the preset threshold, the current execution status of the task corresponding to the incomplete task record is marked as final failure, and no further retrying is performed. By using an exponential backoff retry mechanism or a fixed-interval retry mechanism to resend the request to the communication server, the task execution success rate and fault tolerance for temporary failures are improved, reducing the need for manual intervention and the failure rate.

[0063] Specifically, retries are performed based on the type of execution failure. In the case of retries, the request time, status (still in progress or failed), and number of retries (e.g., incremented by 1) in the request information table are updated.

[0064] In embodiments of the present invention, when the current execution status is execution failure, instead of using an exponential backoff retry mechanism or a fixed interval retry mechanism to resend the request to the communication server, the retry interval can be significantly extended (e.g., from 5 seconds to 60 seconds), or only the highest priority task can be allowed to retry. This prevents excessive calls in high-concurrency scenarios, avoids service overload, and improves system stability.

[0065] In an embodiment of the present invention, when the current execution status is "execution failed," the number of all non-completed task records whose current execution status is "execution failed" is obtained. If the number exceeds a first threshold, the retry frequency is reduced. If the number exceeds a second threshold, the retry mechanism is paused, and an alarm is immediately triggered to notify maintenance personnel, thereby improving overall system stability and avoiding cascading failures. When the number is detected to be below the second threshold, the retry mechanism is automatically activated to avoid manual intervention.

[0066] In one embodiment of the present invention, if the current execution status is successful, the non-completed task records in the task table are updated to complete status, and a query is performed under the same serial task number to see if there is a subtask with the smallest value corresponding to the request order field and whose current status is not executed; if there is, a request is sent to the communication server, and the task status in the request information table and the task table are updated synchronously; if there is no subtask, the task table is periodically queried, and if it is determined that the status of all subtasks under the same serial task number is complete, the modification process is terminated and cleanup work is performed.

[0067] In other words, if the current execution status is "execution successful," the database transaction updates the status of the non-completed task record in the task table to "completed." It also queries for subtasks under the same serial task number whose request order field value is less than a threshold and whose current status is "not executed." If such a subtask exists, an HTTP or HTTPS request is immediately initiated to the attribute modification interface of the communication server for that subtask, and a dual status write is performed simultaneously: the task information of the subtask is inserted into the request record table, and the status of the subtask in the task table is updated to "in execution." If no subtask exists, it means that all tasks under that serial number have been processed, and the next process begins: periodically querying the task table. Once it is determined that all subtasks under the same serial task number are in a "completed" state, the modification process terminates, and cleanup work is performed.

[0068] In one embodiment of the present invention, if the current execution status is "in execution", then the current polling is skipped and the next periodic query is waited for.

[0069] S280: Periodically query the task table. If it is determined that all subtasks under the same serial task number are in the completed state, terminate the modification process and perform cleanup work. The status update operations of the task table and the request information table are both executed in the same database transaction.

[0070] In other words, the task table is periodically queried to check if all subtasks under the same serial task number are marked as completed. If so, the entire modification process for that card number is terminated, and cleanup work is performed. This ensures the complete completion of the process, prevents resource leaks, and improves resource utilization.

[0071] Specifically, if all subtasks under the same serial task number are marked as completed and their completion time exceeds the preset retention period, they are archived or physically deleted. This reduces database load while maintaining consistency with the original solution.

[0072] The asynchronous modification method for communication card attributes based on serial task numbers, as described in this embodiment of the invention, achieves strict sequential serial execution and concurrency conflict avoidance for multiple attribute modification requests for the same card by introducing serial task numbers. Combined with two-layer state management of the task table and request record table, and the atomicity guarantee of database transactions, it effectively ensures the consistency and traceability of task status and execution records at different lifecycle stages. Simultaneously, based on a periodic polling and state-driven task flow mechanism, the system can asynchronously perceive execution progress and automatically trigger subsequent tasks, significantly improving task throughput and resource utilization efficiency in high-concurrency scenarios. Furthermore, the solution employs differentiated strategies for network timeouts and business error codes, namely exponential backoff retries and fixed-interval retries, respectively. Combined with multi-layered fault tolerance measures such as token bucket rate limiting, automatic timeout failure marking, and tiered circuit breaking, it effectively avoids service overload and long-term task suspension, enhancing the system's adaptive recovery capability and overall stability against temporary faults. Periodic cleanup of completed data further reduces database load, ensuring the high efficiency of long-term system operation. Therefore, it achieves an asynchronous modification method for communication card attributes that combines high sequential consistency, high fault tolerance robustness, and high maintainability.

[0073] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0074] According to one aspect of the present invention, an asynchronous modification system for communication card attributes based on serial task numbers is also proposed. Figure 3 This is a schematic diagram of an asynchronous modification system for communication card attributes based on a serial task number, according to an embodiment of the present invention; as shown. Figure 3 As shown, it includes: The generation module 310 is used to receive a card attribute modification request, generate a unique task ID and serial task number for the card attribute modification request, record the task information in the task table, and mark the status of the task corresponding to the card attribute modification request as pending execution. All attribute modification tasks of the same card share the same serial task number. The sending module 320 is used to detect the task status corresponding to the serial task number. If it is determined that there is no running status or pending status in the task status, the target subtask is extracted from all pending tasks under the serial task number, and a request is sent to the communication server based on the target subtask. At the same time, the request information is recorded in the request information table. The execution module 330 is used to periodically query all task records in the request information table whose task status is not completed, obtain the current execution status of the non-completed task records based on the calling interface, and perform corresponding operations based on the current execution status. The current execution status includes executing, executing successfully, and executing failed. The query module 340 is used to periodically query the task table. When it is determined that the status of all subtasks under the same serial task number is completed, the modification process is terminated and cleanup work is performed. The status update operations of the task table and the request information table are both executed in the same database transaction.

[0075] According to an embodiment of the present invention, an asynchronous modification system for communication card attributes based on serial task numbers receives a card attribute modification request, generates a unique task ID and serial task number for the card attribute modification request, records the task information in a task table, and marks the status of the task corresponding to the card attribute modification request as pending execution. All attribute modification tasks for the same card share the same serial task number. The system detects the task status corresponding to the serial task number. If no task status is found to be in progress or pending execution, a target subtask is extracted from all pending tasks under the serial task number. Based on the target subtask, a request is sent to the communication server, and the request information is recorded in a request information table. The system periodically queries all task records in the request information table whose status is not completed. The system obtains the current execution status of the non-completed task records based on the calling interface and performs corresponding operations based on the current execution status, which includes in progress, successful execution, and failed execution. The system periodically queries the task table. If all subtasks under the same serial task number are found to be completed, the modification process is terminated, and cleanup work is performed. The status update operations of the task table and the request information table are both executed within the same database transaction. This method improves the automation, reliability, and efficiency of task execution.

[0076] Optionally, the generation module 310 is specifically used to generate the unique task ID based on a first preset format; and to generate the serial task number based on a second preset format; wherein the task table includes the unique task ID, task name, the communication server corresponding to the SIM card attribute modification request, the request parameters of the SIM card attribute modification request, the request order of the SIM card attribute modification request, the serial task number, and the task status.

[0077] Optionally, if it is determined that the task status includes either the executing status or the pending status, the status of the task corresponding to the SIM card attribute modification request is kept marked as the pending status.

[0078] Optionally, the sending module 320 is specifically used to obtain all tasks to be executed under the serial task number; determine the request order field carried by the corresponding request in all tasks to be executed, and take the subtask with the smallest value corresponding to the request order field as the target subtask; based on the target subtask, send an HTTP or HTTPS request to the attribute modification interface of the communication server, wherein the HTTP or HTTPS request carries the unique task ID and modification parameters; wherein the request information table includes the unique task ID, request time, initial status, and retry count of the task, wherein the initial status is set to executing, and the initial value of the retry count is zero.

[0079] Optionally, the execution module 330 is specifically configured to, when the current execution state is execution failure, determine whether the number of retries for the task corresponding to the non-completed task record exceeds a preset threshold; if not, determine the type of execution failure; if the type is network timeout or connection failure, resend the request to the communication server using an exponential backoff retry mechanism; if the type is an interface returning a preset error code, resend the request to the communication server using a fixed interval retry mechanism, wherein the higher the priority of the preset error code, the shorter the fixed interval; if yes, mark the current execution state of the task corresponding to the non-completed task record as final failure and no longer retry.

[0080] Optionally, the execution module 330 is specifically used to, when the current execution status is "execution successful", update the non-completed task records in the task table to the completed status, and query under the same serial task number whether there is a subtask with the smallest corresponding value of the request order field and the current status is "not executed"; if there is, send a request to the communication server and synchronously update the request information table and the task status in the task table; if there is no subtask, periodically query the task table, and if it is determined that the status of all subtasks under the same serial task number is "completed", terminate the modification process and perform cleanup work.

[0081] Optionally, the execution module 330 is specifically used to skip the current polling and wait for the next periodic query when the current execution status is "in execution".

[0082] According to one aspect of the present invention, an electronic device is provided.

[0083] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Figure 4 As shown, an electronic device may include one or more ( Figure 4 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a microprocessor unit (MPU) or a programmable logic device (PLD)) and a memory 104 for storing data are also shown. In one exemplary embodiment, the electronic device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 4 The structure shown is for illustrative purposes only and does not limit the structure of the terminal device described above. For example, the terminal device may also include components that are more... Figure 4 The more or fewer components shown, or having the same Figure 4 Equivalent functions or ratios shown Figure 4 The functions shown have more different configurations.

[0084] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the asynchronous modification method of communication card attributes based on serial task numbers in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to terminal devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0085] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the switching device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0086] This invention proposes a non-transitory computer-readable storage medium storing computer instructions, the computer instructions being used to cause the computer to execute an asynchronous modification method for communication card attributes based on a serial task number.

[0087] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

[0088] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0089] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A method for asynchronously modifying the attributes of a communication card based on a serial task number, characterized in that, include: S1, Receive a card attribute modification request, generate a unique task ID and serial task number for the card attribute modification request and record the task information in the task table, and mark the status of the task corresponding to the card attribute modification request as pending execution, wherein all attribute modification tasks of the same card share the same serial task number; S2, detect the task status corresponding to the serial task number. If it is determined that there is no running or pending execution status in the task status, extract the target subtask from all pending tasks under the serial task number, and send a request to the communication server based on the target subtask, while recording the request information in the request information table. S3, periodically query all task records in the request information table whose task status is not completed, obtain the current execution status of the non-completed task records based on the calling interface, and perform corresponding operations based on the current execution status. The current execution status includes executing, executing successfully, and executing failed. S4. Periodically query the task table. If it is determined that all subtasks under the same serial task number are in the completed state, terminate the modification process and perform cleanup work. The status update operations of the task table and the request information table are both executed in the same database transaction.

2. The asynchronous modification method for communication card attributes based on serial task number according to claim 1, characterized in that, Generate a unique task ID and serial task number for the card attribute modification request, including: The unique task ID is generated based on the first preset format; The serial task number is generated based on the second preset format; The task table includes the unique task ID, task name, the communication server corresponding to the SIM card attribute modification request, the request parameters of the SIM card attribute modification request, the request order of the SIM card attribute modification request, the serial task number, and the task status.

3. The asynchronous modification method for communication card attributes based on serial task number according to claim 1, characterized in that, If it is determined that the task status exists as either "in execution" or "pending execution", the status of the task corresponding to the SIM card attribute modification request is kept marked as "pending execution".

4. The asynchronous modification method for communication card attributes based on serial task number according to claim 1, characterized in that, Extract the target subtask from all tasks to be executed under the serial task number, including: Retrieve all tasks to be executed under the specified serial task number; Determine the request order field carried by the corresponding request in all the tasks to be executed, and take the subtask with the smallest value corresponding to the request order field as the target subtask; Specifically, based on the target subtask, sending a request to the communication server includes: Based on the target subtask, an HTTP or HTTPS request is sent to the attribute modification interface of the communication server, wherein the HTTP or HTTPS request carries the unique task ID and modification parameters; The request information table includes the unique task ID, request time, initial status, and number of retries for the task. The initial status is set to "in execution" and the initial value of the number of retries is zero.

5. The asynchronous modification method for communication card attributes based on serial task number according to claim 1, characterized in that, Based on the current execution state, perform the corresponding operation, including: If the current execution status is execution failure, determine whether the number of retries for the task corresponding to the non-completed task record exceeds a preset threshold. If not, determine the type of execution failure. If the type is network timeout or connection failure, use an exponential backoff retry mechanism to resend the request to the communication server. If the type is that the interface returns a preset error code, use a fixed interval retry mechanism to resend the request to the communication server. The higher the priority of the preset error code, the shorter the fixed interval. If so, mark the current execution status of the non-completed task record as a final failure and do not retry.

6. The method for asynchronous modification of communication card attributes based on serial task number according to claim 1, characterized in that, Based on the current execution state, perform the corresponding operation, including: If the current execution status is "execution successful", update the non-completed task record in the task table to "completed" status, and query under the same serial task number whether there is a subtask with the smallest value corresponding to the request order field and whose current status is "not executed". If it exists, send a request to the communication server and synchronously update the request information table and the task status in the task table; If it does not exist, periodically query the task table. If it is determined that all subtasks under the same serial task number are in the completed state, terminate the modification process and perform cleanup work.

7. The asynchronous modification method for communication card attributes based on serial task number according to claim 1, characterized in that, Based on the current execution state, perform the corresponding operation, including: If the current execution status is "in execution", then skip this polling and wait for the next periodic query.

8. A communication card attribute asynchronous modification system based on serial task number, characterized in that, include: The generation module is used to receive a card attribute modification request, generate a unique task ID and serial task number for the card attribute modification request, record the task information in the task table, and mark the status of the task corresponding to the card attribute modification request as pending execution. All attribute modification tasks of the same card share the same serial task number. The sending module is used to detect the task status corresponding to the serial task number. If it is determined that there is no running or pending task status in the task status, the target subtask is extracted from all pending tasks under the serial task number, and a request is sent to the communication server based on the target subtask. At the same time, the request information is recorded in the request information table. The execution module is used to periodically query all task records in the request information table whose task status is not completed, obtain the current execution status of the non-completed task records based on the calling interface, and perform corresponding operations based on the current execution status. The current execution status includes executing, executing successfully, and executing failed. The query module is used to periodically query the task table. If it is determined that all subtasks under the same serial task number are in the completed state, the modification process is terminated and cleanup work is performed. The status update operations of the task table and the request information table are both executed in the same database transaction.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 7.

Images