Multi-terminal offline message storage method for electric power heterogeneous mobile application platform

Abstract

The invention discloses a multi-terminal off-line message storage method for a power heterogeneous mobile application platform, particularly relates to the technical field of power industry mobile application message authority control, and is used for solving the problem that in a multi-terminal heterogeneous environment, after user authority contraction, historical off-line messages are still kept in local terminals for a long time and cannot be unified and invalid. The method comprises the following steps: generating an offline message record carrying permission identification information and message index information for each message to be issued on a server side, registering a terminal permission tracking table, constructing a permission state table on a terminal side, and dynamically updating according to a permission change instruction; the terminal executes deletion or encryption shielding processing on the local offline message record based on the permission state table and generates failure processing result information, and the server re-schedules a permission change instruction in combination with the failure processing result information to realize multi-terminal offline message consistent failure control.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of mobile application message permission control in the power industry, and more particularly, to a multi-terminal offline message storage method for a power heterogeneous mobile application platform. BACKGROUND

[0002] Under the background of building a heterogeneous mobile application platform in a power enterprise, instant messaging capabilities are usually deeply integrated with enterprise address books and permission systems, and the visible range of different types of messages such as dispatch instructions, operation information, device data, and customer information is finely controlled through organizational structure and post roles. In order to adapt to weak network or even no network environments such as mountain line inspection, underground pipe corridors, and plant station areas, the platform needs to provide multi-terminal offline message storage capabilities on mobile phones, tablets, special handheld terminals, and desktop terminals, so that field personnel can still view past instructions and business exchange records locally when they cannot connect to the server in real time. Most existing multi-terminal message systems focus on server-side access control, determining whether to issue messages to terminals by checking the current permissions of users, and regarding the local offline message cache of each terminal as an auxiliary function to improve usability and experience. There is a lack of close linkage and unified constraints between enterprise address books and permission systems in terms of offline storage structure design, key management, and life cycle control.

[0003] In the prior art, permission changes first occur on the enterprise address book and server access control side, while the multi-terminal offline messages have been previously stored in the form of local database files, encrypted caches, or system sandboxes in a large number of terminals. These terminals may be in a state of long-term shutdown, no network, or system restrictions on background running, and cannot reliably receive control instructions related to permission shrinkage. At the same time, different operating systems have differences in local encryption capabilities, remote erasure interfaces, and file access control, making it difficult to rely solely on server-delivered deletion or cleaning instructions to make offline messages truly invalid on multiple terminals in a timely and thorough manner. The direct consequence is that sensitive content such as dispatch instructions and device data obtained and cached by users through multi-terminal offline message storage capabilities during normal permission periods may still be viewed and further spread through local offline records after their post adjustment, contract expiration, or account access restriction, causing a persistent risk that conflicts with the strict confidentiality and compliance requirements of the power industry.

[0004] To solve the above problems, a technical solution is provided. SUMMARY

[0005] To overcome the above-mentioned defects of the prior art, embodiments of the present application provide a power heterogeneous mobile application platform multi-terminal offline message storage method, which generates offline message records carrying permission identification information and message index information for each message to be issued and registers a terminal permission tracking table on the server side, constructs a permission state table on the terminal side and dynamically updates according to permission change instructions, performs deletion or encryption shielding processing on local offline message records based on the permission state table on the terminal, and generates invalid processing result information, and the server re-schedules the permission change instructions to achieve consistent invalidation control of multi-terminal offline messages based on the invalid processing result information to solve the problems raised in the above background art.

[0006] To achieve the above object, the present application provides the following technical solutions: S1: On the server side, generate offline message records carrying permission identification information and message index information for messages to be issued according to the current user's permission state, and issue the offline message records together with the corresponding terminal identification information to each registered terminal; S2: On each terminal, establish a permission state table according to the permission identification information, message index information in the offline message records, and the terminal identification information of the local terminal, and update the permission state in the permission state table using the permission identification information when a permission change instruction is received from the server; S3: On each terminal, when a user accesses local offline message records or when the terminal is in an idle state, check the local offline message records one by one according to the updated permission state table, write invalidation marker information to offline message records whose permission state has been contracted, and delete or encrypt and shield the corresponding offline message records according to the invalidation marker information, while generating invalid processing result information containing message index information and invalidation marker information; S4: On the server side, record the invalidation processing state of offline message records corresponding to different permission identification information by each terminal in the terminal permission tracking table according to the invalid processing result information, and generate new permission change instructions for terminals that have not completed invalidation processing for issuance when the terminal is connected to the server again, so as to prompt each terminal to continue to perform steps S2 and S3 until the permission state and the invalidation marker information of the offline message records are consistent.

[0007] Further, step S1 includes collecting user permission states on the server side to generate permission identification information and register in the permission mapping table, combining the session identification sequence number and business source code of each message to be issued to form message index information and register in the message index registration table.

[0008] Furthermore, in step S1, an offline message record containing permission identification information, message index information, message content reference address, and terminal identification information is constructed for each message based on the terminal identification information associated with the user. The offline message record processing status is then registered in the terminal permission tracking table using a combination of message index information and terminal identification information as the key value.

[0009] Furthermore, in step S2, the terminal receives offline message records that match the terminal identification information and generates an intermediate structure record containing permission identification information, message index information, message content reference address, and local storage location pointer. Based on the intermediate structure record, a permission status table is constructed with permission identification information as the key.

