A processing method and device for attendance clock-in

Abstract

Embodiments of the present application disclose a processing method and device for attendance clock-in, and relate to the technical field of computer application. In view of the situation that the clock-in server end is under excessive pressure, the database is abnormal, and the like, and the request containing clock-in data cannot be processed in time, a new processing mechanism is proposed, that is, a delayed clock-in process is executed, so that the normal clock-in of a user can be realized under the abnormal condition of the server end without manual repeated attempts for clock-in, on the one hand, the normal clock-in demand of the user is ensured, on the other hand, the user operation is simplified, the user only needs to trigger the clock-in operation once, and on the other hand, the greater pressure on the clock-in server caused by repeated attempts for clock-in of the user is avoided. In addition, for the situation that the clock-in server does not receive the request and the network of the user is normal, an offline clock-in process is executed, so that even if the clock-in server does not receive the clock-in notification under some conditions, the normal clock-in of the user can be realized.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a method and apparatus for processing attendance and clocking in / out. Background Technology

[0002] Time and attendance tracking refers to employees signing in and out at specific locations at designated times, as stipulated by the company. This method is used to manage employee attendance and calculate working hours. With the development of technology, time and attendance tracking technology has evolved from manual recording and mechanical card-operated systems to electronic attendance systems and finally to cloud-based attendance systems.

[0003] With the rise of cloud computing technology, cloud-based attendance systems have gradually become a widely adopted method for clocking in and out. These systems store attendance data on cloud servers, enabling access and management anytime, anywhere. Employees can clock in and out via mobile apps, specific web pages, etc., while managers can view and manage attendance data in real time, improving convenience and real-time performance. However, with the rapid increase in the number of users clocking in and out, the attendance server experiences significant system pressure during peak clocking-in periods (morning, noon, and evening). When the server experiences excessive pressure and malfunctions, thousands of users may be unable to clock in normally. Therefore, this problem urgently needs to be addressed. Summary of the Invention

[0004] In view of this, this application provides a method and apparatus for processing attendance and clocking in, so as to solve the problem that users cannot clock in and out normally due to server-side anomalies.

[0005] This application provides the following solution:

[0006] Firstly, an attendance tracking method is provided, applied to a user terminal, the method comprising:

[0007] In response to a user triggering a check-in event, a request carrying check-in data is sent to the check-in server and the check-in data is recorded locally on the user terminal, wherein the status of the check-in data is a first state;

[0008] If it is determined that the check-in server has received the request but has not received the check-in result returned by the check-in server within a preset first time period, then a delayed check-in process is executed for the check-in data.

[0009] The delayed check-in process includes: updating the recorded check-in data to a second state, where the second state indicates that the request was successfully sent and the check-in result is pending; if the check-in result is received from the check-in server in response to the request, or in response to an event triggering the retrieval of check-in results, the check-in result is successfully retrieved from the check-in server based on the recorded check-in data in the second state, and then updating the recorded check-in data to a third state, where the third state indicates that the check-in was successful.

[0010] According to one achievable method in the embodiments of this application, the event that triggers the retrieval of check-in results includes: when the check-in data is in a second state, the check-in page is refreshed.

[0011] According to one achievable method in the embodiments of this application, the method further includes:

[0012] If it is determined that the check-in server has not received the request and the user's network is normal, then an offline check-in process is executed for the check-in data;

[0013] The offline check-in process includes: updating the status of the recorded check-in data to the fourth state, where the fourth state indicates that the request has not been sent; if an event triggering offline reporting is received, a request is sent to the check-in server for the check-in data in the fourth state; if a check-in result is obtained from the check-in server, the status of the recorded check-in data is updated to the third state.

[0014] According to one achievable method in the embodiments of this application, the event that triggers offline reporting includes:

[0015] Events triggered by timers, or,

[0016] The event that the check-in page is reopened.

[0017] According to one achievable method in an embodiment of this application, in the offline check-in process, before sending a request for the check-in data to the check-in server, the process further includes:

[0018] Determine if the current mode is in a downgrade mode. If it is, end the process; otherwise, execute the step of sending a request to the attendance server for the attendance data.

[0019] If a downgrade notification is received from the check-in server due to an error on the check-in server side, or if the check-in results are retrieved from the check-in server N times consecutively without success, the system is in downgrade mode, where N is a preset positive integer.

[0020] According to one achievable method in the embodiments of this application, the method further includes:

[0021] If a cancellation notification is received from the attendance server, the downgrade mode is cancelled.

[0022] According to one achievable method in the embodiments of this application, the offline check-in process further includes:

[0023] The attendance data is sent to the log server so that the log server can store the attendance data as an attendance log.

[0024] In response to an event that triggers the recovery of attendance data, the attendance data is retrieved from the log server.

[0025] According to one achievable method in the embodiments of this application, the method further includes:

