A global collaborative digital office intelligent management system and a dispatching method

Abstract

The application belongs to the technical field of digital office scheduling, and discloses a global collaborative digital office intelligent management system and a scheduling method. The method determines a key bearing function according to a current stage and a target stage of a to-be-replaced office task, extracts an original bearing component and a candidate bearing component from running states of an original execution object and a candidate replacement object, forms a candidate replacement bearing configuration according to the bearing function and an established path, and establishes an inheritance relationship, an established dependency and a released dependency; identifies a common failure relationship according to a bottom-layer dependent object pointed by the established dependency, and constructs a sustainable collaborative bearing replacement domain; determines a configuration to be retained and a component to be maintained based on an influence of the common failure relationship on a function coverage, forms a sustainable safe release boundary through node deletion verification, releases the original bearing component and switches a target stage operation control state according to the boundary. The application can avoid that a candidate path of a bottom-layer homology is mistakenly made as an effective redundancy, and makes the original state release correspond to a candidate bearing sustainable condition.

Description

Technical Field

[0001] This invention belongs to the field of digital office scheduling technology, specifically a full-domain collaborative digital office intelligent management system and scheduling method. Background Technology

[0002] As digital office systems gradually evolve towards collaborative operation across terminals, application instances, and service regions, when the same office task is handed over between different processing stages, it is usually necessary to synchronously transfer task data, application context, user sessions, identity permissions, terminal running status, and resource usage status. Existing office scheduling methods typically select a replacement object and deactivate the relevant running status of the original execution object based on whether the candidate terminal is online, whether the data has been copied, whether the user is logged in, or whether the candidate service is available.

[0003] However, while different candidate successor objects appear independent, their state establishment processes may still rely on the same data source, authentication domain, network domain, or resource instance. When multiple candidate successor paths can be interrupted simultaneously by the same underlying failure, switching based solely on the number of candidate objects or the availability of a single state can easily lead to mistaking candidate paths with the same underlying source as effective redundancy, and prematurely releasing the original session, original permissions, original data connection, or original resources before the candidate's carrying capacity has truly been sustained.

[0004] Furthermore, existing scheduling methods typically lack a unified organization of the original state, candidate states, dependency establishment, dependency release, and common failure relationships, making it difficult to promptly correct unexecuted release conditions after changes in underlying dependencies. Therefore, it is necessary to provide a digital office scheduling solution that can organize candidate successor states for critical functions and determine the safe release conditions of the original state based on common failure relationships. Summary of the Invention

[0005] The purpose of this invention is to provide a fully collaborative digital office intelligent management system and scheduling method to solve the problem that during the digital office task succession process, candidate succession objects may appear to be available but have underlying dependencies on the same source, leading to candidate paths being misjudged as independent redundancies and prematurely releasing their original running state.

[0006] To achieve the above objectives, the present invention provides a method for scheduling collaborative digital office work across the entire domain. This method determines the key carrying functions required for the target stage based on the current and target stages of the task to be replaced. It decomposes the operational states of the original execution object and the candidate replacement object into original carrying components and candidate carrying components. Based on the key carrying functions undertaken by the candidate carrying components and their establishment paths, a candidate replacement carrying configuration is formed. The method establishes the inheritance relationship between the original carrying components and the candidate carrying components, the establishment dependencies between the candidate carrying components, and the release dependencies of the original carrying components. It also determines the coverage relationship of the candidate replacement carrying configuration to the key carrying functions. Following the establishment dependencies, the method traces the underlying dependent objects to determine the common failure relationships between the candidate carrying components and the candidate replacement carrying configuration, thereby constructing a sustainable collaborative carrying replacement domain. Based on the impact of the common failure relationships on functional coverage, it determines the candidate replacement carrying configurations to be retained and the original carrying components to be maintained. When, after releasing the corresponding original carrying components, each key carrying function still has an effective candidate carrying path that is not simultaneously affected by the same common failure relationship, a sustainable safe release boundary is formed. The corresponding original carrying components are released according to the sustainable safe release boundary, and the operation control state of the target stage is switched to the candidate replacement carrying configuration to be retained.

[0007] Furthermore, underlying dependent objects that can be simultaneously interrupted by the same underlying failure event are classified into the same failure domain, and the failure domain attributes are propagated along the dependency establishment to candidate bearer components and candidate successor bearer configurations. By performing node deletion verification on the original bearer component to be released, it is determined whether each key bearer function still has a valid bearer path after deletion, and whether there is a failure domain that can simultaneously affect all valid bearer paths of the corresponding function. When the ownership of underlying dependent objects or failure domains changes, the common failure relationship and function coverage relationship are updated, and the remaining safe release boundary that has not yet been executed is re-verified.

[0008] The present invention also provides a fully collaborative digital office intelligent management system, including an office status interface, a processor, and a memory. The office status interface is communicatively connected to an office application server, an identity authentication server, a data storage server, and an office terminal, respectively. The memory stores a computer program, and the processor implements the above-mentioned fully collaborative digital office scheduling method when executing the computer program.

[0009] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described global collaborative digital office scheduling method.

[0010] The beneficial effects of this invention are as follows:

[0011] 1. This invention determines key carrying functions based on the task operation of the target stage, splits the overall operating state of the original execution object and the candidate replacement object into the original carrying component and the candidate carrying component, and combines the candidate carrying components distributed in different terminals, application instances, authentication services, data services and resource instances into a candidate replacement carrying configuration, so that the replacement unit of office tasks is transformed from the entire execution object into a functional carrying component that can be independently established, maintained and released.

[0012] 2. The present invention traces the data source, service instance, authentication domain, network domain and resource instance along the establishment dependency of candidate bearer components, classifies the underlying dependent objects that can be interrupted by the same underlying fault into the same failure domain, and forms a common failure relationship between candidate bearer components and candidate successor bearer configurations. This enables the identification of the state where candidate objects are superficially separated but have the same underlying dependency, and avoids treating common failure paths as mutually independent candidate bearer paths.

[0013] 3. The present invention organizes key bearing function nodes, original bearing component nodes, candidate bearing component nodes, candidate successor bearing configuration nodes and failure domain nodes into a sustainable collaborative bearing succession domain, and performs candidate configuration retention, original bearing component maintenance and release boundary determination based on the same shared relationship instance, so that each judgment adopts the same version of bearing state, dependency relationship and failure domain state.

[0014] 4. This invention performs node deletion verification on the original bearer component to be released. Only when each key bearer function still has a valid bearer path after the simulated deletion of the original bearer component, and there is no failure domain that simultaneously affects all valid paths of the corresponding function, is a safe release boundary formed. This changes the release of the original bearer component from a fixed switching time to a dynamic state boundary constrained by the actual candidate bearer survival status.

[0015] 5. When the underlying dependent objects, establishment dependencies, or common failure relationships change, this invention propagates the changed underlying dependent attributes along the existing establishment dependencies, updates the candidate bearer components, candidate replacement bearer configurations, common failure relationships, and coverage relationships, and re-verifies the existing safe release boundaries that have not yet been executed; when the candidate path is still affected by the same common failure relationship, the candidate path is reconstructed by replacing the underlying dependent objects, so that the release conditions can be corrected according to the actual system topology changes. Attached Figure Description

[0016] Figure 1 This is a structural block diagram of the intelligent management system for full-domain collaborative digital office of the present invention;

[0017] Figure 2 This is a flowchart of the global collaborative digital office scheduling method of the present invention;

[0018] Figure 3This is a schematic diagram of the nodes and relationships of the sustainable collaborative bearing replacement domain of the present invention;

[0019] Figure 4 This is a comparative diagram showing the failure relationship before and after the underlying dependent object was replaced by the present invention. Detailed Implementation