[0010] Furthermore, the permission status table includes a current permission status field, a version time field, and a related message index set field. By listening to permission change instructions, the permission identification information, new permission status, and permission effective time are parsed, and the corresponding records in the permission status table are compared with the time to update the current permission status field and the version time field.

[0011] Furthermore, in step S3, after the terminal receives the offline message verification trigger condition, a target set is constructed from the intermediate structure record, and access determination is performed on the corresponding offline message record in the target set based on the permission identifier information in the permission status table and the current permission status field.

[0012] Furthermore, in step S3, the offline message records that are prohibited from access are deleted or encrypted and blocked according to the policy, and the failure mark information is written into the intermediate structure record. At the same time, the failure processing result entry containing terminal identification information, message index information, permission identification information, failure mark information and verification time field is generated and written into the failure processing result cache queue.

[0013] Furthermore, in step S4, after the server receives the failure processing result information message reported by the terminal, it writes the terminal identification information, message index information and permission identification information into the failure processing result receiving cache table, and updates the current processing status field and the most recent processing time field in the terminal permission tracking table accordingly. It also compiles a message processing progress summary table containing the list of terminal identification information that has not been processed according to the message index information.

[0014] Furthermore, step S4 generates permission change instruction entries with terminal identification information, permission identification information and permission effective time fields for terminals that have not completed processing, based on the permission identification information in the permission mapping table that are in a prohibited access state. These entries are written into the permission adjustment queue to be issued and issued to the corresponding terminals according to the retry threshold control.

[0015] The technical effects and advantages of the multi-terminal offline message storage method for a heterogeneous mobile application platform for power systems according to the present invention are as follows: This invention generates offline message records carrying permission identification information and message index information uniformly on the server side, constructs an independently updatable permission status table on the terminal side, and combines the linkage between the failure handling results reported by the terminal and the terminal permission tracking table and message processing progress summary table. This enables permission changes to be continuously transmitted from the permission mapping layer to the local offline message storage layer of each terminal, achieving consistent control of the offline message failure status in scenarios with multiple terminals and long-term operation in weak networks. This effectively reduces the risk of leakage of sensitive information remaining in external terminals and various heterogeneous terminals after permission contraction.

[0016] By recording the offline message processing results in a closed loop with the terminal permission tracking table, and compiling a list of terminals that have not completed processing at the message granularity, coupled with a permission change instruction scheduling mechanism for specific terminals, operations and maintenance personnel can centrally monitor the processing progress of each message on each terminal on the server side, reducing manual verification and repetitive configuration, and improving the controllability and traceability of permission contraction execution. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a multi-terminal offline message storage method for a heterogeneous mobile application platform for power systems, according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments 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, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: Figure 1 This invention discloses a multi-terminal offline message storage method for a heterogeneous power mobile application platform, comprising: S1: On the server side, based on the current user's permission status, generate an offline message record carrying permission identification information and message index information for the message to be sent, and send the offline message record along with the corresponding terminal identification information to each registered terminal.

[0020] S2: On each terminal, a permission status table is established based on the permission identifier information, message index information and the terminal identifier information of the local machine in the offline message record. When a permission change instruction is received from the server, the permission status in the permission status table is updated using the permission identifier information.

[0021] S3: On each terminal, when a user accesses local offline message records or when the terminal is idle, the local offline message records are checked one by one according to the updated permission status table. For offline message records whose permission status has been contracted, invalidation mark information is written and the corresponding offline message records are deleted or encrypted and blocked according to the invalidation mark information. At the same time, invalidation processing result information containing message index information and invalidation mark information is generated.

[0022] S4: On the server side, based on the failure handling result information, the failure handling status of each terminal for the offline message record corresponding to different permission identifier information is recorded in the terminal permission tracking table. For terminals that have not completed failure handling, a new permission change instruction is generated and sent when the terminal reconnects to the server, so as to prompt each terminal to continue to execute steps S2 and S3 until the permission status is consistent with the failure mark information of the offline message record.

[0023] In the multi-terminal offline messaging scenario of a heterogeneous power mobile application platform, subsequent steps require the terminal side to construct a permission status table based on unified permission identification information and message index information. Simultaneously, the server needs to track the processing status of offline message records for each terminal based on the terminal permission tracking table. If user permission status, business message attributes, and terminal registration information are not encoded and registered according to unified rules during the initial offline message record construction phase, any subsequent operations regarding permission contraction and offline invalidation cannot be implemented for specific messages and terminals. Therefore, step S1 revolves around three consecutive objectives: user permission status collection and permission identification information generation, message index information generation and registration, and offline message record generation and terminal mapping registration. Through sequential processing, the originally scattered permission configuration data, business message data, and terminal registration data are transformed into structured offline message record basic data for direct use in subsequent steps.

[0024] Step S1-1: User permission status collection and permission identification information generation.

[0025] The server first reads the set of permission elements corresponding to the target user identifier from the permission configuration storage. This set includes at least the user's organizational path code, job title code, and message access level code in the power business. Each field is stored in fixed-length or prefixed format for stable subsequent combination. The server writes the organizational path code, job title code, and message access level code into a permission element buffer in a preset order. After writing each field, a fixed delimiter byte sequence is inserted. This delimiter byte sequence is selected to be unique to the business field code, allowing for accurate reconstruction of field boundaries during subsequent parsing. After writing the fields, the server applies a deterministic hash algorithm to the permission element buffer. The hash algorithm can use a publicly available cryptographic hash function, outputting a fixed-length permission identifier, which is considered the unique identifier of the current permission element set. Subsequently, the server creates or updates a record in the permission mapping table. This record includes at least a user identifier field, a permission identifier information field, and a permission effective time field. The user identifier field indicates the object to which the permission belongs; the permission identifier information field is used for reference in subsequent offline message records; and the permission effective time field distinguishes different versions of the permission identifier information when permissions change. Based on this, the server completes the one-way encoding from the set of permission elements to the permission identifier information and establishes a queryable permission mapping record for each user.