[0026] If the recorded check-in data is in the second or fourth state, a prompt message will be displayed on the check-in page, indicating that the check-in has been completed and the check-in result is pending.

[0027] If the recorded check-in data is in the third state, then the displayed prompt message will be removed.

[0028] According to one achievable method in the embodiments of this application, the user-triggered check-in event includes: an event where the check-in component on the page component is triggered; the check-in data includes check-in type information corresponding to the check-in component;

[0029] If a check-in result is received from the check-in server within a preset first time period after the request carrying check-in data is sent to the check-in server, the check-in type corresponding to the check-in component is updated; or, if a delayed check-in process or an offline check-in process is executed, the check-in type corresponding to the check-in component is updated.

[0030] According to one achievable method in this application embodiment, if a receiving response is received from the check-in server in response to the request within a second preset time period after sending the request carrying check-in data to the check-in server, it is determined that the check-in server has received the request; otherwise, it is determined that the check-in server has not received the request.

[0031] Thirdly, an attendance processing device is provided for use in a user terminal, the device comprising:

[0032] The page interaction module is configured to acquire the user's check-in event, and in response to the user's check-in event, record the check-in data locally on the user's terminal.

[0033] The check-in processing module is configured to send a request carrying check-in data to the check-in server in response to the user triggering a check-in event;

[0034] An anomaly diagnosis module is configured to, if it is determined that the check-in server has received the request but has not received the check-in result returned by the check-in server within a preset first time period, trigger the check-in processing module to perform a delayed check-in process on the check-in data.

[0035] The check-in processing module is further configured to execute the delayed check-in process, wherein the delayed check-in process includes: updating the status of the recorded check-in data to a second status, the second status indicating that the request was successfully sent and waiting for the check-in result; if the check-in result returned by the check-in server in response to the request is received, or in response to an event triggering the retrieval of check-in results, the check-in result is successfully retrieved from the check-in server based on the recorded check-in data in the second status, then the status of the recorded check-in data is updated to a third status, the third status indicating that the check-in was successful.

[0036] According to a fourth aspect, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in any one of the first and second aspects.

[0037] According to the fifth aspect, an electronic device is provided, comprising:

[0038] One or more processors; and

[0039] A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any one of the first and second aspects above.

[0040] According to the specific embodiments provided in this application, the following technical effects are disclosed:

[0041] 1) This application proposes a novel processing mechanism to address situations where the check-in server is overloaded or experiences database anomalies, preventing the timely processing of requests containing check-in data. This mechanism involves a delayed check-in process. First, the check-in data status is updated to a second state to indicate successful request transmission but awaiting the check-in result. If the check-in server successfully returns the check-in result, or if the user successfully retrieves the check-in result from the server, the check-in data status is updated to a third state to indicate successful check-in. This delayed check-in method ensures normal user check-in even under server-side anomalies, eliminating the need for repeated manual attempts. This guarantees users' normal check-in needs, simplifies user operations (users only need to trigger the check-in action once), and avoids the increased pressure on the check-in server caused by repeated user attempts.

[0042] 2) This application addresses the scenario where the check-in server does not receive a request and the user's network is normal by implementing an offline check-in process. In the offline check-in process, the recorded check-in data status is first updated to the fourth state to indicate that the request was not sent. If an event triggering offline reporting is received, a request is sent to the check-in server for the check-in data. If the check-in result is obtained from the check-in server, the recorded check-in data status is updated to the third state, indicating successful check-in. This offline check-in method ensures that even if the check-in server does not receive a notification in some cases, the user can still check in normally without repeated manual attempts. This guarantees the user's normal check-in needs and simplifies the user operation, requiring only one check-in trigger.

[0043] 3) The offline check-in process means that even if the check-in server does not receive a check-in request, the user does not need to stay on the check-in page to wait for the check-in. Instead, when the user enters the check-in page again, the offline reporting event is triggered to upload the check-in data, resulting in a better user experience.

[0044] 4) The delayed check-in process and offline check-in process provided in this application ensure that check-in is successful even if the check-in request is not sent to the check-in server or the check-in server does not process it in time, and the user is almost unaware of it, thus improving the user experience.

[0045] 5) When the check-in server encounters anomalies such as insufficient computing resources or database failure, or fails to retrieve check-in results from the check-in server N times in a row, this application puts the user device into a degraded mode, thereby avoiding the user terminal from sending unnecessary requests when the check-in server is unresponsive, and reducing the performance impact on the user terminal and the check-in server.

[0046] 6) In the offline check-in process, this application sends the check-in data to the log server. The log server can store the check-in data as a check-in log, so that if the user terminal loses the check-in data due to an anomaly, the check-in data can be recovered from the log server.

[0047] 7) When the check-in data is in the second or fourth state in this application, a prompt message is displayed on the check-in page to indicate that the check-in has been completed and the check-in result is pending. This avoids the impact on the performance of the user terminal and the check-in server caused by the user frequently trying to check in during delayed check-in or offline check-in.