[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. Furthermore, the embodiments and technical features described herein can be combined with each other unless otherwise specified.

[0021] Example 1

[0022] Please see Figures 1 to 4 This embodiment provides a method for scheduling full-domain collaborative digital office work and a smart management system for implementing the method. This method is applicable to the process of handing over office tasks from their current execution state to a target execution state. This handover can occur between different office terminals, different application instances, different service areas, or in a composite execution environment where multiple objects share the task's running state.

[0023] This embodiment focuses on digital office tasks that require operational continuity, such as contract review and approval, collaborative document editing, business data review, project approval, and work order processing. The office task to be replaced is currently carried out by the original executing object. Before entering the target stage, the system needs to confirm that the data access status, application context, session connection, identity permissions, terminal running status, resource occupancy status, and operation control status required for the target stage can be established and continuously undertaken by the candidate replacement object. The original executing object is not limited to a single office terminal; it can consist of the original office terminal, the original application instance, the original user session, the original identity token, the original data connection, and the original resource instance. Candidate replacement objects can also be distributed across different terminals, different service instances, and different resource regions.

[0024] refer to Figure 1As shown, the full-domain collaborative digital office intelligent management system includes an office status interface, a processor, and a memory. The office status interface communicates with the office application server, the identity authentication server, the data storage server, and the office terminals. The office application server runs document editing, business review, or process approval applications, and provides task stages, application instances, application contexts, and service call statuses. The identity authentication server issues, verifies, and revokes identity tokens, and provides authentication domains, token versions, and permission ranges. The data storage server stores task files, business data, data versions, and execution logs, and provides data source identifiers, data copy status, and read / write connection statuses. The office terminals run office applications, receive user operations, and execute control switching commands, and provide terminal identifiers, login status, application process status, session status, network connection status, and resource usage status.

[0025] The office status interface can adopt application programming interfaces (APIs), message queue interfaces, log collection interfaces, terminal agent interfaces, or service registration interfaces. The processor can be deployed in an enterprise office collaboration platform, a private cloud control node, or an office resource management server. The memory is used to store computer programs, task phase data, runtime status data, office event data, underlying dependency data, shared relationship instances, and execution feedback records. The processor calls the computer programs and corresponding data in the memory to organize and verify candidate succession states, and sends the resulting release control records to the session management service, identity authentication server, data connection management service, resource scheduling service, and office terminals.

[0026] For a single office task handover, the processor records the task identifier, process instance identifier, and handover batch identifier for the task to be handed over, and associates them with the current stage identifier, target stage identifier, original execution object identifier, candidate handover object identifier, and status acquisition time. Statuses distributed across different office areas, network areas, and service areas can also carry area identifiers, network domain identifiers, and service domain identifiers. These identifiers are used for logical positioning of the running status; this embodiment does not require the establishment of a geometric coordinate system. Statuses generated at different stages are associated through task identifiers, process instance identifiers, object identifiers, status versions, and time identifiers to determine the task to which the status belongs and its inheritance order.

[0027] In this embodiment, the memory stores at least the task phase dataset, object runtime status dataset, office event dataset, underlying dependency dataset, shared relationship instance dataset, and execution feedback dataset. The task phase dataset originates from the workflow engine, office application server, and task scheduling configuration, and is used to record the current phase, target phase, target phase task operations, and the key functions required for the corresponding task operations. The object runtime status dataset originates from the office application server, identity authentication server, data storage server, and office terminals, and is used to record the runtime status items of the original execution object and the candidate replacement object. The office event dataset originates from the office event stream and historical execution logs, and is used to record state establishment events, service call events, data version usage events, identity token usage events, session binding events, resource reservation events, state release events, and operation control switching events.

[0028] The underlying dependency dataset originates from the service registry, configuration management database, application deployment information, network topology, data master / replica configuration, resource scheduling configuration, and verified historical fault records. It records the deployment relationships and failure domain affiliations between data sources, service instances, authentication domains, network domains, and resource instances. The shared relationship instance dataset records the original bearer components, candidate bearer components, candidate successor bearer configurations, inheritance relationships, dependency establishment, dependency release, common failure relationships, critical bearer function coverage relationships, and the release status of the original bearer components. The execution feedback dataset originates from office terminals, session management services, identity authentication servers, data storage servers, and resource scheduling services. It records the execution results of release actions, status establishment actions, and operation control switching actions.

[0029] refer to Figure 2 As shown, the processor first determines the key functionalities required for the target stage based on the current and target stages of the task to be replaced. It then breaks down the overall operational state of the original execution object and candidate replacement objects into components capable of undertaking specific key functionalities. Next, it forms candidate replacement configurations according to the establishment paths of these components, supplementing inheritance relationships, establishing dependencies, and releasing dependencies. The processor traces the underlying dependent objects along the established dependencies, identifies common failure relationships between different candidate components and different candidate configurations, and organizes these objects and relationships into a sustainable collaborative replacement domain. Subsequent retention, release, and operational control switching of the original components are all performed based on this relationship state; when underlying dependencies change, only the affected relationship records and unexecuted release boundaries are updated.

[0030] S1. Determine the key functionalities for the target phase and extract the original functionalities and candidate functionalities. Specifically, the processor reads the current process node and target process node of the office task to be replaced from the workflow engine based on the task identifier, and determines the functionalities that the target phase needs to continuously possess by combining the task operations corresponding to the target process node. The processor then reads the running status of the original execution object and multiple candidate replacement objects through the office status interface, and extracts the running status items that have a direct carrying relationship with the functionalities.

[0031] When determining key bearer functions, the processor reads the operation configuration, application interface configuration, and permission configuration of the target stage. For example, if the current stage is the contract drafting stage and the target stage is the legal review stage, the target stage tasks may include reading the current version of the contract, viewing modification records, loading the review interface, obtaining review permissions, filling in review comments, and submitting review results. The key bearer functions corresponding to the above tasks include data access functions, application context maintenance functions, session connection functions, identity and permission functions, terminal operation functions, resource usage functions, and operation control functions. The target stage does not necessarily use all functions; the processor generates a record of key bearer functions for the target stage based on the actual task operations and stores this record in association with the task identifier and the target stage identifier.

[0032] The data access function indicates whether the target stage can read or write the corresponding task data; the application context maintenance function indicates whether the target stage can obtain the current editing position, form status, process status, or other application context; the session connection function indicates whether there is a valid session between the candidate office terminal and the office application server; the identity and permission function indicates whether the target stage has the corresponding user identity and operation permissions; the terminal operation function indicates whether the candidate office terminal has the status to run the corresponding office application; the resource occupancy function indicates whether the computing resources, storage resources, network resources, or reservation resources required by the target stage are available; and the operation control function indicates whether the candidate execution object can obtain a valid operation control status for the office task to be taken over.

[0033] When the workflow engine only records the stage name but not the corresponding task operation, the processor can obtain the task operation corresponding to the stage from the application interface configuration and the historical stable execution records of the same process. If the target stage task operation is still uncertain, the current replacement batch will be recorded as pending review, and the release permission of the original carrier component will not be generated before the target stage operation is confirmed.

[0034] The office status interface sends status query requests to the office application server, identity authentication server, data storage server, and office terminals according to the task identifier, or receives status events actively reported by the above objects. Each running status item carries at least the object identifier, status version, carrying function identifier, and valid range, and may also carry the task identifier, stage identifier, data source identifier, service instance identifier, authentication domain identifier, network domain identifier, resource instance identifier, and interface type.

[0035] The valid interval represents the time range within which the corresponding running state can actually undertake task operations. It can be determined based on the validity period of the identity token, session keep-alive period, resource reservation period, terminal online period, application instance lease, or data connection validity period. The processor determines whether the valid interval of the running state item covers the corresponding task operation segment based on the expected start time, expected end time, and execution order of the task operations in the target stage. If the validity period is insufficient, the state is not directly identified as a valid candidate bearer component; if renewal is allowed, the processor first triggers token renewal, session renewal, resource reservation extension, or data connection reconstruction, and then re-determines based on the updated valid interval.

[0036] The processor further determines whether there is a direct relationship between the running status items and the target stage task operations. When a data connection actually points to the data version that the target stage needs to read, the data connection status has a direct relationship with the data access operation; when the permission scope of an identity token includes the target stage operation and can be invoked by the corresponding application session, the token status has a direct relationship with the identity permission operation; when an application instance saves or can load the application context of the target task, the application instance status has a direct relationship with the application context maintenance operation.

[0037] The processor identifies the running status items in the original execution object that have a direct bearing relationship with the corresponding task operation and whose effective range covers the corresponding task operation segment as the original bearing component, and identifies the running status items in the candidate replacement object that meet the same conditions as the candidate bearing component. An execution object can form multiple bearing components, and the same key bearing function can also have multiple candidate bearing components from different execution objects. The processor generates a bearing component status table, recording the bearing component identifier, object identifier, bearing function identifier, status version, effective range, current establishment status, interface type, and corresponding underlying dependent object identifier, and inputs this status table into step S2.

[0038] When multiple state records for the same object have different versions, the processor determines the valid state version based on the version generation time, application server confirmation records, and the current version on the data storage server. For runtime state items lacking object identifiers, state versions, carrying function identifiers, or valid ranges, they are first supplemented using the office event dataset and underlying dependency datasets; state items that cannot be supplemented remain incomplete and are not included in subsequent configuration combinations.

[0039] S2. Form candidate successor bearer configurations and establish inheritance relationships, dependencies, and release dependencies. Specifically, the processor combines candidate bearer components that jointly support the target stage into one or more candidate successor bearer configurations based on the key bearer functions, state versions, interface types, and establishment paths undertaken by the candidate bearer components. At the same time, it records the state inheritance method from the original bearer component to the candidate bearer component and the order relationship between the establishment of the candidate state and the release of the original state.

[0040] The processor determines the establishment path required for each candidate bearer component to transition from its current state to the established state based on application deployment configuration, state transition records, service call chains, and succession rules. The establishment path for a candidate data access component may include locating the target data version, establishing a data connection, verifying read / write permissions, and confirming the data version. The establishment path for a candidate application context component may include creating a candidate application session, reading the target data version, loading the context, and verifying the context version. The establishment path for a candidate identity and permission component may include submitting an authentication request, issuing a target stage token, and verifying the permission scope. The establishment path for a candidate resource component may include requesting resources, locking resources, and confirming the resource reservation result. The establishment path records the candidate bearer component identifier, establishment action, prior state, underlying dependent objects, establishment completion flag, and establishment failure status.

[0041] In this embodiment, the following formula is used to describe an implementable determination method for the functional coverage state of the candidate replacement bearer configuration, the common failure state of the candidate bearer components, and the survival and safe release state of the original bearer components. The following set operations and logical judgments can be implemented through correspondence tables, state transition tables, relational database query statements, graph database traversal statements, or programmatic mapping rules. While maintaining the critical bearer functional coverage, failure domain attribute propagation, and node deletion verification processing logic unchanged, equivalent relation retrieval, path retrieval, or conditional judgment methods can also be used to form the corresponding state variables.

[0042] The set of key load-bearing functions to be covered by candidate replacement load-bearing configurations is determined according to equation (1):

[0043] (1)

[0044] When the functional coverage set of the candidate successor bearer configuration satisfies equation (2), and the state versions of the candidate bearer components within the configuration are compatible, the interface types match, and the establishment paths are reachable, the corresponding combination of candidate bearer components is determined as the candidate successor bearer configuration:

[0045] (2)

[0046] In equations (1) and (2), Indicates the first in the same successor batch One candidate replacement load-bearing configuration, subscript Used to distinguish different candidate replacement bearing configurations; Indicates candidate successor load-bearing configuration The set of candidate bearer components included; Represents a set Any candidate bearer component in; Indicates candidate bearing components The set of key carrying functions that it can undertake; Indicates candidate successor load-bearing configuration The set of key carrying functions that can be covered; This represents the set of key supporting functions required for the target phase.

[0047] The data source for mapping Φ is the state table of the bearer components, the application interface configuration, and the corresponding records between task operations and bearer functions; the data source for set 𝒦 is the record of key bearer functions for the target stage formed in step S1; the symbol ∪ indicates that the functions undertaken by each candidate bearer component within the configuration are merged; the symbol ⊆ indicates that each key bearer function required for the target stage is included in the function coverage set of the corresponding candidate configuration. Equation (1) forms the function coverage record of the candidate replacement bearer configuration, and Equation (2) is used to exclude candidate combinations that only undertake some key bearer functions. Candidate configurations that meet the coverage conditions continue to enter the underlying dependency identification; if the function coverage is complete but the state version is incompatible, the interface type is mismatched, or the establishment path is unreachable, then the combination is still not recorded as a valid candidate replacement bearer configuration.

[0048] Candidate successor bearer configurations do not require all candidate bearer components to belong to the same candidate successor object. Data access functions can be handled by candidate data storage servers, identity and authorization functions by candidate authentication services, terminal operation functions by candidate office terminals, and application context maintenance functions by candidate application instances. These candidate bearer components together constitute a candidate successor bearer configuration. Processors can form multiple candidate successor bearer configurations within the same succession batch to facilitate subsequent identification of whether their underlying dependencies are independent.

[0049] For each original bearer component, the processor determines candidate bearer components capable of undertaking the same critical bearer function and establishes inheritance relationships based on the actual method of transition from the original state to the candidate state. Inheritance relationships include direct inheritance, object rebinding, successor-side reconstruction, state form transformation, and functional equivalence substitution.

[0050] Direct inheritance indicates that the candidate bearer component continues to use the state used by the original bearer component, such as the candidate application instance continuing to use the same task data version; object rebinding indicates that the bearer state remains valid but the bound object changes, such as rebinding business resources from the original session to the candidate session; successor reconstruction indicates that the candidate successor object re-establishes the candidate state based on the original state, such as the candidate terminal recreating the application session and loading the task context; state form transformation indicates that the original state and the candidate state adopt different forms, but the candidate state can inherit the original state, such as converting the memory context in the original application instance into a context snapshot that can be loaded by the candidate application instance; functional equivalence substitution indicates that the candidate bearer component uses different services or resources to undertake the same key bearer functions, such as replacing the original data connection with a data connection provided by another data replica.

[0051] The inheritance relationship records the original bearer component identifier, candidate bearer component identifier, inheritance type, original state version, candidate state version, and inheritance completion status, and forms inheritance edges in the subsequent directed relationship graph. When the original state version and the candidate state version do not correspond, the processor does not confirm the inheritance relationship and continues to maintain the corresponding original bearer component; when there is an executable version conversion rule, the inheritance relationship is updated to be valid only after the conversion is completed and the candidate application instance confirms that the conversion result is usable.

[0052] When the establishment of a candidate bearer component requires the use of a data version, permission token, session identifier, or resource reservation result generated by another candidate bearer component, the processor establishes an establishment dependency between the corresponding candidate bearer components. For example, if a candidate application context component needs to read the data version provided by a candidate data access component, an establishment dependency is established between the candidate data access component and the candidate application context component; if a candidate operation control component needs to use a candidate session identifier and a candidate identity token, establishment dependencies are established between the candidate session component and the candidate identity and permission component and the candidate operation control component, respectively.

[0053] The processor establishes events based on the task identifier and event time, associating them with the states in the office event dataset. When the application processing or service call corresponding to a later state establishment event actually uses the data version, permission token, session identifier, or resource reservation result generated by a previous state establishment event, the processor supplements the establishment dependencies between the corresponding candidate carrier components. If there is only a time sequence but no output result usage relationship, no forced establishment dependency is established. When historical execution logs are missing, the processor forms initial establishment dependencies based on the current service call chain, application interface configuration, and the current state establishment process; candidate states whose establishment direction cannot be confirmed remain in the pending confirmation state.

[0054] The processor also establishes release dependencies for each original bearer component, recording the establishment state that the corresponding candidate bearer component needs to reach and the prerequisite relationship between this establishment state and the release of the original bearer component. The release dependency of the original identity and permission component can point to the candidate identity token being issued, the permission scope being verified, and the candidate operation session being bound; the release dependency of the original application context component can point to the candidate application context being loaded and its state version corresponding to the original state version. When a candidate bearer component has not reached the established state, the processor will keep the corresponding original bearer component in a maintained state and will not generate an executable release permission. The candidate configuration record, inheritance relationship table, establishment dependency table, and release dependency table formed in step S2 are then entered into step S3.

[0055] S3. Determine common failure relationships based on the underlying dependency objects pointed to by the established dependencies. Specifically, the processor extracts the data sources, service instances, authentication domains, network domains, and resource instances that actually participate in the state establishment along the establishment path and establishment dependencies of the candidate bearer components. It then divides the failure domains based on their deployment relationships and the scope of failure impact, and propagates the failure domain attributes to the candidate bearer components and candidate successor bearer configurations.

[0056] The processor extracts the data source identifier, service instance identifier, authentication domain identifier, network domain identifier, and resource instance identifier from dependency table creation, service call records, and state establishment events. The data source identifier determines the actual data storage instance that the candidate data access component actually connects to; the service instance identifier determines the application service that the candidate application context or session actually depends on; the authentication domain identifier determines the scope of authentication services that the candidate identity / permission component depends on; the network domain identifier determines the network area traversed during candidate state establishment and operation; and the resource instance identifier determines the computing, storage, or reserved resources actually occupied by the candidate resource component. A candidate bearer component can point to multiple underlying dependency objects simultaneously.

[0057] The processor reads the underlying dependency dataset and assigns underlying dependency objects that can be simultaneously interrupted by the same underlying failure event to the same failure domain. Multiple service instances deployed on the same physical host can be assigned to the same host failure domain; multiple candidate objects using the same network egress can be assigned to the same network failure domain; authentication instances using the same authentication database or the same token issuance service can be assigned to the same authentication failure domain; and multiple data connections depending on the same primary storage instance can be assigned to the same storage failure domain. Even if different underlying dependency objects have different object identifiers, they are also assigned to the same failure domain if the service deployment topology, network configuration, or verified historical failure records indicate that they can be simultaneously interrupted by the same failure event.

[0058] The processor propagates the failure domain attributes of the underlying dependent objects along the dependency establishment path to the candidate bearer components. The common failure relationship between any two candidate bearer components is determined according to equation (3):

[0059] (3)

[0060] In equation (3), and Indicates two candidate bearer components to be compared, subscript and Used only to distinguish different candidate bearer components; Indicates a state of joint failure relationship; Indicates candidate bearing components The set of failure domain attributes carried.

[0061] The data sources for failure domain attributes are the identifiers of the underlying dependent objects pointed to by the establishment path, service deployment topology, network topology, data master replica configuration, resource configuration, and verified historical fault records. The symbol ∩ represents the intersection of two failure domain attribute sets, and the symbol ∅ represents the empty set. The common failure relationship status is determined according to Equation (3) only when the failure domain attribute sets of the two candidate bearer components to be compared have been confirmed; when the two candidate bearer components have at least one common failure domain attribute, the common failure relationship status is 1; when both failure domain attribute sets have been confirmed and no common failure domain attribute has been identified, the common failure relationship status is 0. When the failure domain attribute set of any candidate bearer component is missing or is in a pending confirmation state, the common failure relationship status is not directly determined to be 0, but is recorded as a pending confirmation state, and the relevant original bearer component is maintained to enter the subsequent verification. Equation (3) does not take the same object name or instance number as the sole basis. When the underlying dependent objects have different identifiers but can be interrupted by the same fault event at the same time, a common failure relationship is still formed through failure domain affiliation.

[0062] The processor aggregates the failure domain attributes of candidate bearer components to the corresponding candidate replacement bearer configurations, and records the failure domains that the candidate replacement bearer configurations depend on according to their critical bearer functions. When two candidate replacement bearer configurations undertake the same critical bearer function, and their corresponding effective bearer paths are affected by the same failure domain, it is determined that the two candidate replacement bearer configurations have a common failure relationship on that critical bearer function. The common failure relationship is recorded separately according to the critical bearer functions, and the common failure state on a certain function is not directly extended to all functions undertaken by the candidate configurations.

[0063] If the underlying dependent object lacks a failure domain affiliation, the processor first generates a record of failure domains to be confirmed based on the deployment location, network path, primary / replica relationship, and resource affiliation. If the scope of the fault impact cannot be confirmed, the corresponding candidate path is not considered as an independent redundant path, and the relevant original bearer components are retained for subsequent verification. The failure domain attribute table and common failure relationship table generated in step S3 proceed to step S4.

[0064] S4. Construct a sustainable collaborative bearer succession domain. Specifically, the processor organizes the key bearer functions of the target stage, the original bearer components, the candidate bearer components, the candidate successor bearer configurations, and the aforementioned relationships into the same directed relation graph, and stores this directed relation graph as a shared relation instance corresponding to this succession batch, so that subsequent configuration retention judgments, original state maintenance judgments, and release boundary checks call the same version of relation data.

[0065] refer to Figure 3 As shown, the nodes in this directed graph include key bearer function nodes, original bearer component nodes, candidate bearer component nodes, candidate replacement bearer configuration nodes, and failure domain nodes. Key bearer function nodes represent the specific bearer functions required for the target phase; original bearer component nodes and candidate bearer component nodes represent the running status items in the original execution object and candidate replacement object, respectively; candidate replacement bearer configuration nodes represent the combination of candidate bearer components that jointly support the target phase; and failure domain nodes represent the fault range that can simultaneously affect one or more underlying dependent objects.

[0066] The directed edges in a directed graph include carrying edges, inheritance edges, dependency establishment edges, dependency release edges, and common failure edges. Carrying edges connect critical carrying function nodes to the original carrying component nodes, candidate carrying component nodes, or candidate replacement carrying configuration nodes that perform the critical carrying function. Inheritance edges connect original carrying component nodes to candidate carrying component nodes that can perform the same critical carrying function, and record the inheritance type and state version. Dependency establishment edges indicate the dependency direction of a candidate carrying component on other candidate carrying components or underlying dependent objects during the establishment process. Dependency release edges indicate that the establishment of a candidate carrying component is a prerequisite for the release of the corresponding original carrying component. Common failure edges connect failure domain nodes to candidate carrying component nodes and candidate replacement carrying configuration nodes affected by the failure domain. A configuration inclusion relationship is also recorded between a candidate carrying component node and its corresponding candidate replacement carrying configuration node, representing the candidate carrying components included in the candidate replacement carrying configuration and their compositional relationships. This configuration inclusion relationship is recorded as a compositional relationship record in a shared relationship instance and does not replace carrying edges, inheritance edges, dependency establishment edges, dependency release edges, or common failure edges.

[0067] The processor stores the aforementioned nodes and directed edges as shared relation instances. Each shared relation instance records at least the state of the original and candidate bearer components, the candidate successor bearer configuration, inheritance relationships, dependency establishment, dependency release, common failure relationships, critical bearer function coverage relationships, and the release status of the original bearer component. Shared relation instances can be stored in a graph database or represented by a node table, relation edge table, state table, and version table.

[0068] Each shared relationship instance has an instance identifier and an instance version. The instance identifier is used to associate the same office task succession, and the instance version is used to indicate the relationship state after the underlying dependency, candidate bearer component status, or original bearer component release status has been updated. The processor performs the retention judgment of the candidate successor bearer configuration, the maintenance judgment of the original bearer component, and the determination of the survival safety release boundary based on the same shared relationship instance, avoiding the use of states collected at different times for different judgments.

[0069] The processor starts from each critical bearer function node and searches for a relational path to the candidate replacement bearer configuration node along bearer edges, inheritance edges, and dependency establishment edges. When all candidate bearer components in the path are in an established state, the state version meets the inheritance requirements, the interface type matches, the dependency establishment is valid, and the corresponding candidate replacement bearer configuration has not been excluded, the relational path is determined as a valid bearer path. Multiple valid bearer paths can be formed for the same critical bearer function. The processor records the candidate bearer components, candidate replacement bearer configurations, and failure domain nodes traversed by each valid bearer path.

[0070] When the direction of dependency establishment cannot be confirmed, the corresponding relationship path will not be included in the set of valid bearer paths. When the states given by multiple data sources conflict, the server-side state that directly reflects the execution result will be used. The token verification result returned by the identity authentication server takes precedence over the login identifier cached by the terminal, and the resource reservation result returned by the resource scheduling service takes precedence over the resource request record on the application side. If the conflict cannot be eliminated, the corresponding path will be recorded as a path pending review, and the original bearer component that still provides valid bearer support will be retained.

[0071] S5. Determine the candidate replacement bearer configurations to be retained, the original bearer components to be maintained, and the survival safety release boundaries. Specifically, the processor determines the candidate replacement bearer configurations to be retained and the original bearer components to be maintained based on the impact of common failure relationships in shared relationship instances on the critical bearer function coverage relationships, and performs node deletion verification for the original bearer components to be released.

[0072] The processor retains candidate replacement bearer configurations that can collectively cover all critical bearer functions in the target phase. When multiple candidate replacement bearer configurations undertaking the same critical bearer function are all affected by the same common failure relationship, their formation of independent bearer paths cannot be determined solely based on the number of candidate objects. If a critical bearer function undertaken by a certain original bearer component does not yet have an established candidate bearer component, or if all existing candidate bearer paths are affected by the same common failure relationship, and the original bearer component still provides an effective bearer path unaffected by the common failure relationship, then the original bearer component is determined to be the original bearer component that needs to be maintained.

[0073] When a candidate bearer component has not reached the established state, the state version cannot complete inheritance, or the dependency release has not been satisfied, the processor still maintains the corresponding original bearer component. The candidate replacement bearer configurations to be retained and the original bearer components to be maintained are written to the shared relationship instance to limit the range of candidate paths used for node deletion verification.

[0074] For a given original bearer component node to be released, the processor sets a simulated deletion flag in the shared relationship instance, or copies the relationship subgraph related to the original bearer component to form a verification instance. The processor deletes the original bearer component node to be released, along with the bearer edges, inherited edges, and release dependency edges connected to that node, in the verification instance, and then re-searches for valid bearer paths corresponding to each critical bearer function. The survival and safe release status of the original bearer component is determined according to equation (4):

[0075] (4)

[0076] In equation (4), This indicates the sustainable collaborative bearer replacement domain corresponding to the current replacement batch, specifically the shared relationship instance of the current version; This indicates the original carrying component node that is currently to be judged; Indicates the original load-bearing component In shared relationship instances The state of safe release in the context of existence, where the vertical line indicates a judgment is made under the current relationship state, and does not represent division.

[0077] In equation (4), This represents the set of key supporting functions required for the target phase. This represents any key carrying function in the set; This indicates the simulation of deleting the original carrier component node. Following its related edges, key carrying functions The corresponding set of valid bearer paths, superscript It indicates the relationship state after a node is deleted, but does not represent negative numbers or exponential operations; Represents the set of failure domains in a shared relation instance; Represents any failure domain; Indicates any valid bearer path; Indicates the effective bearer path The set of failure domain attributes involved.

[0078] The symbol ∀ represents all objects in the set, ∄ represents non-existence, and ∅ represents an empty set. The first condition in equation (4) indicates that after deleting the corresponding original bearer component, each critical bearer function still has at least one valid bearer path; the second condition indicates that there is no failure domain that can simultaneously affect all valid bearer paths of any critical bearer function. The set of valid bearer paths originates from the path search performed on the shared relationship instance in step S4. For any valid bearer path... Its failure domain attribute set The failure domain attributes associated with the candidate bearer components and candidate successor bearer configurations traversed by the path are merged. The failure domain attributes of the candidate successor bearer configuration are formed by aggregating the failure domain attributes of the candidate bearer components it contains and their direct underlying dependent objects.

[0079] When both conditions of equation (4) are met, the processor records the survival security release state of the corresponding original bearer component as 1 and generates a survival security release boundary; when either condition is not met, the state is recorded as 0, and the corresponding original bearer component continues to be maintained. If a critical bearer function does not have a valid bearer path, it waits for or re-establishes a candidate bearer component to undertake the function; if all valid paths are affected by the same failure domain, it enters the search for alternative underlying dependency objects; if the path is invalid due to state version, interface type, or failure to establish dependencies, it updates the state of the corresponding candidate bearer component and re-verifies. The output of equation (4) directly forms the release, maintenance, and dependency replacement flow, and is not stored as an independent scoring result.

[0080] The survivability release boundary represents the state condition under which the corresponding original bearer component can be released in the current shared relationship instance state, and is not limited to a fixed point in time. The boundary record may include the original bearer component identifier, the release dependency satisfaction status, the shared relationship instance version on which the verification is based, the valid bearer path identifier, the common failure verification result, the release pre-event, the boundary generation time, and the current boundary state. When the shared relationship instance version has not changed and the release dependency continues to be satisfied, the boundary is in an executable state; when the underlying dependent object, failure domain affiliation, candidate bearer component establishment status, or common failure relationship changes, the boundary that has not yet been executed enters a pending review state.

[0081] When the office event flow indicates a change in the underlying dependent object, the establishment of dependencies, or a common failure relationship, the processor obtains the changed underlying dependency identifier or failure domain attribute and propagates it along the establishment of dependencies edges in the shared relationship instance to the corresponding candidate bearer component nodes. It then updates the failure domain attributes, common failure edges, and critical bearer function coverage relationships of the candidate successor bearer configuration nodes. The propagation scope can be limited to the relationship subgraph affected by the changed object; other candidate bearer components that do not depend on this object retain their original state.

[0082] The processor redetermines the candidate replacement bearer configurations to be retained and the original bearer components to be maintained based on the updated coverage relationship, and re-executes node deletion verification on the unexecuted survivability release boundaries. Boundaries that have passed the verification but no longer satisfy equation (4) after the update are marked as invalid; original bearer components that have failed the verification but satisfy equation (4) after the update can generate new boundaries. The above process of re-executing node deletion verification based on the updated coverage relationship and marking the unexecuted survivability release boundaries as still valid, invalid, or regenerated constitutes a reverse correction of the unexecuted survivability release boundaries. Release actions that have been completed are not restored to the unreleased state through boundary reverse correction, and their subsequent processing re-establishes the missing bearer state based on the currently available candidate configurations.

[0083] refer to Figure 4 As shown, when all candidate replacement bearer configurations undertaking the same critical bearer function are affected by the same common failure relationship, the processor searches for alternative underlying dependency objects from the service registry, candidate object configuration table, or resource directory. The alternative underlying dependency object must be able to undertake the corresponding critical bearer function, its interface type must match the candidate bearer component corresponding to the replaced underlying dependency object, and it must not be affected by the current common failure relationship. The processor replaces the corresponding establishment dependency of one of the candidate replacement bearer configurations with the alternative underlying dependency object, re-executes the establishment process of the candidate bearer component, and updates the common failure relationship and coverage relationship of that candidate replacement bearer configuration.

[0084] When all key bearer functions in the target phase have valid bearer paths, the same common failure relationship cannot simultaneously affect all valid bearer paths of any key bearer function, and the original bearer component to be released no longer provides an irreplaceable valid bearer path, the processor determines that the sustainable collaborative bearer replacement domain has reached a stable state. After reaching a stable state, the processor stops the current round of underlying dependency object search and unexecuted boundary correction, and inputs the sustainable safe release boundary in the executable state into step S6. When there is no replacement object with matching interface and different failure domain in the field, the processor retains the corresponding common failure relationship and the original bearer component to be maintained.

[0085] S6. Release the original bearer component according to the survival safety release boundary and switch the operation control state. Specifically, before executing the release, the processor verifies the version of the shared relationship instance and the release dependency state on which the survival safety release boundary is based; if the boundary remains valid, it sends the corresponding release instruction to the original execution object, and switches the operation control state of the target stage after the candidate replacement bearer configuration that needs to be retained reaches the operable state.

[0086] The processor reads the shared relationship instance version from the surviving safe release boundary record and compares it with the current shared relationship instance version. If the two versions match, the release dependency continues to be satisfied, and the corresponding candidate bearer component is still in the established state, the boundary is determined to be executable; if the instance versions are inconsistent, the release dependency fails, or the candidate bearer component's state changes, the corresponding original bearer component is not released, but the boundary is returned to step S5 for re-verification.

[0087] The processor sends a release command to the corresponding original execution object based on the bearer function type of the original bearer component. For the original data access component, the release action can be closing the original data connection, releasing the original data write lock, or revoking the original data write permission; for the original application context component, the release action can be clearing the temporary context in the original application instance or setting the original application context to read-only archive state; for the original session connection component, the release action can be closing the original session or stopping the original session keep-alive; for the original identity and permission component, the release action can be revoking the original identity token, reducing the original permission scope, or unbinding the original identity from the office task to be taken over; for the original terminal running component, the release action can be closing the task process in the original office terminal or removing its running association with the task; for the original resource occupancy component, the release action can be releasing computing resources, storage resources, network resources, or reserved resources.

[0088] After the original execution object executes the release instruction, it returns an execution result via the office status interface indicating whether the release is complete, failed, or has an uncertain status. The processor writes the execution result back to the shared relationship instance and the execution feedback dataset. If the release execution end does not return confirmation, or if the corresponding status is still detected as valid after release, the original bearer component is recorded as having an uncertain release status. Subsequent release actions that depend on this release result are not executed, and a status review is triggered.

[0089] When the candidate replacement bearer configurations to be retained cover all critical bearer functions of the target phase, the candidate bearer component undertaking operation control functions has reached the established state, and the corresponding survival security release boundary is in a valid state, the processor sends a control switching command to the candidate office terminal, candidate application instance, or operation control service. The control switching command carries the task identifier, target phase identifier, candidate replacement bearer configuration identifier, current state version, and control activation information.

[0090] After the candidate execution object confirms that it has obtained the operation control status of the target stage, it returns the confirmation result to the processor through the office status interface. The processor updates the original operation control component to the released state, updates the candidate operation control component to the active state, and updates the target stage to the executable state. When the candidate replacement bearer configuration cannot obtain the operation control status, the original bearer components that have not yet been released continue to be retained; the bearer functions that have been released and need to be re-established are handled by the processor calling other candidate replacement bearer configurations that need to be retained or re-establishing the corresponding candidate bearer components. This replacement is not recorded as completed before the control switch is completed.

[0091] After completing the operation control state switch, the processor writes the state establishment event, inheritance relationship, dependency establishment, common failure relationship, node deletion verification result, survival safety release boundary, release result, and control switch result formed during this switch to the historical execution log. Subsequent office tasks of the same type can call the key bearer function configuration, candidate configuration combination method, and failure domain mapping record in the historical stable switch batch, but the aforementioned process should still be re-executed according to the actual object identifier, state version, effective range, and current underlying dependency state of the subsequent task. Switch batches that experience state loss, inability to eliminate common failure relationships, failure of node deletion verification, or failure of operation control switch are recorded as abnormal batches, and their release boundaries are not directly migrated to subsequent tasks.

[0092] In one specific embodiment, a complete execution cycle is illustrated by taking the transfer of a contract review and approval task from the contract drafting stage to the legal review stage. The task identifier for the office task to be transferred is T001, and the transfer batch identifier is B001. The original execution objects include the original office terminal A, the original application instance App-A, the original session Session-A, the original identity token Token-A, the original data connection Data-A, and the original resource instance Resource-A.

[0093] The system contains candidate office terminal B and candidate office terminal C. Candidate office terminal B can connect to candidate application instance App-B, the first authentication service Auth-1, the first data copy Store-1, and the first resource instance Res-1; candidate office terminal C can connect to candidate application instance App-C, the first authentication service Auth-1, the second data copy Store-2, and the second resource instance Res-2. The office status interface collects terminal online status and session keep-alive status at preset intervals, and uses event-triggered collection for identity token issuance, data version generation, resource reservation confirmation, and operation control switching.

[0094] Based on the task operations during the legal review phase, the processor determines the key bearer functions required for this handover: data access, application context maintenance, session connection, identity and authorization, terminal operation, resource usage, and operation control. The office status interface collects data showing that Store-1 and Store-2 both store contract version V18, App-B and App-C can load contract version V18, office terminals B and C are both online, and Res-1 and Res-2 can provide the resources required for legal review. Based on this, the processor extracts candidate bearer components and forms candidate replacement bearer configurations C1 and C2.

[0095] Candidate successor configuration C1 uses office terminal B, App-B, Auth-1, Store-1, and Res-1; candidate successor configuration C2 initially uses office terminal C, App-C, Auth-1, Store-2, and Res-2. Contract version V18 establishes a direct inheritance relationship with the original data access components. App-B and App-C load contract version V18 to form a successor-side reconstruction relationship. Candidate sessions and original sessions form an object rebinding relationship. Res-1 and Res-2 form a functionally equivalent replacement relationship with the original resource instances.

[0096] Office event data indicates that both App-B and App-C use contract version V18 when establishing application contexts. The establishment of candidate operation control states requires the use of candidate session identifiers and candidate identity tokens. Based on this, the processor establishes the establishment dependencies from data access components to application context components, candidate session components, and candidate identity and permission components to candidate operation control components, and also establishes the release dependencies of the corresponding original bearer components.

[0097] The underlying dependency data indicates that Store-1 and Store-2 are located in different storage failure domains, and office terminal B and office terminal C are located in different terminal failure domains. However, the identity and permission components of the candidate successor bearer configurations C1 and C2 both depend on Auth-1, and the two have a common failure relationship in identity and permission functions. The processor constructs a shared relationship instance G-B001-V1 and performs node deletion verification for the original identity and permission components. After simulating the deletion of the original identity and permission components, although there are two candidate paths for identity and permission functions, one through C1 and the other through C2, both paths are affected by the authentication failure domain to which Auth-1 belongs. Therefore, the original identity and permission components continue to be maintained.

[0098] The processor locates the second authentication service, Auth-2, in the service registry. Auth-2 supports a token interface that matches Auth-1 but resides in a different authentication expiration domain. The processor replaces the authentication establishment dependency in the candidate successor bearer configuration C2 with Auth-2, establishes a new candidate identity and permission component through Auth-2, and updates the shared relationship instance to G-B001-V2 after token issuance and permission verification. At this point, the identity and permission path of C1 passes through the authentication expiration domain of Auth-1, and the identity and permission path of C2 passes through the authentication expiration domain of Auth-2.

[0099] The processor performs node deletion verification again on the original identity and permission component. After simulating the deletion of the original bearer component, the identity and permission function still has two valid bearer paths, and no single authentication failure domain can affect both paths simultaneously. Therefore, a security release boundary for the original identity and permission component is generated. The processor continues to perform the same verification on the original data access component, original application context component, original session connection component, original resource occupancy component, original terminal running component, and original operation control component, and forms release boundaries based on their respective valid bearer paths and failure domain states.

[0100] Before executing the release, the processor confirms that the current shared relationship instance is still G-B001-V2 and that all release dependencies remain satisfied. The processor revokes Token-A, closes Data-A, releases Resource-A, ends Session-A, and removes the operational control state of office terminal A over task T001. The processor sends an operational control switching instruction to candidate replacement bearer configuration C1, keeping candidate replacement bearer configuration C2 as a sustainable candidate configuration. After office terminal B confirms that it has obtained the operational control state of task T001, the processor updates the legal review stage to an executable state and writes the execution result to the shared relationship instance and historical execution log.

[0101] In this embodiment, the key carrying functions of the target stage and their corresponding relationships can be determined based on the enterprise's office process procedures, application operation procedures, permission management specifications, and application interface documents. The status fields, establishment completion flags, and release completion flags of the carrying components can be determined based on the status interfaces that can be provided by the office application server, identity authentication server, data storage server, resource scheduling service, and office terminals.

[0102] The valid state interval can be determined based on the session retention time, identity token validity period, resource reservation period, application instance lease, and expected operation time of the target stage in historical stable succession batches. If the valid interval is shorter than the minimum execution time required for candidate session establishment, application context loading, and operation control state switching, the corresponding running state item will not be considered as a directly usable candidate bearer component. This minimum execution time is determined based on trial operation records, historical stable succession batches, and the actual response time of each service interface.

[0103] Failure domain partitioning rules can be determined based on service deployment topology, network area configuration, data primary / replica configuration, authentication domain configuration, resource area configuration, and historical failure records verified manually. Abnormal batches, manually rolled-back batches, and batches whose failure causes cannot be confirmed are not directly used as the basis for updating stable failure domain mappings. Dependency creation and release can be determined based on application call chains, office event flows, historical stable execution records, abnormal execution records, on-site verification records, and trial operation records.

[0104] The status collection cycle is determined based on the update frequency of the server monitoring interface, the minimum identifiable status change of the office terminal, the response time of the identity authentication service, and the allowed switching time for operation control status. Identity token issuance, resource reservation confirmation, data version generation, and operation control switching can be event-triggered data collection, while terminal online status and session keep-alive status can be collected periodically. The selection range for alternative underlying dependency objects is determined based on the available authentication domains, network domains, data copies, application service instances, and resource area adjustment capabilities on-site. When only one available underlying dependency object exists on-site, the processor retains the corresponding common failure relationships and the original bearer components that need to be maintained.

[0105] Example 2

[0106] Please see Figure 1 This embodiment provides a fully collaborative digital office intelligent management system. The system includes an office status interface, a processor, and a memory. The office status interface is communicatively connected to an office application server, an identity authentication server, a data storage server, and an office terminal, respectively. The memory stores computer programs.

[0107] The office status interface receives task stage data, runtime status data, office event data, underlying dependency data, and release execution feedback. The processor obtains the current stage and target stage of the office task to be replaced through the office status interface, determines the key carrying functions based on the task operation of the target stage, and extracts the original carrying components and candidate carrying components from the runtime status of the original execution object and the candidate replacement object.

[0108] The processor forms a candidate successor bearer configuration based on the key bearer functions undertaken by the candidate bearer components and their establishment path combinations, and establishes inheritance relationships, establishes dependencies, and releases dependencies. The processor determines the failure domain attributes and common failure relationships based on the underlying dependency objects pointed to by the established dependencies, and then constructs a sustainable collaborative bearer successor domain based on the original bearer components, candidate successor bearer configurations, inheritance relationships, release dependencies, common failure relationships, and coverage relationships.

[0109] The memory stores the sustainable collaborative bearer succession domain as a shared relation instance, and records node data, relation edge data, state data, instance version, and the release status of the original bearer component. The processor performs the retention judgment of the candidate successor bearer configuration, the maintenance judgment of the original bearer component, and the determination of the sustainable safe release boundary based on the same shared relation instance.

[0110] When the office event flow indicates a change in the underlying dependent objects, the establishment of dependencies, or a common failure relationship, the processor propagates the changed failure domain attributes along the establishment dependencies in the shared relationship instance, updates the candidate bearer component nodes, candidate replacement bearer configuration nodes, common failure edges, and critical bearer function coverage relationships, and re-verifies the survivability safety release boundaries that have not yet been executed. When all candidate replacement bearer configurations undertaking the same critical bearer function are affected by the same common failure relationship, the processor searches for an alternative underlying dependent object with a matching interface type that is not affected by the common failure relationship, and re-establishes the corresponding candidate bearer component.

[0111] After the processor determines that the sustainable collaborative bearer successor domain has reached a stable state, it sends a release command to the original executing object through the office state interface and an operation control state switching command to the candidate successor bearer configurations that need to be retained. The office state interface receives the release result and the control switching result, and the processor updates the shared relationship instance and execution feedback dataset according to the result.

[0112] The computer program stored in the memory may include state acquisition instructions, carrier component processing instructions, candidate configuration processing instructions, dependency processing instructions, shared relationship instance processing instructions, node deletion verification instructions, and execution control instructions. These instructions can be executed by the same processor or by multiple communicating processors.

[0113] The computer program can also be stored in a computer-readable storage medium. This computer-readable storage medium can be a read-only memory, random access memory, solid-state memory, magnetic disk, optical disk, or other non-transitory storage medium capable of storing the computer program. When the computer program is executed by a processor, it implements the global collaborative digital office scheduling method described in Example 1.

[0114] The above description is merely a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Equivalent substitutions or modifications made by those skilled in the art based on the disclosure of the present invention should all fall within the scope of protection of the present invention.

Claims

1. A method for scheduling collaborative digital office work across all domains, characterized in that, include: S1. Based on the current stage and target stage of the office tasks to be taken over, determine the key carrying functions of the target stage, and extract the original carrying components and candidate carrying components that undertake the key carrying functions from the running status of the original execution object and multiple candidate replacement objects. S2. According to the key bearing functions undertaken by the candidate bearing components and their establishment paths, the candidate bearing components that jointly support the target stage are combined into candidate successor bearing configurations, and the inheritance relationship between the original bearing components and the candidate bearing components, the establishment dependency between the candidate bearing components and the release dependency of the original bearing components are established, and the coverage relationship of the candidate successor bearing configuration to the key bearing functions is determined. S3. Based on the underlying dependency object of the established dependency, determine the common failure relationship between the candidate bearer components and the candidate successor bearer configurations; S4. Based on the original bearing components, candidate successor bearing configurations, inheritance relationships, release dependencies, common failure relationships, and coverage relationships of key bearing functions, construct a sustainable collaborative bearing succession domain; S5. Based on the impact of the common failure relationship in the sustainable collaborative bearing succession domain on the coverage relationship, determine the candidate succession bearing configurations to be retained and the original bearing components to be maintained. After verification and determination that the corresponding original bearing components are released, if each key bearing function in the target stage still has candidate succession bearing configurations that are not simultaneously affected by the same common failure relationship, determine the survival safety release boundary of the corresponding original bearing components. S6. Release the corresponding original load-bearing component according to the survival safety release boundary, and switch the operation control state of the target stage to the candidate replacement load-bearing configuration to be retained.

2. The method for scheduling full-domain collaborative digital office work according to claim 1, characterized in that, The key bearer functions include data access functions, application context maintenance functions, session connection functions, identity and permission functions, terminal operation functions, resource usage functions, and operation control functions required for the target stage task operation. The running status item that has a direct bearing relationship with the corresponding task operation and whose effective range covers the corresponding task operation segment is determined as the original bearing component or candidate bearing component. The original bearing component and candidate bearing component respectively carry the object identifier, status version, bearing function identifier and effective range.

3. The method for scheduling full-domain collaborative digital office work according to claim 1, characterized in that, The inheritance relationships include direct inheritance, object rebinding, successor-side reconstruction, state form conversion, and functional equivalence substitution. For each original bearing component, a candidate bearing component is determined to undertake the same key bearing function. The establishment state of the candidate bearing component and the release of the corresponding original bearing component are established, and the corresponding original bearing component is maintained when the candidate bearing component has not reached the established state.

4. The method for scheduling full-domain collaborative digital office work according to claim 1, characterized in that, This also includes supplementing the dependency establishment based on the office event flow and historical execution logs: The state establishment events of the bearer components are associated according to the task identifier and time sequence. When the application processing or service call corresponding to the later state establishment event uses the data version, permission token, session identifier or resource reservation result generated by the previous state establishment event, the dependency is supplemented between the corresponding candidate bearer components. Extract the data source identifier, service instance identifier, authentication domain identifier, network domain identifier, and resource instance identifier corresponding to each state establishment event. When multiple establishment dependencies point to the same underlying dependency object or can be interrupted simultaneously by the same underlying failure event, determine the candidate bearer components associated with the multiple establishment dependencies as having a common failure relationship, and determine the common failure relationship between the corresponding candidate successor bearer configurations accordingly.

5. The method for scheduling full-domain collaborative digital office work according to claim 4, characterized in that, Low-level dependent objects that can be interrupted simultaneously by the same low-level fault event are classified into the same failure domain, and the failure domain attributes of the low-level dependent objects are propagated along the corresponding established dependencies to the candidate bearer components and candidate successor bearer configurations. The sustainable collaborative bearing succession domain is represented by a directed relation graph. The nodes of the directed relation graph include key bearing function nodes, original bearing component nodes, candidate bearing component nodes, candidate succession bearing configuration nodes, and failure domain nodes. The directed edges include bearing edges, inheritance edges, dependency establishment edges, dependency release edges, and common failure edges. For the original bearing component node to be released, perform node deletion verification. When the original bearing component node is deleted, there is still a valid bearing path between each key bearing function node and at least one candidate replacement bearing configuration node, and there is no failure domain node that is associated with all the valid bearing paths of the corresponding key bearing function node through a common failure edge. Then the original bearing component is determined to have reached the survival safety release boundary. When the underlying dependency object or failure domain affiliation changes, the changed underlying dependency identifier or failure domain attribute is propagated along the established dependency edge to update the failure domain attributes, common failure edges and coverage relationships of the corresponding candidate bearer component nodes and candidate successor bearer configuration nodes, and the node deletion verification is re-executed for the existing safe release boundary that has not yet been executed.

6. A fully collaborative digital office intelligent management system, characterized in that, The system includes an office status interface, a processor, and a memory. The office status interface is communicatively connected to an office application server, an identity authentication server, a data storage server, and an office terminal. The memory stores a computer program, and the processor, when executing the computer program, is configured to: Based on the current and target stages of the tasks to be taken over, the key carrying functions of the target stage are determined, and the original carrying components and candidate carrying components are extracted from the running status of the original execution object and multiple candidate replacement objects. Based on the key carrying functions undertaken by the candidate carrying components and their establishment paths, the candidate carrying components that jointly support the target stage are combined into candidate successor carrying configurations, and inheritance relationships, dependencies and release dependencies are established to determine the coverage relationship of the candidate successor carrying configurations to the key carrying functions. Based on the underlying dependency object to which the dependency is established, the common failure relationship between the candidate bearer components and the candidate successor bearer configuration is determined; Based on the original load components, candidate successor load configurations, inheritance relationships, release dependencies, common failure relationships, and coverage relationships of key load functions, a sustainable collaborative load succession domain is constructed. Based on the impact of the common failure relationship on the coverage relationship, the candidate replacement bearing configurations to be retained and the original bearing components to be maintained are determined. After verification and confirmation that the corresponding original bearing components are released, if each key bearing function in the target stage still has a candidate replacement bearing configuration that is not simultaneously affected by the same common failure relationship, the survival safety release boundary of the corresponding original bearing components is determined. The release of the corresponding original bearing components and the switching of the operation control state in the target stage are controlled according to the survival safety release boundary.

7. The intelligent management system for full-domain collaborative digital office as described in claim 6, characterized in that, The processor stores the sustainable collaborative bearer successor domain as a shared relationship instance; The shared relationship instance at least records the status of the original bearer component and the candidate bearer component, the candidate successor bearer configuration, the inheritance relationship, the establishment of dependencies, the release of dependencies, the common failure relationship, the coverage relationship of the key bearer function, and the release status of the original bearer component; The processor performs the following actions based on the same shared relationship instance: determining the retention of candidate successor bearer configurations, the maintenance of original bearer components, and the determination of the survival safety release boundary.

8. The intelligent management system for full-domain collaborative digital office as described in claim 7, characterized in that, The processor is also configured to: When the office event flow indicates that the underlying dependent object, the establishment dependency, or the common failure relationship has changed, the changed underlying dependency identifier or failure domain attribute is propagated along the establishment dependency in the shared relationship instance to the corresponding candidate bearer component and candidate successor bearer configuration, and the coverage relationship of the common failure relationship and the key bearer function is updated. Based on the updated coverage relationship, the candidate replacement bearing configurations to be retained and the original bearing components to be maintained are re-determined, and the remaining safety release boundaries that have not yet been implemented are reversed.

9. The intelligent management system for full-domain collaborative digital office as described in claim 8, characterized in that, When all candidate replacement bearer configurations that undertake the same critical bearer function are affected by the same common failure relationship, the processor determines an alternative underlying dependency object that can undertake the critical bearer function, matches the interface type of the corresponding candidate bearer component, and is not affected by the common failure relationship. The processor replaces the corresponding establishment dependency of one of the candidate replacement bearer configurations with the alternative underlying dependency object and redetermines the common failure relationship and coverage relationship of the candidate replacement bearer configuration. When each key bearing function in the target phase has an effective bearing path, the same common failure relationship cannot simultaneously affect all effective bearing paths of any key bearing function, and the original bearing component to be released no longer provides an irreplaceable effective bearing path, the sustainable collaborative bearing succession domain is determined to have reached a stable state.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the full-domain collaborative digital office scheduling method according to any one of claims 1 to 5.

Images