[0026] Step S1-2: Message index information generation and registration.

[0027] For each message to be sent submitted by the business side, the server generates message index information and registers the correspondence between this message index information and the message content in the message index registration table. Specifically, the server first determines the session identifier to which the message to be sent belongs. The session identifier can be derived from the session code assigned when the business session is created. The server then queries the message index registration table for the maximum sequence number corresponding to the current session identifier. If the query result is empty, an initial sequence number is assigned to the current message. If a historical sequence number exists, it is incremented by one from the maximum sequence number to obtain the current message's sequence number. Next, the server assigns a business source code based on the message source module; for example, a fixed-length business module code can be used as the business source code. Subsequently, the server constructs a message index element buffer according to a fixed order of the session identifier field, sequence number field, and business source code field. The construction method is similar to step S1-1, also inserting a pre-agreed delimiter byte sequence between different fields. The generated byte sequence serves as the message index information. The server creates a new record in the message index registration table, storing the message index information field and the message content reference address field together. The message content reference address field points to the specific message body location in persistent storage. Simultaneously, it registers the session identifier field and the sequence number field to support subsequent queries based on session and sequence. Through the processing in steps S1-2, each message to be sent obtains globally unique and resolvable message index information, and the correspondence between it and the message content is fully recorded in the message index registration table.

[0028] Step S1-3: Offline message record generation and terminal mapping registration.

[0029] The server uses the permission identification information obtained in step S1-1 and the message index information obtained in step S1-2 to generate offline message records for each terminal for each message to be sent, and registers the initial processing status of each offline message record in the terminal permission tracking table. The processing begins with the terminal registration information. The server queries the terminal registry for a list of terminal identification information associated with the current user identifier. Each item in the terminal identification information list uniquely indicates a terminal instance that has logged into the platform. For a message to be sent to a user, the server reads the corresponding message index information and message content reference address from the message index registration table, reads the permission identification information that matches the user identifier and is currently valid from the permission mapping table, and then constructs an offline message record for each terminal identification information item in the terminal identification information list. The offline message record contains at least a message index information field, a permission identification information field, a message content reference address field, a terminal identification information field, and an initial status flag field, where the initial status flag field is initially set to an unprocessed state. For each offline message record generated, the server writes it to an offline message record queue. This queue is sorted by terminal identification information and generation time, and is used for subsequent push notifications to various terminals. Simultaneously, the server inserts a record into the terminal permission tracking table, using a combination of the message index field and the terminal identification information field as the key, recording the terminal's processing status for this offline message record. The initial status is consistent with the initial status flag field in the offline message record. Through this process, the server establishes a complete link from user identification to the terminal identification information list, then to offline message records and terminal permission tracking records, providing directly referenceable foundational data for subsequent steps such as building a permission status table on the terminal side and updating the processing status on the server side.

[0030] Step S1 completes the entire process from configuring the power company's original permissions and inputting business messages to outputting basic data for offline message records. User permission status collection and permission identification information generation establish unique permission identification information for each user at the current moment. Message index information generation and registration assigns parsable message index information to each message to be sent and establishes a stable association with the message content. Based on this, offline message record generation and terminal mapping registration generate offline message records containing permission identification information and message index information for each terminal identification information, while simultaneously registering the initial processing status in the terminal permission tracking table. In this way, subsequent steps can directly read the permission identification information and message index information from the offline message records on the terminal side to construct the permission status table and local verification logic. The server can then analyze the status evolution of each offline message record on each terminal based on the records in the terminal permission tracking table. Step S1 thus provides a unified and complete data foundation for the execution of the entire multi-terminal offline message storage method in permission contraction scenarios.

[0031] In step S1, the server generates an offline message record for each message to be sent and writes permission identifier information, message index information, and terminal identifier information into the offline message record. After receiving these offline message records, if the terminal simply stores them sequentially in a local file, then in subsequent permission contraction scenarios, the local business module cannot quickly filter out the offline message records that need to be invalidated based on the latest permission status. In power operation scenarios, there are many underground spaces, mountain lines, and other weak network areas. Even when the terminal is offline for a long time, it still needs to rely on the local permission status to decide whether to display a certain historical instruction or attachment to the user. Therefore, step S2 takes the terminal as the processing subject and uses three sets of operations—offline message record parsing, intermediate structure record establishment, and permission status table construction—to transform the permission identifier information and message index information written by the server in the offline message record into local permission control data that the terminal can use independently. Through the incremental update mechanism of permission change instructions, the local permission status is kept consistent with the latest configuration of the server in time, providing an authoritative basis for the subsequent verification and invalidation of offline message records.

[0032] Step S2-1: Offline message record reception and local preprocessing queue construction.