[0048] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a system architecture diagram applicable to the embodiments of this application;

[0051] Figure 2 A flowchart illustrating the attendance tracking method provided in this application embodiment;

[0052] Figure 3 This is a flowchart illustrating the overall process of attendance tracking provided in an embodiment of this application.

[0053] Figure 4a A schematic diagram of the check-in page provided in an embodiment of this application;

[0054] Figure 4b A schematic diagram of the interface displayed after clocking in, provided in an embodiment of this application;

[0055] Figure 4c A schematic diagram of another check-in page provided in an embodiment of this application;

[0056] Figure 5 A schematic diagram of the delayed check-in process provided in an embodiment of this application;

[0057] Figure 6 A schematic diagram of the offline check-in process provided in the embodiments of this application;

[0058] Figure 7 A flowchart illustrating the check-in process performed by the check-in server as provided in this embodiment of the application;

[0059] Figure 8 A flowchart of the check-in server response to retrieving check-in results provided in this application example;

[0060] Figure 9 A schematic block diagram of an attendance processing device provided in an embodiment of this application;

[0061] Figure 10 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0062] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0063] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0064] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0065] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0066] There are already some offline attendance solutions, but these solutions usually address attendance issues in scenarios with abnormal network conditions. However, there is no effective solution for offline attendance issues caused by abnormal server conditions such as excessive server load.

[0067] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: user terminal 101, network 102 and attendance server 103, and may further include log server 104.

[0068] Network 102 serves as a medium for providing a communication link between user terminal 101 and server-side devices such as attendance server 103 and log server 104. Network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0069] Users can use user terminal 101 to interact with attendance server 103 via network 102. Various applications can be installed on user terminal 101, including at least applications with attendance functionality in this embodiment, such as instant messaging applications with attendance functionality. Other applications can also be installed, such as voice interaction applications and web browser applications. To implement the attendance function, user terminal 101 can have basic functions such as location tracking and network connectivity.

[0070] User terminal 101 can be various electronic devices that support attendance tracking, including but not limited to: smart mobile terminals, wearable devices, etc. Smart mobile devices can include mobile phones, tablets, laptops, PDAs (Personal Digital Assistants), internet-connected cars, etc. Wearable devices can include smartwatches, smart glasses, smart bracelets, VR (Virtual Reality) devices, AR (Augmented Reality) devices, mixed reality devices (i.e., devices that support both virtual and augmented reality), etc. The attendance tracking processing device provided by this invention can be set up and run in or on the aforementioned user terminal 101. It can be implemented as multiple software programs or software modules (e.g., to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0071] For example, if the attendance check-in processing is set up and runs on the aforementioned user terminal 101, then the user can trigger attendance check-in through the user terminal 101. The user terminal 101 can use the method provided in this embodiment of the invention to send a request carrying check-in data to the check-in server to realize attendance check-in.

[0072] The attendance server 103 and the log server 104 can be single servers, or they can be located in a server cluster consisting of multiple servers, or they can be cloud servers. Cloud servers, also known as cloud computing servers or cloud hosts, are a host product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak service scalability.

[0073] The attendance server 103 receives a request carrying attendance data sent by the user terminal 101 and executes the attendance processing flow on the server side to realize the user's attendance attendance function.

[0074] In this embodiment of the application, the log server 104 is used to record the attendance data sent by the user terminal 101 and store the attendance data in the form of a log.

[0075] It should be understood that Figure 1 The number of user terminals, networks, attendance servers, and log servers shown is merely illustrative. Depending on implementation needs, any number of user terminals, networks, attendance servers, and log servers can be included.

[0076] Figure 2 This is a flowchart of an attendance tracking method provided in an embodiment of this application. The method can be performed by… Figure 1 User terminal 101 in the system shown executes the command. For example... Figure 2 As shown, the method may include the following steps:

[0077] Step 201: In response to the user triggering the check-in event, send a request carrying check-in data to the check-in server and record the check-in data locally on the user terminal. The status of the check-in data is the first state.

[0078] Step 203: If it is determined that the check-in server has received the request but has not received the check-in result from the check-in server within the preset first time period, then the delayed check-in process is executed for the check-in data.

[0079] Step 205: Execute the delayed check-in process: Update the status of the recorded check-in data to the second status, which indicates that the request was successfully sent and is waiting for the check-in result; if the check-in result is received from the check-in server in response to the request, or in response to the event that triggers the retrieval of check-in results, and the check-in result is successfully retrieved from the check-in server based on the check-in data in the second status, then update the status of the recorded check-in data to the third status, which indicates that the check-in was successful.