[0033] In the heterogeneous mobile application platform for power systems, after connecting to the server, the terminal sequentially receives offline message records according to the communication protocol. Each offline message record contains terminal identification information, permission identification information, message index information, message content reference address, and initial state flag fields. The terminal holds a unique terminal identification information locally, which is written to persistent storage when the terminal first registers and used for identity matching in subsequent sessions. When the terminal receives an offline message record from the communication channel, it first extracts the terminal identification information field from the offline message record and compares it field by field with the terminal identification information in the local persistent storage. Only if the two are completely identical is the offline message record written to the local preprocessing queue.

[0034] The comparison process performs consistency checks on each bit of the code, avoiding fuzzy matching to prevent offline message records belonging to other terminals from being mistakenly entered locally. After completing the terminal identification information consistency check, the terminal splits each offline message record in the local preprocessing queue by field, copying the permission identification information, message index information, message content reference address, and initial state flag to a new intermediate structure record. At the same time, a local storage location pointer field is added to the intermediate structure record to record the physical storage location of the offline message record in the local file or database.

[0035] The terminal assigns local sequence numbers to intermediate structure records, which increment sequentially according to the order of reception. This allows the original reception order to be restored during subsequent debugging or tracing. Through the above processing, the terminal obtains a set of uniformly structured intermediate structure records. Each record simultaneously retains the mapping between permission identification information, message index information, and local offline storage location, establishing a traceable intermediate layer for subsequent construction of the permission status table and execution of offline message record verification.

[0036] Step S2-2: Construct the permission status table and maintain the associated message index set.

[0037] After the intermediate structure records are prepared, the terminal needs to build a local permission status table based on these intermediate structure records. This allows local permission determination to no longer rely on scanning offline message record files one by one, but to quickly locate the set of message index information related to a certain permission identifier through the permission status table.

[0038] The terminal first creates a permission status table structure in local memory or persistent storage. The permission status table includes fields for permission identification information, current permission status, version time, and associated message index set. After the permission status table is created, the terminal begins to traverse the intermediate structure records in the local preprocessing queue. For each intermediate structure record, it extracts the permission identification information and message index information fields.

[0039] The terminal searches for records in the permission status table using the permission identifier information as the query key. If no record with the same permission identifier information exists in the permission status table, a new permission status table record is created, the permission identifier information is written to the permission identifier information field, the current permission status field is initialized to authorized access status, the version time field is initialized to a zero time value, and a new collection structure is created in the associated message index collection field, and the current message index information is written to this collection.

[0040] In subsequent implementation, the associated message index set field stores message index information as a unique set. When inserting new message index information, a lookup within the set is performed. If the message index information does not exist in the set, it is inserted; otherwise, it is skipped, thus ensuring that the set content is unique. If a record with the same permission identifier information already exists in the permission status table, a new record is not created. Instead, the associated message index set field of the corresponding record is accessed directly, and a lookup and insertion process is performed on that set to add the new message index information to the set, while keeping the current permission status field and version time field unchanged.

[0041] To improve subsequent query efficiency, the terminal constructs a hash index structure on the permission status table based on the permission identifier field. This allows for record location based on the permission identifier information to be completed in constant time complexity. Simultaneously, within the associated message index set field, the data is sorted according to the byte order of the message index information. The sorting process compares each byte from the most significant bit to the least significant bit. Through this process, the terminal obtains a data table with the permission identifier information as the primary key. Each permission identifier information corresponds to a set of deduplicated and sorted message index information, providing a complete index for controlling offline message access based on permission identifier information in subsequent steps.

[0042] Step S2-3: Update the permission status table driven by the permission change command.

[0043] After the terminal completes the initial permission status table construction, the server sends a permission change command to the terminal via the communication channel when the background permission configuration changes. This permission change command contains at least a permission identifier field, a new permission status field, and a permission effective time field. While online, the terminal continuously listens for the command stream from the server. When it receives a permission change command, it parses out the permission identifier, new permission status value, and permission effective time value. The terminal uses the parsed permission identifier as the query key to look up the access permission status table. If a corresponding record is found, it retrieves the version time field value from the record and compares it with the permission effective time value.

[0044] The time comparison employs a common maximum value selection algorithm, using the later time on the timeline as the result time value. If the permission effective time is later than the version time field value, the permission effective time is used as the new version time field value, and the current permission status field is updated to the new permission status value. If the version time field value is not earlier than the permission effective time value, the current permission status field and the version time field remain unchanged to prevent an earlier permission change instruction from overwriting a newer permission status. When there is no record in the permission status table that matches the permission identifier information in the permission change instruction, the terminal creates a new permission status table record based on the instruction content, writes the permission identifier information into the permission identifier information field, sets the current permission status field to the new permission status value, sets the version time field to the permission effective time value, and creates an empty set structure in the associated message index set field for appending message index information when new offline message records belong to this permission identifier information.

[0045] Through the above dynamic update process, the permission status table continuously reflects the latest status of the server's permission configuration on the terminal side. Even if the order in which permission change instructions arrive is not fixed, the latest version of the permission status is always retained, providing a reliable basis for the terminal to rely on the local permission status for offline message access control in a network-off environment.

[0046] Through the sequential processing of steps S2-1, S2-2, and S2-3, the terminal first filters out records matching the terminal identification information from the offline message records issued in step S1, constructs an intermediate structure record with a local storage location pointer, and then generates a permission status table locally based on the permission identification information and message index information in the intermediate structure record. The terminal maintains a set of associated message indexes in the permission status table using the permission identification information as an index. Finally, the latest permission status increment from the server is reflected in the current permission status field and version time field of the permission status table through a permission change instruction. In this way, when processing offline message records in subsequent steps, the terminal no longer relies on real-time server access or performs indiscriminate scanning of all offline message records. Instead, it directly obtains the current permission status and the corresponding set of message index information by querying the record entries in the permission status table that correspond to the permission identification information carried by the offline message records. This provides a complete and consistent permission data foundation for performing offline message record verification, invalidation marking, and local deletion or encryption masking based on the permission status table in step S3.