[0080] As can be seen from the above process, this application proposes a novel processing mechanism to address situations where the check-in server is overloaded or experiences database anomalies, preventing the timely processing of requests containing check-in data. This mechanism involves executing a delayed check-in process. First, the check-in data status is updated to the second state to indicate that the request was successfully sent but the check-in result is pending. If the check-in server successfully returns the check-in result, or if the user successfully retrieves the check-in result from the check-in server on their terminal, the check-in data status is updated to the third state to indicate successful check-in. This delayed check-in method ensures normal user check-in even in the event of server-side anomalies, eliminating the need for repeated manual attempts. This guarantees users' normal check-in needs, simplifies user operations (users only need to trigger the check-in action once), and avoids the increased pressure on the check-in server caused by repeated user attempts.

[0081] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first," "second," etc., involved in this disclosure do not have limitations in terms of size, order, or quantity, but are only used to distinguish them by name. For example, "first state," "second state," and "third state" are used to distinguish different states by name.

[0082] Figure 3 The overall processing flowchart for attendance tracking provided in this application embodiment is as follows: Figure 3 As shown, the overall processing flow may include the following steps:

[0083] In step 301, a check-in page is provided to the user.

[0084] The check-in page can be provided to users by applications with check-in functionality, or it can be a specific check-in page provided to users through a browser, and so on. For example, when a user checks in an instant messaging application, the attendance function component is triggered, leading to the check-in page.

[0085] The check-in page can include components that trigger check-in, and can further display the current time, current check-in type, etc. For example... Figure 4a As shown in the diagram, the circular component corresponds to the component that triggers the clock-in process. This component displays the current time, 08:45:00, and the current clock-in type, "clock out." It can also further include the current location, whether the user is within the attendance range, etc.

[0086] In step 303, in response to the user triggering the check-in event, a request carrying check-in data is sent to the check-in server and the check-in data is recorded locally on the user terminal. The status of the check-in data is the first status.

[0087] Users can trigger the check-in event by activating components on the check-in page, or through other methods such as voice assistants, which will not be listed here. When a user activates a component on the check-in page, the user terminal can first determine whether the user is within the attendance range via location. If so, check-in is allowed, and a request carrying check-in data is sent to the check-in server; otherwise, the user can be directly notified that they are not within the attendance range. Location methods can include, but are not limited to, GPS (Global Positioning System) positioning, Wi-Fi positioning, cell tower triangulation, etc.

[0088] The aforementioned check-in data can include information such as check-in time, check-in location, check-in type, and check-in status. Check-in type can be such as clocking in / out, clocking out / out, or field work check-in. The check-in type is usually determined based on a combination of factors, including the type and location of the previous check-in. For example, if the previous check-in was a clock-in / out, and this check-in is within the attendance range, it is generally considered a clock-out / out. Conversely, if this check-in is outside the attendance range and the user selected the field work check-in method, it is considered a field work check-in.

[0089] In this embodiment, the check-in status mainly includes a first state, a second state, a third state, and a fourth state. The first state is actually the initial state of the check-in data. The second state indicates that the request was successfully sent and the check-in result is pending. The third state indicates that the check-in was successful. The fourth state indicates that the request was not sent. It should be noted that, in this embodiment, the first and fourth states can also be set as a single state to indicate that the request was not sent.

[0090] In step 305, anomaly diagnosis is performed. If no anomaly is found, the normal check-in process is executed in step 307. If it is determined that the check-in server received the request but did not receive the check-in result returned by the check-in server within a preset first time period, the delayed check-in process is executed in step 309. If it is determined that the check-in server did not receive the request and the user's network is normal, the offline check-in process is executed in step 311. If it is determined that the user's network is abnormal (this situation is not shown in the figure), the user is prompted that the network is abnormal and the process ends.

[0091] The above-mentioned method for anomaly diagnosis involves sending a request containing attendance data to the attendance server. If a response is received from the attendance server within a second preset time period, it is confirmed that the attendance server has received the request, where the second preset time period is less than the first preset time period; otherwise, it is confirmed that the attendance server has not received the request. Diagnosis of user network anomalies can be performed by assessing the strength of the network signal, and can be implemented using any existing technology, which will not be detailed here.

[0092] It's also important to note that regardless of whether the check-in process is normal, offline, or delayed, the check-in type in the check-in component is updated after the check-in data is stored locally, ensuring it doesn't affect the user's next check-in. For example, after a user triggers their work attendance check-in, whether it's a normal, offline, or delayed check-in, the check-in type in the check-in component is updated to "off-get off work check-in" after the check-in data is stored locally. This allows the user to trigger their off-get off work check-in normally the next time.

[0093] The normal check-in process, delayed check-in process, and offline check-in process are described in detail below with reference to specific examples.

[0094] First, the normal check-in process is described. This process is consistent with existing technologies: the user terminal sends a request carrying check-in data to the server. Upon receiving the request, the server returns a response to the user terminal and then adds the request to a message queue for asynchronous processing. If no exceptions occur on the server side, it performs the check-in calculation normally, such as processing the check-in time and location information, and returns the check-in result to the user terminal. Simultaneously, the check-in server caches the result. After receiving the check-in result, the user terminal updates the recorded check-in data status to the third state, indicating successful check-in.

[0095] The following is combined Figure 5 Provide a detailed description of the delayed check-in process. For example... Figure 5 As shown, the delayed check-in process can specifically include the following steps:

[0096] In step 501, the status of the updated attendance data is changed to the second status.

[0097] The second status indicates that the request was successfully sent and is awaiting the check-in result.

[0098] In step 503, the user is prompted on the check-in page that they have checked in and are waiting for the check-in result.

[0099] If delayed check-in has been confirmed, it means that the request has been successfully sent to the check-in server. To avoid users trying to check in multiple times, the check-in page can display a message indicating that the user has checked in and is waiting for the check-in result. This way, users will know that they have checked in and will not put further pressure on the check-in server by trying to check in multiple times.

[0100] like Figure 4b As shown, if a user triggers the check-in at 08:45 and executes the delayed check-in process, the interface will display the message "This check-in has been recorded, the result is being calculated, and you can view the check-in result in the statistics later" after the check-in. Figure 4b The prompt message shown is merely one example. Other prompt messages or display methods may be used, as long as they are within the spirit and principles of this application and fall within the scope of protection of this application.

[0101] In step 505, is a check-in result returned by the check-in server in response to the request received? If yes, proceed to step 507; otherwise, proceed to step 509.

[0102] In step 507, the status of the locally recorded check-in data is updated to the third status, and the above prompt that the user has checked in and is waiting for the check-in result is removed.

[0103] The third status indicates that the check-in was successful.

[0104] In step 509, it is determined whether the event of retrieval of check-in results has been triggered. If so, step 511 is executed; otherwise, the process continues to step 505 or step 509 for monitoring (the figure takes step 505 as an example).

[0105] In this application embodiment, the event that triggers the check-in result retrieval can be of various types: for example, if the status data of the check-in data is in the second state and the check-in page is refreshed (e.g., the user actively queries the check-in results through the check-in page, causing the page to be refreshed), then the check-in result retrieval event can be considered triggered; another example is that the check-in data status data is in the second state and the check-in result retrieval event is triggered periodically; and so on.

[0106] In step 511, the attendance results are retrieved from the attendance server based on the recorded attendance data.

[0107] The term "retrieving check-in results" refers to requesting the check-in result from the check-in server's cache. If the check-in server determines that the requested check-in result already exists in its cache, it will return the result to the check-in server. During this retrieval process, the request is not placed in a message queue by the check-in server to await check-in calculation. Since the check-in results obtained after processing are cached by the check-in server and sent sequentially to the corresponding user terminals, for each retrieval request, the check-in server directly checks whether the cache contains the requested check-in result—that is, whether the check-in result has already been generated. If it has, it directly returns the result to the user terminal, ensuring the user terminal retrieves the check-in result; otherwise, it does not return the result, and the user terminal does not retrieve the check-in result.

[0108] In step 513, it is determined whether the attendance result has been retrieved. If the attendance result has been retrieved, step 507 is executed; otherwise, the process continues to step 505 or step 509 for monitoring (the figure takes step 505 as an example).

[0109] It should be noted that steps 505 and 509 can be executed in any order, or simultaneously. The order of executing step 505 first and then step 509 provided in this embodiment is only one possible way.

[0110] The following is combined Figure 6 Provide a detailed description of the offline check-in process. For example... Figure 6 As shown, the offline check-in process may include the following steps:

[0111] In step 601, the status of the updated attendance data is set to the fourth state, which indicates that the request has not been sent.

[0112] In step 603, the user is prompted on the check-in page that they have checked in and are waiting for the check-in result.

[0113] If offline check-in has been confirmed, it means that the request has been recorded locally but has not yet been successfully sent. To avoid users trying to check in frequently, a message can be displayed on the check-in page indicating that the user has checked in and is waiting for the check-in result.

[0114] like Figure 4c As shown, if a user triggers the check-in at 10:05 and confirms the execution of the offline check-in process, the interface will display the message "10:05 check-in has been recorded, the result is being calculated, no need to check in again" after the check-in. Figure 4c The prompt message shown is merely one example. Other prompt messages or display methods may be used, as long as they are within the spirit and principles of this application and fall within the scope of protection of this application.

[0115] In step 605, the attendance data is sent to the log server so that the log server can store the attendance data as attendance logs.

[0116] In the offline check-in process provided in this application embodiment, since the request cannot be successfully sent to the check-in server, to avoid the accidental loss of check-in data on the user terminal and thus check-in failure, the check-in data can be sent to a log server, which stores the check-in data as a check-in log. If a user terminal experiences an anomaly that results in the loss of check-in data, it can request the log server to recover the check-in data. That is, the user terminal responds to an event that triggers data recovery; for example, the user can trigger data recovery through a specific component on the check-in page, and the user terminal retrieves the check-in data from the log server. For example, the log server can use the most recent check-in log corresponding to the user terminal to recover the check-in data.