[0047] In step S1, the server generates an offline message record for each message to be sent, containing permission identifier information, message index information, and terminal identifier information, and registers the initial state in the terminal permission tracking table. In step S2, the terminal parses the offline message record into an intermediate structure record and constructs a permission status table containing fields for permission identifier information, current permission status, version time, and associated message index set. When power operation terminals are running in the field, they are often in a weak network or out-of-network environment for a long time. Users still need to frequently view historical instructions, equipment photos, and business communication content. If the terminal does not actively perform offline message verification and invalidation processing according to the permission status table locally, but only retains the original offline message record, then after permission is reduced, it may still display invalid sensitive information, which is inconsistent with the power company's requirements for permission closure and information control. Based on this, step S3 takes the terminal-side execution process as the core, uses user access behavior and terminal idle state as trigger points, selects the target set to be verified from the intermediate structure record, and performs access judgment on each offline message record in combination with the current permission status field in the permission status table. For offline message records that are no longer allowed to be accessed, the deletion processing path or encryption and blocking processing path is executed, and failure mark information is written into the intermediate structure record. Finally, structured failure processing result information is generated, which provides a basis for the server to update the processing status of each message in the terminal permission tracking table.

[0048] Step S3-1: Identification of offline message verification trigger conditions and construction of target set.

[0049] With the offline message record transmission and permission status table construction completed in steps S1 and S2, step S3-1 first identifies the triggering time of offline message verification during terminal operation, and constructs the target set that needs to participate in this round of verification based on the intermediate structure record.

[0050] When the terminal is running in the foreground, it continuously monitors user interface operations. Once the user selects a session or a period of historical messages, the terminal filters out a set of intermediate structure records from the local preprocessing queue according to the mapping relationship between the message index information in the intermediate structure records and the session identifier. This set is then used as the user's access target set. During the filtering process, candidate records are first quickly locked based on the session identifier field, and then records falling within the time range are filtered sequentially based on the message index information, so that the range of records in the user's access target set accurately corresponds to the user's request.

[0051] When the terminal runs in the background, it statistically analyzes the processing load at preset time intervals. The load statistics use a moving average algorithm, which calculates the average value of processing time over a series of consecutive time slices and the length of the local preprocessing queue, forming a sequence of average load values. When the latest average load value is lower than a preset load threshold, the terminal is determined to be in an idle state. The load threshold is determined by the platform during the deployment phase based on the processing capability level recorded in the terminal hardware resource configuration table. It is calculated by performing a moving average on the stress test data of terminals of different levels and then selecting a range of average load values ​​that meet the latency requirements. One value from this range is then randomly selected as the threshold parameter.

[0052] After the terminal enters the idle state, it selects the intermediate structure records newly added since the last idle check and the intermediate structure records that were placed in the pending set due to unknown permission status during the last check from the local preprocessing queue. It sorts these two subsets by the local sequence number field and merges them into the idle check target set.

[0053] Both the user access target set and the idle verification target set are arranged in ascending order of the local sequence number of the intermediate structure record. When the terminal enters step S3-2, it can select one of the target sets as the verification object for this round according to the current trigger type, thereby establishing a clear mapping relationship between the trigger event and the intermediate structure record set to be verified.

[0054] Step S3-2: Offline message access determination and local failure handling based on the permission status table.

[0055] After the target set has been constructed in step S3-1, step S3-2 uses the permission information from the permission status table within the terminal to perform access determination and invalidation processing on the offline message record corresponding to each intermediate structure record in the target set. The terminal sequentially traverses the target set, reading the permission identifier information, message index information, local storage location pointer, and existing invalidation flag information within each intermediate structure record. If the intermediate structure record already contains invalidation flag information indicating the invalidation result of a previous round, it means that the corresponding offline message record has already completed the deletion processing path or encryption masking processing path in the previous verification. In this case, the terminal only needs to update the most recent verification time in the intermediate structure record and does not re-execute the invalidation processing to avoid duplicate operations.

[0056] For records with empty invalidation flags, the terminal uses the permission identifier as the query key to access the access permission status table. It locates the corresponding record using a hash index structure and reads the current permission status field and version time field. If no record matching the permission identifier is found in the permission status table, this intermediate structure record is added to the pending set, and the verification time for this round is recorded for processing in the next round after the permission status table is updated. If a record is successfully found in the permission status table, the terminal determines the value of the current permission status field. If the value indicates authorized access, only the latest verification time is written to the intermediate structure record, and the content of the offline message record in local storage remains unchanged. If the value indicates prohibited access, the terminal selects either the deletion processing path or the encryption / blocking processing path according to the policy configuration. In the deletion process, the terminal accesses the file or database record containing the message content based on the local storage location pointer, clears or overwrites the message content with meaningless filler values, and deletes the corresponding entry in the local index structure, so that the user interface cannot find the original content through the index structure when it is redrawn. In the encryption and masking process, the terminal requests a random session key from the local key management module, applies a symmetric encryption algorithm to the message content, replaces the original plaintext content with ciphertext, and writes a masking flag for this record in the local index structure. When the user interface is displayed, only the prompt information is displayed based on the masking flag, and the original content is not displayed.