[0117] In step 607, if an event triggering offline reporting is received, it is determined whether the current mode is downgraded. If it is downgraded, the current offline check-in process ends; otherwise, step 609 is executed.

[0118] In this embodiment of the application, the events that trigger offline reporting may include, but are not limited to, events triggered by a timer, events where the check-in page is reopened, and so on.

[0119] In this embodiment, if the check-in server experiences an anomaly such as insufficient computing resources or database failure, a degradation notification can be sent to the user terminal. Alternatively, if the user terminal fails to retrieve check-in results from the check-in server N times consecutively, it can be considered that the user terminal is experiencing an anomaly such as insufficient computing resources or database failure, and the user terminal can switch to degradation mode. Here, N is a preset positive integer, such as 2. Alternatively, a component to trigger degradation can be provided on the check-in page; after the user triggers this component, the user enters degradation mode.

[0120] If the clock-in server's computing resources are restored, a notification to cancel the downgrade can be sent to the user terminal. After receiving the notification, the user terminal cancels the downgrade mode.

[0121] If the user terminal determines that it is currently in degraded mode, it means that the check-in server has insufficient computing resources. Even if a request is sent, the check-in server may not be able to process it for a long time, so the current offline check-in process ends.

[0122] In step 609, is there any attendance data in the fourth state recorded locally? If so, proceed to step 611; otherwise, end the current offline attendance process.

[0123] In step 611, a request is sent to the attendance server for the attendance data in the fourth state.

[0124] In this step, the user terminal can send a batch of requests to the attendance server for attendance data in the fourth state (i.e., no request has been sent yet), and the request carries the attendance data.

[0125] In step 613, the attendance result sent by the attendance server is received, and the corresponding attendance data status is updated to the third status.

[0126] It should be noted that after step 611 above, there may be situations where the check-in server receives the request or not. If it is determined that the check-in server received the request but no check-in result is received from the check-in server within the preset first time period, the process will switch to the delayed check-in process. If it is determined that the check-in server did not receive the request and the user's network is normal, the current offline check-in process will end, and subsequent processes will still use the offline check-in process. If it is determined that the user's network is abnormal (this situation is not shown in the figure), the user will be prompted that the network is abnormal, and the process will end.

[0127] In addition, in the above offline check-in process, the frequency of request sending can be controlled when sending the request in step 611 to avoid putting too much pressure on the check-in server.

[0128] Through the above process, after a user triggers the check-in component, the user's terminal stores the check-in request locally, and the user can then exit the check-in page. Although the check-in request is not sent to the check-in server, the check-in data is updated to the fourth state. The next time the user reopens the check-in page, the locally stored check-in data in the fourth state will be sent to the check-in server in batches, thus achieving offline check-in.

[0129] Figure 7 The flowchart of the attendance processing performed by the attendance server provided in the embodiments of this application is as follows: Figure 7 As shown, the check-in process may include the following steps:

[0130] In step 701, the attendance server receives a request carrying attendance data.

[0131] In step 703, the attendance server adds the request to the message queue for asynchronous processing and then executes step 705.

[0132] In step 705, a response is returned to the user terminal.

[0133] In step 706, the clock-in calculation is performed, such as processing the clock-in time and location information.

[0134] In step 709, the attendance results are stored in the cache, and step 711 is executed.

[0135] In step 711, the check-in result is pushed to the corresponding user terminal.

[0136] The above process is the basic attendance processing flow of the attendance server, and will not be described in detail here.

[0137] If a user terminal requests to retrieve the attendance results, then execute... Figure 8 The process shown includes the following steps:

[0138] In step 801, the attendance server obtains the user terminal's request to retrieve the attendance results.

[0139] In step 803, it is determined whether the requested check-in result exists in the cache. If it does, step 805 is executed; otherwise, step 807 is executed.

[0140] In step 805, the check-in result is returned to the user terminal.

[0141] In step 807, a downgrade notification is sent to the user terminal.

[0142] In this embodiment, if the requested check-in result is not in the cache, it can be assumed that the check-in server's computing resources are insufficient and the user terminal fails to retrieve it. A degradation notification can then be sent to the user terminal. Alternatively, a degradation notification can be sent to the user terminal only after the user terminal has failed to retrieve the check-in result a preset number of times.

[0143] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0144] According to another embodiment, an attendance processing device is provided. Figure 9 A schematic block diagram of an attendance processing device according to one embodiment is shown, the device being disposed in... Figure 1 The user terminal in the architecture shown. Figure 9 As shown, the device 900 includes: a page interaction module 901, a check-in processing module 902, and an anomaly diagnosis module 903. The main functions of each component are as follows:

[0145] The page interaction module 901 is configured to acquire the user's check-in event, respond to the user's check-in event, and record the check-in data locally on the user's terminal.

[0146] The attendance processing module 902 is configured to send a request carrying attendance data to the attendance server in response to a user-triggered attendance event.

[0147] The anomaly diagnosis module 903 is configured to trigger the check-in processing module 902 to perform a delayed check-in process on the check-in data if it is determined that the check-in server has received a request but has not received a check-in result from the check-in server within a preset first time period.

[0148] The attendance processing module 902 is also configured to execute a delayed attendance process, which includes: updating the status of the recorded attendance data to the second status, which indicates that the request was successfully sent and is waiting for the attendance result; if the attendance result returned by the attendance server in response to the request is received, or in response to an event that triggers the retrieval of attendance results, the attendance result is successfully retrieved from the attendance server based on the recorded attendance data in the second status, and then the status of the recorded attendance data is updated to the third status, which indicates that the attendance was successful.

[0149] Among them, the events that trigger the retrieval of check-in results include: the event where the check-in page is refreshed when the check-in data is in the second state.

[0150] Furthermore, the anomaly diagnosis module 903 is further configured to trigger the attendance processing module 902 to perform an offline attendance process on the attendance data if it is determined that the attendance server has not received the request and the user's network is normal.

[0151] The attendance processing module 902 is also configured to execute an offline attendance process: update the status of the recorded attendance data to the fourth state, which indicates that the request has not been sent; if an event triggering offline reporting is received, a request is sent to the attendance server for the attendance data in the fourth state; if the attendance result is obtained from the attendance server, the status of the recorded attendance data is updated to the third state.

[0152] The events that trigger offline reporting may include, but are not limited to: events triggered by timers, or events where the check-in page is reopened.

[0153] As one possible implementation method, the attendance processing module 902, in the offline attendance process, can be configured to: determine whether it is currently in degraded mode; if in degraded mode, end the process; otherwise, execute the step of sending a request for attendance data to the attendance server; wherein, if a degrade notification is received from the attendance server due to an exception on the attendance server side, or if the attendance results are retrieved from the attendance server N times consecutively without success, then it is in degraded mode, where N is a preset positive integer. Exceptions on the attendance server side can include, for example, insufficient computing resources, database failure, etc.

[0154] Furthermore, the attendance processing module 902 is further configured to: cancel the downgrade mode if it receives a cancellation downgrade notification from the attendance server.

[0155] As one possible implementation method, the attendance processing module 902 can be further configured in the offline attendance process to send attendance data to the log server so that the log server can store the attendance data as attendance logs; and to retrieve attendance data from the log server in response to an event that triggers the recovery of attendance data.

[0156] As one possible implementation method, the page interaction module 901 can be further configured to: if the recorded check-in data is in the second or fourth state, display a prompt message on the check-in page to indicate that the check-in has been completed and the check-in result is pending; if the recorded check-in data is in the third state, remove the displayed prompt message.

[0157] One possible implementation method is that the user-triggered check-in event can include: the check-in component on the page being triggered. The check-in data can include the check-in type information corresponding to the check-in component. If a check-in result is received from the check-in server within a preset first time interval after sending a request carrying check-in data to the check-in server, the page interaction module 901 can update the check-in type corresponding to the check-in component; or, if a delayed check-in process or an offline check-in process is executed, the page interaction module 901 can update the check-in type corresponding to the check-in component.

[0158] As one possible implementation method, the anomaly diagnosis module 903 can be specifically configured as follows: if the user terminal receives a response from the check-in server in response to the request within a second preset time period after sending a request carrying check-in data to the check-in server, then it is determined that the check-in server has received the request; otherwise, it is determined that the check-in server has not received the request.

[0159] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0160] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0161] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0162] And an electronic device, comprising:

[0163] One or more processors; and

[0164] A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0165] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0166] in, Figure 10 An exemplary architecture of an electronic device is shown, which may include a processor 1010, a video display adapter 1011, a disk drive 1012, an input / output interface 1013, a network interface 1014, and a memory 1020. The processor 1010, video display adapter 1011, disk drive 1012, input / output interface 1013, network interface 1014, and memory 1020 can communicate with each other via a communication bus 1030.

[0167] The processor 1010 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0168] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system 1021 for controlling the operation of the electronic device 1000, and the basic input / output system (BIOS) 1022 for controlling the low-level operations of the electronic device 1000. Additionally, it can store a web browser 1023, a data storage management system 1024, and an attendance processing device 1025, etc. The aforementioned attendance processing device 1025 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0169] Input / output interface 1013 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0170] The network interface 1014 is used to connect the communication module (not shown in the figure) to enable communication and interaction between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0171] Bus 1030 includes a pathway for transmitting information between various components of the device (e.g., processor 1010, video display adapter 1011, disk drive 1012, input / output interface 1013, network interface 1014, and memory 1020).