[0057] Regardless of the failure handling path used, the terminal writes failure marker information into the intermediate structure record, indicating the failure handling path type and the processing time of this round. This allows subsequent steps to construct failure handling result information based on the failure marker information. The associated message index set field in the permission status table is not deleted in this step; the mapping relationship between message index information and permission identifier information is retained. The failure marker information in the intermediate structure record controls whether the message participates in processing again, thus completing the offline message storage status update without compromising the integrity of the permission status table.

[0058] Step S3-3: Generation of failure handling result information entries and local cache management.

[0059] At the end of step S3-2, the failure marker information in the intermediate structure record is consistent with the actual storage state of the offline message record. Step S3-3 further needs to convert these local processing results into structured failure processing result information so that they can be reported to the server and drive the terminal permission tracking table to be updated. The terminal re-traverses the target set of this round, selects intermediate structure records whose failure marker information is not empty and whose state has changed in this round, extracts terminal identification information, message index information, permission identification information, failure marker information, current round verification time, and failure processing path type for each record, constructs failure processing result entries, and writes the above fields into the entry structure in a fixed order.

[0060] The failure flag information includes a success indicator. The current verification time field uses the same time format as the version time field in the permission status table, so that the server can compare the time order in the terminal permission tracking table. The terminal writes all failure processing result entries to a local failure processing result cache queue. The cache queue is sorted according to the current verification time field, using a stable sorting algorithm to maintain the original traversal order when time values ​​are the same. To meet communication aggregation requirements, the terminal also maintains a batch read pointer and a reporting flag field on the local failure processing result cache queue. The batch read pointer indicates which failure processing result entry should be read from the next report, and the reporting flag field indicates which entries have been successfully sent to the server and completed the confirmation receipt processing.

[0061] Once the terminal detects that a communication connection has been established with the server and the time interval condition in the reporting policy is met in subsequent steps, it reads the unreported failure handling result entries from the local failure handling result cache queue in sequence starting from the batch read pointer position, encapsulates them into failure handling result information messages and delivers them to the server for processing, providing complete data for the server to update the processing status corresponding to the message index information and terminal identification information in the terminal permission tracking table.

[0062] Through the continuous execution of steps S3-1, S3-2, and S3-3, the terminal, under both user access trigger and idle trigger conditions, filters the target set to be processed in this round from the intermediate structure record. It transforms the permission identification information issued by the server in the permission status table into access judgment results for specific offline message records. Based on the current permission status field, it executes deletion or encryption / masking processing paths for offline message records that are no longer allowed access, and writes failure marker information and the current round's verification time into the intermediate structure record. Subsequently, the terminal generates failure processing result entries containing terminal identification information, message index information, permission identification information, and failure marker information based on these intermediate structure records, and writes them into the local failure processing result cache queue in chronological order. This lays the data foundation for subsequent steps to report to the server to form a complete failure processing result information message when communication conditions are met. Through the above processing, step S3 forms a continuous processing chain within the terminal from the permission status table to the offline message storage status and then to the failure processing result information. This enables the power field terminal to manage local offline message content according to the latest permission configuration in the offline state, and provides traceable execution records for consistent failure control across terminals.

[0063] In the aforementioned steps, the server has already established initial records for each offline message record and each terminal identifier in the terminal permission tracking table through step S1. The terminal then performs access determination and invalidation processing on the offline message records locally based on the permission status table through steps S2 and S3, and generates invalidation processing result entries to be written to the invalidation processing result cache queue. In the scenario of permission contraction, power companies not only require that the offline message content on the terminal's local device be consistent with the latest permission status, but also require the server to have a complete view of the processing progress of each message on all terminals. This allows the server to proactively initiate permission contraction commands to drive subsequent processing when it discovers that some terminals still retain uninvalidated offline message records. Therefore, step S4 introduces three sets of processing logic on the server side: receiving and parsing invalidation processing result information messages, updating the terminal permission tracking table, and rescheduling permission change commands. This enables the server to integrate the invalidation processing result entries reported by the terminals with the original records in the terminal permission tracking table into a consistent processing status view, and accordingly, to issue new permission change commands to terminals that have not yet completed invalidation processing, thereby achieving overall convergence of the offline message storage status of multiple terminals from the server's perspective.

[0064] Step S4-1: Receiving the failure handling result information message and writing the failure handling result receiving cache table.

[0065] After the terminal encapsulates the failure handling result entry into a failure handling result information message based on step S3 and establishes a communication connection, the server first receives the failure handling result information message at the communication access port, parses the message header, and reads the terminal identification information and message generation time field.

[0066] The server uses the terminal identification information to access the terminal registry for matching. Only when a record with completely identical terminal identification information exists in the terminal registry will the failure handling result message enter the subsequent processing flow; otherwise, it will be discarded, ensuring that only results reported by terminals with legitimate sources enter the core data structure. After source confirmation, the server begins parsing the multiple failure handling result entries contained in the message body. For each failure handling result entry, it sequentially reads the message index information, permission identification information, failure flag information, verification time field, and failure handling path type field, and combines these fields with the terminal identification information corresponding to the current message to assemble a failure handling result reception record.

[0067] In the failure handling result reception record, the terminal identification information field is used to identify the source terminal, the message index information field is used to identify the specific message, the permission identification information field is used to associate with the permission mapping table, the failure mark information is used to indicate the processing status that the terminal has completed locally, the verification time field records the time when the terminal completed this processing, and the failure handling path type field indicates whether it is a deletion processing path or an encrypted and blocked processing path.

[0068] The server uses a combination of terminal identification information, message index information, and permission identification information as a composite key to write failure handling result reception records into the failure handling result reception cache table. If a record with the exact same composite key already exists in the cache table, the verification time field in the existing record is compared with the verification time field in the new record. If the verification time field of the new record is later than that of the existing record, the new record overwrites the existing record; otherwise, the existing record is retained unchanged. Through this time-based overwriting strategy, the failure handling result reception cache table retains only the most recent failure handling result for each terminal and each message combination, providing a stable input for subsequent updates to the terminal permission tracking table.

[0069] Step S4-2: Synchronize the terminal permission tracking table status and construct the message processing progress summary table.

[0070] After the failure handling result receiving cache table has been aggregated, step S4-2 updates the terminal permission tracking table internally on the server side using the cached records, and generates a message processing progress summary table accordingly. The server first groups the records in the failure handling result receiving cache table according to the terminal identification information, with each group corresponding to one terminal, and then processes each record in each group individually. For a failure handling result receiving record, the server reads the terminal identification information, message index information, permission identification information, failure flag information, verification time field, and failure handling path type field, and then uses the combination of the terminal identification information and message index information as a join key to access the terminal permission tracking table. If a record with a matching composite key already exists in the terminal permission tracking table, the server reads the most recent processing time field from it and compares it with the verification time field in the failure processing result reception record. If the verification time field is later than the most recent processing time field, the server updates the current processing status field in the terminal permission tracking table to the processing completion status indicated by the failure flag information, updates the most recent processing time field to the verification time field, and updates the processing path type field to the failure processing path type field, thus ensuring that the status recorded in the terminal permission tracking table is consistent with the terminal's latest processing result. If the verification time field is not later than the most recent processing time field, the failure processing result reception record is considered a historical record, and the existing fields in the terminal permission tracking table are not modified. If a record with a matching composite key does not exist in the terminal permission tracking table, the server creates a new record, writes the terminal identification information, message index information, and permission identification information, initializes the current processing status field to the processing completion status indicated by the failure flag information, initializes the most recent processing time field to the verification time field, and initializes the processing path type field to the failure processing path type field.

[0071] After updating the terminal permission tracking table, the server groups the records in the table using the message index information as the key. Multiple terminal records corresponding to the same message index information are grouped into the same group. For each group, the total number of records in the group is counted as the total number of associated terminals. Simultaneously, the number of records in the group whose current processing status field is not in the "processing completed" state is counted as the number of terminals with incomplete processing. The terminal identification information of these terminals with incomplete processing is collected to form a list of terminals with incomplete processing. The server writes the message index information, the total number of associated terminals, the number of terminals with incomplete processing, and the list of terminals with incomplete processing into the message processing progress summary table. This allows the message processing progress summary table to reflect the processing coverage of each message on each terminal and the remaining processing gap from the server's perspective.

[0072] Step S4-3: Generation of permission change instructions, adjustment of pending permissions queue, and control of retry threshold.

[0073] After the message processing progress summary table is constructed, step S4-3 uses the contents of the message processing progress summary table and the permission mapping table to generate new permission change instruction entries, and manages the issuance of instructions through the pending permission adjustment queue and retry threshold control logic. The server iterates through each record in the message processing progress summary table. For records containing a number of terminals with incomplete processing greater than zero, it reads the message index information and the list of terminals with incomplete processing, and accesses the terminal permission tracking table through the message index information to obtain the corresponding permission identification information; then, using the permission identification information as the key, it reads the current permission status and permission version time value in the access permission mapping table. When the current permission status field indicates that the corresponding permission has been contracted to the prohibited access state, it means that all terminals will eventually need to be in the offline message invalid state for this message index information. At this time, the server generates a permission change instruction entry for each terminal identification information in the list of terminals with incomplete processing.

[0074] Each permission change instruction entry includes at least a terminal identification information field, a permission identification information field, a permission effective time field, and a mandatory verification flag field. The permission effective time field is set to the permission version time value recorded in the permission mapping table, used to compare the version time field in the local permission status table on the terminal side. The mandatory verification flag field instructs the terminal to immediately execute the permission status table update in step S2 and the offline message verification and invalidation handling in step S3 upon receiving the permission change instruction, without waiting for local normal trigger conditions to be met. The server assigns the generated permission change instruction entries to the corresponding sub-queues in the pending permission adjustment queue according to the terminal identification information. Within each sub-queue, the entries are arranged according to the permission effective time field, ensuring a clear chronological order for subsequent permission change instructions received by the same terminal. To control the frequency of instruction delivery to each terminal, the server sets a retry threshold for each terminal. The retry threshold is obtained by calculating the arithmetic mean of the number of records for which processing was not completed within a certain number of consecutive statistical periods for that terminal.

[0075] Specifically, the process involves recording the number of unprocessed records for each terminal within multiple consecutive statistical periods, forming a sequence. A simple arithmetic average is then calculated on this sequence, and the average result serves as the retry threshold for that terminal. The server then compares the number of terminals with unprocessed records in the message processing progress summary table with the retry threshold. When the number of unprocessed records for a terminal exceeds its retry threshold, or when the time interval since the terminal last received a permission change instruction exceeds a preset time limit, the server retrieves a batch of permission change instruction entries from the head of the corresponding sub-queue, encapsulates them, and sends them to the corresponding terminal via the communication channel. After receiving these permission change instructions, the terminal again executes the permission status table update in step S2 and the offline message verification and invalidation processing in step S3, causing unprocessed offline message records to continue progressing towards the invalidation state.