[0172] It should be noted that although the above-described device only shows the processor 1010, video display adapter 1011, disk drive 1012, input / output interface 1013, network interface 1014, memory 1020, bus 1030, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0173] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. 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 computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0174] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing attendance tracking, applied to a user terminal, characterized in that, The method includes: In response to a user triggering a check-in event, a request carrying check-in data is sent to the check-in server and the check-in data is recorded locally on the user terminal. The check-in type corresponding to the check-in component is updated to the check-in type of the next stage, and the status of the check-in data is the first state. If it is determined that the check-in server has received the request but has not received the check-in result returned by the check-in server within a preset first time period, then a delayed check-in process is executed for the check-in data. The delayed check-in process includes: updating the recorded check-in data to a second state, indicating that the request was successfully sent and the check-in result is pending; if the check-in result is received from the check-in server in response to the request, or in response to an event triggering the retrieval of check-in results, the check-in result is successfully retrieved from the cache of the check-in server based on the recorded check-in data in the second state, then the recorded check-in data is updated to a third state, indicating that the check-in was successful; wherein, after the server performs check-in calculation processing on the request, it returns the check-in result to the user terminal and caches the check-in result.

2. The method according to claim 1, characterized in that, The events that trigger the retrieval of check-in results include: when the check-in data is in the second state, the check-in page is refreshed.

3. The method according to claim 1, characterized in that, The method further includes: If it is determined that the check-in server has not received the request and the user's network is normal, then an offline check-in process is executed for the check-in data; The offline check-in process includes: updating the status of the recorded check-in data to the fourth state, where the fourth state indicates that the request has not been sent; if an event triggering offline reporting is received, a request is sent to the check-in server for the check-in data in the fourth state; if a check-in result is obtained from the check-in server, the status of the recorded check-in data is updated to the third state.

4. The method according to claim 3, characterized in that, The events that trigger offline reporting include: Events triggered by timers, or, The event that the check-in page is reopened.

5. The method according to claim 3, characterized in that, In the offline check-in process, before sending a request to the check-in server for the check-in data, the process further includes: Determine if the current mode is in a downgrade mode. If it is, end the process; otherwise, execute the step of sending a request to the attendance server for the attendance data. If a downgrade notification is received from the check-in server due to an error on the check-in server side, or if the check-in results are retrieved from the check-in server N times consecutively without success, the system is in downgrade mode, where N is a preset positive integer.

6. The method according to claim 5, characterized in that, The method further includes: If a cancellation notification is received from the attendance server, the downgrade mode is cancelled.

7. The method according to claim 3, characterized in that, The offline check-in process also includes: The attendance data is sent to the log server so that the log server can store the attendance data as an attendance log. In response to an event that triggers the recovery of attendance data, the attendance data is retrieved from the log server.

8. The method according to claim 3, characterized in that, The method further includes: If the recorded check-in data is in the second or fourth state, a prompt message will be displayed on the check-in page, indicating that the check-in has been completed and the check-in result is pending. If the recorded check-in data is in the third state, then the displayed prompt message will be removed.

9. The method according to claim 3, characterized in that, The events that trigger user check-in include: the event of the check-in component on the page being triggered; the check-in data includes the check-in type information corresponding to the check-in component; If a check-in result is received from the check-in server within a preset first time period after the request carrying check-in data is sent to the check-in server, the check-in type corresponding to the check-in component is updated; or, if a delayed check-in process or an offline check-in process is executed, the check-in type corresponding to the check-in component is updated.

10. The method according to claim 1 or 3, characterized in that, If a response to the request is received from the check-in server within the second preset time period after the request carrying check-in data is sent to the check-in server, it is determined that the check-in server has received the request; otherwise, it is determined that the check-in server has not received the request.

11. An attendance processing device, applied to a user terminal, characterized in that, The device includes: The page interaction module is configured to obtain the user's check-in event, respond to the user's check-in event, record check-in data locally on the user's terminal, and update the check-in type corresponding to the check-in component to the check-in type of the next stage. The check-in processing module is configured to send a request carrying check-in data to the check-in server in response to the user triggering a check-in event; An anomaly diagnosis module is configured to, if it is determined that the check-in server has received the request but has not received the check-in result returned by the check-in server within a preset first time period, trigger the check-in processing module to perform a delayed check-in process on the check-in data. The check-in processing module is further configured to execute the delayed check-in process, wherein the delayed check-in process includes: updating the recorded check-in data status to a second status, the second status indicating that the request was successfully sent and waiting for the check-in result; if the check-in result returned by the check-in server in response to the request is received, or in response to an event triggering the retrieval of check-in results, the check-in result is successfully retrieved from the check-in server based on the recorded check-in data in the second status, then the recorded check-in data status is updated to a third status, the third status indicating successful check-in; wherein, after the server performs check-in calculation processing on the request, it returns the check-in result to the user terminal and caches the check-in result.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 10.

13. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 10.

Images