[0076] Through the collaborative work of steps S4-1, S4-2, and S4-3, the server extracts and integrates the failure handling result information messages reported by the terminals into a failure handling result receiving cache table. Then, using the terminal permission tracking table as the core, it synchronizes the latest processing status of each terminal for each message index information into the database, forming a progress view in the message processing progress summary table that includes the number of terminals with incomplete processing and a list of such terminals. Subsequently, based on the message processing progress summary table and the permission mapping table, the server filters out message index information that is still in an inaccessible state but has terminals with incomplete processing. For these message index information and corresponding terminal identification information, it generates permission change instruction entries and distributes them to the target terminals in batches through a pending permission adjustment queue and retry threshold control, driving the terminals to repeatedly execute steps S2 and S3. Thus, step S4 establishes a closed loop on the server side from result reception and status aggregation to instruction redistribution, enabling the power heterogeneous mobile application platform to have cross-terminal global scheduling and continuous convergence capabilities in scenarios involving multi-terminal offline message storage and permission contraction.

[0077] Specifically, the above description is only a preferred embodiment of this application and is not intended to limit this application.

[0078] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0079] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A power heterogeneous mobile application platform multi-terminal offline message storage method, characterized in that, The method comprises the steps of: S1: on the server side, generating an offline message record carrying permission identification information and message index information for a message to be delivered according to the current user's permission state, and delivering the offline message record to each registered terminal along with the corresponding terminal identification information; S2: on each terminal, establishing a permission state table according to the permission identification information, the message index information in the offline message record, and the terminal identification information of the local terminal, and updating the permission state in the permission state table using the permission identification information when a permission change instruction is received from the server; S3: on each terminal, when a user accesses the local offline message record or when the terminal is in an idle state, checking the local offline message record according to the updated permission state table, writing invalid marker information to the offline message record whose permission state has been contracted, and deleting or encrypting and shielding the corresponding offline message record according to the invalid marker information, while generating invalid processing result information containing the message index information and the invalid marker information; S4: on the server side, recording the invalid processing state of each terminal for the offline message record corresponding to different permission identification information in the terminal permission tracking table according to the invalid processing result information, and generating a new permission change instruction for the terminal that has not completed the invalid processing to be delivered when the terminal is connected to the server again, so as to prompt each terminal to continue to execute steps S2 and S3 until the permission state is consistent with the invalid marker information of the offline message record.

2. The method according to claim 1, wherein: Step S1 comprises collecting user permission states on the server side to generate permission identification information and registering it in the permission mapping table, combining the session identification sequence number and the service source code of each message to be delivered to form message index information and registering it in the message index registration table.

3. The method according to claim 2, wherein: Step S1 constructs an offline message record containing permission identification information, message index information, message content reference address, and terminal identification information for each message based on the associated terminal identification information of the user, and registers the offline message record processing state in the terminal permission tracking table using the combination of message index information and terminal identification information as the key value.

4. The method according to claim 1, wherein: Step S2 receives the offline message record matching the terminal identification information on the terminal side and generates an intermediate structure record containing permission identification information, message index information, message content reference address, and local storage location pointer, and constructs a permission state table with permission identification information as the key based on the intermediate structure record.

5. The method according to claim 4, wherein: The permission state table includes a current permission state field, a version time field and an associated message index set field. By monitoring the permission change instruction, the permission identifier information, new permission state and permission effective time are parsed, and the corresponding record in the permission state table is compared and updated in time to update the current permission state field and the version time field.

6. The power heterogeneous mobile application platform multi-terminal offline message storage method of claim 4, wherein: Step S3, after receiving the offline message check trigger condition at the terminal, constructs a target set from the intermediate structure record, and determines access to the corresponding offline message record in the target set according to the permission identifier information and the current permission state field in the permission state table.

7. The power heterogeneous mobile application platform multi-terminal offline message storage method of claim 6, wherein: Step S3, for the offline message record that is prohibited from access, performs a deletion processing path or an encryption shielding processing path according to a strategy, writes invalidation marker information in the intermediate structure record, generates an invalidation processing result entry containing terminal identifier information, message index information, permission identifier information, invalidation marker information and check time field, and writes the invalidation processing result entry into the invalidation processing result cache queue.

8. The power heterogeneous mobile application platform multi-terminal offline message storage method of claim 7, wherein: Step S4, after receiving the invalidation processing result information message reported by the terminal at the server, writes the invalidation processing result information into the invalidation processing result receiving cache table according to the terminal identifier information and the permission identifier information, updates the current processing state field and the latest processing time field in the terminal permission tracking table, and forms a message processing progress summary table containing a list of uncompleted processing terminal identifier information according to the message index information.

9. The power heterogeneous mobile application platform multi-terminal offline message storage method of claim 8, wherein: Step S4, according to the permission identifier information in the permission mapping table that is in the prohibited access state, generates a permission change instruction entry containing terminal identifier information, permission identifier information and permission effective time field for the uncompleted processing terminal, writes the permission change instruction entry into the pending permission adjustment queue, and controls the permission change instruction entry to be sent to the corresponding terminal according to a retry threshold.

Images